DevOps ain't dead but… we gotta talk

Content Writer

Copywriter

Ghostwriter

Google Docs

Google Drive

Microsoft Word

Humanitec

DevOps isn't dead by any means. The field is still evolving, and the continued adoption of cloud-native technologies means there's plenty of room for fresh growth and innovation.

But the picture isn't perfect. Organizations often do DevOps in problematic ways, and engineers suffer the fallout. From causing daily cognitive load to permanent shellshock, many DevOps setups are just plain broken.

We've heard countless stories recommending platform engineering as a perfect repair for DevOps. But can platforms achieve their true potential without an accompanying shift in mindset?

We asked Mallory Haigh, Humanitec's Director of Customer Success, for her take on the situation. She gave us a glimpse into the future of DevOps’ by focusing on the human element.

Tackling the issue from a standpoint grounded in full-stack engineering and anthropology, Mallory explained many of us overlook a few realities. Here's her studied opinion on why DevOps being alive and kicking doesn't always equate to healthy developer experiences—and how to fix it.

DevOps as a victim of misinterpretation and misapplication

According to Mallory, DevOps is about collaboration between humans and technology. The big question is how to help people keep up without burning out.

One of the first truths to realize is that DevOps is a victim of misinterpretation and misapplication. Truly effective DevOps is about people management, human interaction, and culture.

Sadly these elements often get lost in the shuffle. Far too many teams fall into the same trap. They commit to a mistaken ideal by declaring, "You build it, you run it—and you just have to suck it up and deal with it."

At best, this philosophy is flawed. At worst, it actively promotes burnout and a legion of related problems.

How does DevOps go wrong, and how can we get back on track?

For starters, nothing is truly “clean” in cloud native. Distributed computing may be fast and functional but also chaotic and complex.

Just look at the facts: Developers waste 25% of their time operating apps as complexity increases—and complexity is rising.

Compared to 2010, today's apps have 25 times the number of services and infrastructure resources per app. They require 5 times the number of specialized tools to meet scaling demands. And you’d better believe that means more specialized roles to match!

This is just the nature of technology in a shifting global environment. Cloud-native best practices won't quit evolving anytime soon. Thus, the rote "you build it, you run it" paradigm inevitably leads to more developer responsibilities and certain burnout doom.

Now, assigning Ops responsibilities to application architects may have seemed like a grand idea when it first popped up in 2006. After all, who would be better informed about services than their architects?

Somewhere along the way, however, companies got it wrong. In the process, they saddled developers with disproportionate, untenable burdens.

The logical 2.0 of DevOps

According to Mallory, there’s no need to chuck the baby out with the bathwater. You just have to do things a bit more responsibly.

This is precisely where platform engineering, aka DevOps 2.0, comes in. It enables “you build it, you run it” in a sustainable way that inherently empowers contributors.

Platform engineering doesn’t just facilitate organizational growth; it never does so at the expense of those on the front lines. Instead, it cultivates personal improvement alongside infrastructural expansion and cloud-native practices.

Platform engineering holds the answers… If you can make a case for it

The platform engineering shift is powerful, but Mallory pointed out that the cloud-native community has seen a noticeable lag. Many platform engineering concepts take about five years to catch on.

Ideas like Internal Developer Platforms (IDPs) and Platform Orchestrators have indisputable merits. It’s just not easy to get DevOps veterans and decision-makers to adapt. Platform engineers must advocate for their position.

So why go to bat for DevOps 2.0? One major reason is that platforms are great at:

Enabling developer self-service that eliminates ticket ops

Reducing cognitive load to let developers focus on the most important problem-solving tasks

Delivering useful abstractions engineers can rely on implicitly as they use their favorite IDEs, terminals, and tools

Providing psychological safety by enforcing standardization by design

Psychological safety is essential to productivity. Developers are no strangers to experimentation, but this doesn’t mean they’re blind to risks. Good engineers know their decisions have impacts, which can be a huge stressor.

Standardization by design offers a sort of safety net. By reducing the need for ticket-based ops and promoting best practices, platform-centric workflows can mitigate the stress factors that threaten to degrade the developer experience (DevEx).

Platforms keep engineers happier and promote a healthier work-life balance. Above all, they let your teams occupy a more welcoming headspace that encourages productive, fearless innovation.

Implementation details: The “how” makes a difference

There’s no one true way to do DevOps. Likewise, organizational journeys from DevOps to platform engineering are accordingly varied and unique.

