Cloud Crunch
Cloud Crunch

Episode · 1 year 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 cloud Crunch, the podcast for any large enterprise planning on moving to or is in the midst of moving to the cloud hosted by the cloud computing experts from Second Watch, Ian will be chief architect Cloud Solutions and Skip Berry, executive director of Cloud Enablement. And now here are your hosts of Cloud Crunch. Welcome back to Cloud crunch. This week we have an internal special guest with me that I've had the opportunity to work with quite a bit. Joey, your second watch. He's a principal cloud consultant here with our team and also have a very special guest today. Who's a Google Cloud Dev Ops expert Parish Jayakumar The solution manager lead for AP 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 give everybody a little quick background on our special guest. Today, Harish leads the Global Application Modernization Solutions team for Google Cloud. His team helps customers with their application modernization journey by building solutions around G C P products. Our rich comes having spent several milestone years with Docker, and we definitely want to drill into that a little bit. Where his experience includes helping customers transform their businesses with their application modernization journey, as well as accelerating growth at Docker as their worldwide VP of solutions engineering, he brings in more than two decades of expertise across solution, sales and product while working in several capacities at Microsoft, Dell and EMC supporting their enterprise customers. We've been talking about strategies you can use to increase the value of being in the cloud, and that is obviously a re occurring theme of the show. Last week we examine how you can create competitive advantages with your cloud data now that you're an expert on that topic, and I'm sure everybody is after a 30 minute podcast listening session with us. Let's look at accelerating application development with Dev ops. If you move to the cloud to take advantage of the rapid deployment of infrastructure to support development, you understand the power of bringing applications to market fast. All about driving that customer value quick. Now it 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 ops work together when I say that I take credit for his work because he did all the work. Uh, but, Joey, let's kick this off. I I know that you're an expert in the field as well. I would love for you guys to start some conversation. Thanks again. And to get things started off, I kind of wanna go over a question that we get all the time. What is Dev ops mean? And what does it mean to start a dev Ops transformation? Uh, how much time do we have way? Uh, it's really interesting, right? And, you know, I've seen this being 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 I think 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 software systems. 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 the reliability around it right on. And if I was to, like, take that up, it's completely 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's not the definition of develop. So it's basically a cultural in an organization moment 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 I completely agree. Any times I get into...

...a develops discussion, I always try to hammer the the Its's really a cultural shift. It's gotta be, Ah, full cultural transformation first. So let's say company wants toe pursue Dev ops, right? How should we start looking at performing that transformation with them? 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 set off practices, guidelines and culture that's designed to break down these silos? So So as an organization, I'm trying to answer your second question with Based of that is, that's where you stop right is. What do we need to break down the silos and designed to development? That's the first question we wanna be ableto think about it, right? Five key areas. And if you, if you see from our SRE implementation, develops the way. Google's book. If you see that the five key areas to think about is reduced, these organizational silos, right, accept failure as normal, right? That's that's that's again, back to the cultural piece as well as from the methodology. How you want to think about it on then Don't try to boil the ocean right its's. You've gotta implement gradual changes every small step that you wanna be able to go take step forward. You wanna be able to leverage tooling and automation that's that's super super important. In fact, the key part of this is being able to automation. And then finally, you gotta be able to measure anything that Z I would say, even though I'm saying it the last, it's fundamentally important because that just shows you how you're moving in those gradual changes. One after the other. Yeah, absolutely. So when we go in and do Dev Ops work at second 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 highlights the same points that you mentioned. It stands for culture automation. Lean, Azzan lean. You know, manufacturing lean deployments, metrics and sharing is the last one. Eso when we do kind of maturity assessments, we like to use that model to really dive down and see where an organization is. Gotcha. So yeah. No, that kind of makes sense, actually. Right. And I don't know if you've heard about Google's methodology. I was gonna kind of jumping, but maybe this 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 enough thio being expert on it. So please, here's some more. Yeah, jump in and tell us about it. Yeah. So the thing is that it's kind of like the defect standard, even in the industry before even Google acquitted a big big fans of this and Google a quiet then. So basically daughter stands for develops research an assessment, right? And the idea behind this is the whole Doris Research is what makes high performing teams functional in the develop space. That's that's where their entire studies about right. So every year, day and I'm going to say now us have produced this develops research report on it. Zero. Even when I talked to customers every time they bring up those reports and it's fundamentally based on Doris leadership in the developed space was it was a natural fit for Google Cloud when you know when both were looking to help improve both the developer and the operations ecosystem. But the idea behind Dora is it follows a very strong, data driven approach that helps teams leverage put automation, process, cultural changes, everything around it. Right? So that's that's the fundamental idea behind how data works. So basically Doris research is based on four key metrics, right deployment frequency lead time for changes on which is basically from the time you actually come into your code,...

