Cloud Crunch
Cloud Crunch

Episode · 2 years ago

S1E16: Managed DevOps - An Oxymoron?


Managed DevOps sounds like an oxymoron, so why would someone consider it? Hear from our DevOps pro about the factors that contribute to companies stalling mid-DevOps Transformation and how a Managed DevOps strategy can help overcome that plateau.

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. Welcome back, everybody, to cloud crunch, where our lovely podcast here, where we explore the impact of moving to the cloud and all strategies around it. Want to welcome back our guests Stefana Mahler and our cohost skip berry. Skip, how are you today? But do a grady and welcome Stefana again. Hi, guys, thanks so much for having me on the call today. Oh, absolutely, absolutely so. I think what we're gonna do today, Stefana, you've been a guest before. We had a fantastic conversation about devops. We're going to talk today about is managed devops. So this is going to be an interesting conversation because I think it's going to take it down and a much deeper path here. Let's kick it off with let's just call it out managed of OP. Sounds like an oxymoron. Yeah, absolutely so. I'm assuming you're asking, Hey, Stefauna, why would we say we're managing someone's Dev ops for them? I absolutely agree. It does sound like an oxymoron and when we first came out with the name managed Jav ops, it was really struggle to figure out how are we conveying what it truly is. So let me break it down a bit of what it truly is. It's not taking away your team and replacing them with a manage team that will handle devops for you. The idea behind manage ev ops is to enable your team over time, to adopt devops practices by taking off the big chunks of difficult work that they don't have to do. Maybe that includes implementing technology, maybe that includes managing that technology initially, allowing you to take your team across that change of adopting Dev ops transformation truly while implementing this this work along the way. So managed job ops is not to go and replace your entire team with an external party that can manage it for you. The idea is to help augment your team along the way. So I think what you're saying there, if I hear it correctly, for our listeners is that it really allows the organization to focus on the core benefits of devops and not get tied down in the rudimentary aspects of it. Would that be a fair statement? Absolutely, because the key core benefits that these people are looking for, these companies are looking for, or increasing their operational efficiently sencies, delivering their products faster, reducing that security and compliance risk or perhaps increasing that quality of product and quality of performance. So the key thing... there is if you're focused on those four goals, how are you focused then on implemented the technology to get to those four goals? Maybe it's easier to bring in a tool or a team that can actually implement that for you while you focus on achieving the goals that are a set set forth and focus on your application itself. Right. You don't want to be sitting there focusing on all the underlying tools. You want to abstract your team away from that. That met Minutia, if you would interesting. So no more toil on toil, if you will write exactly exactly. I think you spend a lot of time in deve ops just implementing a tool right or just implementing a one single change into the process that your team will adopt and that and that's what you're trying to remove the pain of adopting this big change. Why is it something that companies are looking for? And then back into alignment with managed evops, if you can kind of summarize that, absolutely. So let me start off with what is devops? Everyone has their own definition. I'd like to try to combine all of that to explain it a bit. One is Dev ops as a term built by combining the words development and operations. Does that mean it only includes development operations? Absolutely not, and I think that's why a lot of people have been concerned. Or wait, it's just making Dev and ops worked better together. That's not the truth. The truth is it is a set of cultural values and organizational practices that, when implemented, will help improve your business outcome. So when you think of that, you know it's a lot bigger than just the DEV team and just the OPS team, right, because if it's going to affect business outcomes, it's going to affect the full organization, and I mean not just the technical organizations as well. Right, just defining it a little bit further, the idea of devops, the D of the term was to bridge the gap between development and operations, to speed up that pipeline to production of new applications, and it's grown from there and it has become what we'd call a game changer for many businesses so that they can increase their efficiency, they can deliver products faster. I said this before, they can reduce the security and compliance risk that they've seen in the past and they can improve their product quality. So all of that effectively in the end affects a higher customer value for from their solutions, from their applications. You know, we it seems fluffy right, Dev ops as a term, but if you dive deeper into the methodology you can see how it touches every point of your application life cycle, including your stakeholders and marketing, your stakeholders and finance, your stakeholders and sales. It's also interesting that it could be perceived as a very risky endeavor to change your culture like this, but at the same time what you're really are doing, and touched on, is de risking so many things going forward when you get there. One of the things, though, that we did touch on a little bit last time, but it would also kind of like to dig into a little bit further.

