(funky jazz music) >> From our studios in the heart of Silicon Valley, Palo Alto, California, this is a CUBE conversation. >> Hello, and welcome to theCUBE studios in Palo Alto, CA for another CUBE Conversation, where we go in-depth with thought leaders driving innovation across tech industry. I'm your host, Peter Burris. Everybody talks about the unbelievable explosion in the amount of data that digital business is going to generate. That's true. But there's an analogue to that, and that is the unbelievable explosion in software that's going to be created over the next decade. The difference, though, is that if you create data, sometimes it's good, sometimes it's bad, different quality levels, but it's really easy to create really bad software, and bad software can take down a business. So as a consequence, every business, from the CIO down to the most lowly person in the organization, has to participate in the process of creating great software, either in the design or conceptualization standpoint, to a use standpoint. It's a very important topic and it's one I'm really excited about, and to have that conversation, we're joined by two great thought leaders in this space. Dominik Tornow is the principal engineer at the office of CTO at Cisco, and Sara Lynn Hua is a UX designer at Chegg, Inc. Thanks for joining us on theCUBE. >> Thanks for having us. >> So, Sara. Let's talk to you first. Tell us a little bit about Chegg. >> Yeah, so Chegg is an education technology company that provides both physical and fiscal services to students. >> Okay, great. So with that in mind, I want to come to this issue of the marriage of UX and the marriage of cloud native. Let's start here, what is UX? >> So UX stands for user experience design and user experience design is the process of creating a meaningful and intuitive experience in a product, like a software application for a user. >> So, cloud native. >> Well, cloud native applications, as we talked about, are applications that are scalable and reliable by construction. So in order to have a cloud native system, you need a system that is capable of detecting and mitigating load in failure, and you can basically say cloud and cloud native applications have as much in common as Java and JavaScript, or, if you want to avoid the bar fight, have as much in common as car and carpet. So cloud native application or cloud native systems have effects on your entire organization. >> So, Sara, as a UX person, a person who's really worried about having a, building software that is intuitive and useful for human beings, how do you think about the impact of cloud native? Is that something that is good, bad, indifferent? Where's cloud native at Chegg? >> So, Chegg is in the process of adopting cloud native principles. Chegg has three million subscribers and is actively growing especially in the international space, so obviously reliability and scalability are one of our highest priorities. We have a lot of different applications and we have a lot of different teams, so, due to a lot of different acquisitions, we're at different stages of adopting cloud native principles. >> So it's something that has immediate implications, not only as you talk to students and people who you are trying to inculturate to great UX design, but also in your business as well. >> Exactly. >> Alright, so let's get into this. Because there is a lot of excitement about cloud native and building applications faster, but as I said up front, it's not uncommon for people to build really bad applications fast. So, how does UX and cloud native come together? From your perspective, Sara, what do you think that marriage needs to look like? >> So I think a lot of what ends up happening with cloud native, adopting cloud native principles, is that user experience designers are sometimes left outside of that decision. We learn about it later on and there are lot of far-reaching implications of adopting cloud native principles that we normally don't think about from a design perspective, and one of them would be, we don't know to design for partial failure. If certain components depend on a service, and that part of the system then fails, then from a user experience perspective, a user using that component may have an awful experience, but we're not necessarily thinking about that in terms of reliability. >> So it's a reliability question, so some of the precepts of cloud native aren't recognized as potential constraints as you imagine the nature of the application, but still, you're still focused on translating user insights and user practices and user realities into design elements that can be built. But it starts with at least into design elements. You're trying to build the right application. Have I got that right? >> Mm-hmm. I think when we talk about how cloud native relates to design we also have to talk a bit about how designers and developers collaborate. >> So you've got UX folks that are really focused on building the right application. How does that impact the way cloud native developers have to start thinking? >> Well, if Sara is responsible for building the right application, I am responsible for building the application right, and there is, of course, there is a collaboration. There is a peer relationship between design and development, and design happens to be the first step in the process. So while designers uncover the requirements of the application, right, it is my job to implement these requirements. And in this case I am a service provider to the UX and UI designers, and I get to veto only on three counts. That is, if a certain design negatively impacts scalability, negatively impacts reliability, or, of course, negatively impacts security. Other than that, I only communicate the consequences. For example, consequences in terms of costs. So if designers lay out a few alternatives, design alternatives for an application, I can, of course, communicate, how long is it going to take to implement it? Or how costly is this solution going to be? However, it is, at the end of the day, the business and the design makes the decision. >> So if I think about it, if I can, just let me throw out kind of how I think about some of this stuff. I imagine you really focusing on the social dynamics that have to be reflected in the software, given, you know, human constraints and human experiences, and quite frankly whether or not people are going to find the system useful and meaningful and enjoyable to use, otherwise they don't adopt it, and I think of you in terms of the technology dynamics. So both of you are thinking about the underlying dynamics of how it's going to work. You facing the system and you facing the user. Have I got that right? >> Yes, you absolutely got that right. So if you make people happy, I make systems happy, and you see this is also a core conflict, right? So even though we are working on the same application, right, there is, of course, a lot of tension because we are pulling in two different directions. >> Mm-hmm. >> Well, you mentioned earlier what cloud native is and the idea, you know, all the things by design at the system level, but there are a number of techniques that cloud native developers are starting to apply. We talked a little bit about one of them up front, partial failure, that has to be accommodated because we're talking about a greater distribution of systems. One of them is eventual consistency. Historically we like to say, "Oh, when I tell the computer to do something, "it's going to do it "irrefutably and absolutely." But that doesn't work in cloud native. Talk a little bit about eventual consistency and what that's going to mean from a design standpoint. >> So for some applications, scalability and reliability may benefit, as you said, for applying eventual consistency. So eventual consistency, meaning that the effects of the last write converge in the different parts of the system at different times, right, and yes, while that benefits the scalability and reliability of the system, that may absolutely negatively impact the user experience. >> How? >> Well, for example if you have, let's say a sports app, right? So two users are using ESPN to get their sports updates on how the game is going, and these two users are getting information. If they're getting information from the same node then we don't have a problem, but if these two users are getting information from different nodes, there's a delay in when they get the game score. This doesn't matter unless the two users are actually sitting in the same room. So someone might get an update about this game way earlier that someone else might, and then they'll be like, "Oh, look at this, the Warriors just scored!" And the other person is like, "What are you talking about?" So once you have the use case of them being in the same room then that actually creates this negative user experience of someone assuming their app is slower. Something like that. >> I'm going to take that example and I'm going to add another one, because I think that this has significant importance when we talk about the implications. Let's talk about financial transactions. So we're, you know, stock trading. That, it shouldn't necessarily be that the fact that I'm a few thousand kilometers away necessarily puts me at a disadvantage, but metaphorically if my node is processing slower than your node and you get that information about what's happening with stocks faster than I do, then I'm at a disadvantage. That has a pretty significant impact, social as well as technical, on subsequent behaviors. So there's this notion of blast radius, of how those impacts affect not just a particular transaction at a particular terminal, you're going to have impacts in much broader social settings. Tell us a little bit about that. >> Yeah, so for blast radius, the way I like to look at it, is the parts of the system that are directly or indirectly affected by the failure of another part of the system. Would you say you agree with that? >> Perfect definition. So the blast radius being the parts of the system that are transitively affected by one part of the system failing. And even so we share the same definition of blast radius, our experience is actually very different. >> Mm-hmm. >> So let's talk a little bit about, for example, a recommendation service like in an e-commerce application or a video streaming service that takes my past behavior into account and recommends additional items to consume in the future. So, I would say in typical systems the recommendation service is a standalone service. Not many services depend on the recommendation service. Right. So if the recommendation service fails, for me the blast radius is very small. I may not necessarily want to get up at a Saturday night in order to fix the recommendation system. >> You, being the cloud native person. >> Correct, but the UX designer may have a complete different view of that. >> Yeah, so at Chegg, for example, we use recommendations to give our users certain parts of content, so users really rely on our recommendations to really master a subject that they are studying, and we have all these pages dedicated to just having recommendations for the user. You're studying math, great. Here's a list of practice problems that you probably should go through before your quiz. So imagine they're studying for a math exam tomorrow and they're up at two a.m. and going through these practice problems and bam! That recommendations module suddenly fails. That is something that keeps me up at night because the parts of this system that, or what I think about as parts of the system, are user flows and user interactions, and if we do not provide that service to that user at that time, it could result in them leaving us as a subscriber because of that negative user experience. >> So it's very clear today that we need to factor the practical constraints of the system as we do UX, but more importantly, we need to really accommodate the real human experience, those user interactions, user flows, in how we design the systems. It's not really what's happening today the way we want it to. Give us one simple step, Sara, we'll start with you. One simple step that you think would improve these two groups working together. >> Well, like I mentioned before, having those conversations with designers because when a company is moving towards cloud native principals, and towards adopting cloud native principals, and they leave designers out of the conversation, designers aren't aware that they need to design for partial failure. >> So get designers into those sprints early on in the system design and not just later on as you get close to thinking about what the user is going to experience. >> Right, exactly. >> That is, I 100% agree with that. It is first and foremost a conversation to be had, and you have to have this conversation on the very first step of the journey. You cannot bring in, whether UX or UI, designers at a late stage in time. You have to bring them in at the very first moment. And you have to establish the peer relationship, and you do have to understand that as a developer you are a service provider to the designers. >> And you know, I'll make a quick observation, and my quick observation is having been in this world a little bit. It's actually a lot more fun to think about the human element early on in the process. It just makes the constraints on the technical side a little bit more interesting and a little bit more meaningful. >> That is very true, I agree. I very much like the examples that Sara brought up because if you think about a cold-hearted technology, you would think about nodes that scale up, for example, in the example of the eventual consistency. You think of nodes to scale up but you do not think of the consequences. Yet, if you have this conversation early on with the designers, right, you see the consequence of what it does if your system scales, and you can actually apply simple remedies that have great effect on the user experience. In that case if there is geographical proximity to users you route them to the same node and you make the user experience so much better. It is very fulfilling. >> Sara Lynn Hua, Chegg. Dominik Tornow, Cisco. Thank you very much for being on theCUBE. Great conversation. >> Thanks for having us. >> And once again, I want to thank you for participating in another CUBE conversation. Until next time. (funky jazz music)

