Cloud Crunch
Cloud Crunch

Episode · 2 years ago

S1E10: DevOps' Place in Cloud Transformation

ABOUT THIS EPISODE

Stefana Muller, Sr Product Manager of DevOps at 2nd Watch, joins us today to talk about DevOps' place in cloud transformation. We examine ideal entry points into DevOps transformations, methodologies, secrets to a successful transformation, and the "impossible ask." 

We'd love to hear from you! Tweet Stefana (@stefanamuller) or email us at CloudCrunch@2ndwatch.com with comments, questions, and ideas.

Involve, solve evolved. 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. Hey, everybody, welcome to cloud crunch. Glad to have you back for another episode. Today I have my co host, skip Berry. We have a very special guest today, Stefano Muler, senior product manager for our devops practice here at Second Watch. He's one of our colleagues and love working with her. So this is going to be a fun conversation. Today's conversation is going to be about devops and how it fits into a larger cloud transformation. Welcome to fauna. Thank you, Ian, it's so great to be here. Hey, welcome to Fana. Great to see you on the podcast. Thanks, skip. Yeah, this is going to be a fun conversation, so let's get started right into it. Let's talk about the magic word devops. What is it? There's so many definitions o there. So We'd love to hear your expert opinion on this one. So you really want me to do this? You want me to define v OPS. Huh Yeah, okay, all all the DEV OPS has. Well, you know, I'll start out with us. I think it's really important, obvious lie, to just look at the word. Dev OPS. Is a set of practices that combines software development, which is DEV, and it operations, which is ops, and the reason it's the devn ops is that's where the initial struggle existed. But that definition has really grown over time and it's important to know that. Yes, initially we were very focused on just ev and ops and making them work better together and enabling process and technology there, but we can't forget that we've learned something over the past ten...

...to twelve years that this has been around. So as we've grown, we've realized that struggle doesn't just exist between Dev and ops. So I like to add to this definition, as any technologist would right. I like to add that in this definition we have to cover the growth of Dev ops, to obviously cover cultural values, organizational practices and improving business outcomes by increasing collaboration and feedback between all different departments, including business stakeholders, development, QA, it operations, and security. Awesome, that's good. I think that's a great clear definition and I love that now when you say all parties, you know you were kind of mentioning that. Is it. Does it go beyond just the technical folks? Absolutely so. I think it's really important to note that when you go through a Dev ops transformation, your company is speed things up, and mostly in the Dev and op space right where you develop products and then you go in operate them in production. WHO GETS AFFECTED BY THAT? Finance right now? You're going to have to transact quicker sales, you're going to have to sell differently marketing, you're going to have to understand that new features are coming out a lot more quickly. Right so you'll promo, promote them more. I can really point almost every business area in an organization and say that there is change that occurs because of devops, even legal. I had this conversation recently with an organization that said, well, we decided to move to devops transformation and we had to transact differently in our legal team, had to change contracts. Yes, that exists. So that's why it's a transformation. It's not just a Oh, we're going to implement v OPS right, and I think that's really important to understand. And why a lot of folks focus on Dev and ops initially is, Hey, frankly, the name...

...suggests it, but then they realize, oh my goodness, it is really changing my business. I would agree, Stefana, in my experience in the evolution of this really it's everyone used to say, you know, by directional between developers and operations. Right, but you have to look at it again. To your point exactly, this is really a momidirectional, if you will, from a organizational change and the failure to embrace that as really the failure to transform. So it's pretty interesting, absolutely, and I think you know it's interesting because we again focus on Devin ops initially, but think of project management across the board. Has to change. And you know, when you look at it as well, devops started from the agile transformation effort right where people are trying to speed up tree, they're trying to find newer ways to develop software. So when you look at that, Agile touched a lot of departments as well, even though it was a development methodology. So it really does make a lot of sense that devops would touch a lot of departments as well. Totally. I think that's great. And then obviously there's a lot of leaders inside an organization. Some of them right letter leaders, some of them are businesses, ecutives just across the whole kind of business. If some were to convince them that this is the right approach, what what would you explain to them? That would be the outcomes of doing this successfully. So I think it's important to know that. You know, initially devops is there to remove the struggle between departments, to streamline processes, to streamline, you know, the culture of constant innovation, allowing teams to innovate, removing those barriers. What do companies get out of this? You know, once they understand their challenges, they're trying to resolve those specific challenges. So every company's going to get something new or different out of it. For example, if you have a high cost of development and you're trying to implement Deva of ups to address that high cost of development, obviously you're measuring towards that success it.

