 from our studios in the heart of Silicon Valley, Palo Alto, California, this is a CUBE Conversation. Hello and welcome to the CUBE Studios from 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. 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 analog 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 from a design or conceptualization standpoint to a youth standpoint. It's a very important topic and it's what I'm really excited about. And to have that conversation, we're joined by two great thought leaders in the space. Dominic Turnow is the principal engineer of the office of CTO at Cisco and Sara Linhua is a UX designer at Cheg Inc. Thanks for joining us on the CUBE. Thanks for having us. So, Sara, let's talk to you first. Tell us a little bit about Cheg. Yeah, so Cheg is an education technology company that provides both physical and physical 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 our 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 and 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 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. Where 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, and 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 for as you talk to students and people who you're trying to acculturate to great UX design, but also in your business as well. Exactly. All right, 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, Sarah, 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 a 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, then 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 reliability questions. 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? 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 Sarah 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 video 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 gonna take to implement it or how costly is this solution gonna be? However, it is at the end of the day, the business and the design that makes a 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 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 were thinking about the underlying dynamics of how it's gonna work. You facing the system, you facing the user. 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. So even so, we are working on the same application. There is of course a lot of tension because we are pulling in two different directions. Well, you mentioned earlier that what cloud native is and the idea of all the things by design at the system level. But there are a number of techniques that cloud native developers are starting to apply. And we talked a little bit about one of them up front, partial failure, that has to be accommodated because we're talking about 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. And yes, while that benefits the scalability and reliability of the system, that may absolutely negatively impact the user experience. Well, for example, if you have, let's say, a sports app, 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 than someone else might. And then they'll be like, oh, look at this, the warrior's just scored and the other person's like, what are you talking about? So once you have that use case of them being in the same room, then that actually creates this negative user experience of someone assuming that their app is slower, something like that. I'm gonna give it, I'm gonna take that example, I'm gonna add another one, because I think that this is significant importance when we talk about the implications. Let's talk about financial transactions or 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, but can have impacts in much broader social settings. Talks 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. 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. So at CHEG, 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're 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 you're quit. So imagine they're studying for a math exam tomorrow and they're up at 2 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 the 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 practicality 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. How, it's not really what's happening today the way we want it to. Give us one simple step. Sarah, 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 principles, towards adopting cloud native principles 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, a little bit more meaningful. That is very true, I agree. I very much like the examples that Sarah brought up. Because if you think about cold hearted technology, you will think about notes that scale up, for example in the example of the eventual consistency, you think of notes 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 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 a geographical proximity to users, you route them to the same note and you make the user experience so much better. It is very fulfilling. Saralyn Hoa, Chegg, Dominic Turnau, 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.