(smooth music) >> From our studios in the heart of Silicon Valley, Palo Alto, California, this is a CUBE Conversation. >> Hello and welcome to theCUBE Studios in Palo Alto, California, for another CUBE Conversation where we go in-depth with thought leaders driving innovation across the tech industry. I'm your host Peter Burris. This is going to be the second in our series of demystifying cloud native that we've undertaken with some of the thought leaders at Cisco. The basic thrust of this conversation, the basic thrust of the series is to have developers learn something about what it means to build increasingly distributed applications utilizing cloud native services that will work, scale, and serve enterprise need. Now to have that conversation we've got Dominik Tornow, who is a principal engineer of the office of the CTO at Cisco. Dominik, welcome back to theCUBE. >> Hey, thank you very much for having me again. >> Okay, so upfront I said we're going to continue in our series of demystifying cloud native, but before we do let's review what do we mean by cloud native? >> So in our last installment we talked about cloud native and defined cloud native applications as applications that are scalable and reliable by construction, and in order to be scalable and reliable by construction an application has to be able to detect and mitigate load and failure. >> So if we think about detecting and mitigating load and failure it's a very, very simple definition but very powerful, as all good definitions are. What types of technologies are available today that allow us to actually instantiate this notion of cloud native as you've defined it? >> So you want to look under the umbrella term of operation automation, and there are multiple solutions available that you'll find either proprietary on clouds like AWS, Google, or Azure, or you'll also find solutions in the opensource space, and the most prominent solution of that nowadays is obviously Kubernetes. >> And so microservices is kind of an architectural approach that people can start thinking about. >> And microservices is an approach people can start thinking about, because microservices are, especially when they are stateless microservices, scalable and reliable by construction by themselves. Now you have a very good foundation to build a scalable and reliable application out of scalable and reliable components. >> Look, I've been around in the IT industry for a long time. Worked inside IT, run IT organizations, been an analyst, and I know from experience that you can take great technology and nonetheless create crap applications with it, so what is it about microservices that increases the likelihood of success with cloud native, but also very importantly what must developers stay cognizant of to ensure that they stay within the good guardrails and don't drift out to junk applications? >> So first let's look at what microservice application architecture actually is, because when we contrast it to a traditional, also called monolithic application architecture, we see that on the boundaries looking from the outside in we are still talking about one coherent application, right? From an end user's perspective we are not looking at a loose assortment of services. We are still looking at one coherent application performing a task, but looking into the inside we see significant differences. So for a traditional application all components of the application run within one process and one machine local network, so to say. However, when we move to a microservice application, through microservice application, the individual components, and actually the individual component instances, run in their own processes, and they communicate via an actual network. Now having your individual component instances run in individual processes allow you to easily meet scalability and reliability. You can easily scale up more component instances, or in case of failure you can easily scale up replacements for them, but as you said, you have to keep in mind this does not come for free because you are throwing a few challenges the developer's way. On a workload level the challenge is now partial failure. One of these component instances may have experienced a crash fault at any point in time, whereas in a traditional application the application as a whole would experience a crash fault, but not part of the application. And when we move to the network level then it looks actually even more bleak because now messages may get lost, messages may get duplicated, messages may experience delay, so latency, and with all of that this is something the developer has to face and has to work around. This is-- >> Well, let's dig into this a little bit. So the monolithic application basically you have a single process so all the resources are bind, or bind together inside a single memory space or inside a single shared state, and when one of them fails that brings them all down, so the user knows explicitly it's up or it's down. >> Correct. >> But when you start building some of these microservices where each of these individual components, the loss of a particular, perhaps critical, perhaps not, like but let's say a security feature within the cluster could go down, but the rest of it might feel like it's still working, which could dramatically increase the likelihood of exposure on any number of different levels, have I got that right? >> You got that right, and especially if we talk about state, dreaded state, but the one that we actually all need in our applications. If we talk about state we're talking about inconsistencies, and that is obviously the nightmare of every application developer and application operator. >> So we've got message loss, message deduplication, message reordering, and we're introducing latency because we're putting a stateless network as the mechanism through which we get the communication amongst the different components, have I got that right? >> That is absolutely correct, and let me throw in one more caveat in that case. We were talking about workload level partial failure and network level message loss or message duplication. Unfortunately there is actually no way to reliably detect has the request not been sent, was it lost? Did the process, the receiving process experience a partial failure? Or has response not been received, was it lost? So you cannot reliably detect any of these conditions, which leads us to the point that we cannot guarantee exactly once message delivery. We can only guarantee at most once or at least once, but as developers all we ever want is one service consumer call a service provider exactly once. However, we have to work around these terms, and this is what makes our application development very, very complex. >> Yeah, we want that consistency and that ability to discretely say what is or is not isolated in the overall notion of what constitutes a transaction. >> Very correct. Bottom line that is a good takeaway. Microservices, one way or another, will kill your transaction. (laughs) >> If you don't do them right. So from a developer standpoint, as you, you know, you're within Cisco, but you spend a lot of time thinking about the developer role, thinking about what developers need to do differently to fully exploit these cloud native capabilities. How do you communicate or see developers and infrastructure people doing a better job of communicating so that they can each be aware of the realities that the other is facing? >> So personally I strongly believe in strong, accurate, and tangible definitions in order to have a solid basis and foundation for good communication, because our responsibilities in a cloud native world, whether it's application developer, application operator, or infrastructure operator, are only going to get more complex. So we rely on solid and precise technical communication to A, identify the challenges and communicate solutions for these challenges effectively. >> Now one of the things that's interesting about the cloud native microservices sets of technologies is that they're starting to be paired with other classes of technologies for doing a better job of going beyond just simply orchestrating the communication amongst various resources in a cluster. Where do you see some of these new technologies, like Istio and whatnot, starting to assert themselves to help developers do a better job of building cloud native applications? >> So let me state the following hypothesis, for cloud native we got the workload management right. We didn't get the network right just yet. And when it comes to workload management solutions like Kubernetes do a fantastic job for the application developer and the application operator and provide solid primitives to build your applications on top of it. However, we are still suffering from problems not within a Kubernetes cluster but across Kubernetes clusters, so when we look at, for example, the Kubernetes networking model communication within the cluster, we are set, we're good. Communication across clusters we still have some challenges. And we do see emerging solutions in the space, like for example Istio and other service meshes that increasingly do not only address the situation within the cluster but also across clusters, but we still need to make a leap forward into a different kind of cloud native networking, and I do believe that cloud native networking will show itself or define itself as a workload to workload connectivity. So eventually we will separate the runtime domain, the cluster from the connectivity domain, and then enable a workload on one cluster to talk to a workload on another cluster seamlessly without opening about 15 or 25 tickets. >> Yeah, exactly. (chuckles) And so the communications becomes natural to each of the workloads. >> Correct. The communication becomes natural to each of the workloads, which is a prerequisite for efficient development. Of course I quipped a bit with the tickets, but it is an actual reality that as soon as you leave one cluster and you, for example, need to reach workloads that are on-premise or you need to reach workloads in a different cloud, sometimes even just a different availability zone, you will encounter communication processes with infrastructure folks in your department. The communication is heavily around tickets. It will slow you down a lot, and in our agile world that is not sustainable. >> Well look, as you said earlier, there are four things you have to worry about as you request services from the network, latency, loss, deduplication, partial, et cetera. As you increase the latency the other three are absolutely going to create problems for you. >> Oh yes, absolutely. >> And so I think that's kind of what you're saying is even within a single cloud provider if you start changing reasons and you start introducing distances you start introducing latency, the issues of partial message delivery, deduplication of messages, message loss, et cetera, will assert themselves and become a bigger challenge for developers. >> You know the heisenbug theorem, right? In distributed applications the heisenbug is a bug that will disappear as soon as you look at it. (laughs) So-- (chuckles) >> I didn't know that. >> So a distributed-- (chuckles) >> But now I'm thinking about it. (chuckles) >> In distributed applications when you test your system on a local machine or even a set of local machines, right, you have a very good chance that the actual corner cases will never show up in your test cases, but as you said, when you introduce latency the heisenbug from an alt outsider will become a surefire thing. So as soon as you roll your application in production and then roll it out across geographical regions introducing the latency you will see a lot of that. >> Heisenbug. >> The heisenbug. >> I like that. (chuckles) All right, Dominik Tornow, the principal engineer in office of the CTO at Cisco talking about demystifying cloud native. I want to thank you once again for being on theCUBE. We look forward to seeing you again. >> Thank you very much, me too. >> And once again, thanks for joining us for another CUBE Conversation. I'm Peter Burris, see you next time. (smooth music)

(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)