How does a typical voyage look? Well, there are good trips… And bad ones. Mallory dished up this informative example.

Imagine your team worked for a company that wanted to build a new car model.

An immature organization might tell you, “Here’s a credit card and directions to a store with the raw materials. See you on the highway!” Then, when you inevitably struggled, they’d send reinforcements to help and call it “DevOps.”

A more mature organization would take a different approach by embracing platform engineering. It would say, “Here’s a credit card, but forget wandering the aisles at the materials shop—go directly to the source and use these specific components.” In this version, DevOps helps struggling teams organize white CloudOps helps them find and prep the right materials.

What about the true pinnacle? The most advanced seasoned organization provides more precise instructions and assembly guidelines. The platform team lays a foundation, DevOps imparts workflow structure, and the developers remain free to build.

Resuscitating DevOps in seven simple steps

How can you get into an ideal, empowering mindset when your development practices seem ready to flatline? Mallory shared these crucial steps to help you resurrect DevOps in a faster, better, healthier form.

1. Go all or nothing when treating your platform as a product

Why commit to treating your platform as a product? It’s simple: You’ll improve your odds of successfully adapting your platform to your organization, workflow, and team structures.

Assign your platform a dedicated product owner or product manager. Next, build a platform team with software engineers, and equip them with a roadmap to guide their efforts.

Lastly, remember: Products should benefit their users, so listen to what yours are saying.

2. Prioritize: Don’t fall for the prioritization fallacy

Ranking desired platform features by importance is good… But teams often prioritize the wrong things.

Many platform newbies jump at the first developer lifecycle complaint that comes to mind, like creating new applications or services. Then, they erroneously optimize that aspect to the exclusion of more productive alternatives.

What’s missing from this picture? You guessed it. The holistic viewpoint required to determine which platform features are true priorities.

These false starts often fail to account for the Ops practices that take the most time. Examine your unique setup, and choose optimizations that deliver the greatest organizational value.

3. Set a minimum bar: Agree on the lowest common denominator tech stack

Accept the harsh truth. You’ll never build a flawless, do-everything platform, so temper your ambition. Instead, pick a lowest common denominator, reusable tech stack to serve as the foundation for bigger achievements.

Hint: Conduct a rigorous review of your tech stack to establish the baseline. Don’t be surprised if you come up with containers and Kubernetes (K8s)!

4. Prepare for advocacy: Identify your team of future evangelists

Evangelists are essential to successful adoption. These proponents sell the advantages of platform engineering by couching the benefits in real-world examples with an unbeatable personal perspective.

Choose a team of innovators, preferably with an app that exactly hits your target tech stack. They’ve done the hard work of making your lowest common denominator functional, so build on their accomplishments.

Trust your earliest adopters. They’re the most suited to educate others and push platform growth, so give them the keys to self-empowerment and get out of the way. You’ll be amazed at what happens.

5. Choose which elements should be dynamic or preexisting

Which components will remain agnostic across your platform and workloads? Which will be dynamically tailored to specific resources or environments?

Making smart choices here can ease the path forward, especially with a solid Platform Orchestrator. And always adhere to a declarative application model. In doing so, you’ll gain the power to configure things dynamically with minimal manual input, fewer breakdowns, and less-exhausted DevOps engineers.

6. Start building

The big moment is finally here. Take advantage of the opportunity by building something that’s 10 times better than what you had before, no matter how small.

Concentrate your efforts on where the ROI is. Focus and remember your prioritization efforts from before!

If there was ever an appropriate occasion to spend too much time on something, your first buildout is it. You have to get it right, and you absolutely must make your evangelist team fall in love.

7. Stick with the journey

Platforms aren’t built overnight, so don’t give up. Iteration will always win, and the rewards are great.

Taking that first step may seem dangerous. At the end of the day, though, isn’t liberating your platform team from ticket ops one hell of a worthy cause? It’ll take no small amount of bravery and fortitude, but you’ll keep your developers engaged, minimize cognitive load, and increase psychological safety for the entire organization.

Adopt a healthy platform-centric mindset

Ready to rediscover the philosophical foundations of platform engineering? Curious how evangelism, change management, continual feedback, and platform implementation interact to power successful adoptions? There’s an easy way to get informed.

Just watch the webinar for more of Mallory’s insights. She answered a whole heap of audience questions about what a healthy buildout looks like and shared some awesome pointers, so don’t miss a detail!