Cloud Crunch
Cloud Crunch

Episode · 7 months ago

S2E11: 5 Strategies to Maximize Your Cloud’s Value: Strategy 2 - Accelerating Application Development with DevOps

ABOUT THIS EPISODE

Today we dive into the second strategy you should consider using to maximize your cloud's value - accelerating application development with DevOps. Google Cloud DevOps expert and the Solution Manager Lead for App Modernization on GCP, Harish Jayakumar, joins 2nd Watch's own Joey Yore to talk about the power of brining applications to market faster and fully immersing your company in a DevOps transformation.

...involve Solve, evolve, welcome to cloudCrunch, the podcast for any large enterprise planning on moving to or isin the midst of moving to the cloud hosted by the cloud computing expertsfrom Second Watch, Ian will be chief architect Cloud Solutions and SkipBerry, executive director of Cloud Enablement. And now here are your hostsof Cloud Crunch. Welcome back to Cloud crunch. This weekwe have an internal special guest with me that I've had the opportunity towork with quite a bit. Joey, your second watch. He's a principal cloudconsultant here with our team and also have a very special guest today. Who'sa Google Cloud Dev Ops expert Parish Jayakumar The solution manager lead forAP modernization on Google Cloud So welcome to the show, everybody. Joey,good to see you and hear from you again and nourish. Thanks for joining us.Thank you for having me. Awesome. Very good. So now I just want to giveeverybody a little quick background on our special guest. Today, Harish leadsthe Global Application Modernization Solutions team for Google Cloud. Histeam helps customers with their application modernization journey bybuilding solutions around G C P products. Our rich comes having spentseveral milestone years with Docker, and we definitely want to drill intothat a little bit. Where his experience includes helping customers transformtheir businesses with their application modernization journey, as well asaccelerating growth at Docker as their worldwide VP of solutions engineering,he brings in more than two decades of expertise across solution, sales andproduct while working in several capacities at Microsoft, Dell and EMCsupporting their enterprise customers. We've been talking about strategies youcan use to increase the value of being in the cloud, and that is obviously are occurring theme of the show. Last week we examine how you can createcompetitive advantages with your cloud data now that you're an expert on thattopic, and I'm sure everybody is after a 30 minute podcast listening sessionwith us. Let's look at accelerating application development with Dev ops.If you move to the cloud to take advantage of the rapid deployment ofinfrastructure to support development, you understand the power of bringingapplications to market fast. All about driving that customer value quick. Nowit may be time to fully immerse your company into a Dev Ops transformation.All right, now on our end, I know Joey, Joey and I have done some great Dev opswork together when I say that I take credit for his work because he did allthe work. Uh, but, Joey, let's kick this off. I I know that you're anexpert in the field as well. I would love for you guys to start someconversation. Thanks again. And to get things started off, I kind of wanna goover a question that we get all the time. What is Dev ops mean? And whatdoes it mean to start a dev Ops transformation? Uh, how much time do wehave way? Uh, it's really interesting, right? And, you know, I've seen thisbeing in the space, as I wouldn't say as long as, uh, many people over here,I don't think there's any specific canonical definition itself. And Ithink that's by design that as a community, I think everyone you know,we're still learning how to get better at building and operating softwaresystems. That's why there's no, like one definite thing. But in my opinion,kind of finally boils it down to your software delivery velocity and thereliability around it right on. And if I was to, like, take that up, it'scompletely mostly a cultural in an organization moment, toe increase this.So if these two are not type that, then it's not, in my opinion, a very that'snot the definition of develop. So it's basically a cultural in an organizationmoment that is aiming to increase this software reliability and velocity.That's that's how I would kind of like put on what develops this. Yeah, I Icompletely agree. Any times I get into...

