 From Copenhagen, Denmark, it's theCUBE. Covering KubeCon and CloudNativeCon Europe 2018. Brought to you by the CloudNative Computing Foundation and its ecosystem partners. Hello everyone, welcome back to theCUBE's exclusive coverage here in Copenhagen, Denmark for KubeCon 2018, part of the CNC at the CloudNative Compute Foundation, part of the Linux Foundation. I'm John Furrier, co-host of theCUBE. Here with my co-host this week, Lauren Cooney, the founder of Spark Labs. Got two great guests in the industry here, Lutuck or the CTO of Cloud Computing for Cisco Systems and Aparna Sinau, who's the group product manager for Google Cloud. Thanks for coming on, great to see you guys. Great to be here. Thanks for having us. So I'll say the two big players, you got networking, you got me moving up the stack at Google Cloud with all the goodness you have hundreds of people here at this show. CloudNative, big, you're CloudNative. Yep. You guys are running the networks, a lot of stuff's happening. The big story is the Kubernetes de facto standard position that's been echoed by many people here. Kubernetes tightly controlled core with a lot of innovation going on around Kubernetes. Yes. When I hear words like de facto standards, it reminds me of the old networking days when the OSI model and the TCP IP was forming. Massive shift at that point. Almost a seminal moment now. But in fact, I think that in open source, it's a different notion than the old days of standards. Here we've got multiple communities, multiple companies that are working together to create a common platform. And that's what I think the success of open source is about. So actually Kubernetes coming into CNCF has really makes that possible. And we just graduated it. So we should have a celebration around that Kubernetes now has graduated in terms of a CNCF project. Yeah. You know, one thing I would say about de facto standard, I don't take that for granted. Kubernetes is built as a platform that runs anywhere across on-premises, data centers, public clouds, runs anywhere. But you know that it will be or is a de facto standard is something that we don't take for granted. We make sure in the community that we're working on increased support for, for example, different types of storage with a storage interface standard, different types of networking with a CNI, different types of runtimes. So establishing those interfaces and establishing those standards is key to making it the platform. But that's certainly the potential of Kubernetes is to be. I mean, it's not the end game, it's the beginning. It is. And the nurturing and making sure that ecosystem will thrive is important. And that's why I want to get your thoughts because you got Google and Cisco here. So let's talk about first the relationship. You guys are working together. Absolutely, yeah. Talk about the relationship between Google and Cisco. I think it came about because we're both recognizing the enterprises, for example, are incorporating cloud computing as a part of their overall IT strategy. And so they need to find a way, how can they actually make that happen without companies that are working in both of those areas getting together? So it's very natural, I think, for the two of us to sort of come together because this way we can take our enterprise customers and using Kubernetes as sort of the foundational platform, make it so that they can run applications wherever they want. They can run it in their private data center. They can run it in Google Cloud. And we can make this now provide a lot of the networking so that you can extend private networks into Google Cloud and vice versa. So I think it's a marriage made in heaven in that way. Aparna, your reaction to this is a partnership. Yeah, you know, Google is a very developer-friendly, developer-focused company. Always has been, you know, the majority of Google is actually developers. So it's a company for developers, by developers. And, you know, with Google Cloud actually, the irony is we're also a networking company. And so there's a nice affinity working with Cisco. Our DNA is very much open source. There's multiple projects that have come out of Google that have been very successful open source projects. I mean, TensorFlow, Kubernetes I think is unique in that we've really created and participated and built a community around it. And so with this partnership, we're really excited to have Cisco also be part of the community, certainly with Kubernetes, but also the Istio project. And a lot of the projects in Cloud Native have come from Google's experience running services at global scale. Kubernetes certainly came that way from the board heritage. And then Istio also, from what we call one platform, internally, to manage services. That's a great point. You brought up scale and it's interesting. It's almost like you have two large scale companies here. You got Cisco with massive scale footprint of enterprises from day one. Routers, you need to move packets around the internet. You guys have built scale for Google with millions of services out there, millions of users. I mean, it's just unprecedented. So now as you come into the enterprise, the Cisco relationship is an opportunity to blend the best of the Google with a footprint at Cisco. How is that going to work? How's that working? And what's the vision? I mean, obviously it's a nice match. You got a great footprint in the enterprise. Get massive scale with the cloud. Bringing that in, moving that out. Hybrid cloud, obviously. Is that the... Well, we also noticed, for example, as I sort of said, the foundational piece is actually running Kubernetes everywhere. And so we just recently announced a Cisco container platform, which is based on Kubernetes. That means that enterprises now can develop applications in Google Cloud and then run them in their enterprise, or vice versa. And then on top of that, we're adding then the networking capabilities, three things such as CSR and things like that to allow us to connect both the enterprise and their public cloud running Kubernetes. And then Istio, as we were mentioning, is this thing on top. And I'm, as you know, a big fan of where that really is going to take us. Because I think one of the things that enterprises want to be able to do is they want to be able to consume services out of Google Cloud, whether it be in terms of the kind of data services or increasingly AI, intelligence services, TensorFlow, be able to use it as a part of their enterprise applications. And so I have within my team, for example, contributors, both in terms of what we're doing in terms of Istio, Kubernetes. I've got people on my team who are bringing, for example, IPv6 into Kubernetes. That's important because guess what? Service providers also want to move into a container world. And then also Kubeflow. And so all of these things are starting to come together so that you can start building applications as an assembly of these services and many of those services that I will see coming from the public cloud and Google in particular. Yeah. Aparna, I want to ask you, because this is important to distinguish this Istio trend because we ask a lot of people in the queue here and then our reporting, okay, what's next at the Kubernetes? If you have a de facto standard, you've got stuff when coming around it in the ecosystem, everyone talks about Service Mesh and Istio project. Now the best thing about infrastructure as code, which is DevOps in the cloud, is you can make things programmable and automate. So if you look at what Istio is doing, it feels like an application benefit, but also an automated networking concept with services. So you've got kind of a new dynamic going on where a lot of dynamic things are happening, a lot of services are being provisioned maybe for the first time. So how do you instrument it? This is going to be a future area of innovation. So again, going back to that standard, that platform that runs everywhere, why is it a standard? Why is it becoming a standard? And I hear this from our customers, our users. It's because they don't have to train multiple times for multiple different environments. They can really scale their workforce. They can hire people that they train up in Kubernetes and they can scale that workforce. So it applies regardless of where they go and it gives them that mobility. And if you think about the ecosystem around Kubernetes, so Kubernetes is one project, a major big project, but then the ecosystem around Kubernetes has really exploded. In the last year, it has gone from 4,000 projects to 15,000 projects. And I was looking through those projects and seeing which are the ones that have the most stars and there's actually three projects that stood out as having more than 3,000 stars, but being new like in the last year and Istio is at the top of that list. And obviously it's very popular in terms of number of stars, but it's only one year old. And I don't know how much people know that. And I think it's interesting, because I'm going to throw kind of a curve ball here at you and say, you know, I'm hearing that the service mesh is actually, people are using it, but it's actually hasn't been deployed into production. Is that the case? Is that? It's starting to be. So on GKE, Google Kubernetes Engine, we've got customers that are deploying Istio. It's starting. Again, it's a one year old project. And then also on premise, using the open source and we've got a program called the EEP program. It's like an early program. They're deploying and using Istio. And it tends to be a very nice attach to Kubernetes. So what is the use case for that? So one of the things to understand, it is very new and less than a year old and we're not even at a one dot out yet. But the components that go into Envoy, for example, has been battle tested, because Istio is made up of, just to get technical in terms of having proxies that make up the data plane and that's battle tested or whatever. So now we're adding a control plane on top of that, where policy, telemetry, observability, all of that comes to the fore. That's what's new. And so bringing that together and so people have, and Istio is not the only service mesh. Service meshes have actually been made up of these proxies and how do you manage them? Istio seems to be a better way that the proxies can be very inefficient. So I want to just ask a question on that because one of the things that I'm trying to understand is for the average person in tech, not the inside baseball, they're trying to understand why is Istio so powerful? So is there what pain points are they solving? The easiest way to think about that is we move to a microservices architecture and that's so that every development team can focus on their particular area of expertise. They don't want to have to learn networking. Everything else, so what we've done and we've offloaded all of the issues around how do you do load balancing, circuit breakers and telemetry off to a service mesh? That allows the developer to dramatically increase their productivity because they're only focused on their one application area and now the operations team brings that together through the networking construct. So they built a distributed application without having to know really much about the security. Yes, it's very much that separation of concerns. So, and Kubernetes has the same principle. It separates the infrastructure from the applications. And what Istio does it, it allows you to manage those applications at scale, visualize them, make them secure and to control them in a scalable way. So you're not writing the service management pieces into the application and the developer is therefore freed from that burden and the application operations team can then manage things like distributing certificates or rotating certificates, right? Those are things you need to do across all of your services. So you're bringing up something that's interesting and I know you guys run at scale in hundreds of thousands of services, if not more. I don't know the numbers, millions, whatever it is. It's massive. Four billion containers. A lot, tons. A week. So when you talk about that, what I'm hearing and I've talked to the SRE site reliable engineers before, the role of the admin is gone to more of an operator. And then the operator role is less of an operating because it's operating only on exception because if you got policy in the control plane, that seems to where the action is. Is that, am I getting that right? How do you explain that notion of less admin, more operational kind of? There is a change in roles. The administration of the application is not so application specific, if you will, right? And I think the best analogy to it is the way that we do development at Google, everybody is a developer, right? And they write their services, but there's a lot of common infrastructure that you do not replicate. So for example, storage, monitoring, logging, publishing your API, quotas, rate limiting, charge backs, billing, all of that is common infrastructure. You write your service, it is immediately using all of that infrastructure. You don't build those things into your application. And that has so many benefits. You can write your service and it can be global. So one, time savings, no brain error. Automation. And when you change any one of those services, how the monitoring is done or anything else, now you don't have to tell the application development team that that changes the application. So this is infrastructure as code, passes the test, right? You can program the infrastructure. This is services. This is a services world, rather than an infrastructure world or an application-style load world. This is the world of services. That's really what we're here for. What's the growth in microservices? I'm seeing different stats. Can you just give an order of magnitude just from your own personal experience and looking at the market? How fast is the notion of microservices growing? Because this is really the proxy for the cloud native shift. And you guys certainly are microservices oriented. You, we talk about this all the time. Any data or any anecdotes around growth of microservices? Well, I mean, there's a lot of surveys. And most of the surveys point towards, I think containers are a good proxy. 88% of enterprises are using containers. It's becoming, whether you move to the cloud or not, actually, containers are basically a way of doing things more repeatedly, giving you efficiency from an infrastructure perspective, giving you reliability so that you can basically exchange out the hardware and your container environment is still resilient and then giving you that developer productivity. That's becoming something that enterprises are embracing, it seems, from the surveys. And I think that's the building block for microservices. And I think many people are already moved, we remember so, I mean, we've got history here. So that, we've been trying to move towards this world in which it is a services world. And before it was much too heavyweight. XML, RPC and everything that made it soap and everything else, difficult to do these things. Now things have gotten much, much easier. So a lot of people are actually doing a services architecture already. And the microservices, I think, is just a more formal way of doing that at a finer grain. And when you get to this finer grain, that's when you need something like a service mesh now to pull this thing back together again. All right, let's do a plug for the service mesh. People that are watching are going to be intrigued by this conversation. What's the state of the service mesh piece of it? A lot of stars, so good community vibe going on. How do they get involved? What's needed? What's the white space? Where's the work being done? Also, John, what skills are needed to actually kind of as a developer? We've got a lot of new folks here at the show that are just learning about this. And what do they need to know to actually do this and bring this back into their companies? Yeah. If they're, so first of all, it's at Istio.io. So that's the place to start. There's a lot of very good documentation there. There's very simple examples that can be downloaded so that you can try it out. You can try it out. We're using containers here on top of Kubernetes. You can do it on your laptop. You can do it in the cloud. So we're in this wonderful age of the internet, in fact, that most of the learning is done online and that you can get everything you need online. You don't have to walk away from the show with a CD pack or anything else like that. So I would encourage developers to just simply try it out themselves. Remember, though, then there's Istio developers, people who are actually contributing code into Istio. That's sort of a specialized group of people who are very interested in it. More people, it'll be 10 to one users of Istio, than there will be actually of the Istio developer community. And the Istio developer community, I urge people to get involved, because that's where we need to expand the number of use cases and make sure that we're covering the things that are important across the board for a variety of things. I mean, Istio is not that difficult to learn. It's an L7 proxy. It has a great affinity to the Kubernetes project. So if you are using Kubernetes or are involved in the Kubernetes project, then it basically is something that you can deploy into your Kubernetes cluster and get started with it. There are a number of trainings and workshops, actually at this conference. There were a couple of Istio trainings and there are many tracks. And then there's training online. There's a tutorial on the Google site with GKE and I think from many other companies as well to get started with Istio. But it's basically a proxy and it's not actually only limited to Kubernetes. You can run it in a VM environment. It basically any service, it is a proxy that intercepts and basically can provide load balancing, traffic management, quotas, all of those things that you expect of a rich proxy. And so if you have a networking background, it's actually very easy to pick it up. That's great. Now, when you're talking about this proxy and things along those lines, I'm sure that there are use cases that are the first ones to pop up. Can you talk a little bit about that? Yes, the first, I think first use case of Istio is actually Canary, Canary deployments. So being able to route traffic from one version of your application to another version of your application, make sure that that's, let's say it's an upgrade, make sure that that's running well and then gradually route more of your traffic. So that's a very developer centric, it's a use case that appeals. And then of course security. And that's a less developer centric more a control and ops perspective. And then observability and again control, also an ops perspective. Those are the three main use cases. That's great. That's awesome. And we get, you had Kubeflow going on here. You guys had a couple of Google folks on. So I mentioned three projects that are the top projects. Istio number one, number two is Kubeflow. Again, within the last year, more than 3,000 stars. And then the third one is Scaffold. Great stuff. I love the programmability, automation. And one of the things that was mentioned before, because when people hear proxy, they think of the old time, actually when you've used a proxy and a DNS there, which now it's very high performance. And one of the things that you're seeing also, it connects up with other open source projects such as FDIO, which is VPP, which is now being used integrated into Envoy, which is the proxy. So the data plane itself, I think is going to be more efficient than people trying to do their own network. That's a good point, Lou. I mean, people think proxies are inefficient. It's a hack, a bridge between point A and point B. That was a lot of the initial skepticism around this. So this was about two years ago, we were sitting around saying, okay, Kubernetes, what's next? And we came up with Open Service Broker so that you can consume services. And then the early start of Istio, starting with Envoy and then building the service mesh around that. And that was indeed one of the early concerns is, well, will it be too heavy? Will it add latency? Will there be a performance bottleneck? I think a lot of that concern has been addressed and it'll continue to be addressed. Well, we got to wrap up, but I want to get some comments from you guys. Reaction to the show here in Europe. I'll see Google is in big force. Istio is prime time. You predicted that in Austin. It looks like it's tracking beautifully. Reactions, what did you walk away with here from this event? What observations, revelations, surprises? Share some color for the folks who couldn't make it. We were talking earlier about the number of use cases now that we're seeing that our customers are coming in and describing how they're using Kubernetes and other of the technologies making up the cloud native world. And that allows people to learn. And so that's why I'm always excited because I can sit there in the audience and you can see everybody else going, oh, I'm going to apply that to what I'm trying to do. And just the breadth now. So you're surprised at the uptake or you're happy with the uptake. That's your reaction. And I think you would agree. Yeah, I think the reason I come to KubeCon is to meet users. It's a user conference and with each passing KubeCon it becomes more and more user centric. So some of the talks here, the takeaways that I had, the folks from Spotify talked about how users need to get more involved and the benefits of getting more involved in the community. That was a very inspiring talk. Another talk yesterday talked about how Kubernetes needs to be a platform for everything. Not just cloud native, but actually also legacy. And so these are points. And then the third piece, a lot of users talking about multicloud and making that a reality. These are things that I'm taking away as users are doing this today. Multicloud certainly is a path. People have that an outcome in mind. Doing the work now to get there. Thanks for coming on a part of it, Lou. Great to have you guys. You guys are awesome. Senior folks in the industry, experienced executives driving the change here. Cloud native, microservices architecture, whole new modern paradigm shift and software architecture here at KubeCon, Kubernetes, Istio Hot Projects, Kubeflow and more here on the Kube. Live coverage here in Copenhagen. Stay with us for more coverage after this short break.