DevOps success: A new team model emerges

Source – enterprisersproject.com

When DevOps began, so did a shorthand description for the model: It broke down the wall between dev and ops. The teams communicated better and operated with a shared set of objectives and concerns. At the extreme, there were no longer devs and ops people, but DevOps skill sets. But now, another view of DevOps has emerged: It’s about enabling ops to provide an environment for developers, then get out of the way as much as possible.

Is this model a good fit for your business needs – and do you understand what the dev and ops teams inside your organization would need to make it work? Let’s take a look.

Definition of DevOps evolves

DevOps widened Agile principles to encompass the entire application lifecycle including production operations. Thus operations (and security) skills needed to be added to the cross-functional teams that included designers, testers, and developers.

This view of DevOps focuses on “two pizza” cross-functional teams — small, multi-disciplinary groups that own a service from its inception through its entire lifecycle. This works in part because such services are autonomous, have bounded context, and can be developed independent of other services and groups, so long as they honor their API contract. It also assumes that these “generalist” teams have the necessary skills to operate the underlying platform.

However, an alternative view posits that generalist DevOps teams may not want to be in the business of running the infrastructure and the platform — and may not have the skills to do so efficiently.

This is what Adrian Cockcroft, Netflix’s former cloud and DevOps guru — he’s now at Amazon Web Services (AWS) — was getting at with the “No Ops” term, which he popularized. While Netflix is a special case, Cockcroft hinted at something that’s broadly applicable: In evolved DevOps, a lot of what ops does is put core services in place and get out of the way. There’s value in putting infrastructure, processes, and tools in place so that dev doesn’t need to interact with ops as much –  while being even more effective. (In the Netflix case, the underlying infrastructure was largely provided and operated by AWS.)

Reducing friction in the interactions between devs and ops doesn’t always mean making communication easier. It can also involve making communication unnecessary. Think about it this way: You do not, in fact, want to communicate with a bank teller more efficiently. You want to use an ATM. You want self-service.

In this model of DevOps, key aspects of operations happen outside of and independent of the application development process.

Of course, communication between dev and ops (as well as other disciplines) still matters. The most effective processes have continuous communication. This enables better collaboration, so that teams can identify failures before they happen; feedback, to continuously improve and cultivate growth; and transparency.

It’s important for IT leaders to understand that devs and ops teams need different things as they move into this newer, evolved way of doing DevOps.

What dev needs

Dev teams that are making the most of this model need to focus on improved application architectures and developer workflows. This includes a focus on the tools and how the company builds applications.

Typically, this starts with microservices. DevOps works best with more modular application architectures that allow for faster iteration and more incremental releases.

What are some signs your DevOps teams might need microservices? Perhaps they’re creating many brittle apps, where minor changes cause major breakage. Or the continuous integration/continuous deployment (CI/CD) process gets bogged down by big deployments. Maybe different teams keep rewriting services that do the same thing, but in gratuitously different ways.

One consequence of these types of problems is that they hurt a team’s ability to experiment. That’s a big problem; quick iteration is a core goal of DevOps.

What ops needs

For companies embracing this view of DevOps, the ops team’s role is to provide core platforms and capabilities for developers, support them, but largely stay behind the scenes. Does this run counter to the original DevOps notions about breaking down the wall between dev and ops? Not really. You can still have a culture of collaboration — while still making explicit communications unnecessary much of the time.

Ops teams providing core capabilities and getting out of the way need to be able to do three things: Deploy a modern, scalable container platform; enable developer workflows; and mitigate risk while automating security. That modern container platform should be capable of operating at scale across hybrid clouds. That workflow uses repeatable automation for consistency and efficiency.

On the security side, these teams integrate security seamlessly, as much as possible, throughout the development process. The goal is to do this in a transparent way that doesn’t hurt DevOps teams’ agility but manages risk. This means DevOps teams need containers that are secure and trusted, with a validated supply chain for software and easy ways to confirm what’s inside containers.

Questions to ask now

If you’re an IT leader trying to implement DevOps, it’s time to ask some core questions, starting with why it makes sense for the business. Perhaps, like Netflix, your business desires the added speed this model can deliver, enabling faster product development and time-to-market cycles. For businesses being disrupted by upstart competitors with a greenfield advantage or by innovative first-adopters that embraced early cloud offerings early, gaining speed can be a make-or-break factor.

Consider these questions as you evaluate:

• What’s the business problem?
• Where am I today?
• How big are my teams?
• What skills do I have (or can hire)?
• On-premise and/or public clouds?

Take a fresh look at your DevOps approach and how to improve it with new thinking. In the digital world, you can’t rely on the same systems and processes that got you here.