>>Hello, and welcome. Very excited to see everybody here. DockerCon is going fantastic. Everybody's uh, engaging in the chat. It's awesome to see. My name is Peter McKee. I'm the head of developer relations here at Docker and Taber. Today. We're going to be talking about container first development now and in the future. But before we do that, a couple little housekeeping items, first of all, yes, we are live. So if you're in our session, you can go ahead and chat, ask us questions. We'd love to get all your questions and answer them. Um, if you come to the main page on the website and you do not see the chat, go ahead and click on the blue button and that'll die. Uh, deep dive you into our session and you can interact with the chat there. Okay. Without further ado, let's just jump right into it. Katie, how are you? Welcome. Do you mind telling everybody who you are and a little bit about yourself? >>Absolutely. Hello everyone. My name is Katie and currently I am the eco-system advocate at cloud native computing foundation or CNCF. My responsibility is to lead and represent the end-user community. So these are all the practitioners within the cloud native space that are vendor neutral. So they use cloud native technologies to build their services, but they don't sell it. So this is quite an important characteristic as well. My responsibility is to make sure to close the gap between these practitioners and the project maintainers, to make sure that there is a feedback loop around. Um, I have many roles within the community. I am on the advisory board for KIPP finishes, a sandbox project. I'm working with open UK to make sure that Elton standards are used fairly across data, hardware, and software. And I have been, uh, affiliated way if you'd asked me to make sure that, um, I'm distributing a cloud native fundamental scores to make cloud and they do a few bigger despite everyone. So looking forward to this panel and checking with everyone. >>Awesome. Yeah. Welcome. Glad to have you here. Johanna's how are you? Can you, uh, tell everybody a little bit about yourself and who you are? Yeah, sure. >>So hi everybody. My name is Johannes I'm one of the co-founders at get pot, which in case you don't know is an open-source and container based development platform, which is probably also the reason why you Peter reached out and invited me here. So pleasure to be here, looking forward to the discussion. Um, yeah, though it is already a bit later in Munich. Um, and actually my girlfriend had a remote cocktail class with her colleagues tonight and it took me some stamina to really say no to all the Moscow mules that were prepared just over there in my living room. Oh wow. >>You're way better than me. Yeah. Well welcome. Thanks for joining us. Jerome. How are you? Good to see you. Can you tell everybody who you are and a little bit about yourself? Hi, >>Sure. Yeah, so I'm, I, I used to work at Docker and some, for me would say I'm a container hipster because I was running containers in production before it for hype. Um, I worked at Docker before it was even called Docker. And then since 2018, I'm now a freelancer and doing training and consulting around Docker containers, Kubernetes, all these things. So I used to help folks do stuff with Docker when I was there and now I still have them with containers more generally speaking. So kind of, uh, how do we say same, same team, different company or something like that? Yeah. >>Yeah. Perfect. Yeah. Good to see you. I'm glad you're on. Uh, Jacob, how are you? Good to see you. Thanks for joining us. Good. Yeah. Thanks for having me tell, tell everybody a little bit about yourself who you are. >>Yeah. So, uh, I'm the creator of a tool called mutagen, which is an open source, uh, development tool for doing high performance file synchronization and, uh, network forwarding, uh, to enable remote development. And so I come from like a physics background where I was sort of always doing, uh, remote developments, you know, whether that was on a big central clusters or just like some sort of local machine that was a bit more powerful. And so I, after I graduated, I built this tool called mutagen, uh, for doing remote development. And then to my surprise, people just started using it to use, uh, with Docker containers. And, uh, that's kind of grown into its primary use case now. So I'm, yeah, I've gotten really involved with the Docker community and, uh, talked with a lot of great people and now I'm one of the Docker captains. So I get to talk with even more and, and join these events and yeah, but I'm, I'm kind of focused on doing remote development. Uh, cause I, you know, I like, I like having all my tools available on my local machine, but I also like being able to pull in a little bit more powerful hardware or uh, you know, maybe a software that I can't run locally. And so, uh, that's sort of my interest in, in Docker container. Yeah. Awesome. >>Awesome. We're going to come back to that for sure. But yeah. Thank you again. I really appreciate you all joining me and yeah. So, um, I've been thinking about container first development for a while and you know, what does that actually mean? So maybe, maybe we can define it in our own little way. So I, I just throw it out to the panel. When you think about container first development, what comes to mind? What w what, what are you kind of thinking about? Don't be shy. Go ahead. Jerome. You're never a loss of words >>To me. Like if I go back to the, kind of the first, uh, you know, training engagements we did back at Docker and kind of helping folks, uh, writing Dockerfiles to stop developing in containers. Um, often we were replacing, um, uh, set up with a bunch of Vagrant boxes and another, like the VMs and combinations of local things. And very often they liked it a lot and they were very soon, they wanted to really like develop in containers, like run this microservice. This piece of code is whatever, like run that in containers because that means they didn't have to maintain that thing on their own machine. So that's like five years ago. That's what it meant to me back then. However, today, if you, if you say, okay, you know, developing in containers, um, I'm thinking of course about things like get bought and, uh, I think it's called PR or something like that. >>Like this theme, maybe that thing with the ESCO, that's going to run in a container. And you, you have this vs code thing running in your browser. Well, obviously not in your browser, but in a container that you control from your browser and, and many other things like that, that I, I think that's what we, where we want to go today. Uh, and that's really interesting, um, from all kinds of perspectives, like Chevy pair pairing when we will not next to each other, but actually thousands of miles away, um, or having this little environment that they can put aside and come back to it later, without it having using resource in my machine. Um, I don't know, having this dev service running somewhere in the cloud without needing something like, it's at the rights that are like the, the possibilities are really endless. >>Yeah. Yeah. Perfect. Yeah. I'm, you know, a little while ago I was, I was torn, right. W do I spin up containers? Do I develop inside of my containers? Right. There's foul sinking issues. Um, you know, that we've been working on at Docker for a while, and Jacob is very, very familiar with those, right? Sometimes it, it becomes hard, but, and I, and I love developing in the cloud, but I also have this screaming, you know, fast machine sitting on my desktop that I think I should take advantage of. So I guess another question is, you know, should we be developing inside of containers? Is that a smart thing to do? Uh, I'd love to hear you guys' thoughts around that. >>You know, I think it's one of those things where it's, you know, for me container first development is really about, um, considering containers as sort of a first class citizen in, in terms of your development toolkit, right. I mean, there's not always that silver bullet, that's like the one thing you should use for everything. You know, you shouldn't, you shouldn't use containers if they're not fitting in or adding value to your workflow, but I think there's a lot of scenarios that are like, you know, super on super early on in the development process. Like as soon as you get the server kind of running and working and, you know, you're able to access it, you know, running on your local system. Uh that's I think that's when the value comes in to it to add containers to, you know, what you're doing or to your project. Right. I mean, for me, they're, um, they're more of a orchestrational tool, right? So if I don't have to have six different browser tabs open with like, you know, an API server running at one tab and a web server running in another tab and a database running in another tab, I can just kind of encapsulate those and, and use them as an automation thing. So I think, you know, even if you have a super powerful computer, I think there's still value in, um, using containers as, as a orchestrational mechanism. Yeah. Yeah, >>For sure. I think, I think one of the, one of my original aha moments with Docker was, oh, I can spin up different versions of a database locally and not have to install it and not have to configure it and everything, but, you know, it just ran inside of a container. And that, that was it. Although it's might seem simple to some people that's very, very powerful. Right. So I think being able to spin things up and containers very quickly is one of the super benefits. But yeah, I think, uh, developing in containers is, is hard right now, right. With, um, you know, and how do you do that? Right. Does anybody have any thoughts around, how do you go about that? Right. Should you use a container as just a development environment, so, you know, creating an image and then running it just with your dev tools in it, or do you just, uh, and maybe with an editor all inside of it, and it's just this process, that's almost like a VM. Um, yeah. So I'll just kick it back to the panel. I'd love to hear your thoughts on, you know, how do you set up and configure, uh, containers to develop in any thoughts around that? >>Maybe one step back again, to answer your question, what kind of container first development mean? I think it doesn't mean, um, by default that it has to be in the cloud, right? As you said, um, there are obvious benefits when it comes to the developer experience of containers, such as, I dunno, consistency, we have standardized tools dependencies for the dev side of things, but it also makes their dev environment more similar to all the pipeline that is somehow happening to the right, right. So CIC D all the way to production, it is security, right? Which also somehow comes with standardization. Um, but vulnerability scanning tools like sneak are doing a great job there. And, um, for us, it gets pod. One of the key reasons why we created get pod was literally creating this peace of mind for deaths. So from a developer's point of view, you do not need to take care anymore about all the hassle around setups and things that you will need to install. >>And locally, based on some outdated, REIT me on three operating systems in your company, everybody has something different and leading to these verbs in my machine situations, um, that really slow professional software developers down. Right. Um, back to your point, I mean, with good pod, we obviously have to package everything together in one container because otherwise, exactly the situation happens that you need to have five browser tabs open. So we try and leverage that. And I think a dev environment is not just the editor, right? So a dev environment includes your source code. It includes like a powerful shell. It includes file systems. It includes essentially all the tools you need in order to be productive databases and so on. And, um, yeah, we believe that should be encapsulated, um, um, in a container. >>Yeah. Awesome. Katie, you talked to a lot of end users, right. And you're talking to a lot of developers. What, what's your thoughts around container first development, right? Or, or what's the community out there screaming or screaming. It might be too to, uh, har you know, to, to two grand of the word. Right. But yeah, I love it. I love to hear what your, your thoughts. >>Absolutely. So I think when you're talking about continuing driven development, uh, the first thing that crosses my mind is the awareness of the infrastructure or the platform you're going to run your application on top of, because usually when you develop your application, you'd like to replicate as much as possible the production or even the staging environment to make sure that when you deploy your application, you have us little inconsistencies as possible, but at the same time, you minimize the risk for something to go wrong as well. So when it talking about the, the community, um, again, when you deploy applications and containers and Kubernetes, you have to use, you have awareness about, and probably apply some of the best practices, like introducing liveliness and readiness probes, to make sure that your application can restart in, in case it actually goes down or there's like a you're starving going CPU or something like that. >>So, uh, I think when it comes to deployment and development of an application, the main thing is to actually improve the end developer experience. I think there has been a lot of focus in the community to develop the tool, to actually give you the right tool to run application and production, but that doesn't necessarily, um, go back to how the end developer is actually enabling that application to run into that production system. So I think there has been, uh, this focus for the community identified now, and it's more, more, um, or trying to build momentum on enhancing the developer experience. And we've seen this going through many, uh, where we think production of many tools did what has been one of them, which actually we can have this portable, um, development environment if you choose so, and you can actually replicate them across different teams in different machines, which is actually quite handy. >>But at the same time, we had tools such as local composts has been a great tool to run locally. We have tool such as carefully, which is absolutely great to automatically dynamically upload any changes to how within your code. So I think all of these kinds of tools, they getting more matured. And again, this is going back to again, we need to enhance our developer experience coming back to what is the right way to do so. Um, I think it really depends on the environment you have in production, because there's going to define some of the structures with the tool and you're going to have internally, but at the same time, um, I'd like to say that, uh, it really depends on, on what trucks are developing. Uh, so it's, it's, I would like to personally, I would like to see a bit more diversification in this area because we might have this competitive solutions that is going to push us to towards a new edge. So this is like, what definitely developer experience. If we're talking about development, that's what we need to enhance. And that's what I see the momentum building at the moment. >>Yeah. Yeah. Awesome. Jerome, I saw you shaking your head there in agreement, or maybe not, but what's your thoughts? >>I was, uh, I was just reacting until 82. Uh, it depends thinking that when I, when I do training, that's probably the answer that I gave the most, uh, each time somebody asks, oh, should we do diesel? And I was also looking at some of the questions in the chat about, Hey, the, should we like have a negatory in the, in the container or something like that. And folks can have pretty strong opinions one way or the other, but as a ways, it kind of depends what we do. It also depends of the team that we're working with. Um, you, you could have teams, you know, with like small teams with folks with lots of experience and they all come with their own Feb tools and editorials and plugins. So you know that like you're gonna have PRI iMacs out of my cold dead hands or something like that. >>So of course, if you give them something else, they're going to be extremely unhappy or sad. On the other hand, you can have team with folks who, um, will be less opinionated on that. And even, I don't know, let's say suddenly you start working on some project with maybe a new programming language, or maybe you're targeting some embedded system or whatever, like something really new and different. And you come up with all the tools, even the ADE, the extensions, et cetera, folks will often be extremely happy in that case that you're kind of giving them a Dettol and an ADE, even if that's not what they usually would, uh, would use, um, because it will come with all of the, the, the nice stage, you know, the compression, the, um, the, the, the bigger, the, whatever, all these things. And I think there is also something interesting to do here with development in containers. >>Like, Hey, you're going to start working on this extremely complex target based on whatever. And this is a container that has everything to get started. Okay. Maybe it's not your favorites editor, but it has all the customization and the conserver and whatever. Um, so you can start working right away. And then maybe later you, we want to, you know, do that from the container in a way, and have your own Emacs, atom, sublime, vs code, et cetera, et cetera. Um, but I think it's great for containers here, as well as they reserve or particularly the opportunity. And I think like the, that, that's one thing where I see stuff like get blood being potentially super interesting. Um, it's hard for me to gauge because I confess I was never a huge ID kind of person had some time that gives me this weird feeling, like when I help someone to book some, some code and you know, that like with their super nice IDE and everything is set up, but they feel kind of lost. >>And then at some point I'm like, okay, let's, let's get VI and grep and let's navigate this code base. And that makes me feel a little bit, you know, as this kind of old code for movies where you have the old, like colorful guy who knows going food, but at the end ends up still being obsolete because, um, it's only a going for movies that whole good for masters and the winning right. In real life, we don't have conformance there's anymore mentioned. So, um, but part of me is like, yeah, I like having my old style of editor, but when, when the modern editorial modern ID comes with everything set up and configured, that's just awesome. That's I, um, it's one thing that I'm not very good at sitting up all these little things, but when somebody does it and I can use it, it's, it's just amazing. >>Yeah. Yeah. I agree. I'm I feel the same way too. Right. I like, I like the way I've I have my environment. I like the tools that I use. I like the way they're set up. And, but it's a big issue, right? If you're switching machines, like you said, if you're helping someone else out there, they're not there, your key bindings aren't there, you can't, you can't navigate their system. Right? Yeah. So I think, you know, talking about, uh, dev environments that, that Docker's coming out with, and we're, you know, there's a lot, there, there's a, it's super complex, all these things we're talking about. And I think we're taking the approach of let's do something, uh, well, first, right. And then we can add on to that. Right. Because I think, you know, setting up full, full developed environments is hard, right. Especially in the, the, um, cloud native world nowadays with microservices, do you run them on a repo? >>Do you not have a monitor repo? Maybe that would be interesting to talk about. I think, um, you know, I always start out with the mono repos, right. And you have all your services in there and maybe you're using one Docker file. And then, because that works fine. Cause everything is JavaScript and node. And then you throw a little Python in there and then you throw a little go and now you start breaking things out and then things get too complex there, you know, and you start pulling everything out into different, get repos and now, right. Not everything just fits into these little buckets. Right. So how do you guys think maybe moving forward, how do we attack that night? How do we attack these? Does separate programming languages and environments and kind of bring them all together. You know, we, we, I hesitate, we solve that with compose around about running, right about executing, uh, running your, your containers. But, uh, developing with containers is different than running containers. Right. It's a, it's a different way to think about it. So anyway, sorry, I'm rattling on a little bit, but yeah. Be interesting to look at a more complex, uh, setup right. Of, uh, of, you know, even just 10 microservices that are in different get repos and different languages. Right. Just some thoughts. And, um, I'm not sure we all have this flushed out yet, but I'd love to hear your, your, you guys' thoughts around that. >>Jacob, you, you, you, you look like you're getting ready to jump there. >>I didn't wanna interrupt, but, uh, I mean, I think for me the issue isn't even really like the language boundary or, or, um, you know, a sub repo boundary. I think it's really about, you know, the infrastructure, right? Because you have, you're moving to an era where you have these cloud services, which, you know, some of them like S3, you can, you can mock up locally, uh, or run something locally in a container. But at some point you're going to have like, you know, cloud specific hardware, right? Like you got TPS or something that maybe are forming some critical function in your, in your application. And you just can't really replicate that locally, but you still want to be able to develop against that in some capacity. So, you know, my, my feeling about where it's going to go is you'll end up having parts of your application running locally, but then you also have, uh, you know, containers or some other, uh, element that's sort of cohabitating with, uh, you know, either staging or, or testing or production services that you're, uh, that you're working with. >>So you can actually, um, you know, test against a really or realistic simulation or the actual, uh, surface that you're running against in production. Because I think it's just going to become untenable to keep emulating all of that stuff locally, or to have to like duplicate these, you know, and, you know, I guess you can argue about whether or not it's a good thing that, that everything's moving to these kind of more closed off cloud services, but, you know, the reality of situation is that's where it's going to go. And there's certain hardware that you're going to want in the cloud, especially if you're doing, you know, machine learning oriented stuff that there's just no way you're going to be able to run locally. Right. I mean, if you're, even if you're in a dev team where you have, um, maybe like a central machine where you've got like 10 or 20 GPU's in it, that's not something that you're going to be able to, to, to replicate locally. And so that's how I kind of see that, um, you know, containers easing that boundary between different application components is actually maybe more about co-location, um, or having different parts of your application run in different locations, on different hardware, you know, maybe someone on your laptop, maybe it's someone, you know, AWS or Azure or somewhere. Yeah. It'd be interesting >>To start seeing those boundaries blur right. Working local and working in the cloud. Um, and you might even, you might not even know where something is exactly is running right until you need to, you know, that's when you really care, but yeah. Uh, Johanas, what's your thoughts around that? I mean, I think we've, we've talked previously of, of, um, you know, hybrid kind of environments. Uh, but yeah. What, what's your thoughts around that? >>Um, so essentially, yeah, I think, I mean, we believe that the lines between cloud and local will also potentially blur, and it's actually not really about that distinction. It's just packaging your dev environment in a way and provisioning your dev environment in a way that you are what we call always ready to coat. So that literally, um, you, you have that for the, you described as, um, peace of mind that you can just start to be creative and start to be productive. And if that is a container potentially running locally and containers are at the moment. I think, you know, the vehicle that we use, um, two weeks ago, or one week ago actually stack blitz announced the web containers. So potentially some things, well, it's run in the browser at some point, but currently, you know, Docker, um, is the standard that enables you to do that. And what we think will happen is that these cloud-based or local, um, dev environments will be what we call a femoral. So it will be similar to CIS, um, that we are using right now. And it doesn't literally matter, um, where they are running at the end. It's just, um, to reduce friction as much as possible and decrease and yeah, yeah. Essentially, um, avoid or the hustle that is currently involved in setting up and also managing dev environments, um, going forward, which really slows down specifically larger teams. >>Yeah. Yeah. Um, I'm going to shift gears a little bit here. We have a question from the audience in chat, uh, and it's, I think it's a little bit two parts, but so far as I can see container first, uh, development, have the challenges of where to get safe images. Um, and I was going to answer it, but let me keep it, let me keep going, where to get safe images and instrumentation, um, and knowing where exactly the problem is happening, how do we provide instrument instrumentation to see exactly where a problem might be happening and why? So I think the gist of it is kind of, of everything is in a container and I'm sitting outside, you know, the general thought around containers is isolation, right. Um, so how do I get views into that? Um, whether debugging or, or, or just general problems going on. I think that's maybe a broader question around the, how you, you know, you have your local hosts and then you're running everything containers, and what's the interplay there. W what's your thoughts there? >>I tend to think that containers are underused interactively. I mean, I think in production, you have this mindset that there's sort of this isolated environment, but it's very, actually simple to drop into a shell inside of a container and use it like you would, you know, your terminal. Um, so if you want to install software that way, you know, through, through an image rather than through like Homebrew or something, uh, you can kind of treat containers in that way and you can get a very, um, you know, direct access to the, to the space in which those are running in. So I think, I think that's maybe the step one is just like getting rid of that mindset, that, that these are all, um, you know, these completely encapsulated environments that you can't interact with because it's actually quite easy to just Docker exec into a container and then use it interactively >>Yeah. A hundred percent. And maybe I'll pass, I'm going to pass this question. You drone, but maybe demystify containers a little bit when I talked about this on the last, uh, panel, um, because we have a question in the, in the chat around, what's the, you know, why, why containers now I have VMs, right? And I think there's a misunderstanding in the industry, uh, about what, what containers are, we think they're fair, packaged stuff. And I think Jacob was hitting on that of what's underneath the hood. So maybe drown, sorry, for a long way to set up a question of what, what, what makes up a container, what is a container >>Is a container? Well, I, I think, um, the sharpest and most accurate and most articulate definition, I was from Alice gold first, and I will probably misquote her, but she said something like containers are a bunch of capsulated processes, maybe running on a cookie on welfare system. I'm not sure about the exact definition, but I'm going to try and, uh, reconstitute that like containers are just processes that run on a Unix machine. And we just happen to put a bunch of, um, red tape or whatever around them so that they are kind of contained. Um, but then the beauty of it is that we can contend them as much, or as little as we want. We can go kind of only in and put some actual VM or something like firecracker around that to give some pretty strong angulation, uh, all we can also kind of decontam theorize some aspects, you know, you can have a container that's actually using the, um, the, um, the network namespace of the host. >>So that gives it an entire, you know, wire speed access to the, to the network of the host. Um, and so to me, that's what really interesting, of course there is all the thing about, oh, containers are lightweight and I can pack more of them and they start fast and the images can be small, yada yada, yada. But to me, um, with my background in infrastructure and building resilient, things like that, but I find really exciting is the ability to, you know, put the slider wherever I need it. Um, the, the, the ability to have these very light containers, all very heavily, very secure, very anything, and even the ability to have containers in containers. Uh, even if that sounds a little bit, a little bit gimmicky at first, like, oh, you know, like you, you did the Mimi, like, oh, I heard you like container. >>So I put Docker when you're on Docker. So you can run container for you, run containers. Um, but that's actually extremely convenient because, um, as soon as you stop building, especially something infrastructure related. So you challenge is how do you test that? Like, when we were doing.cloud, we're like, okay, uh, how do we provision? Um, you know, we've been, if you're Amazon, how do you provision the staging for us installed? How do you provision the whole region, Jen, which is actually staging? It kind of makes things complicated. And the fact that we have that we can have containers within containers. Uh, that's actually pretty powerful. Um, we're also moving to things where we have secure containers in containers now. So that's super interesting, like stuff like a SIS box, for instance. Um, when I saw that, that was really excited because, uh, one of the horrible things I did back in the days as Docker was privileged containers, precisely because we wanted to have Docker in Docker. >>And that was kind of opening Pandora's box. That's the right, uh, with the four, because privileged containers can do literally anything. They can completely wreck up the machine. Um, and so, but at the same time, they give you the ability to run VPNs and run Docker in Docker and all these cool things. You can run VM in containers, and then you can list things. So, um, but so when I saw that you could actually have kind of secure containers within containers, like, okay, there is something really powerful and interesting there. And I think for folks, well, precisely when you want to do development in containers, especially when you move that to the cloud, that kind of stuff becomes a really important and interesting because it's one thing to have my little dev thing on my local machine. It's another thing when I want to move that to a swarm or Kubernetes cluster, and then suddenly even like very quickly, I hit the wall, which is, oh, I need to have containers in my containers. Um, and then having a runtime, like that gets really intense. >>Interesting. Yeah, yeah, yeah. And I, and jumping back a bit, um, yeah, uh, like you said, drum at the, at the base of it, it containers just a, a process with, with some, uh, Abra, pardon me, operating constructs wrapped around it and see groups, namespaces those types of things. But I think it's very important to, for our discussion right. Of, uh, developers really understanding that, that this is just the process, just like a normal process when I spin up my local bash in my term. Uh, and I'm just interacting with that. And a lot of the things we talk about are more for production runtimes for securing containers for isolating them locally. I don't, I don't know. I'll throw the question out to the panel. Is that really relevant to us locally? Right. Do we want to pull out all of those restrictions? What are the benefits of containers for development, right. And maybe that's a soft question, but I'd still love to hear your thoughts. Maybe I'll kick it over to you, Katie, would you, would you kick us off a little bit with that? >>I'll try. Um, so I think when, again, I was actually thinking of the previous answers because maybe, maybe I could do a transition here. So, interesting, interesting about containers, a piece of trivia, um, the secrets and namespaces have been within the Linux kernel since 2008, I think, which just like more than 10 years ago, hover containers become popular in the last years. So I think it's, it's the technology, but it's about the organization adopting this technology. So I think why it got more popular now is because it became the business differentiator organizations started to think, how can I deliver value to my customers as quickly as possible? So I think that there should be this kind of two lane, um, kind of progress is the technology, but it's at the same time organization and cultural now are actually essential for us to develop, uh, our applications locally. >>Again, I think when it's a single application, if you have just one component, maybe it's easier for you to kind of run it locally, have a very simple testing environment. Sufficient is a container necessary, probably not. However, I think it's more important when you're thinking to the bigger picture. When we have an architecture that has myriads of microservices at the basis, when it's something that you have to expose, for example, an API, or you have to consume an API, these are kind of things where you might need to think about a lightweight set up within the containers, only local environment to make sure that you have at least a similar, um, environment or a configuration to make sure that you test some of the expected behavior. Um, I think the, the real kind of test you start from the, the dev cluster will like the dev environment. >>And then like for, for you to go to staging and production, you will get more clear into what exactly that, um, um, configuration should be in the end. However, at the same time, again, it's, it's more about, um, kind of understanding why you continue to see this, the thing, like, I don't say that you definitely need containers at all times, but there are situations when you have like, again, multiple services and you need to replicate them. It's just the place to, to, to work with these kind of, um, setups. So, um, yeah, really depends on what you're trying to develop here. Nothing very specific, unfortunately, but get your product and your requirements are going to define what you're going to work with. >>Yeah, no, I think that's a great answer, right. I think one of the best answers in, in software engineering and engineering in general as well, it depends. Right. It's things are very specific when we start getting down to the details, but yeah, generally speaking, you know, um, I think containers are good for development, but yeah, it depends, right. It really depends. Is it helping you then? Great. If it's hindering you then, okay. Maybe think what's, what's the hindrance, right. And are containers the right solution. I agree. 110% and, >>And everything. I would like absurd this too as well. When we, again, we're talking about the development team and now we have this culture where we have the platform and infrastructure team, and then you have your engineering team separately, especially when the regulations are going to be segregated. So, um, it's quite important to understand that there might be a, uh, a level of up-skilling required. So pushing for someone to use containers, because this is the right way for you to develop your application might be not, uh, might not be the most efficient way to actually develop a product because you need to spend some time to make sure that the, the engineering team has the skills to do so. So I think it's, it's, again, going back to my answers here is like, truly be aware of how you're trying to develop how you actually collaborate and having that awareness of your platform can be quite helpful in developing your, uh, your publication, the more importantly, having less, um, maybe blockers pushing it to a production system. >>Yeah, yeah. A hundred percent. Yeah. The, uh, the cultural issue is, is, um, within the organization, right. Is a very interesting thing. And it, and I would submit that it's very hard from top down, right. Pushing down tools and processes down to the dev team, man, we'll just, we'll just rebel. It usually comes from the bottom up. Right. What's working for us, we're going to do right. And whether we do it in the shadows and don't let it know, or, or we've conformed, right. Yeah. A hundred percent. Um, interesting. I would like to think a little bit in the future, right? Like, let's say, I don't know, two, three years from now, if, if y'all could wave a and I'm from Texas. So I say y'all, uh, if you all could wave a magic wand, what, what, what would that bring about right. What, what would, what would be the best scenario? And, and we just don't have to say containers. Right. But, you know, what's the best development environment and I'm going to kick it over to you, Jacob. Cause I think you hinted at some of that with some hybrid type of stuff, but, uh, yeah. Implies, they need to keep you awake. You're, you're, you're, uh, almost on the other side of the world for me, but yeah, please. >>Um, I think, you know, it's, it's interesting because you have this technology that you've been, that's been brought from production, so it's not, um, necessarily like the right or the normal basis for development. So I think there's going to be some sort of realignment or renormalization in terms of, uh, you know, what the, what the basis and the abstractions that we're using on a daily basis are right. Like images and containers as they exist now are really designed for, um, for production use cases. And, and in terms of like, even even the ergonomics of opening a shell inside a container, I think is something that's, um, you know, not as polished or not as smooth as it could be because they've come from production. And so I think it's important, like not to, not to have people look at, look at the technology as it exists now and say like, okay, this is slightly rough around the edges, or it wasn't designed for this use case and think, oh, there's, you know, there's never any way I could use this for, for my development of workflows. >>I think it's, you know, it's something Docker's exploring now with, uh, with the, uh, dev containers, you know, it's, it's a new, and it's an experimental paradigm and it may not be what the final picture looks like. As, you know, you were saying, there's going to be kind of a baseline and you'll add features to that or iterate on that. Um, but I think that's, what's interesting about it, right? Cause it's, there's not a lot of things as developers that you get to play with that, um, that are sort of the new technology. Like if you're talking about things you're building to ship, you want to kind of use tried and true components that, you know, are gonna, that are going to be reliable. But I think containers are that interesting point where it's like, this is an established technology, but it's also being used in a way now that's completely different than what it was designed for. And, and, you know, as hackers, I think that's kind of an interesting opportunity to play with it, but I think, I think that's, what's going to happen is you're just going to see kind of those production, um, designed, uh, knobs kind of sanded down or redesigned for, for development. So that's kind of where I see it going. >>Yeah. Yeah. And I think that's what I was trying to hint out earlier is like, um, yeah, just because all these things are there, does it actually mean we need them locally? Right. Do they make sense? I, I agree. A hundred percent, uh, anybody else drawn? What are your thoughts around that? And then, and then, uh, I'll probably just ask all of you. I'd love to hear each of your thoughts of the future. >>I had a thought was maybe unrelated, but I was kind of wondering if we would see something on the side of like energy efficiency in some way. Um, and maybe it's just because I've been thinking a lot about like climate change and things like that recently, and trying to reduce like the, uh, the energy use energy use and things like that. Perhaps it's also because I recently got a new laptop, which on paper is super awesome, but in practice, as soon as you try to have like two slack tabs and a zoom call, you know, it's super fast, both for 30 seconds. And after 30 seconds, it blows its thermal budget and it's like slows down to a crawl. And I started to think, Hmm, maybe, you know, like before we, we, we were thinking about, okay, I don't have that much CPU available. So you have to be kind of mindful about that. >>And now I wonder how are we going to get in something similar to that, but where you try to save CPU cycles, not just because you don't have that many CPU cycles, but more because you know, that you can't go super fast for super long when you are on one of these like small laptops or tablets or phones, like you have this demo budget to take into account. And, um, I wonder if, and how like, is there something where goaltenders can do some things here? I guess it can be really interesting if they can do some the equivalent of like Docker top and Docker stats. And if I could see, like how much what's are these containers using, I can already do that with power top on Linux, for instance, like process by process. So I'm thinking I could see what's the power usage of, of some containers. Um, and I wonder if down the line, is this going to be something useful or is this just silly because we can just masquerade CPU usage for, for Watson and forget about it. >>Yeah. Yeah. It was super, super interesting, uh, perspective for sure. I'm going to shut up because I want to, I want to give, make sure I give Johannes and Katie time. W w what are your thoughts of the future around, let's just say, you know, container development in general, right? You want, you want to start absolutely. Oh, honest, Nate. Johns wants more time. I say, I'll try not to. Beneficiate >>Expensive here, but, um, so one of the things that we've we've touched upon earlier in the panel was multicloud strategy. And I was reading one of the data reports from it was about the concept of Kubernetes from gamer Townsville. But what is working for you to see there is that more and more organizations are thinking about multicloud strategy, which means that you need to develop an application or need an infrastructure or a component, which will allow you to run this application bead on a public cloud bead, like locally in a data center and so forth. And here, when it comes to this kind of, uh, maybe problems we come across open standards, this is where we require something, which will allow us to execute our application or to run our platform in different environments. So when you're thinking about the application or development of the application, one of the things that, um, came out in 2019 at was the Oakland. >>Um, I wish it was Kybella, which is a, um, um, an open application model based application, which allows you to describe the way you would like your service to be executed in different environments. It doesn't need to be well developed specifically for communities. However, the open application model is specialized. So specialized tries to cover multiple platforms. You will be able to execute your application anywhere you want it to. So I think that that's actually quite important because it completely obstructs what is happening underneath it, completely obstructs notions, such as containers, uh, or processes is just, I want this application and I want to have this kind of behavior is so example of, to scale in this conditions or to, um, to be exposed for these, uh, end points and so forth. And everything that I would like to mention here is that maybe this transcends again, the, uh, the logistics of the application development, but it definitely will impact the way we run our applications. >>So one of the biggest, well, one of the new trends that is kind of gaining momentum now has been around Plaza. And this is again, something which is trying to present what we have the on containers. Again, it's focusing on the, it's kind of a cyclical, um, uh, action movement that we have here. When we moved from the VMs to containers, it was smaller footprint. We want like better execution, one, this agnosticism of the platforms. We have the same thing happening here with Watson, but again, it consents a new, um, uh, kind of, well, it teaches in you, uh, in new climax here, where again, we shrink the footprint of the cluster. We have a better isolation of all the services. We have a better trend, like portability of how services and so forth. So there is a great potential out there. And again, like why I'm saying this is some of these technologies are gonna define the way we're gonna do our development of the application on our local environment. >>That's why it's important to kind of maybe have an eye there and maybe see if some of those principles of some of those technologies we can bring internally as well. And just this, like a, a final thought here, um, security has been mentioned as well. Um, I think it's something which has been, uh, at the forefront, especially when it comes to containers, uh, especially when it comes to enterprise organizations and those who are regulated, which I feel come very comfortable to run their application within a VM where you have the full isolation, you can do what we have complete control of what's happening inside that compute. So, um, again, security has been at the forefront at the moment. So I know it has mentioned in the panel before. I'd like to mention that we have the security white paper, which has been published. We have the software supply chain, white paper as well, which twice to figure out or define some of these good practices as well, again, which you can already apply from your development environment and then propagate them to production. So I'm just going to leave, uh, all of these. That's all. >>That's awesome. And yeah, well, while is very, very interesting. I saw the other day that, um, and I forget who it was, maybe, maybe all can remember, um, you know, running, running the node, um, engine inside of, you know, in Walzem inside of a browser. Right. And, uh, at first glance I said, well, we already have a JavaScript execution engine. Right. And it's kind of like Docker and Docker. So you have, uh, you know, you have the browser, then, then you have blossom and then you have a node, you know, a JavaScript runtime. And, and I didn't understand was while I was, um, you know, actually executing is JavaScript and it's not, but yeah, it's super interesting, super powerful. I always felt that the browser was, uh, Java's what write once run anywhere kind of solution, right. That never came about, they were thinking of set top, uh, TV boxes and stuff like that, which is interesting. >>I don't know, you'll some of the history of Java, but yeah. Wasm is, is very, I'm not sure how to correctly pronounce it, but yeah, it's extremely interesting because of the isolation in that boxing. Right. And running powerful languages that were used to inside of a more isolated environment. Right. And it's almost, um, yeah, it's kind of, I think I've mentioned it before that the containers inside of containers, right. Um, yeah. So Johannes, hopefully I gave you enough time. I delayed, I delayed as much as I can. My friend, you better, you better just kidding. I'm just kidding, please, please. >>It was by the way, stack let's and they worked together with Google and with Russell, um, developing the web containers, it's called there's, it's quite interesting. The research they're doing there. Yeah. Yeah. I mean, what we believe and I, I also believe is that, um, yeah, probably somebody is doing to death environments, what Docker did to servers and at least that good part. We hope that somebody will be us. Um, so what we mean by that is that, um, we think today we are still somehow emotionally attached to our dev environments. Right. We give them names, we massage them over time, which can also have its benefits, but it's, they're still pets in some way. Right. And, um, we believe that, um, environments in the future, um, will be treated similar like servers today as automated resources that you can just spin up and close down whenever you need them. >>Right. And, um, this trend essentially that you also see in serverless, if you look at what kind of Netlify is doing a bit with preview environments, what were sellers doing? Um, there, um, we believe will also arrive at, um, at Steph environments. It probably won't be there tomorrow. So it will take some time because if there's also, you know, emotion involved into, in that, in that transition, but ultimately really believe that, um, provisioning dev environments also in the cloud allows you to leverage the power of the cloud and to essentially build all that stuff that you need in order to work in advance. Right? So that's literally either command or a button. So either, I don't know, a command that spins up your local views code and SSH into, into a container, or you do it in a browser, um, will be the way that professional development teams will develop in the future. Probably let's see in our direction of document, we say it's 2000 to 23. Let's see if that holds true. >>Okay. Can we, can, we let's know. Okay. Let's just say let's have a friendly bet. I don't know that's going to be closed now, but, um, yeah, I agree. I, you know, it's my thought around is it, it's hard, right? Th these are hard. And what problems do you tackle first, right? Do you tackle the day, one of, uh, you know, of development, right. I joined a team, Hey, here's your machine? And you have Docker installed and there you go, pull, pull down your environment. Right. Is that necessarily just an image? You know, what, what exactly is that sure. Containers are involved. Right. But that's, I mean, you, you've probably all gone through it. You joined a team, new project, even open-source project, right there. There's a huge hurdle just to get everything configured, to get everything installed, to get it up and running, um, you know, set aside all understanding the code base. >>Cause that's a different issue. Right. But just getting everything running locally and to your point earlier, Jacob of around, uh, recreating, local production cues and environments and, you know, GPS or anything like that, right. Is extremely hard. You can't do a lot of that locally. Right. So I think that's one of the things I'd love to see tackled. And I think that's where we're tackling in dev environments, uh, with Docker, but then now how do you become productive? Right. And where do we go from there? And, uh, and I would love to see this kind of hybrid and you guys have been all been talking about it where I can, yes. I have it configured everything locally on my nice, you know, apple notebook. Right. And then, you know, I go with the family and we go on vacation. I don't want to drag this 16 inch, you know, Mac laptop with me. >>And I want to take my nice iPad with the magic keyboard and all the bang stuff. Right. And I just want to fire up and I pick up where I left off. Right. And I keep coding and environment feels, you know, as much as it can that I'm still working at backup my desktop. I think those, those are very interesting to me. And I think reproducing, uh, the production running runtime environments as close as possible, uh, when I develop my, I think that's extremely powerful, extremely powerful. I think that's one of the hardest things, right. It's it's, uh, you know, we used to say, we, you debug in production. Right. We would launch, right. We would do, uh, as much performance testing as possible. But until you flip that switch on a big, on a big site, that's where you really understand what is going to break. >>Right. Well, awesome. I think we're just about at time. I really, really appreciate everybody joining me. Um, it's been a pleasure talking to all of you. We have to do this again. If I, uh, hopefully, you know, I I'm in here in America and we seem to be doing okay with COVID, but I know around the world, others are not. So my heart goes out to them, but I would love to be able to get out of here and come see all of you and meet you in person, maybe break some bread together. But, um, again, it was a pleasure talking to you all, and I really appreciate you taking the time. Have a good evening. Cool. >>Thanks for having us. Thanks for joining us. Yes.