Leaders can get a slew of benefits from this. I can list out a few just to give you examples. One, cost reduction. Second, speed or faster time to market. I like to call it faster time to value, because it's not just deploying a new product or feature but actually getting that value to your end customer quickly. Higher Security in your process and your development cycle and so on. Making everything that you do measurable and reportable and transparent is really helpful to measure your business. And last but not least, one of the biggest things, and the reason why a lot of companies went there, is that high level client experience. So delighting your customers with new, stable technology often keeping your customers right, getting that retention. All right, that's great. Like that. Like that very much. Let's kind of Geek out for a little bit, if you don't mind. Let's talk about tools, because everybody gets excited about tools and I think you know obviously we see people that say I just need to put the tooling in place, but obviously they're very critical. What is your feeling of the value of the tooling and how it fits into the larger picture? So we all know this. I call it devops washing. I'm going to use that term. I actually stole that from Matt Stratton, who's one of the founders of the devops term. Right. He said that all the tools vendors out there. They're great right there enabling devops through tools, but they often come up with these ideas that the tool is going to solve the devops problem. Right, and the answer is it will assist. It is an enabler to assist in that, but it's not going to solve all your problems. Matter of fact, putting something in place that automates something, automate speed to failure right, if your team isn't ready for that. I like the speed to failure guys. You'll...

...hear me talk about it all the time there. You can speed up fast enough with devops, but you're going to end up in a place where you can't handle what you can't handle. So I think that's important to note. But let's back up a bit. Yes, tools of course enabled ev up. So where do people typically start? It's CICD, right. They always think continuous integration, continuous delivery. That means devops. I'll pause for a moment because if you have any other suggestions of where people start in devops, I've seen it really CICD first. Maybe infrastructures codes to try to enable that automation. Have you seen other things? Now? I think that's really. In my opinion, that's where a lot of people get started. That's where they spend their time focusing the develop a pipeline and the potentially some agile practices around that as well. I kind of comes hand in hand. Yeah, and then where I see things fail really from from the outset of that, and this is where second watch comes in, is really start talking about your evolvement from a production support application, monitoring, automated dashboards, not to start quantifying, and that's really, you know, to your point earlier, Stefana is refining the devops transformation, if you will. Absolutely. I think you know. When we look at that devops pipeline, if you've ever seen it, sometimes it's an infinity symbol, sometimes it's a left to rights, you know, map of what the tooling should look like. The center of that tooling happens to be, or rather a little bit to the left, and center happens to be CICD. But the interesting thing about that is it doesn't cover what you just said, skip right. It doesn't cover the monitoring and all of that, because DEV OPS forms out of development, right. So they focus on the things to speed up development. Interestingly enough, we now realize all right, as we've gone through this process over and over again, that you can't just focus there right if you're going to try to bridge the gap between development and operations, you have to make sure that full pipeline laps...

...or rather move together, and it's a full end to end feedback cycle. So that monitoring end of the devoup cycle is so important. And I often say to clients or anyone asking for advice in their devops transformation, I often say you don't just start with the ICD because you're just speeding up right on the DEV side. Make sure your OPS team has their tools ready as well to feed into that CICD pipeline, because then you're breaking down those barriers early on. Good Point. Yeah, now, obviously our podcast is called cloud crunch, emphasis on cloud. Why do you feel as though this is a great time? You know our listeners are interested and potentially starting a journey to the cloud or they're in the middle of it, getting going, and it's so there's some spectrum of where they are, expiration or doing. Why, at this particular junction, would it be useful to really start thinking about changing the methodologies the way things have been done before and moving more towards this model. So there's tons of synergies between cloud transformation and devops transformation. I'm going to start with cloud, because moving to cloud is that significant business change, business process change and technology change, right, and it has all these promises more speed, lower cost, all the wonderful benefits of cloud. A lot of companies jump in with the intenses to see those benefits right away, and I know Ian and skip, you see this all the time. Right. They expect, Hey, by the way, I want to see the Roi in three months right. Interestingly enough, the challenge is often they hit that wall midway through their transformation. They move everything the cloud and now they're stuck. They don't know how to move forward more quickly, how they're going to hit all of those things that they expected. So they can't hit the speed that they seek. They can't figure out why they're spending more money than they...