Is What are the differences between DEV OPS and sire? How are a complement each other? How are they different? Let's it's the five paragraph theme here. Compare and contrast DEF OPS and Sari. All right, so what if I stopped you there and I said Dev ups and essay or the same? So I don't want to say the same. Dev OPS is a methodology, right. Sire is a way to implement that methodology. It's not for everybody and just for our audience to understand what sire is. Its site reliability engineering. It was a methodology, or rather a role, that was developed by Google and they have a book on it. Read the book. It's definitely really insightful on how to implement and the books free. Yes, it's a it's a free ebook. I've read it a few times over to learn how site reliability engineer is different than an ops person, different than a DEV person. They're almost a combination of the two and they work really closely alongside the application owner. So that could be a product manager or an application owner. What is the difference? Devops as a full methodology? Surrey again falls underneath that. I think that's clear. One thing that's interesting. That you'll see in the market a lot is that people are looking to hire Dev ops engineers right and they often look to higher sres. To be honest with you, I don't know what a Dev ops engineer is and I don't think anyone else does either. Do they exist? Yeah, does this Unicorn, or rather you know elusive devops Engineer Exist? Probably not, because every single company is looking for different skills from that person that they're calling a Dev ops engineer. I think Google did a great job of saying here's what an sire is, here's the skills they need and they are the bridge between the DEV and the OPS team and they are measured based on the same things Dev and ops are measured. So they've remove that conflict by implementing what you'd call the sire team. Does that help answer the question? And I don't know if I touched upon all of the differences, but yeah, I know. I think that's a great explanation because we see it often when we're talking to customers that it gets confusing between the two. Often when I'm having an earlier conversation with somebody, they feel like they have to go down one path of the other. That's probably one of the best explanations that I've heard how to describe it. So one's kind of what's a cultural and one's an implement tatition. They really can work together. Being a Google partner, of course we're heavily exposed to sere methodology coming out of there and it is worked very well for them and I think obviously Google has pretty advanced in their career their methodologies of getting things done out in the market place. Well, an interesting area. Since we're talking devops and sire and the distinguishing facts around that, what about true devops and application support? How do we help our customers and listeners understand really the separation there, the difference between the two? So so sorre ends up...

...touching application support a lot of times because they're touching the application. Let's just define that a little bit. I've spoken to many different companies that have provided what they'd called devops resources on a project and most of those resources are application engineers that also know a little bit about ops right, and oftentimes that's augmenting your application development staff. That's kind of outsourcing APP Dev, which isn't really what many companies were looking for when they say they need devops right. They don't want you building features for them, they want you to remove the pain of operating their application, the pain of getting that application to production. So when I see the marketing out there, and I don't want to say marketing is bad, but the marketing out there saying that you know will do Dev ops for you and that Dev ops includes, Hey, we're going to fix bugs for you in your application code, is that truly answering the problem you're looking to solve right? And I think the answer is no. If, in fact, you outsource level two and level three support, who's fixing bugs? What ends up happening is you don't have a devops methodology, your team is not intertwined in that technology, they don't know where the pain points are and they're just going to continue to churn out non quality code right because they're unable to do that. Instead, that application support should be the owners, that the onus on the application support should be the DEV OPS team. It should be the DEV team, the OPS team and maybe even, if you do have an SI re organization, the Sire team that owns that work. So I really have a struggle with the promotion of devops external devops resources just coming into patch your products and or your applications and that that really isn't what you're looking to do when you say you want to do devops transformation. Does that make sense? Because I know that there's a little minutia there that many don't understand, the difference between. I have not yet to meet an organization that has just blatantly said noted Ev ops when never interested in that because is there's no value in it. I think the math out there, the studies show it, and they read these reports as well as anybody else, for Gardner and other sources, and they know they need it and they just can't get there. Somehow, from inception to execution, there's something that stops. And why do you think that that takes place? Well, I think it's clear. Right, there's a promise of devops, just like there's a promise of cloud. Let's tie it back to cloud. Right. There's this promise that we've all entered into this transformation thinking we're going to achieve, and we often enter in and say, okay, I'm going to start with this little thing here. Right, I'm going to implement CICD, because that seems devopsie.