...a develops discussion, I always try tohammer the the Its's really a cultural shift. It's gotta be, Ah, full culturaltransformation first. So let's say company wants toe pursue Dev ops, right?How should we start looking at performing that transformation withthem? Yeah, So I mean, I don't think on your previous point their joy, right?So what? And if you break that next to the cultural level is what is the setoff practices, guidelines and culture that's designed to break down thesesilos? So So as an organization, I'm trying to answer your second questionwith Based of that is, that's where you stop right is. What do we need to breakdown the silos and designed to development? That's the first questionwe wanna be ableto think about it, right? Five key areas. And if you, ifyou see from our SRE implementation, develops the way. Google's book. If yousee that the five key areas to think about is reduced, these organizationalsilos, right, accept failure as normal, right? That's that's that's again, backto the cultural piece as well as from the methodology. How you want to thinkabout it on then Don't try to boil the ocean right its's. You've gottaimplement gradual changes every small step that you wanna be able to go takestep forward. You wanna be able to leverage tooling and automation that'sthat's super super important. In fact, the key part of this is being able toautomation. And then finally, you gotta be able to measure anything that Z Iwould say, even though I'm saying it the last, it's fundamentally importantbecause that just shows you how you're moving in those gradual changes. Oneafter the other. Yeah, absolutely. So when we go in and do Dev Ops work atsecond watch, we use a model called Calm. Are you familiar with that one?No. Okay, it's calm. It's an acronym. C a L m s on drily. It kind of highlightsthe same points that you mentioned. It stands for culture automation. Lean,Azzan lean. You know, manufacturing lean deployments, metrics and sharingis the last one. Eso when we do kind of maturity assessments, we like to usethat model to really dive down and see where an organization is. Gotcha. Soyeah. No, that kind of makes sense, actually. Right. And I don't know ifyou've heard about Google's methodology. I was gonna kind of jumping, but maybethis is a good point that she talked about it. Have you heard off, daughter?It was a company that Google acquired. Think it was back in 2018? If I'm not,if I'm not mistaken, Um, I've heard a little bit, but probably not enoughthio being expert on it. So please, here's some more. Yeah, jump in andtell us about it. Yeah. So the thing is that it's kind of like the defectstandard, even in the industry before even Google acquitted a big big fans ofthis and Google a quiet then. So basically daughter stands for developsresearch an assessment, right? And the idea behind this is the whole DorisResearch is what makes high performing teams functional in the develop space.That's that's where their entire studies about right. So every year, dayand I'm going to say now us have produced this develops research reporton it. Zero. Even when I talked to customers every time they bring upthose reports and it's fundamentally based on Doris leadership in thedeveloped space was it was a natural fit for Google Cloud when you know whenboth were looking to help improve both the developer and the operationsecosystem. But the idea behind Dora is it follows a very strong, data drivenapproach that helps teams leverage put automation, process, cultural changes,everything around it. Right? So that's that's the fundamental idea behind howdata works. So basically Doris research is based on four key metrics, rightdeployment frequency lead time for changes on which is basically from thetime you actually come into your code,...