...right and then change fail rate and then finally, the time to restore the service. Now these four metrics can be applied to any kind of software delivery, whether it's farm where or mobile or anything that you want to be able to go do so if you are able to measure that kind of a software delivery performance based off this this is a valid and reliable way to do this. And this is Dora's mantra across these four metrics, right? And every research, every analysis is based on these four things, right? Right? Yeah. So, uh, we dio use those for metrics as well. And yeah, as far as measuring your your delivery and and kind of, I'd say the end result of how well you're you're performing in terms of that delivery, those air Absolutely the four of the main points. I'd be looking into a swell Yeah, And you know, the way it kind of works is that, you know, based on these four metrics, then you can go and start evaluating these organizations, 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 are 3.5 x times more likely to have stronger availability practice and I want to tie this to the business side of this is that you can make that business impact with this. There's a strong correlation between these elite performers and the business impact off the organization, which has this kind of 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. It sounds a lot like, you know, from the outside sometimes what gets measured gets, you know, you know that whole business adage, but you've got to measure things in order. Thio manage it. And then secondly, you know some of the things that you talked about some of these five principles really kind of resonate for me or reducing those silos and creating that culture where failure is common. So and I want to get into this a little bit of get your interpretation of some of the challenges that you see out there. But a lot of that the cornerstone to that, in my opinion, for an organization is creating trust. So what other challenges do you see that are out there in order to keep these transformations, Dev Ops particularly moving 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, like I said, was, you know, just not able to be ableto measure these things right? I think that's the second problem that I've seen over here on. The third thing is that if you actually see, like, you know, the concept of this elite performers that I talked about, they don't see trade off. So sometimes they say, like, Oh, you either do You can only do speed or you can only do educate 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 that the 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 and again, having like a lean team and being able to quickly innovate and change 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 of change? How long is it taking you able to do this repeatedly? What? How long does it take? When you discover security volume between your stack? How long 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 of questions that you need to keep repeatedly asking and being able to do those things right? So and and things to enable it are the organization and structural 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 right way to do. See, I see what what's the you know, like, how do I measure C I C d. On it and and some And some of these...

...things is where, like, you know, when you see challenges with customers is when you move to things like the cloud a lot of these could get a little bit more easier because you have things like, you know, it makes itself service on demand. Self service. You know, all those things kind of coming to get your elasticity. You get those things out of the 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 and say, I suppose you can buy the cloud and you can put the developers all that stuff. But guess what? If you have to still step back and raise a ticket in service 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 gas station and saying Why I'm not able to fill this. I mean, well, three ecosystem, you gotta build it on it now. Absolutely. That's a very good point. I think also the both the models that you're all are saying are very interesting, particularly the measure, because I think a lot of people kind of stagnate on that, but it sounds like you've got some good ideas in these models. Particularly before that, you discussed to really kind of kick start that. 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 of the core requirements beyond kind of that cultural shift in order to be successful when you go to this type of transformation? Yeah. Yeah. Like to your question about this, right? I mean, the fundamental idea, even in the culture piece that Dora, what it preaches is that, you know, teams deliver results, right? Not individuals. So how do we build these high performing teams and enable them to deliver the speed and stability in these Across these four metrics is what we're talking about. So after the culture pieces like, great next, let's talk about you know, what is your lien team that you're gonna be following What is continuous delivery in your In your opinion, ever. You need to get these changes. Bug fixes quickly into production, right? Those are things that I would say after the culture pieces like then start looking into forming that lane team getting into like talking about your application, a lead times measuring them and start fixing each one of them in a specific way. Yeah, absolutely. And I know we're saying, 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 the same page, it makes it very difficult to be successful also, you know, we've talked about measuring. I've seen many places where they'll measure, but they're not actually doing thing with those measurements. You really need to make sure that as you're measuring your continuously looking to improve on those measurements, if you're at a month lead time for deployment, you know, you probably want to get that a lot lower. So whatever barriers there are in the way, you want to make sure that your really trying to knock those down another area. I think I'd like to point some attention to is around the silos 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 and really, what we want to start doing is making cross functional teams to better aid and knocking down those silos to better aid in improving those deployment metrics. And, uh, ultimately get us towards that successful transformation 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 that you just made because that's that's one of that is the planning side that you have these small batch sizes dedicated cross functional teams and going through this continues planning. And then there is, you know, from the planning phase. The next is the If it was to look in the development and tests 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 an automated environment provisioning...

