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