...right and then change fail rate andthen finally, the time to restore the service. Now these four metrics can beapplied to any kind of software delivery, whether it's farm where ormobile or anything that you want to be able to go do so if you are able tomeasure that kind of a software delivery performance based off thisthis is a valid and reliable way to do this. And this is Dora's mantra acrossthese four metrics, right? And every research, every analysis is based onthese four things, right? Right? Yeah. So, uh, we dio use those for metrics aswell. And yeah, as far as measuring your your delivery and and kind of, I'dsay the end result of how well you're you're performing in terms of thatdelivery, those air Absolutely the four of the main points. I'd be looking intoa swell Yeah, And you know, the way it kind of works is that, you know, basedon these four metrics, then you can go and start evaluating theseorganizations, and you can see where they are, whether there are, you know,lower performer, medium high and elite performer based on these numbers, right?And then it's proven that elite performers in these four metrics are3.5 x times more likely to have stronger availability practice and Iwant to tie this to the business side of this is that you can make thatbusiness impact with this. There's a strong correlation between these eliteperformers and the business impact off the organization, which has this kindof elite performers in it. So which is why all these are tied together. Yeah,that's fascinating because, you know, kind of drilling into these things. Itsounds a lot like, you know, from the outside sometimes what gets measuredgets, you know, you know that whole business adage, but you've got tomeasure things in order. Thio manage it. And then secondly, you know some of thethings that you talked about some of these five principles really kind ofresonate for me or reducing those silos and creating that culture where failureis common. So and I want to get into this a little bit of get yourinterpretation of some of the challenges that you see out there. Buta lot of that the cornerstone to that, in my opinion, for an organization iscreating trust. So what other challenges do you see that are outthere in order to keep these transformations, Dev Ops particularlymoving forward. Yeah, that's a great question. So I think honestly, to me,I'm a big, big, firm believer off This is mostly the culture thing. You know,I think that's the first thing you need to be. Just be able to embrace that.You could be able to do these things right. The second thing challenge, likeI said, was, you know, just not able to be ableto measure these things right? Ithink that's the second problem that I've seen over here on. The third thingis that if you actually see, like, you know, the concept of this eliteperformers that I talked about, they don't see trade off. So sometimes theysay, like, Oh, you either do You can only do speed or you can only doeducate you Let me do this or you can't do this. You know, you could write on.That's the That's the big thing as well. If you see the the daughter talks thatthe founders have done is that high performers are not actually trading off.Any of the speed was the stability associate it so it comes down again andagain, having like a lean team and being able to quickly innovate andchange repeatedly outside of this. So you need to be asking these questions.How long is it taking for your organization to deploy that one line ofchange? How long is it taking you able to do this repeatedly? What? How longdoes it take? When you discover security volume between your stack? Howlong does it take for you to patch and deployed us? Great. Is it five days?Why is it five days? What can we do that? So those are the kind ofquestions that you need to keep repeatedly asking and being able to dothose things right? So and and things to enable it are the organization andstructural changes falling Just simple basic practices like C I C d. Itself.We could spend, like, you know, like to ours, talking about what's the rightway to do. See, I see what what's the you know, like, how do I measure C I Cd. On it and and some And some of these...

...things is where, like, you know, whenyou see challenges with customers is when you move to things like the clouda lot of these could get a little bit more easier because you have thingslike, you know, it makes itself service on demand. Self service. You know, allthose things kind of coming to get your elasticity. You get those things out ofthe walks. That makes it much, much more easier on this because, say,suppose you random built all this right now. Let's just take a step back andsay, I suppose you can buy the cloud and you can put the developers all thatstuff. But guess what? If you have to still step back and raise a ticket inservice now, in wait weeks for a test environment, well, it's not the cow,right? So it's like it's like biting the Tesla and still taking to the gasstation and saying Why I'm not able to fill this. I mean, well, threeecosystem, you gotta build it on it now. Absolutely. That's a very good point. Ithink also the both the models that you're all are saying are veryinteresting, particularly the measure, because I think a lot of people kind ofstagnate on that, but it sounds like you've got some good ideas in thesemodels. Particularly before that, you discussed to really kind of kick startthat. So going on, you know, you talked about how culture is so very important.Both of you have. What do you feel is also very, you know, what are some ofthe core requirements beyond kind of that cultural shift in order to besuccessful when you go to this type of transformation? Yeah. Yeah. Like toyour question about this, right? I mean, the fundamental idea, even in theculture piece that Dora, what it preaches is that, you know, teamsdeliver results, right? Not individuals. So how do we build these highperforming teams and enable them to deliver the speed and stability inthese Across these four metrics is what we're talking about. So after theculture pieces like, great next, let's talk about you know, what is your lienteam that you're gonna be following What is continuous delivery in your Inyour opinion, ever. You need to get these changes. Bug fixes quickly intoproduction, right? Those are things that I would say after the culturepieces like then start looking into forming that lane team getting intolike talking about your application, a lead times measuring them and startfixing each one of them in a specific way. Yeah, absolutely. And I know we'resaying, other than culture. But again, culture, it's It's so important here.So I do want to emphasize there's gotta be by in both top down from management,down to developers and also from developers up. If everyone's not on thesame page, it makes it very difficult to be successful also, you know, we'vetalked about measuring. I've seen many places where they'll measure, butthey're not actually doing thing with those measurements. You really need tomake sure that as you're measuring your continuously looking to improve onthose measurements, if you're at a month lead time for deployment, youknow, you probably want to get that a lot lower. So whatever barriers thereare in the way, you want to make sure that your really trying to knock thosedown another area. I think I'd like to point some attention to is around thesilos and having sort of those big silos teams of like the database team,the development team, the ops team, it really is kind of anti Dev ops and andreally, what we want to start doing is making cross functional teams to betteraid and knocking down those silos to better aid in improving thosedeployment metrics. And, uh, ultimately get us towards that successfultransformation where we're smooth running Dev ops organization Agree,Agree Plus 100 or 1000. How much we want to put to that to the point thatyou just made because that's that's one of that is the planning side that youhave these small batch sizes dedicated cross functional teams and goingthrough this continues planning. And then there is, you know, from theplanning phase. The next is the If it was to look in the development andtests right there looking at agile development, continuous integration,automation built into it. And then there's the release in the deploy side,which is Do I have standardized platform and processes? Is that anautomated environment provisioning...