>> live from San Francisco, celebrating 10 years of high tech coverage. It's the Cube covering Veum World 2019 brought to you by IBM Wear and its ecosystem partners. >> Welcome back to the Cube. It's the Emerald 2019 our 10th year water wall coverage. Three days, two sets, lots of content. Instrument of my co host is Justin Warren. And one of the big stories coming into the show is VM Wear actually went on an acquisition spree. A hold number of acquisitions. Boston based Carbon Black over $2 billion Pivotal brought back into the fold for also, you know, around that ballpark of money on Happy to Welcome to the program. One of those acquisitions, such and Conti, is sitting to my right. He's the co founder of Hana is also a professor at Stanford University. Thank you so much for joining us and joining us. Also for the segment. Shakeri Air, the executive vice president general manager of Telco Edge Cloud at VM Wear, Shaker said, Yes, there's a lot of acquisitions not to play favorites, but maybe this is his favorite. No question about it. All right. Eso such in, you know, boy, you know the Paolo Alto Stanford connection. We were thinking back, You know, the Founders Of'em where, of course, you know came from Stanford. Many acquisitions over the year, including the mega next era acquisition. You know, quite a few years ago, I came out of Stanford. Give us what was the genesis in the Why of Hana. >> It's actually interesting Stanford Connection to So I've been a faculty at Stanford for the last 10 years on dhe. I have seen the SD and moment very close on up front on one of the dirty secrets of S. T M says it makes the netbooks programmable, but someone still has to write the programs on. So that's usually a very complex task on the pieces beyond the company was, Can we use the eye to learn how to program the network rather than humans having to program the network to do management or optimization? So the division really waas can be built? A network that learned how to optimize itself learns how to manage itself on the technology we're building. Is this a pipeline that basically tries to deliver on that for mobile? >> It's great, Sachin, you know, my background is networking and it feels like forever. We've been hooking well. We need to get people from the cli over to the gooey. But we know in today's rightly complex world, whether it's a I or just automation, humans will not be able to keep up with it. And, you know, we know that that's where a lot of the errors would happen is when we entered humans into doing some of this. So what are some of the key drivers that make this solution possible today that, you know, it might not have been able to do done when when one train was first rolling out the first S t n? >> Yeah, talk about it in three dimensions. The one is, Why do we need it today? Right on. Then what is being what is happening that is enabling this today, right? So, apart from what I talked about Stu and I think the other big driver is, the way I like to think about it is that the Internet is going from a means of consumption to a means of control and interaction. So, increasingly, the application to BC driving the next big decade, our very way of controlling things remotely or the network like a self driving car, or be in interacting but very highly rich visual content like E. R. India. So the applications are becoming a lot more demanding on the Net. At the same time, the network is going through a phase off, opening up on becoming disaggregated network complexity is increasing significantly. So the motivation behind the company and why I thought that was the right time to start the company was these two friends are gonna collide with five coming along the applications that are driving five g and then at the complexity increasing our five. So that's why we started the company. What actually is enabling. This is the fact that we have seen a lot of progress with the eye over the last few years. It hasn't really. It hadn't really been applied at scale to networks and specifically mobile that book. So we definitely saw no, actually there, but increasingly, ah, lot of the infrastructure that is being deployed there was more and more telemetry available. There was more and more data becoming available and that also obviously feet this whole engine. So I think the availability of all of these Big Data Technologies Maur data coming in from the network and the need because of these applications and that complexity. I think there's a perfect confluence >> that there's lots of lots of II floating around at the moment, and there's different flavors of it as well. So this machine learning there's Aye aye, sir. When when you say that there's there's a I behind this What? What particular kind of machine learning or a Y you're using to drive these networks? >> This a few different techniques because the problems we solve our anomaly detection off. Then problems are happening in the network predicting how network conditions are going to evolve. For example, predicting what your devices throughput is gonna be the next 30 seconds. We're also learning how to control the knobs in the neck using AI ai techniques. So each of these has different classes of the eye techniques. So, for example, for control we're using reinforcement learning, which is the same technique that Google used to kind of been on alphago. How do you learn how to play a game basically, but area the game you're playing it optimizing the network. But for the others, it's a record of neural networks to do predictions on Time series data. So I think it's a combination of techniques I wouldn't get to wherever the techniques. It's ultimately. But what is the problem you're trying to solve? And then they picked the right technique to solve it, >> and so on that because the aye aye is actually kind of stupid in that it doesn't know what they wouldn't. What an optimized network looks like. We have to show it what that is. So what? How do you actually train these systems to understand? But what is an optimized network? What? How does how does that tell you? Define this is what my network optimal state should be. >> So that's a great question, because in networking like that, any other discipline that wants to use the eye. There's not a lot of label data. What is the state I want to end up at what is a problem state or what is a good state? All of this is labels that someone has to enter, and that's not available axe kid, and we're never gonna be able to get it at the scale we wanted. So one of our secret sauce is if you will, is semi supervised learning but basic ideas that we're taking a lot of domain knowledge on using that domain knowledge to figure out what should be the right features for these models so that we can actually train these models in a scalable fashion. If you just throw it a lot of data any I model, it just does not converge. Hardly constructive features on the other thing is, how do I actually define what are good kind of end state conditions? What's a good network? And that's coming from domain knowledge to That's how we're making I scale for the stomach. >> I mean, overall, I would say, as you look at that, some of the parameters in terms of what you want to achieve are actually quite obvious things like fewer dropped calls for a cellular network. You know, that's good. So figuring out what the metrics need to be and what the tuning needs before the network, that's where Hana comes in in terms of the right people. >> All right, so shake her. Give us a little bit of an understanding as to where this fits into the networking portfolio. You know, we heard no we heard from Patty or two ago. You know what would have strong push? Networking is on the NSX number. Speaks for itself is what's happening with that portfolio? >> No, absolutely. In fact, what we're doing here is actually broader than networking. It's sort off very pertinent to the network off a carrier. But that is a bulk off their business, if you will. I think if you sort of go back and look at the emirs of any any, any vision, this is the notion of having any cloud in any application land on any cloud and then any device connected to those applications on that any cloud side we are looking at particularly to cloud pools, one which we call the Telco cloud and the other is the edge cloud. And both of these fortuitously are now becoming sort of transforming the context of five G. So in one case, in the telco cloudy or looking at their core and access networks, the radio networks, all of this getting more cloud ified, which essentially leads toe greater agility in service deployment, and then the edge is a much more distributed architecture. Many points over which you can have compute storage network management and security deployed. So if you now think about the sort of thousands off nodes on dhe virtualized clouds, it is just impossible to manage this manual. So what you do need is greater. I mean, orders of magnitude, greater automation in the ability to go and manage and infrastructure like this. So, with our technology now enhanced by Johanna in that network portfolio in the Telco Edge Cloud portfolio, were able to go back to the carriers and tell them, Look, we're not just foundational infrastructure providers. We can also then help you automate help you get visibility into your networks and just help you overall manager networks better for better customer expedience and better performance. >> So what are some of the use coasters that you see is being enabled by five G? There's a lot of hype about five short the moment and not just five jail. So things like WiFi six. Yeah, it would appear to me that this kind of technique would work equally well for five g Your wife. I short a WiFi six. So what are some of the use cases? You see these thieves service providers with Toko Edge clouds using this for? Yeah, So I think overall, first of all, I'd >> say enterprise use cases are going to become a pretty prominent part off five, even though a lot off the buzz and hype ends up being about consumers and how much bandwidth and data they could get in or whether five chicken passing preys or not. But in fact, things like on premise radio on whether that is private. Lt it's 40 or five t. These are the kinds of Uschi cases that were actually quite excited about because these could be deployed literally today. I mean, sometimes they're not regulated. You can go in with, like, existing architectures. You don't need to wait for standardization to break open a radio architecture. You could actually do it, Um, and >> so this sort off going in and >> providing connectivity on an enterprise network that is an enhanced state off where it is today. We've already started that journey, for example, with yellow cloud and branch networking. Now, if we can take that toe a radio based architecture for enterprise networking, So we think, ah, use case like that would be very prominent. And then based on edge architectures distributed networks now becoming the next generation Cdn is an example. That's another application that we think would be very prominent. And then I think, for consumers just sort of getting things like gaming applications off on edge network. Those are all the kinds of applications that would consume this sort off high skill, reliability and performance. >> Can you give a little sketch of the company pre acquisition, you know, is the product all g eight? How many customers you? Can you say what you have there? Sure >> it does us roughly three years old. The company itself so relatively young. We were around 33 people total. We had a product that is already deployed with chairman Telcos. So it is in production deployment with Chairman Telco Ondas in production trials with a couple of other tier one telcos. So we built a platform to scale to the largest networks in the world on If I, if I were to summarize it, be basically can observe, makes sense or in real time about every user in the network, what their experiences like actually apply. I modeled on top of that to optimize each user's expedience because one of the vision bee had was the network today is optimized for the average. But as all off our web expedience personalized netbook experiences, not personalized can be build a network Very your experiences personalized for you for the applications, your running on it. And this was kind of a foundation for that. >> I mean, we In fact, as we've been deploying our telco Cloud and carrier networks, we've also been counting roughly how many subscribers are being served up. Today we have over 800 million subscribers, and in fact, I was talking to someone and we were talking about that does. Being over 10% off the population of the world is now running on the lack of memory infrastructure. And then along comes Johanna and they can actually fine tune the data right down to a single subscriber. Okay, so now you can see the sort of two ends of the scale problem and how we can do this using a I. It's pretty powerful. Excellent. >> So So if we have any problems with our our service fighters, b tech support and I love to hear from both of you, you know what this acquisition position means for the future of the places and obviously VM wear global footprint. A lot of customers and resource is. But you know what I mean to your team in your product. >> I mean, definitely accelerating how quickly we can now start deploying. This and the rest of the world be as a small company, have very focused on a few key customers to prove the technology we have done that on. I think now it's the face to scale it on. Repeat it across a lot of other customers, but I think it also gives us a broader canvas to play that right. So we were focused on one aspect of the problem which is around, if you will, intelligence and subscriber experience. But I think with the cloud on but the orchestration products that are coming out of the ember, we can now start to imagine a full stock that you could build a network of full carrier network code off using using remote technology. So I think it's a broad, more exciting, actually, for us to be able to integrate not just the network data but also other parts of the stock itself. And >> it strikes me that this probably isn't just limited to telcos, either. The service providers and carriers are one aspect of this bit particularly five G and things like deployments into factory automation. Yes, I can see a lot of enterprise is starting to become much in some ways a little bit like a tell go. And they would definitely benefit from this >> kind of thing. Yeah, I mean, in fact, that's the basis of our internal even bringing our telco and EJ and I ot together and a common infrastructure pool. And so we're looking at that. That's the capability for deploying this type of technology across that. So you're exactly right, >> Checker want to give you the last word, you know, Telco space, you know? And then, obviously the broader cloud has been, you know, a large growth area. What, you want people taking away from the emerald 2019 when it comes to your team? >> Yeah, I think. To me, Calico's have a tremendous opportunity to not just be the plumbing and networking providers that they can in fact, be both the clowns of tomorrow as well as the application providers of tomorrow. And I think we have the technology and both organically as well as through acquisitions like Ohana. Take them there. So I'm just super excited about the journey. Because I think while most of the people are talking about five D as this wave, that is just beginning for us, it's just a perfect coming together on many of these architectures that is going to take telcos into a new world. So we're super excited about taking them. >> Shaker. Thank you so much for joining against auction. Congratulations and good luck on the next phase of you and your team's journey along the way. Thank you. Thank you for Justin. Warren comes to Minutemen, Stay with us. Still a bit more to go for VM World 2019 and, as always, thank you for watching the Cube.

