 From our studios in the heart of Silicon Valley, Palo Alto, California, this is a CUBE Conversation. Hello everyone, welcome to this special CUBE Conversation here in the CUBE studios here in Palo Alto, California. I'm John Furrier, host of theCUBE. We have a special series we're starting called Demystifying Cloud Native. And I'm joined with my co-host of this series, Dominic Tornau, Principal Engineer with Cisco, Office of the CTO, Dominic, thanks for joining me. Thanks for agreeing to participate in this awesome series around demystifying cloud native. Thanks. Thanks for having me. So cloud native is hot, but it's changing. It's super important. Some people have a definition here or there. What is your definition of cloud native? Well, for, to define cloud native, let's use a mechanical approach, right? So we are talking about cloud native applications. So the first question there would be, what is cloud? And I personally define the cloud as a service provider that allows a service consumer to dynamically acquire and release resources. Now, from that point, with that definition in mind, we can define three related concepts. That would be public cloud, private cloud and hybrid cloud. So the public cloud is a service provider outside of your organization. The private cloud is a service provider inside your organization. And the hybrid cloud is a union of both. So with this definition, we can define a cloud application. And a cloud application then is any application that runs on a cloud provider, right? But now what is a cloud native application, right? If I take a classical application and put it on the cloud, it becomes a cloud application by definition, but it doesn't become a cloud native application. If we wanna grok cloud native applications, right? We gotta grok a concept that is responsiveness. Responsiveness is very close to availability, but the term availability is highly overloaded. So I personally like to talk about responsiveness. And responsiveness is the ability of an application to hit its service level agreements. Typically, it's response time, right? A typical service level agreement may be 90% of my requests need to be served within 250 milliseconds. So that is the responsiveness of an application. And now we can define scalability and reliability. Scalability is responsiveness under load, and reliability is responsiveness under failure. And now to close the loop, we can define cloud native. And my definition of a cloud native application is a cloud application that is scalable and reliable by construction. Dominic, what is your view on hybrid versus multi-cloud? Because that's something that we see a lot in the industry around hybrid being public private, union of that, you mentioned that. But the talk of multi-cloud is being kicked around a lot. What's the reality of multi-cloud? Is that just I have multiple clouds. What's the impact to development teams and companies as they think about hybrid and multi-cloud? So the hybrid cloud, right, is an instance of a multi-cloud because by definition you have multiple cloud providers that make up the multi-cloud. And in a hybrid cloud, you have at least one public and at least one private cloud. And of course, the implications, whether it's public to public or public to private cloud are huge. It does affect your application all the way from the architecture down to the way how you operate your application, right? And when it comes to multi-cloud, we are looking at significant challenges when it comes to the operation, automation and the federation between the clouds. What do you think about the role Kubernetes is going to play in the enterprise? Because right now it's really, I think one of the most popular, if not, the most de facto things I've seen in many, many years. I think it's, to me, I think, the only thing I think about that's impactful as Kubernetes is going way back to TCPIP, what that meant for internet working, which spawned massive change, massive wealth creation, massive computing capabilities, essentially created networking subnets and as we know networking as we know it. Kubernetes has that same feel to it in a whole nother kind of modern way. It seems to be something that people are getting behind in a de facto, it's not officially a standard, I guess what it could be, how important, what's the big deal around Kubernetes? Oh, Kubernetes, so Kubernetes is definitely something that is exciting in the ecosystem because it puts cloud native in all of our reach, right? With Kubernetes, cloud native is up for grabs, right? A cloud, any application, when you just put it on Kubernetes, it won't become a cloud native application just by containerization, right? But Kubernetes provides so many primitives that actually allow you to address a challenge of scalability and allow you to address a challenge of reliability. And on top of that, it has as you mentioned the energy in the ecosystem, right? And with Kubernetes, if you architect your application right, you do have a chance to efficiently, cost efficiently and also effort efficiently have a cloud native application that is scalable and reliable by construction. And if you think about it, it's scalable and reliable by construction that requires your application to be able to A, detect load and failure, and B, mitigate load and failure. And now if you take Kubernetes and you take it apart and you look under the hood, you see that the Kubernetes primitives are actually designed for that, right? They allow the application to scale itself. They allow the application to actually recover from failure. You do have to architect your application that way. If your application cannot handle partial failure, your container comes down and with your container, you're actually losing, you're losing vital state in your application, Kubernetes cannot help you with that. But if you architect it correctly, Kubernetes will never stop trying to actually meet your demand. That's a great point. How has Kubernetes changed the relationship between the application and the application developer's requirements? Because I think a lot of people see Kubernetes as a silver bullet. Oh my God, Kubernetes is going to solve all my problems. That's not really what it is there for. You're kind of getting at that. Detecting failure, understanding events. These are things that are super important, but the application folks have to do the work. Can you just unpack that relationship between the app builder? What's my relationship to Kubernetes? I love hate relationship because Kubernetes is going to help you a lot, but Kubernetes also demands a lot, right? So... Explain that. Demands a lot. What does it mean by that? The architectures that we are used to. Sorry. It demands a lot. It demands a lot. The architectures that we are used to need to change. And if you come from, let's say 10 years ago, 15 years ago, right? And we are building a reactive application, which at that point would just be called a web application. You have a request coming in and the web server taking that request and basically spawning the request context. In that request context, your application is still sequential, right? And if everything fails, the database is here to save the day, the transaction is here to save the day and will prevent you from running into any inconsistencies. Now, if we are in a microservice architecture world, multiple different microservices, no transactions there to save the day, you have to architect with that reality in mind. Kubernetes cannot provide an abstraction that make the reality of distributed applications disappear and look like one local application. It cannot. However, it can support you. If you got the application architecture right, it can support you to actually bring the application to life. And in that case, I do like to differentiate between system, application and platform. The application is all the bits that you built, right? The platform is all the bits that run your application and it is the system, basically the combination once the application and the platform are composed, right? That is now scalable and reliable by construction. And you can rely on a lot of pieces when it comes to Kubernetes to actually make this a reality. So as people are out there thinking about cloud native, this modern error is upon us. We've seen observability become a very important topic and that's basically a network management in my mind, but we've seen observability have its own category and there's been successes out there. Pager, duty, signal effects, all got liquid, all these ventures got successes. Automation is another area. How do you see the interplay between automation and observability? Because Kubernetes has a lot of things going on. Applications are going to have a lot more services happening with microservices and other things. Observability and automation are two important concepts. Besides orchestration, Kubernetes, the observability and automation, how do you see those fitting into that cloud native architecture? So observability, when we hear observability, right? We should ask ourselves the question, well, who is the observed and who is the observer? And classically, if you think of the observer, we think about ourselves, right? We have either the developers and we have an operations team and it is the operations team that is fed the data from the observability tool set, right? However, now if we bring operations into the mixture and especially operation automation, we can close the loop between observability, automation operation and again, observability. That is the observability tool set, right? Monitoring the application feeds into the operation of the application in order to actually, again, orchestrate parts of the application. And here with Kubernetes is actually the perfect example and a very simple example is autoscaling. So autoscaling on Kubernetes, we are basically just monitoring either metrics, like for example, CPU load or memory pressure or CPU load and memory load. Or we are looking into application metrics like the messages queued up in a message queue. And this is now the indicator for Kubernetes to actually scale up more parts on demand or scale down more parts on demand. And yes, this is not rocket science. We had this for a while, yet with Kubernetes and its extensibility, right? We can take that further and further down up from a very generic level where we have autoscaling on a very generic level to an absolutely application specific or use case specific level. If you dig into Knative, for example, you will actually quickly discover that Knative is or especially Knative serving, one of the subsets on Knative is a operations automation platform for microservice applications on Kubernetes. And again, it feeds the observability into the operation and the operation into the observability. They work hand in hand. They work hand in hand. Daimak, I want to ask you, put you on the spot here with a question. So take your time to think about this. What is the most important story or thread or topic or interest that people should pay attention to in this cloud native wave? And the second part is, what's the most important thing that people need to be paying attention to? They might not be paying attention to. Well, unfortunately, I think I have to disappoint you. The one most important one is actually very hard to find. It will influence everything. It will influence your organization. It will influence the architecture of the application. It will influence how you operate these applications and how you move forward with new versions. So which one is the most important one or the most significant one very much depends on your role. But there is absolutely no question that the cloud native journey affects all of these roles. So then you could argue that the top story is that cloud native is a completely new operating model different from the old way of doing it. Do you agree with that? I very much agree with that. Some people think like cloud native, I don't even know what that is. I'm in the 1990s with my IT department and my application developer still running single threaded mainframes. You know, based on the definition, doesn't the definition actually sound pretty innocent, right? Scalable and reliable by construction. That actually doesn't sound like it's magic dust and that also doesn't sound too hard. But once you actually start uncovering and dive into what that actually means, right? Then you see that the implications of that, right? Are far reaching. It starts from UX engineering to software engineering to the operations and will affect the entire organization and the organization. Let's just say you and I are having a beer. It's October Fest, you know, we're having a beer and I say, hey, I've got to get moderate with my IT. My boss is, you know, banging down my door saying, we need to go cloud native. We got to get modern applications. But we're running old school IT. Dominic, what do I do? Give me some advice. What's the playbook? What's your, what would you tell me? Oh, playbook is again, actually fairly hard because on the one side, we are actually not very far into this journey. So it is not necessarily that there is a lot of chapters in this playbook to choose from. And the other one is you have to give your IT department the possibility to actually re-architect the entire system. Of course, this is a step-by-step journey and you cannot do this overnight. But if you want to arrive at a truly cloud native destination, you actually have to walk the entire cloud native journey. Talk about the intersection between design and development because this again, if everything's flipped upside down where applications are in charge, UX and UI are important. UX, meaning thinking about the user experience, engineering is super critical to get that done up front, just like security. If security is being done on the front end, baked into everything, doesn't UX have to be baked into everything? If that's the case, that's again a dynamic. So what's your take on that development and design intersection? Remember 15 years ago? It was like, when do we bring in a UX designer? At the end of the project. At the absolute end of the project, exactly. So we have it ready and then we have only one demand, make it pretty, right? So obviously that didn't work great. Well, I mean, that made sense. I think with the web, web was very limited at the time, HTML, and you had some interactive base interactive features. So it was limited tool set then. At that time it did work, but it was still not ideal. I agree. Right, but now we actually, we need to flip the playbook there on its head. And I would argue that as an application developer, my boss, so to say, the one who is giving me the requirements are the UX engineers by now. So the UX engineers are the ones, that determine the functional requirements of my application. Now, as an application engineer, I still determine A security and B also the non-functional requirements of my application. And once again, we come to reliability or we come to scalability and reliability by construction. So we also need to start working hand in hand together. So UX and UX design or design and development, looking at design and development, you see there is somewhat of a misalignment to begin with. UX design is responsible for building the right thing and development is responsible for building the thing right. So in that case, we are almost orthogonal on our way, right? And in the cloud native world actually forces us together. And as a simple example, if you look at one webpage now, that may actually be served by multiple microservices. So given the possibility of partial failure, right? Will the page come up or will the page not come up is actually not a binary condition or a binary decision anymore, right? Parts of the page may be up, parts of the page may be down. Is that critical? Is the page still viable or is it not? That is for the UX designer to decide and I am here to help. So how's the balance get aligned? How do you realign that you're saying bring in UX to lead the application development, then to the application developer, then to the development team? It actually has to be very short feedback cycle. So I personally argue for designers and developers going along that journey together. So there shall not be a handoff. Once there is an actual handoff, you already lost. So cloud native, we're bringing everything together. UX, the front end applications taking control, infrastructure as code. This paradigm is significant. This is here to stay for the next generation or two at least. Yes, this paradigm actually does change how we approach software engineering at large. All right, we're going to dig into more of it. There's plenty more to talk about. We've got KubeCon coming up in San Diego, Istio, service meshes, stateful applications, a lot more stuff to talk about. Dominic, thanks for having this conversation. Demystifying cloud native here with Dominic Tornau, principal engineer at Cisco, office of the CTO. I'm John Furrier of theCUBE. Thanks for watching.