Deconstructing DevOps, a CIO’s Challenge. Solving For the Wrong Problems?

So you head up a technology organization, you’ve got a seat at the proverbial executive C-Suite table (or aspiring for it) and you’re leading your organization through the maze of what it uniquely means for your firm to become digital and digitally transform. Amongst the many, many other things you’re responsible for you’re trying to bring new technology products and services to market faster, cheaper, in a more reliable manner, in an agile way, failing fast, iterating and informing changes through analytics, while moving to and using the cloud. You’re pushing (dragging?) your organization forward, changing the culture, empowering smart people to lead small, nimble teams and you’re shipping code and product faster than your organization has ever before.

Sounds Peachy doesn’t it?

But to do this you’re dependent on DevOps (a.k.a. Site Reliability) tools and teams to enable your fleets, product ownership teams, and developers to get their code to where it belongs, plumb up all those services, third party providers, clouds and integrate with your classic (legacy) systems. DevOps has been toiling away, making great progress over the short term, but your organization is starting to experience a deceleration (if you’ve gotten far enough along in maturing and actualizing DevOps) and there’s in fighting within the groups between developers and DevOps that’s beginning to look a lot like it used to between your Infrastructure/Operations teams and Developers in the past. Applications don’t behave the same on the developer's desktop as it does in the cloud, developers aren’t aware of or privy to what it takes to make their applications enterprise grade so it is secure, manageable, scalable, and since they’re not empowered they can’t be held responsible and accountable for it.

Worse yet, you don’t have enough DevOps engineers to throw at the problems. Hell, there’s not even enough of them in the market to source and it’s also busting your budget to hire them when you do find them. As of today, Indeed alone lists over 8,000+ open DevOps Opportunities in the U.S.

Could it be that you’re trying to solve your problems the wrong way? Over the past 20 years IT did well for themselves by building monolithic applications that, probably still run your  business today, but are also today’s legacy. They were/are large, brittle, difficult to maintain and release and over the years the institutional knowledge of the code and how these applications behave have walked in and out your office doors. Yup, that sounds familiar!

Could it be that you’re trying to solve your problems the wrong way? Over the past 20 years IT did well for themselves by building monolithic applications that, probably still run your business today, but are also today’s legacy. They were/are large, brittle, difficult to maintain and release and over the years the institutional knowledge of the code and how these applications behave have walked in and out your office doors. Yup, that sounds familiar!

Could it be that you’re reproducing all of the challenges of those monolithic applications in today’s, agile, microservice, cloud powered, DevOps delivered age and just moving the problem? The short answer is maybe!

The premise for DevOps is to treat your infrastructure as code, highly automate the newly software defined data center (and/or cloud), release small(er) bits of code automatically and often, while handling elasticity of applications, keeping costs in check and keeping the security, privacy and compliance folks happy. This inevitably leads to significant investments in people, processes, tooling and custom coding that is centralized in your configuration management tools (Chef, Puppet, Ansible, etc.). So instead of monolithic applications, you’re building and investing in large, complicated DevOps orchestration and tooling that’s dependent on a small team.

There may be better architecture patterns to follow, that allow for democratization of DevOps orchestration, while empowering your developers and holding them responsible and accountable for their code and applications scaling up to production to run your business. Casey Bisson, Head of Product & Developer Relations from BluBracket, does a great job detailing these problems and offering up an alternative architectural pattern to creating stateless applications using DevOps. Helping break down the root causes of these challenges in his presentation at this year’s Container Summit.

It’s worth a listen to help think of how you may be able to pivot and tackle your challenges in a different way. Casey’s examples center around using Docker based services to help solve for the problem, but this same pattern could easily be used in Virtual Server (Cloud or OnPrem) environments. It's not a panacea, but if it's an edict, you may be able to lessen some of your DevOps burdens.

The big take away here is that unless you continue to think about the problems differently, you may face the same challenges over and over again! Here’s to not going insane!

© 2022 Mesh Digital LLC, ALL RIGHTS RESERVED