>> Narrator: Live From Seattle, Washington it's theCUBE, covering KubeCon and CloudNativeCon North America 2018. Brought to you by Red Hat, the cloud-native computing foundation and antiquo system partners. >> Okay welcome back everyone it's live coverage here at theCUBE at KubeCon and CloudNativeCon here at Seattle for 2018 event. 8,000 people, up from 4,000 last year. I'm John Furrier with Stuart Miniman, my cohost. Next guest Daniel Berg, distinguished engineer at IBM Cloud Kubernetes Service. Daniel, great to have you on. >> Thank you. >> Thanks for joining us. Good to see you. I'll say you guys know a lot about Kubernetes. You've been using it for a while. >> Yes very much. >> Blue mix, you guys did a lot of cloud, a lot of open source. What's going on with the service? Take a minute to explain your role, what you guys are doing, how it all fits into the big picture here. >> Yeah yeah yeah so I'm the distinguished engineer over top of the architecture and everything around the Kubernetes Service. I'm backed by a crazy wicked awesome team. Right? They are amazing. They're the real wizards behind the curtain right? I'm the curtain is basically all it is. But we've done a phenomenal amount of work on IKS. We've delivered it. We've delivered some amazing HA capabilities, highly reliable but what's really great about it is the service that we provide to all of our customers? We're actually running all of IBM cloud on it, so all of our services, the Watson service, the cloud dataset base services, our keepertech service, identity management, billing, all of it, it's all running. First of all it's moving to containers and Kubernetes and it's running on our managed service. >> So just to make sure I get it all out there, I know we talked to a lot of other folks at IBM. I want to make sure we table it. You guys are highly contributing to the upstream. >> Daniel: Yes. >> As well as running your workload and other customers' workloads on Kubernetes within the IBM cloud. >> Unmodified right? I mean we're taking upstream and we're packed in and the key thing that we're doing is we're providing it as a managed service with our extensions into it. But yeah we're running, we've hit problems over the last 18, 20 months right? There's lots of problems. >> Take us into people always wonder what happens when this reaches real scale. So what experiences, what can you share with us? >> So when you really start hitting like real scale, real scale being like 500, 1,000, couple thousand nodes, right, then you're hitting real scale there. And we're dealing with tens of thousands of clusters, right? You start hitting different pressure points inside of Kubernetes, things that most customers are not going to hit and they're gnarly problems, right? They're really complicated problems. One of the most recent ones that we hit is just scaling problems with CRDs. Now that we've been promoting heavily CRDs, customized Kubernetes, which is a good thing. Well, it starts to hit another pressure point that you then have to start working through scaling of Kubernetes, scaling of the master, dealing with scheduling problems. Once you start getting into these larger numbers that's when you start hitting these pressure points and yes we are making changes and then we're contributing those back up to the upstream. >> One of the things we've been hearing in the interviews here and obviously in the coverage is that the maturation of Kubernetes, great, check, you guys are pushing these pressure points, which is great cause you're actually using it. What are the key visibility points that you're seeing where value's being created, and two what're some of the key learnings that you guys have had? I mean, so you're starting to see some visibility around where people can have value in the stack. Well, or not stack, but in the open source and create value and then learnings that you guys have had. >> Right, right, right. I mean for us the key value here is first of all providing a certified Kubernetes platform, right? I mean, Kubernetes has matured. It has gotten better. It's very mature. You can run production workloads on it no doubt. We've got many many examples of it so providing a certified managed solution around that where customers can focus on their application and not so much the platform, highly valuable right? Because it's certified, they can code to Kubernetes. We always push our teams both internal and external focus on Kubernetes, focus on building a Kube native experience cause that's going to give you the best portability ability moving whether you're using IBM cloud or another cloud provider right? It's a fully certified platform for that. >> Dan, you know, it's one thing if you're building on that platform but what experience do you have of taking big applications and moving it on there? I remember a year or two ago it seemed like it was sexy to talk about lift and shift and most people understand it's like really you just can't take what you had and take advantage of it. You need to be, it might be part of the journey but I'm sure you've got a lot of experiences there. >> Yeah we've got, I mean, we've seen almost every type of workload now cause a lot of people were asking Well, what kind of workloads can you containerize? Can you move to Kubernetes? Based on what we've seen pretty much all of them can move so and we do see a lot of the whole lifT and shift and just put it on Kubernetes but they really don't get the value and we've seen some really crazy uses of Kubernetes where they're on Kubernetes but they're not really, like what I say Kube native. They're not adhering to the Kubernetes principles and practices and therefore they don't get the full value so they're on Kubernetes and they get some of the okay we're doing some health checking but they don't have the proper probes right? They don't have the proper scheduling hints. They don't have the proper quotas. They don't have the proper limits. So they're not properly using Kubernetes so therefore they don't get the full advantage out of it. So what we're seeing a lot though is that customers do that lift and shift, but ultimately they have to, they have to rewrite a lot of what they're doing. To get the most value, and this is true of cloud and cloud native, ultimately at the end of the day if you truly want to get the value of cloud and cloud native you're going to do a rewrite eventually and that will be full cloud native. You're going to take advantage of the APIs and you're going to follow the best practices and the concepts of the platform. >> Containers give you some luxury to play with workloads that you don't maybe have time to migrate over but this brings up the point of the question that we hear a lot and I want to get your thoughts on this because the world's getting educated very fast on cloud native and rearchitecting, replatforming, whatever word you want to use, reimagining their infrastructure. How do you see multicloud driving the investment or architectural thinking with customers? What're they, what're some of the things that you see that are important for 2019 as people are saying you know what? My IT is transforming, we know that, we're going to be a multicloud world. I've got to make investments. >> You definitely have to make those. >> What are those investments architecturally, how should they lay those out? What're your thoughts? >> So my thought there is ultimately, you've got focus on a standardized platform that you're going to use across those because multicloud it's here. It's here to stay whether it's just on premises and you're doing off premises or you're doing on premises and multiple cloud vendors and that's where everybody's going and it's going to be give it another six, 12 months. That's going to be the practice. That's going to be what everybody does. You're not one cloud provider, you're multiple. So standardization, community, massive. Do you have a community around that? You can't vendor lock in if you're going to be doing portability across all of these cloud providers. Standardization governance around the platform the certification so Kubernetes you have a certified process that you certify every version so you at least know I'm using a vendor that's certified. Right? I have some promise that my application's going to run on that. Now is that as simple as well I picked a certified Kubernetes and therefore I should be able to run my application. Not so simple. >> And operationally, they're running CICD, you got to run that over the top. >> You've got to have a common, yeah, You've got to have a common observability model across all of that, what you're logging, what're you're monitoring, what's your CICD process. You've got to have a common CICD process that's going to go across all of those cloud providers, right, all of your cloud environments. >> Dan, take us inside. How're we doing with security? It's one of those sort of choke points. Go back to containers when they first started through to Kubernetes. Are we doing well on security now and where do we need to go? >> Are we doing well on it? Yes we are. I think we're doing extremely well on security. Do we have room for improvement? Absolutely everybody does. I've just spent the last eight months doing compliance and compliance work. That's not necessarily security but it dips into it quite often right? Security is a central focus. Anybody doing public cloud, especially providers, we're highly focused on security and you've got to secure your platforms. I think with Kubernetes and providing first of all proper isolation and customers need to understand what levels of isolation am I getting? What levels of sharing am I getting? Are those well documented and I understand what my providers providing me. But the community's improving. Things that we're seeing around like Kubernetes and what they're doing with secrets and proper encryption, encryption, notary with the image repositories and everything. All that plays into providing a more secure platform so we're getting there, things are getting better. >> Well there was a recent vulnerability that just got patched rather fast. >> Daniel: There was. >> It seemed like it moved really quick. What do we learn from that? >> Well we've learned that Kubernetes itself is not perfect, right? Actually I would be a little bit concerned if we didn't find a security hole because then that means there's not enough adoption, where we just haven't found the problems. Yes we found a security hole. The thing is the community addressed it, communicated it, and all of the vendors provided a patch very quickly and many of them like with IKS we rolled out the patch to all of our clusters, all of our customers, they didn't have to do anything and I believe Google did the same thing so these are things that the community is improving, we're maturing and we're handling those security problems. >> Dan, talk about the flexibility that Kubernetes provides. Certainly you mentioned earlier the value that can be extracted if you do it properly. Some people like to roll their own Kubernetes or they want the managed service because it streamlines things a bit faster. When do I want management? When do I want to roll my own? Is there kind of a feel? Is it more of a staffing thing? Is it more scale? Is it more application, like financial services might want to roll their own? We're starting to maybe see a different industry. What's your take on this? >> Well obviously I'm going to be super biased on this. But my belief there is that I mean obviously if you're going to be doing on premises and you need a lot of flexibility. You need flexibility of the kernel you may need to roll your own right? Because at that point you can control and drive a lot of the flexibility in there, understanding that you take on the responsibility of deploying and managing and updating your platform, which means generally that's an investment you're going to make that takes away from your critical investment of your developers on your business so personally I would say first and foremost... >> It's a big investment. >> It's a massive investment. I mean look at what the vendor, look at IKS. I've got a large team. They live and breathe Kubernetes. Live and breathe every single release, test it, validate it, roll updates. We're experts at updating Kubernetes without any down time. That's a massive investment. Let the experts do it. Focus on your business. >> John: And that's where the manage piece shines. >> That's where the mange piece absolutely shines. >> Okay so the question about automation comes up. I want to get your thoughts on the future state of Kubernetes because you know we go down the cloud native devops model. We want to automate away things. >> Daniel: Yes. >> Kubernetes is that some differentiation but I don't want to manage clusters. I don't want to manage it. I want it automated. >> Daniel: Yeah. >> So is it automating faster? Is it going to be automated? What's your take on the automation component? When and where and how? >> Well, I mean through the manage services I mean it's cloud native. It's all API driven, CLIs. You've got one command and you're scaling up a cluster. You get a cluster with one command, you can go across multiple zones with one command. Your cluster needs to be updated you call one command and you go home. >> John: That sounds automated to me. >> I mean that's fully and that's the only way that we can scale that. We're talking about thousands of updates on a daily basis. We're talking about tens of thousands of clusters fully automated. >> A lot of people have been talking the past couple of weeks around this notion of well all containers might have security boundary issues. Let's put a VM around it maybe stay for is it maybe just more of a fix? Cause why do I want to have a VM or is it better to just keep native core? Is that real conversation or is that fud? >> I mean it is a real conversation because people are starting to understand what are the proper isolation levels with my cluster. My personal belief around that is you really only need that level of isolation, those mini VMs, around your containers. Running a single container in a single VM seems overkill to me. However if you're running a multitenant cluster with untrusted content you better be taking extra precautions. First and foremost I would say don't do it because you're adding risk, right? But if you're going to do it yes, you might start looking at those types but if you're running a cluster in its an isolated cluster with full isolation levels all the way down to the hardware in a trusted environment, trust being it's your organization, it's your code. I think it's overkill then. >> Future of Kubernetes what happens next? People are hot on this. You've got service meshes, a lot of other goodness. People are really trying to stay with the pace, a lot of change and again a lot of education. But it's not a stack like I hear words like Kubernetes stack and the CNCM has a stack. So it's not necessarily a stack per se. >> Right it's not. >> Clarify the linguistic language around what we're talking about here. What's a stack? What's not a stack? It's all services. >> Look at it this way. So Kubernetes has done a phenomenal job as a project in the community to state exactly what it's trying to achieve, right? It is a platform. It is platform for running cloud native applications. That is what it is and it allows vendors to build on top of it. It allows customers to build on it and it's not trying to grow larger than that. It's just trying to improve overall that platform and that's what's fantastic about Kubernetes because that allows us and when you see the stack it's really cloud native. What pieces am I going to add to that awesome platform to make my life even better? Knative, Istio, a service measure. I'm going to put that on because I'm evolving, I'm doing more microservices. I'm going to build that on top of it. Inside of IBM we did cloud foundry enterprise environment, CFEE, cloud foundry on Kubernetes. Why not, right? It's a perfect combination. It's just going up the level and it's providing more usability, better different prescriptive uses of Kubernetes but Kubernetes is the platform. >> When I think about the composability of services it's not a stack. It's lego blocks. >> Daniel: Yeah it's pieces. I'm using different pieces here, there, everywhere. >> All right well Daniel thanks for coming on, sharing great insight. Congratulations on your success running major workloads within IBM for you guys and the customers. Again just the beginning, Kubernetes the beginning. Congratulations. Here inside the Cube we're breaking down all the action. Three days of live coverage. We're at day one at KubeCon and CloudNativeCon. We'll be right back with more coverage after this short break.