...automated, you know, release and deploy to change that they have, and then finally, again, back to the Can I monitor it, optimize it, measure it, you know. So those four buckets are kind of like, you know, Kiki building blocks off the growing capabilities, so Obviously, what we're trying to do with this, you know, is is really evangelize. Acceleration of application development, but not just the acceleration. It's also 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? The collaboration pieces is amazing. So how do you see this really affecting the organization? As far as how much can this accelerate bringing to customer value 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 can talk about the methodology, as you said, right? I mean, we've actually this is again from the studies that we've shown that you know what we call about High performers are more agile. We've seen 46 times more frequent deployments from them coming just from these high performance right, and it also more reliable. And they say you know, they're five x more likely to exceed any 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 off simply by moving to this model is the speed faster delivery of features. I come up with an idea today three of us just sat down. Can I quickly spend this up? 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 is also 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 all the things I think you will start seeing in terms often accelerated application development right. And that automatically brings in tow, improved quality of court as well. And also quick recovery. Because now you're able to like with these automated things, you know immediately how quickly you can find out that you're called bricks, so you can immediately come back, find out about it. But the Landes continues tests again and go back and patch it again. So that improves the quality of the cold. Quick recovery makes it a bit more efficient around it. right. So those are the kind of things that it's almost 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 go faster and be more agile and, you know, get this accelerated deployment, you're gonna naturally be working with smaller and smaller pieces with much mawr automated testing. So whenever you're making smaller changes through this process as well, you're actually gonna be lowering your risk of anyone deployment, causing some sort of catastrophic failure. And again like like you said, whenever there is a failure, it's easy toe is it recover from? But I think the minimizing the risk per change is another really important thing about Dev ops andan. The other point I'd like toe bring up is also in your development phase, not just your deployment phase. Having a good dev ops culture. Really? Let's you experiment more so you can not be locked into a specific technology stack. You can discover new new technologies to 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 fail fast or succeed fast, right? You can quickly figure out. Is this going to work? Is this not going to work? And you can make better informed decisions and And that, I think, is a big part of the accelerated development cycle as well. Yeah, in that failure part, I think is very key. What comes to mind this week was I was watching a space six test. Where there, uh, testing some of the components toe get to Mars. And...

...they've been landing these boosters out on the drone ship quite frequently, but they were bringing down a new booster rocket that they haven't done before. It blew up and everybody was like, This is awesome. We got all kinds of great data from it. And like that, to me, is like the epitome of celebrating failure. And yeah, that's a good thing. That that that's what I'm saying. It was not that. It's It's It's awesome. Man. With that, Yeah. I mean, what did you learn from it? Right. And so I think, and what I keep hearing you I'll talk about, you know, is measuring and feeding it back 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 lessons learned and doing it so rapidly, not waiting months to come back and look at it. And I think that is, uh, just such incredible power. And, you know, and what I also want to kind of implore people to is this methodology doesn't It's not just for software development, right? I mean, it could be for anything inside your business to some degree. Absolutely. Yeah, And you mentioned feedback loops. And ultimately, what we're trying to do with a lot of the Dev ops methodology is we want to reduce the time it takes to get feedback. We want fast feedback as quickly and as often as possible so that we can constantly make those decisions. That's why we're breaking things 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 feedback times. 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 technical aspects of it, but it's also incorporating that that data back from customer experience, that the value that they're seeing And of course, the business owners inside the organization as well. It could even be sales. And they'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 from process and feedback from culture, right? I mean, these are the three fundamental pillars behind these transformations. And, like, I mean, I honestly I I am part of sales here, and through my entire career, I've been in sales, and I always tell, you know, the people are higher and everything it is like you could spend six weeks sitting and reading as much as you can when you want to ramp up. Or you could go attend three customer meetings and you will get so much more knowledge about anything that you want than any of the videos are things that you're listening to. So yeah, that's great. Now I want to kind of wrap it up for a question for both of you. And when you you're coming into a new environment and somebody wants toe, you know, embrace this, let's say and obviously we talked about some analysis that may take place at the beginning, and everybody's results may be different. But what is the typical first step that you tell people they should probably take in order to develop this culture developed a culture? Or how do you get started implementing 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 approach on how you want to get started. Ah, former small team, take a small project and go experiment with that right? That's how I would start. I mean, I believe you. If you really want to do that, I would say start with a door assessment, which is what you know a lot of the customers were working with today. 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 see where we wouldn't see easy to make the transformation. But we know where we wanna go. So if I was to force and say what to do, I would say Let's start with an assessment of your current capabilities that you have because even if you take that small team and you just cause they don't know what the boxes, what are they gonna do? Right?...