...automated, you know, release and deployto change that they have, and then finally, again, back to the Can Imonitor it, optimize it, measure it, you know. So those four buckets arekind of like, you know, Kiki building blocks off the growing capabilities, soObviously, what we're trying to do with this, you know, is is really evangelize.Acceleration of application development, but not just the acceleration. It'salso the quality and those types of things as well. And then, of course,you know, just bringing teams together and get him to talk, right? Thecollaboration pieces is amazing. So how do you see this really affecting theorganization? As far as how much can this accelerate bringing to customervalue on really realizing that value? What? Have you seen some of the kind of,you know that use names or anything like that? But how does it accelerate?Sure. I mean, like, I could start first with, like, numbers. And then we cantalk about the methodology, as you said, right? I mean, we've actually this isagain from the studies that we've shown that you know what we call about Highperformers are more agile. We've seen 46 times more frequent deployments fromthem coming just from these high performance right, and it also morereliable. And they say you know, they're five x more likely to exceedany profitability market share on productivity goals on it, in my opinion,like you know when they say accelerate development, it's what you get out offsimply by moving to this model is the speed faster delivery of features. Icome up with an idea today three of us just sat down. Can I quickly spend thisup? Coming to my get, you know, just get this rolling. Can I do this ASAP?Like that's those things becomes super important, right? The second thing isalso the agility on it, right? I wanna be able to quickly. There's a new tech.I want to try it out. Can I quickly go start using those things? These are allthe things I think you will start seeing in terms often acceleratedapplication development right. And that automatically brings in tow, improvedquality of court as well. And also quick recovery. Because now you're ableto like with these automated things, you know immediately how quickly youcan find out that you're called bricks, so you can immediately come back, findout about it. But the Landes continues tests again and go back and patch itagain. So that improves the quality of the cold. Quick recovery makes it a bitmore efficient around it. right. So those are the kind of things that it'salmost like a It's like a circle that each of the student toe one another.Yeah, and just attack on there. The other thing you get. So in order to gofaster and be more agile and, you know, get this accelerated deployment, you'regonna naturally be working with smaller and smaller pieces with much mawrautomated testing. So whenever you're making smaller changes through thisprocess as well, you're actually gonna be lowering your risk of anyonedeployment, causing some sort of catastrophic failure. And again likelike you said, whenever there is a failure, it's easy toe is it recoverfrom? But I think the minimizing the risk per change is another reallyimportant thing about Dev ops andan. The other point I'd like toe bring upis also in your development phase, not just your deployment phase. Having agood dev ops culture. Really? Let's you experiment more so you can not belocked into a specific technology stack. You can discover new new technologiesto use new tools, new languages that may be better fit for a specific task,and being in that good Dev ops kind of momentum. You can really start to failfast or succeed fast, right? You can quickly figure out. Is this going towork? Is this not going to work? And you can make better informed decisionsand And that, I think, is a big part of the accelerated development cycle aswell. Yeah, in that failure part, I think is very key. What comes to mindthis week was I was watching a space six test. Where there, uh, testing someof the components toe get to Mars. And...