Right, I just said that. Skip, you should laugh at the devopsie term. Right. It seems devopsie to go and implement CI CD. But the key thing is we're not actually looking at what our true goals were here. If we want to speed up to failure, and I say that all the time, we could do that very quickly automation. I'll let us speed up to failure as quickly as we'd like. Right. But the the key thing is devops is not what I'd call Sunshine and roses. Right. It is not a simple change that you can just go and implement a tool and walk away. And a lot of companies spend the time saying, yes, I'm going to do a devops transformation, implement CCD, and then they walk away thinking, Hey, it's done. I have a client right now that I'm helping support through our team and skips team. Actually, they actually implemented and built out a full Kuber Niti's infrastructure, which is awesome, right, and they're waiting for the rest of the department's to on board. I said they're going to wait for a long time. Right. You have to bring those people along that change, and that is a devops change right. It is a devops change to implement a new architecture of an application and change into micro services and all of those little things that are necessary to adopt ev up. So I think the answer to your question is, you know, the reason there is a stall that many companies just focus on the technology aspect. They they end up creating a new, unreliable system. They have, you know, great, great tools, tons of tools, but now it's unreliable, that the security wasn't implemented in it. They're having to handle the rework, they're having to still handle their skills shortage in internally, the team doesn't know the platform, so they're not going to use it. So, just like any adoption of a new technology or new implementation or methodology, you need to slow Goo it in in a way that feeds the team small steps along the way to adopt these changes. You can't just wipe it away and say everyone's going to do devops tomorrow. Good Buck. So I'd like to add to my I understanding of devops stall as well. There's a key area that I said earlier in our conversation that a lot of companies struggle with, and that's basically the technology and also that small coaching along the way, understanding what change small changes to make, and that's really where a manage jevop service could really assist. Right one it could implement the technology for you and abstract your team from that minutia, but it also can help your team along the way on a regular basis, providing them steps to move forward, because the end result of Dev ops transformation is continuous improvement and they have to learn how to continuously improve. You can't do that in a set time frame, right.

Why would someone want to consider manage devops then, even though you just address that, but I'd like to hear it so for me, you know, when I think about it right in, the three of us have talked about this before. Trying to sell something or sell position to a customer. You know why we do this differently and you put a great spin on it all the time and I'd love to hear like how you would help a customer understand that. Absolutely. So it's a good question. Why would you even consider manage ups? What kind of customer would want this type of service? So let me give you a scenario to consider, because that'll help frame the problem or frame the challenge. So customers decided that they need to speed up delivery, they've decided increasing qualities important. They've decided that Dev ops is the map method that they want to move towards. Great, that's a good decision, right. A lot of times that will come from the top down. We're doing devops across the board. Wonderful. But what if you don't have the skills internally for this new change? You don't have a team that can manage the tools because that wasn't funded in this new transformation. That often happens right and you're wondering, okay, what tools do we use? What methodology? Who Do we train first? What team do we work on? And that's really when you can go outside your company and say, Hey, there's some services out that that could help lift us into this position. To get started, I like to say it's not trying to hire these elusive devops engineers up front and then replacing your team with them. It's helping your team up skill along the way. So in that scenario where you don't have the team to do and adopt the new methods, you don't have the team that understands the technology or they're trying to learn the technology but want to make change as they're doing it. That is a great scenario for a managed devop service. I don't think this is a service that you'll use forever. I'm I know that's scary to say from a managed service provider, but I yeah, it's silly to say that you're going to use manage de ops for the full transformation. I think it's a great starting place. Sure, yeah, design, build, run, you know, and then back to you right as you come along, and it brings your team along right in that process. Manage Jeff ops isn't just outsourcing your technology to us. We're coaching you, we're enabling you to learn how to manage that technology in the future, and that is why I guess the term managed devops is a little bit of a misnomer, right, because it's a little hard to understand that that's not just US managing everything. Yeah, to me it feels like something like hub spot for sales and marketing. It kicks starts and let you get the flow going very rapidly and realizing value much sooner, while you continue to upskill and maybe hone it and figure out how you're going to do it even better at a bigger scale later on. Even in a scenario like remember account tempts in the S and s right, it's like just need temporary to come in this one project or whatever, but then to help ramp up the rest of my team. It's a great example of those scenarios, right. So upskill everybody and the... still has a mission to drive, you know, set of goals to actually get there, and that's what we're saying that we can bring wow, we're bring it back the S. I like it, I love it. I love yeah, Bell Bottoms next week, guys. Yeah. So I think another thing to consider also is that, you know, with this scenario, you want to make sure that if you're going to outsource this manage devops type of solution, you want to make sure that that team is obviously skilled in technology, but also skilled on organizational change management a bit so that they can help you move teams give you advice on where it to go in the future. Have that road map, if you would, of where your devops transformation should start and where it should lead or head. Obviously you're not going to have an end goal, because the end goal is continuous improvement, but you should have some idea of what goals you have along the way, and that is a key thing that a lot of remember. We said devops tall earlier. They stall because they didn't know what they were measuring against. So measurement is so key to this managed devops offering and that and manage and any devops transformation, having that measurement along the way and coming back to the initial metrics and saying, Hey, did we reduce the ticketing? Did we reduce the problems that the customers have reported? Have we increased product quality or if we decreased it? Having that measurement is so important to see if this is going in the direction you've planned so that you can react. It's very similar to agile. Right. Agile said we need to measure and bring everything back to the beginning of the change, which is in development, and that's where devops definitely enables this change as well. So you touched on a couple things. The key to success their Kpis or capabilities of measure met organsational change management. What else would you put together in a platform like this that would make it very compelling? And you know, we talked about being a quick start. What else I mean? Obviously, the Dev ops, the pipeline, the CCD, we got all that, but what else would you throw in there? So I think it's important to understand Dev ops is not just one CICD tool, right. It's a full gamut of solutions, plus the culture change on top of that. So the full gamut doesn't start with just developing or coding. It actually starts with planning what you're going to code, right. So that planning process, engaging your product owners, engaging the team that's feeding back from the customer and making sure that is managed in a similar system as to the ticketing or the agile framework that you're using for your development team. And all the way through is we go walk through that Dev ops infinity symbol if you would. You want to go all the way through to monitoring and operating this application and production. But again it's in a fit infinity symbol. So in the end it comes right back to the planning process and and...