...thought. Their teams aren't ready for whatever they tried to do in the cloud transformation, or maybe they're not fully trained and their outsourcing such and frankly, their culture doesn't support the new normal that they're in. Right. So, even though they went to cloud and there's this speed to cloud, you know, the security teams at the end of the process telling them they can't move forward, or legals not ready for this. So we're all of the things right, you can imagine. So when I look at that you can see the synergies really clearly between cloud and devops. There's a there's a gap in process and people to keep this moving forward quickly. DEVOPS can become that support in your cloud transformation. It can help you solve for those specific problems. I list it out and I think many companies often think that they should start devops later. They're not ready because they're not agile yet. You can start it in the beginning of your cloud transformation. You can start using those practices early so you don't hit the wall. Right. They're not mutually exclusive freely at the end. Exactly exactly I mean. And you don't have to do devops to be in cloudy. They are, of course, but if you want to achieve those specific goals of cloud right, the speed, the cost reduction, all of that, you really do need to transform it, transform how your team's work. So absolutely I know that's that's a great insight. I think one of the things that I've enjoyed witnessing as some of our clients who have expressed deep interest in getting there and they've come to us and said, could you help us evaluate where we are right now and where our risks are associated with fully fully getting into this whole transformational aspects of devops? Can you talk about some of the things that that can help enterprise figure out where they are right now and where they need to improve? Yeah, absolutely so.

There are many different models. You can go online and Google devops assessment and you can take an assessment and see where you are and they pretty much cover all the different areas, using different terms to describe them. So they're pretty much all the same. I want to mention that I like specifically as a model that was founded by jazz humble and Damon Edwards when they first created the first devop stays. The model is called calms. So actually John Willis was also in that and that loop. Just to keep make sure I give the credit where credit is due. COLMS is a great way to assess where you are today and also continuously measure an assess. So I'll explain that a little bit. There's five different areas there. Every every letter of that word is an act it's an acronym. See, is stands for culture, A for automation, L FOR LEAN, M for measurement and S for sharing. So if you cover all of these areas you're you'll be able to see, you know, for example, and culture, how do is your top down culture shift? Are Your developers working with APP owners and operations and legal and all the other departments? How does your management team support that culture? Do you enable the team to fail fast, you know, and do things that are not very comfortable for management? Right? I think those are important. And then you go into automation, and we talked about that earlier. CEICD all automating all your processes, removing what they call toil, which is, you know, wasteful work. When you move into lean, that's where you're able to visualize your work using some of those lean practices that you've seen in our industry for many years and other industries, right in the car manufacturing industry and so on, reducing batch sizes, limiting your work in process. Then...

...you move into measurement, and again, key to this process is having measurement up front, because if you can measure or your progress, you know if you're going somewhere right, and a lot of folks say I spend x amount of dollars do in this transformation and I don't know where we went. Well, you have to set your goals and measurement up front or you won't be able to measure that you went anywhere. Right. I think that's so important to keep that telemetry out there for everyone to see as well. And then, last but not least, sharing, and that is obviously a key area, being able to capture and convert knowledge across the team. We call that tribal knowledge. Right, the team's knowledge sharing experience, whether they're successful or not, being okay with sharing unsuccessful experiences so that others can learn from those mistakes. So I went through the COMMS devas assessment model. You can read tons of books on this, but I think you know from a second watch perspective, we really focus on that model because it does cover all the different areas of DEVOPS, allowing us to make sure we're measuring up front and then measuring along the way. Yeah, certainly in practice as well. Right. And I guess to some that up it's really at the end of the day, it comes down to culture and how your culture evolves. Right. So I think the comms acronym method, if you will. It's something that we embrace a second watch and we go out and stay in force, but that that's symbiotic of how we go and influence a customers journey at the end of the day. That, you know, that's a key point. SKIP. You don't have to just use colms for devops, transformation even right. So it could absolutely be applied to any other transformational effort to reduce cost, to increase speed, to get to those benefits. Yeah, it will. So, yeah, this I find this fascinating. I was forced in my family...