>> live from San Francisco, celebrating 10 years of high tech coverage. It's the Cube covering Veum World 2019. Brought to you by VM Wear and its ecosystem partners. >> Hey, welcome back here and live here in Mosconi North. The Emerald 2019 Cube Live coverage on Shopping Day Volante Jr Jr. Who's here? EVP general manager, Telco and Edge of Cloud for Vienna. Where Thanks for coming on. Thanks for having me. I know you're super busy. We don't have a lot of time. Get right to it. Um five g a big part of the key. No discussion that's gonna enable a whole bunch of Pakal the pregame show pre gaming not even talk about that. Also. Telco on the Edge Computing Big part Michael Dell said, Edges the future Now these air to emerging areas for you guys. What's the positioning? What's the update? >> No, absolutely. I mean, if you look a tw telecom infrastructure. For the longest time, telcos have played a role just as pure basic connectivity providers. And with five g coming on board, they finally have an opportunity to break out of that and redefine the cloud off the future. So for us the big opportunity around five g is not just the better provisioning off like Higher Man With Service is to consumer for voice and data buy the whole set off new enterprise service is that can be provided on top of this five g network. And in order to be able to do that, you really need to go in with a virtualized telco Cloud architecture. Underneath that, and so we are working with carriers globally now preparing them for five G with an architecture that's going to help them deploy. New service is faster for both their consumer as well as enterprise. >> Going to be the white knight at, so to speak. For these telcos because they've been struggling for years over the top and any kind of differentiates service is even in the network layer. Exactly. I've had tons of rack and stack machine, so they're after their well, well stacked up in terms of computer storage. Also connectivity to the edge. That's the back hall. So you have back haul, which is connectivity. Companies that have massive expertise in scale but fumbling in operational cloud natives that >> by not just that, but I also think that having the idea off on application platform that allows them to go and deploy service is faster and then decide whether they're just going to play at the network connectivity level or at the application tear or a full SAS tear. These are all options that are open to them now with this notion off. Telco five G coupled with an NFI and cloud telco cloud infrastructure. Underneath that and never before have they had this option to doing that. And this is now open to them >> and the cloud native is there greenfield for AP supporter having applications on top of it. Exact icing on the cake, right? >> Exactly, Exactly. And so they're all looking at core architectures and then, potentially, their radio architectures now all being opened up toe deploying new service is that are much faster to provisions and then extending that to EJ and >> five G's deploying. So we know it's out there. So it is pre game is Pat, Guzman said. You know, not even an inning Yet in the metaphor of baseball innings, I >> gotta ask you get my phone. That's not that's fake ill. I know it >> did that with four g to >> skeptic e stands for evolution, which is coming soon. >> That's vaporware for tell Coke language. The surface area is going to radically get bigger with this capability. Yeah, security's gonna be baked in. This is the number one concern for io ti. And more importantly, industrial I ot We've been reporting on silicon angle dot com. This is a national security issue because we're under cyber attacks. Town's getting locked out with ransomware critical infrastructure exposed. We're free country, and I want to be free. We don't lock down. So you have security built into this new promiscuous landscape that is called the coyote Edge. Because you wanna have no perimeter. You want the benefits of cloud. But one whole malware is in there. One take over physical device could cost lives. >> Yeah, there's a big concern. Yeah. What's your thoughts? Yeah, No. So I think there >> are two ways of looking at it. One is the way you looked at it in terms of the security perimeter expanding and then us making sure that we have the right level off infrastructure security baked in to enable this to be an easier, manageable security architecture. This is sort of the pitch you heard from Mia Mary, even in the context of our acquisition of carbon black and how we're thinking about baking security into the infrastructure, the other way of looking at this is if you think about some of the concerns around providers off telecom infrastructure today and how there might be or might not be security back doors. This is happening in today's hardware infrastructure. Okay, so in fact, I would argue that a sick software defined architecture, er, actually ends up providing you greater levels of security. Because what you now have is the option off running all of these network functions as secured as software workloads in a policy envelope that you can introspect. And then you can decide what kind of security you want to deploy on what kind of workload. >> That's an innovative approach. But it doesn't change much, really, from an infrastructure standpoint, does it? Or does it? >> No, it does, >> because now, instead of having a hardware box where you have to worry, I mean, if it's a close, hard red box and you don't quite know what is happening there, the question is, is that more secure than a infrastructure radio running the software that you can actually introspect. I would argue that the software defined approach is more secure than having a hardware box that you don't know. >> I would buy the premise that certainly we know that supply chain concerned. You know the speculation Super Micro, which never was proved. >> It doesn't matter who the vendor is or what the country is. It really is a concern in terms of not being able to introspect what has happened Going inside >> for my tea shop. I'm running VM where operating I want developers. So now you're going to tell Coz you revitalize their business model? They had a rule out appy. Now what did you see? That connecting is gonna be connective tissue between >> I'll think about it. I didn't feel goto a telco. We look at really three stakeholders in there. One is I t the second Is there be to be or enterprise facing business and then the 3rd 1 is their core and access network or the CTO. We're now have a value proposition of having a uniform architecture across all three stakeholders with the uniform ability to create applications and drop it on top of each of these infrastructures with the ability to manage and secure these again in a uniform way, not just that, but also make this work well with other cloud infrastructures private, hyper scale, public as well as EJ. >> That's table stakes. You have to do that. These jokers have to operate whatever >> well it is, But it's not. I mean, if you think about what the infrastructure off a tailcoat today is, it's far from that, because it's it's sort of a closed environment. You can't access anything from a telco environment in order to go build an application to it, and it does not resemble anything like any club >> you could enable Telco. Just I'm just kind of thinking connecting the dots here real time in the Cube. If I'm a telco, hell, I'll take that VM wear on a deli and see model. Make me a cloud and I'll sell Cloud Service is to markets that kind of >> it is. Actually it's a very important part of our business model because most telcos would not move their own infrastructure from a network standpoint onto a public cloud. But they are eagerly awaiting the ability to operate their own network as a cloud, and if they can have somebody manage that for them, then that is very much within the >> you're enabling. An increase in the number of cloud service provides potentially the paint on the makeup of the telco tier one tier two tier three size. Pretty much >> potentially. I mean, it's taking an existing operator and having them operate in a more agile way and potentially increasing anew form off a cloud service >> provided telcos wouldn't move into the public cloud because of they want to control. And the cost is that right or it's >> mostly control. It's not about cost. It's about taking What is your sort of coordinating for, ah, packet corps or for a radio network? Yeah, and there is also an angle around competition, I think telcos our what in about the Amazons of the world and the azure eyes of the world potentially becoming a service provided >> themselves. And that's what I wanted to ask you about the business impact of all this discussion you guys were having is, you know, the cost for bits coming down. The amount of data is increasing faster. You got over the top providers just, you know, picking off the telcos. Telcos can't compete their infrastructures of so hardened. Will this all change that? >> Absolutely So. I think that it has the potential to changing all that. I don't think all the telcos will take advantage of it. Some off them might end up being more traditional and sort of sticking to where they were. But for those that are willing to make the leap, I mean, as an example, Vodafone is a customer that has actually gone in with this architecture with us. A. T and T is working with us with the Vela Cloud software from via Mary bringing a new form off branch computer branch connectivity through SD man. So these are all examples of telcos that are actually leading the >> charter. But if they don't lean in, they have this vision there either. Well, it's either because they're protected by their local government or they're going to go out of business. No, I would >> agree. I mean, it's sort of silly from our standpoint to be talking about five G and not thinking about this as the architecture for five, right? I mean, if you only focus on radio waves and your wireless network that's like a part of the problem, but you really need to have the ability to deploy these agile service's. Otherwise, you could get killed by >> the O. T. T. So how do you compete against the competition? What's the business plan that you have? C. Five G? We see that in the horizon that's evolving its evolution, so to speak. Pun intended on edge is certainly very relevant for enterprises, whether it's manufacturing or industrial or just people. Yeah, >> I'd say there are two things. One is a CZ. I'm sure you heard from folks at GM, where our vision is this notion of any any anywhere. We've talked about any cloud at any application that any device. So that becomes one of the strongest different chaining factors in terms of what V Amir can bring. Tow any of our customers compared to the competition, right? Nobody can actually make it really across these dimensions. If you then take that architecture and use that to deploy a telco cloud, we're now making investments that are telco specific that allow the tailcoat than take this and make the most out of it. As an example, we're investing in open stack we're investing in container ization. We just bought a company called Johanna and Johanna essentially allows the operator to go and provide metrics from their radio access networks. Use at that to train a learning engine and then feed that back so that the operator can tune their network to get like fewer dropped calls in the region. So if you combined technology like that with this, any cloud infrastructure that we have underneath that that's the best in class deployment methodology for any. Tell Cho to deploy >> five. Your business model metrics for you internally is get Maur deployments. What stage of development five G certainly is in a certain stage, but you know, edges there. Where is the Progress bar? If you're the kind of oh, >> it's actually mold phenomenally. I mean, every time we have conversations like this, we're moving about further in terms off. How many carriers are deploying on via mare on a telco cloud Architecture? How many subscribers are basically being serviced by an architectural like this? And then how many network functions are being deployed? Two of'em air architecture. So we are over 100 carriers now we are over. We have about 800 million subscribers, or so that about globally are being serviced by a V M Air supported network. On then, we have essentially over 120 network functions that >> are operating on top of you. Usually bring in all the same stuff that's announced that the show that stuff's gonna fold into the operating platform or Joe Chuckles have different requirements. Off course. It's >> both. We take the best of what is there from the sort of overall vehement factory and then as a team. My team then builds other widgets on top that are telco specific. >> How big is your your tam up Terry for you? >> Well, so the best way to look at it as telcos globally spend about a trillion dollars in capital investment and then probably to X that in terms of their operating expenditure over the course off all of the things that they do right? And out of that, I would say probably a tent off that. So if you take about $100 billion opportunity, opens itself up toe infrastructure investment in terms off the kinds of things that we're talking about now, they're not gonna move from like 0 200 of course. So if you take some period of time, I would say good subset off that $100 billion opportunity is gonna open itself up >> to it. This kind of business cases, eliminating that two x factor, at least reducing it. Is that exactly? That's not just that Service is that's, >> ah, cost reduction alternative. But then you have the ability to go deploy. Service is faster, so it's really a combination off both sort of carrot and the stick, right? I mean, the character here is the ability to go monetize More new service is with five G faster. The stick is that if you don't do it, Ortiz will get there faster and your costs off. Deploying your simple service is will increase his >> telcos, in your opinion, have what they have to do to get the DNA chops to actually be able to compete with the over to top OT T providers and be more agile. I mean, it's obviously sort of new skills that they have to bring in a new talent. Yeah, >> well, first and foremost, they need toe get to a point where their infrastructure is agile and they get into a business model off knowing how to monetize that agile infrastructure. So, for example, they could offer network as a service on a consume as you go basis. They could offer a platform as a service on top off that network in order for or titties to go build applications so they can do Rev shares with the forties. Or they could have offer. Full service is where they could go in and say, We are the conferencing provider for videoconferencing for enterprises. I mean, these are all models that >> the great conversation love to do. Your Palo Alto? Yes. Have you in our studio want to do more of a deep dive? We love the serious, super provocative, and it's important Final question for you. Though Pat Sr here on the Cube, lay asked him, Look back in the past 10 years. Yeah, look back in the next 10 years. What waves should everyone be riding? He said three things that working security and kubernetes humans being number one actually promoting convinced everyone for the ride, for obvious reasons, clouded. I get that, but networking Yeah, that's your world. That's changing. Which which events do you go to where you meet your audience out there in the telco because networking is a telco fundamental thing. Sure moving packets around. This is a big thing, >> eh? So far, operator networking related stuff, I would say. I mean the biggest shows that for us would be Mobile World Congress as an example, right? It's where many operators are. But I would also say that when we do our own events like this is the ember. But the movie forums in in Asia packers an example. A lot of the telco conversations I find they are best done one on one before. Yeah, the forums are our forums, but we will goto have one on one conversations or small group conversations >> with our telco customers. Locals Shakaar Thanks for spending. You get a hard stop. Very busy. >> Thank you. Thanks for having me >> here, Sugar Yaar, Who's here inside the Cube bringing down five G, which is still pregame. A few winning something first thing is gonna come up soon, but edges super hot. A lot of telco customers be back with more live coverage of the emerald after this short break