(upbeat music) >> 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 theCUBE 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 cohost for this series, Dominik Tornow, Principal Engineer with Cisco Office of the CTO. Dominik, thanks for joining me, and thanks for agreeing to participate in this awesome series around demystifying cloud-native. >> Hey, 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, alright. So, we are talking about cloud-native applications. So, the first question there would be "what is cloud?" Alright. 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, alright. But now, what is a cloud-native application, alright? If I take a classical application and put it on the cloud it it becomes a cloud application by definition, but it doesn't become a cloud-native application. If we want to grasp cloud-native applications, alright, we've got to grasp 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 a 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. >> Dominik, what is your view on hybrid versus multi-cloud? Cause that's something that we a lot of in the industry around hybrid being public private, a union of that. And 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 the 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 effect your application all the way from the architecture down to the way how you operate your application, alright. And when it comes to, 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? Cause right now, it's really, I think, one of the most popular, if not the most defacto things I've seen in many, many years. I think it's--to me I think-- The only thing I can think of as impactible as Kubernetes is going way back to TCPIP and what that meant for internet working, which spawned massive change, massive wealth creation, massive computing capabilities. It essentially created networking subnets and, as we know, networking as we know it. Kubernetes has that same feel to it in a whole another kind of modern way. It seems to be something that people are getting behind in a defacto--it's not officially a standard, I guess. Well, it could be. How important--what's the big deal around Kubernetes? What's your thoughts on this? >> Oh, Kubernetes are 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, alright. A cloud--any application, when you just put it on Kubernetes, it won't become a cloud-native application just by containerization, alright. But Kubernetes provides so many primitives that actually allow you to address the challenge of scalability and allow you to address the challenge of reliability. And top of that, it has, as you mentioned, the energy in the ecosystem, alright. 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, 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, alright. They allow you to-- They allow the application to scale itself. They allow the application to actually recover from failure. You do have to up and architect your application that way. If your application cannot handle partial failure, your container comes down and with your container you are actually 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 demands. >> That's a great point. How has Kubernetes changed the relationship between the application and the application developers' requirements. Because I think a lot of people see Kubernetes as this silver bullet. Oh my god, Kubernetes's going to solve all my problems. But that's not really what it is there for. You're kind of getting at that. Detecting failure, understanding the 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 I'm the app builder. What's my relationship to Kubernetes? >> (laughs) A love hate relationship. Because Kubernetes is going to help you a lot, but Kubernetes also demands a lot, alright. So-- >> Explain that. Demands a lot. What did you 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 a web server taking that request and basically spawning the request context. In that request context, your application is still sequential, alright. And if everything fails, the database is here to save the day, the transactions. It's here to save the day and will prevent you from running into any inconsistencies. Now, if you're in a microservice architecture world right, 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've 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 build, 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 era's upon us. We've seen observability become a very important topic. And that, you know, that's basically network management in my mind. But we've seen observability have its own category and its big successes out there, PagerDuty, SignalFx, they all got li-- Well all these ventures got successes. Automation's another area. How do you see the interplay between automation and observability? Because Kubernetes has a lot of things going on. Application's going to have a lot more services happening and with microservices and other things. Observability and automation are two important concepts besides orchestration Kubernetes, though observability and automation. How do you see those fitting into that cloud-native architecture? >> So, observability. When we hear observability, right, we should ask ourself the question where "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 or we have an operation's team, and it is the operations team that is fed the data from the observability tool set, alright. 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, alright, 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 pods on demand or scale down more pods on demand. And yes, this is not rocket science. We had this for a while, yet with Kubernetes and it's 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 K Native, is a operations automation platform for microservice applications on Kubernetes. And again, it feeds the observability into the operations and the operations into the observability. >> They work hand in hand? >> They work hand in hand. >> Dominik, 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 that 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 your applications. 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 effects 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? >> Yes. >> Would you agree with that? >> I very much agree with that. >> Because 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's still running "single threaded mainframes." >> You know, based on the definition-- Doesn't the definition actually sound pretty innocent? Alright. 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 it will effect the entire organization and organizational setup. >> Let's just say you and I are having a beer. It's Oktoberfest, you know, we're having a beer, and I say, "Hey, I have, you know, "I've got to get modern with my IT. "My boss is, you know, banging down my doors saying "We need to go cloud-native. "we've got to get modern applications." But we're running old school IT. Dominik, what do I do? Give me some advice. What's the playbook? What's your--what would you tell me? >> A 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 wanted 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. Cause this, again if everything is 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 upfront, 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. (laughs) >> At the absolute end of the project, exactly. So we have it ready, and then we have only one demand, make it pretty, alright. So, obviously, that didn't work great. >> Well, I mean that made sense in with in the web, the web was very limited at the time, HTML and you had some interactive base interactive features, so it was a limited tool set then. >> At that time, it did work, but it was still not ideal. >> Yes, and I agree. >> Right? But now we actually--we need to flip. 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 right now. So, the UX engineers are the ones, alright, that determine the functional requirements of my application. Now, as a 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. Okay. 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 web page now, that may actually be served by multiple microservices. So, given the possibility of partial failure, alright, will the page come up, or will the page not come up? It's 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 them. >> 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 hand off. Once there is an actual hand off, you already lost. >> So cloud-native. We're bringing everything together. UX, the front end. Applications taking control. Infrastructure is code. This paradigm's 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. >> Alright, we're going to dig into more of it. There's plenty more to talk about. We've got CUBEcon coming up in San Diego, STO, service meshes, state flow applications, a lot more stuff to talk about. Dominik, thanks for having this conversation demystifying cloud-native, here with Dominik Tornow, Principal Engineer at Cisco, Office of the CTO. I'm John Furrier, theCUBE. Thanks for watching. (energetic music)