...they've been landing these boosters outon the drone ship quite frequently, but they were bringing down a new boosterrocket that they haven't done before. It blew up and everybody was like, Thisis awesome. We got all kinds of great data from it. And like that, to me, islike the epitome of celebrating failure. And yeah, that's a good thing. Thatthat that's what I'm saying. It was not that. It's It's It's awesome. Man. Withthat, Yeah. I mean, what did you learn from it? Right. And so I think, andwhat I keep hearing you I'll talk about, you know, is measuring and feeding itback in the system. It's really those feedback loops. And again, you know,that's part of Dev Ops. But it's really listening to that empathetically and,you know, from my business perspective and really incorporating the lessonslearned and doing it so rapidly, not waiting months to come back and look atit. And I think that is, uh, just such incredible power. And, you know, andwhat I also want to kind of implore people to is this methodology doesn'tIt's not just for software development, right? I mean, it could be for anythinginside your business to some degree. Absolutely. Yeah, And you mentionedfeedback loops. And ultimately, what we're trying to do with a lot of theDev ops methodology is we want to reduce the time it takes to getfeedback. We want fast feedback as quickly and as often as possible sothat we can constantly make those decisions. That's why we're breakingthings in the smaller pieces. That's why we're getting rid of silos,increasing collaboration with our and sharing throughout the organization.And ultimately, you know, that's why it becomes a cultural thing is because,yeah, we have to build the culture that could support those minimized feedbacktimes. Yeah, and that feedback to for you know, what you're all are saying,You know, put words in your mouth. It's not just from the data of the technicalaspects of it, but it's also incorporating that that data back fromcustomer experience, that the value that they're seeing And of course, thebusiness owners inside the organization as well. It could even be sales. Andthey're like, Yeah, this is great. We're getting great feedback from it,So Oh, yeah, 100%. I mean, it's it's feedback from tech feedback fromprocess and feedback from culture, right? I mean, these are the threefundamental pillars behind these transformations. And, like, I mean, Ihonestly I I am part of sales here, and through my entire career, I've been insales, and I always tell, you know, the people are higher and everything it islike you could spend six weeks sitting and reading as much as you can when youwant to ramp up. Or you could go attend three customer meetings and you willget so much more knowledge about anything that you want than any of thevideos are things that you're listening to. So yeah, that's great. Now I wantto kind of wrap it up for a question for both of you. And when you you'recoming into a new environment and somebody wants toe, you know, embracethis, let's say and obviously we talked about some analysis that may take placeat the beginning, and everybody's results may be different. But what isthe typical first step that you tell people they should probably take inorder to develop this culture developed a culture? Or how do you get startedimplementing Dev ops? So everything even develops, we say a small, small,small cycles that you want to be able to go do. I would use the same approachon how you want to get started. Ah, former small team, take a small projectand go experiment with that right? That's how I would start. I mean, Ibelieve you. If you really want to do that, I would say start with a doorassessment, which is what you know a lot of the customers were working withtoday. That's how we do that is like first understand your current state,right? Once you know where your current status, then it's easy for you to seewhere we wouldn't see easy to make the transformation. But we know where wewanna go. So if I was to force and say what to do, I would say Let's startwith an assessment of your current capabilities that you have because evenif you take that small team and you just cause they don't know what theboxes, what are they gonna do? Right?...