...wraps back around that feedback loop is speeding up. So I think when you're looking at solutions and technology, the full gamut needs to be there. You also need to consider that throughout that pipeline that we're talking about, security is infused. It is not security between Dev and OPS, right. It's not Dev sack ops, it's DEV SAC SEC, Dev Dev ops, secdev ops. I mean it's every acronym you can think of, right, because security starts in planning. Security, then continues into build and coding, rather coding and build, right, and then it continues throughout that pipeline. It is not an afterthought anymore. And I think again, for a lot of companies who are so worried about quickly pushing code to production, if they see the security already infused in there, that makes it a lot easier to consume this really speedy time to park to market. Now, that's very true. It's a very valid point, because it's everybody's job. Security, security, security, and you got to put in every aspect of it. Otherwise it could become, we always joke, the Department of no and know we want to turn them into the Department of Canow yes, and you know it as a great point in because I think we always look at security as that blocker, right, and they are, they should be in some sense. Right. Yeah, the risk mitigators, yactly, their focus is mitigating risk and you have the rest of the department focused on what do we say earlier speed to delivery. Yeah, product quality, but speed, speed, speed, so it's it opposite. Their goals are opposite and I think with a devops methodology, infusing security early cross trains not only Dev for security, but security for Dev and ops. So the security team getting up to speed and seeing the value of the pipeline being a very secure ply bind makes it really easy for them to say here's the value we provide and here's how we're de risking. If you don't bring them in early on, you will fail and cause yourself that Dev op stall. Absolutely no, it's a very, very valid point and including them early has been the key to success everywhere we've seen. Well, I want to thank you for your time again. It's another fantastic conversation that we've had and skip, it's always good to hear your voice as well. Thank you, audience, for joining us today. We really look forward to your feedback and suggestions. As always, please reach out to us any time at cloud crunch at second watchcom and we look forward to the next episode with you. Thank you again. You've been listening to cloud crunch with Ian Willoughby and skip Berry. For more information, check out the block second watchcom company block or reach out to Second Watch on twitter.

In-Stream Audio Search


Search across all episodes within this podcast

Episodes (43)