...in one thousand nine hundred eighty four to read a book called the goal, and the goal is the predecessor essentially to the Phoenix project by James Kim and it's actually referenced in that book. It's fascinating to me that what came out of quality management of manufacturing as really lend itself to this industry. So it's to some degree it's a it's new, but it's not new at all. It's just now cooling of what we do these days. Taylor, reductionism is the term. Yeah, let's not go there. That's the right, right, right. So it's a fascinating book. The goal published one Thousan nine hundred and eighty four. So we talked a little bit about security early on and I think it's very important that we touch on that in a little bit deeper level because a lot of cases there are people, you know, what I see frequently is security because it's a new model. Their job is not just to say no, but their job is to eliminate risk and we totally understand that it's a hard job for them and when things are really going quickly, I think human nature in a lot of cases is going to just kind of say, let's stop and hold on. Think about this a little bit further. What have you seen as a great success model to really bring security into this process early on and make sure that they feel comfortable, get up to speed and really contribute in this model and be very impactful well increasing experimentation and all the things that we want going to market quicker with value. So that's a great question, but I'm going to flip it on you. You said how do we get security involved? Right, right, I want to flip it the other way and I learned this yesterday, so don't not that I learned it yesterday. I've heard it before many times, but I was on a Webinar yesterday with our our expert in security, Victoria Geronimo, and she said the the opposite. She said security obviously can get involved in the devops pipeline and they can learn how to get involved there, but what a about making sure the developers and the operations team are involved in security? Right?...

Yes, security and operations in depth all have different goals. Right, they all have different goals and I think that's the key to understanding how to fix this problem with the conflict. Security wants to make sure that they're decreasing the risk there. That's their number one goal. Right, decrease of risk. And when you apply speed and you apply tons of new stuff, what do you end up doing? Right, skips like yes, that's an increase of risk measurably exactly. So you know when you're trying to reduce risk, you try to reduce change, you try to reduce all the things that deve ops wants to increase. It's interesting. I think that there is a few ways that you can help integrate security into devops and Dev ops into security that will help companies bridge that gap up front. Number one for me is cross training. I think that if you train security in what devops goals are and help them figure out how they can apply to those goals, it's really important for them to understand the devops is not out there to cause more risk, right, but getting bridging knack APP but then the vice versa. Right. Dev and ops need the same level of security training right, understanding the role of security, the goal of security and what could happen if something were to go wrong. Giving them real examples helps because if you've ever spoken to a developer, and I'm a developer so I can yell at Myself For this, we don't listen unless we've experienced it ourselves or if someone truthfully can tell us a real story. So give them real examples. My second thing I want to talk about is tooling, because we, I did say tooling is an enabler right earlier in our conversation. It's so important to make sure security tooling...

...is integrate did in your devops pipeline early, because if you just let security be that blocker to get to operations, you're just creating another block in the process. It's called the throw it over the wall mentality, right as soon as Dev is done, they throw this this code over to security. Security spends three days scanning it for vulnerabilities, comes back with forty five hundred vulnerabilities and result is operations is never seeing that code and we're all stuck. Right. That's my story and I'm sticking to it. I managed in my past. I managed to product that had over a hundred developers and we face this constantly, the vulnerability scanning. We would just over override it. We said, Oh yeah, we'll get to that later. Is that secure now? It's interesting because it comes back to that omnidirectional transformation and evolution, if you will. Right. So the you know, the Dev Sec ops movement, if you will, although it's been around for a while. What have you put to your points to Funa, integrating that as part of the foundational knowledge? When you start right from really, you know, Grid Zero, zero on the on the map, right, is it's ingrained in the development process. It's it's ingrained in the actual operations process. So when you get to the point where to your point where you have the scan codea would have you all the gains that you've made through the efficiencies of Devos, you don't slow that back down, you don't regress right, exactly play. Yeah, that's a very important factor. I think one of the tools I saw recently skip that I thought was really important, and I'm not going to mention the vendor, but they actually integrate in the development process prior to the built where you can scan for vulnerabilities then and they open tickets automatically based on that, so the entire team is aware of that vulnerability and the entire team can assessed in patching it before we merge that code. That is where that's tearing down some...

...major walls right there, moving a shifting completely left in the cycle, right, and that is important to devops and I think you know, I would love to see more development organizations embracing that type of technology so that they can break down those barriers early. Agree. Hey, I want to double back on something, just probably get both you and Ian's opinion of this. When you think the cloud of the CSPS, you know, the the big ones, you know that we obviously deal with their role in an evolving whether it's Dev sec ops, devops just in general, the broad the broad strokes of the term. You know, where this didn't originally was conceived obviously in the development worlds, when Agile. You know all the stuff that we mentioned before. But what do you think their role is in helping companies evolve here? You know, ultimately, you know consumption in the cloud as the big thing. That's how their business survives. But I'm just curious about both of your opinions where you see that evolving to and really from a responsibility perspective, even from security. Well, I think our our CSP partners right there. Their goal is to obviously increase consumption on their platforms. Devops enables that right with the speech. So that's a value to them. But they also need to enable devoups right, and they do. Many of the vendors have their own coding tools mostly right now. What I've seen is them focus in the Dev segment with the tooling and then separate tooling for ops. I think that is where they can grow is enabling that or bridging the gap between the two with the tooling that they provide, overlapping Dev tools with ops tools so that people can have a cloud native option. That makes it very quick and easy for them to enable A to enable their teams with tooling from a process perspective in...