So transformation starts withunderstanding first where you are today. Step one, Step two. Let's take the dataand see. OK, this is where you stand. This is where you're missing. Maybe youdon't have the skills. You don't have the tools for automation. You don'thave the, you know, small set off things that we need to go build. Steptwo. Step three. Let's build those pieces. Where do we start for shrinkingthem? Maybe the first step is to form the steep Wait, Let's form the steep.Let's pick two metrics that are really one metric we wanna work on. Let's workon that one metric, and then everything else kind of falls into place. That'show I would go with the step by step approach on it. Yeah, I wish I coulddisagree or have a different line of thinking, but I I I pretty much woulddirectly agree there. Start off with the assessment. Understand where yourcompany is strong and where they're weak. Leverage where you're alreadystrong. Improve where it's weak. Using a pilot team, as you mentioned, is agreat way to start because you're minimizing risk to your organization asa whole. And you're gaining those learning experiences of what you'reprobably going to see as you open up the transformation. The rest oforganization, I think on top of that, I would add, though training inparticular if you're weaker and some of the automation and metrics types areas.I often seen customers that have largely neglected automated testing,and that's not something you can just add overnight or just say, Hey, we'regoing to start doing automated testing again. That's another thing thatrequires a lot of buying. Your automated testing has to be good tests.If they're bad tests, they're not really useful. And, you know,infrastructure is code. When we're talking about building cloud resourceis and everything as well, and I found you could go ahead and startintroducing portions of your organization to those topics. If that'san area you're not strong in, Um, if you are strong in those areas, then youknow, maybe it's some of the other culture deployment metrics or justgeneral sharing opportunities that you're lacking in. That's really thatassessment. Being honest eyes super important. Having the right people askquestions is a good idea because you know, people will answer differentlydepending on who they're talking. Thio whether you like to admit it or not,right, Right? Absolutely. Harry, one of the things that kind of stood out to meand your background I just gotta want to close out on this is that you camefrom a docker background, obviously, and you know, that's a very interestingtool in this whole ecosystem as well. We see it often, right, but we spentvery little time talking about too late, because I think, you know, put morewords in your mouth. And ultimately it seems like a two people challenge.Would you agree with that? I would 5000% agree Attack, you know, like it'sonly as good as the people who you could give it to right? I've spent somany times like just spend 100 meetings and at one time I still remember. Ijust I think I got up and told this. I don't know if it's a customer or likeanother, you know, made up or something. And at at some point, I'm like and I'vebeen talking to you for six months about this. We just have multiplemeetings I've taught you. And I've you've read every book about swimmingright now, just going to jump into the water. It sometimes it's that it's thisover analysis, paralysis on it and thats why this the mentality to likequickly just do something and see it and it's okay, you know you're gonnafail. And whereas I've seen some companies before that they've adoptedDoctor is very, very, very early stage, right, even though, like I mean, it wasnot even ready for running in production. But we were like, you knowwhat? They were ready to experiment with it. It was a hard journey, but wecame out really, really successful, and...

...at the end of it, they had the teamstrained. They had the people trained and they had things around it there wastrained well as well. So that's why for me, like, I can give you the mostshiniest object. But if you're gonna keep it inside your bedroom and not useit, it's useless. So that's great. Well, I want to thank both of you very muchfor joining me this week. Larry. Fantastic conversation, Joey. Hope tosee again after this pandemic as well. And, uh, yeah, thanks again, Greatconversation. And wow, it's always, you know, we talk about the evolves all thetime, but it's it's always good to get this perspective. I feel like this ispretty actionable stuff that you guys were ableto uncover for us. So thanksagain for that. Next week, we're gonna be looking at the third and the fourthstrategies. Do increasing your clouds value to that, go hand in hand,increasing the security of the cloud environment and ensuring compliance. Asalways, we welcome your feedback, please. Email is that cloud crunch atsecond watch dot com for your ideas, comments and suggestions. Thanks again.See you next week. You've been listening to Cloud Crunchwith Ian Willoughby and Skip Very. For more information, check out the blogged.Second watch dot com slash company slash vlog or reach out to second watchon Twitter.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (30)