So transformation starts with understanding first where you are today. Step one, Step two. Let's take the data and see. OK, this is where you stand. This is where you're missing. Maybe you don't have the skills. You don't have the tools for automation. You don't have the, you know, small set off things that we need to go build. Step two. Step three. Let's build those pieces. Where do we start for shrinking them? 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 work on that one metric, and then everything else kind of falls into place. That's how I would go with the step by step approach on it. Yeah, I wish I could disagree or have a different line of thinking, but I I I pretty much would directly agree there. Start off with the assessment. Understand where your company is strong and where they're weak. Leverage where you're already strong. Improve where it's weak. Using a pilot team, as you mentioned, is a great way to start because you're minimizing risk to your organization as a whole. And you're gaining those learning experiences of what you're probably going to see as you open up the transformation. The rest of organization, I think on top of that, I would add, though training in particular 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're going to start doing automated testing again. That's another thing that requires 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 resource is and everything as well, and I found you could go ahead and start introducing portions of your organization to those topics. If that's an area you're not strong in, Um, if you are strong in those areas, then you know, maybe it's some of the other culture deployment metrics or just general sharing opportunities that you're lacking in. That's really that assessment. Being honest eyes super important. Having the right people ask questions is a good idea because you know, people will answer differently depending 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 me and your background I just gotta want to close out on this is that you came from a docker background, obviously, and you know, that's a very interesting tool in this whole ecosystem as well. We see it often, right, but we spent very little time talking about too late, because I think, you know, put more words 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's only as good as the people who you could give it to right? I've spent so many times like just spend 100 meetings and at one time I still remember. I just I think I got up and told this. I don't know if it's a customer or like another, you know, made up or something. And at at some point, I'm like and I've been talking to you for six months about this. We just have multiple meetings I've taught you. And I've you've read every book about swimming right now, just going to jump into the water. It sometimes it's that it's this over analysis, paralysis on it and thats why this the mentality to like quickly just do something and see it and it's okay, you know you're gonna fail. And whereas I've seen some companies before that they've adopted Doctor is very, very, very early stage, right, even though, like I mean, it was not even ready for running in production. But we were like, you know what? They were ready to experiment with it. It was a hard journey, but we came out really, really successful, and...

...at the end of it, they had the teams trained. They had the people trained and they had things around it there was trained well as well. So that's why for me, like, I can give you the most shiniest object. But if you're gonna keep it inside your bedroom and not use it, it's useless. So that's great. Well, I want to thank both of you very much for joining me this week. Larry. Fantastic conversation, Joey. Hope to see again after this pandemic as well. And, uh, yeah, thanks again, Great conversation. And wow, it's always, you know, we talk about the evolves all the time, but it's it's always good to get this perspective. I feel like this is pretty actionable stuff that you guys were ableto uncover for us. So thanks again for that. Next week, we're gonna be looking at the third and the fourth strategies. Do increasing your clouds value to that, go hand in hand, increasing the security of the cloud environment and ensuring compliance. As always, we welcome your feedback, please. Email is that cloud crunch at second watch dot com for your ideas, comments and suggestions. Thanks again. See you next week. You've been listening to Cloud Crunch with 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 watch on Twitter.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (33)