...the cloud migration effort. A lot of our most of our CSPS have a great cloud adoption framework. I think they need to consider the cultural aspects of devops in that cloud adoption for framework as well. Yeah, just I think that's great and you continue to see development in the tooling, particularly with the clapprovirus of course, and just you know how everything is API driven. That helps the tools that if you take like what Amazon has done recently in the last several months with code coverage and security inspection of code, it just keeps going deeper. I think in the past with the share responsibility model in a lot of the things were on the customer to figure out how to solve and the cloud providers keep going up to stack on that shirt security model for enablement still ultimately the customers responsibility, but I think it's fantastic that that tooling is there. Well, I'm going to change just a little bit of what we're focusing on. I want to put up maybe a little challenge or maybe we could say how it fits sort complementary or kind of competing, but there's a lot of confusion about how sire or site reliability engineering versus devops and sometimes I think people think it's one or the other, or some people understand it. Maybe they can kind of work together. What is your interpretation that Stuffun I have I have an opinion. Maybe it's because I know a lot of series. Frankly, if you can have sis, it enables devops tremendously. The challenge I see with us are though, is a very expensive model. So there's tons of great opportunity there. There's a nessary handbook that Google puts out that I've read inside and out on measurement and helping to enable the team to develop that those proper practices to make sure you're keeping your product up and running and your development team is working together with that same operations team, or rather they're the same team, right. So I'm a proponent of SRES. I...

...also think that it's a very expensive model because it does cost a lot of head count. Right, you do need to have the dedicated teams attach to each product area and that person is multi disciplinary, right. So that person is a unique person in the industry that understands operations and did system administration in their past or whatnot, and also understands development and coding and different pipelines than such. So I think you've got many forward thinking organizations already started in the Sur re journey and doing quite well there. But on the other hand you've got organizations to not not that they're not forward thinking but knowing the cost they'd have to invest in there, it takes a little bit of time to get up to that Sur re model. That that's my opinion on that subject. Yeah, so it's interesting. So I guess, in the Grand Scheme of things from develops perspective and everythings to fund in your mind, how would be the best way to you know, if you were about to embrace on your journey, or bark on your journey rather, what would be a best way to start start up? It's a good question. So I don't have all the answers here, but one of the ways that I've seen very successful is start small with a team that's willing right and prove it. So what I do initially with a lot of clients as well, go out there and will assess where they are today. We might assess four or five different teams using the comms model understand where they let, where they lie and what things need to add be addressed. That also identifies the goals we want to achieve right, because, again, every company has different goals when it comes to deb ups. So I think understanding where you are today then focusing in on one or two teams that are highly functioning that can actually be successful in this will...

...create that case study internally to let you sprawl this this this effort. I also see it's so important upfront not just to do these proof of concepts but also bring the right people along the change curve. So one of the things I think we need to focus more on as an industry is getting the IT exacts on board with devops and understanding what it is and not that it's not just tools and it's not just CICD that they need to help support this effort. They need to remove the barriers, they need to help with the measurement, they need to invest in this effort so that they can achieve the benefits. The way you do that with it exacts, you know, is is show them the money, right. All its besides, yeah, really show them the cost cutting, show them what the goals are and then measure towards those. And I'm not saying that they're only fueled by that, but that does help them justify the means of this transformation. Absolutely, Stefana. Thank you so much, and I would encourage everybody to check in with Stefana on the socials and we could put this in the show notes. But what's the best way people can reach out to you, Stefana? My favorite way is twitter, so I'm at Stefana Moller, Ste F Anamuller, hope to see you on twitter. Yeah, well, thank you very much, Stefano. That was excellent. Thanks to very much for your time. Absolutely that's good. We'll put that in the show notes. And Audience Please, we love your suggestions. Please reach out to us with comments and ideas at cloud crunch at second watchcom. That'll also be in the show notes and we look forward to seeing you in another episode. Skip, thank you so much for your time, always great, and Stefana, thanks again. Thank you. I'm I takure to day. Everybody. You've been listening to cloud crunch with Ian Willoughby and skip Berry. For more information, check out the blog second watchcom...

...company block or reach out to second watch on twitter.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (33)