Serverless DevOps: Where Does Ops Belong?

This is a part of our Serverless DevOps series exploring the future role of operations when supporting a serverless infrastructure. Read the entire series to learn more about how the role of operations changes and the future work involved.

Get rid of your operations team.

Just as the term serverless can be confusing, so too can be operations. People picture different things when the term is used and this makes conversation confusing. I have a fairly expansive definition of what operations is. This often leads to conversations where I hear people propose a scenario where operations does not exist, and what they propose as a replacement is still what I consider to be operations. How can we discuss the impact of serverless on operations when we can’t even agree on what we’re talking about?

Once we have a common understanding of what we’re talking about, let’s then establish where operations people belong. I don’t think operations teams make much sense in a serverless environment. But, operations people hold useful value. So where do they go?

What Is Operations?

People's understanding of operations is often different, but usually correct. The choice of definition is just a signal of a person's experiences, needs, and priorities; and ultimately their point of view. Those divergent definitions, however, often result in disjointed conversations where people talk past one another.

At the highest level, operations is the practice of keeping the tech that runs your business going. But if you dig a little deeper, the term operations can be used in a variety of ways. Because these meanings were tightly coupled for the longest time people tend to conflate them

What is operations? It is a:

A team
A role
A responsibility
A set of tasks

Traditionally, the role was held by the operations engineer on the operations team who had operational responsibility and performed operations-related tasks. The introduction of DevOps in recent years has changed that set-up significantly. The rigid structure of silos that once kept all of these definitions with one person were torn down. And with that the definitions themselves broke apart.

On one side of the DevOps adoption spectrum, operations teams and the role of individuals remained largely unchanged. Both developers and operations remained separate teams but with some operations responsibility crossing over onto development teams while both operations and development experienced higher than previous levels of communication between each other. We see this change in operational responsibility when someone says “developers get alerts first,” in their organization. Or, when someone says developers are no longer able to toss code “over the wall”.

On the other end of the adoption spectrum, operations teams and people went away. Some organizations grouped engineers with operational and software development skills together to create cross-functional teams. Those organizations don’t have an ops team, and they don’t plan on having one.

In the middle of these two ends of the adoption spectrum, the operations role varies. In some organizations, it has changed little beyond the addition of automation skills (e.g. Puppet, Ansible, and Chef). Other teams have seen automation as a means to an end for augmenting their operations responsibilities. And in some cases, operations engineers trend much closer toward a developer; a developer of configuration management and other tooling.

So what does serverless hold for these definitions of operations?

What Will Operations Be With Serverless?

Here is the future I see for operations for serverless infrastructure:

The operations team will go away.
Operations engineers will be absorbed by development teams.
Operations engineers will be responsible for needs further up the application stack.

Serverless operations is not NoOps. It is also not an anti-DevOps return to silos. If the traditional ops teams is dissolved, those engineers will require new homes. Their homes will be individual development teams, and those teams will be product pods or feature teams.

That will lead to a rapid rise in the formation of fully cross-functional teams who can handle both development and operations. Finally, many operations engineers will find themselves applying their strengths deeper into software applications than they may be used to.

Why Dissolve the Ops Team?

When we picture the pre-DevOps world, we see two silos: one developers and one operations, with a wall between them. Developers were often accused of tossing engineering over a wall and onto an unsuspecting operations organization. When DevOps came, we tore that wall down, and the two became more collaborative.

But what “tearing down the wall” was in practice varied by organization. In some cases it just meant more meetings. Now someone warned operations before they threw something at them.

But you still had capability-aligned, independent teams that were required to work together to deliver a solution. And in reality, there were probably more than two teams involved.

Who else was involved? There was a project or product manager who oversaw delivery and ensured it satisfied the needs of the organization. If you were in a product or SaaS company, there was perhaps UX and design ensuring the usability and look of the product.

There may have been more than one development team involved; frontend and backend development may be different teams. All of those independent, capability-aligned teams needed to work together to deliver a solution.

Product and SaaS companies in particular realized this entire process was inefficient. So organizations started realigning teams away from functional capabilities and toward product, feature, or problem domains. Those feature teams, or product pods, or whatever they were called were cross-functional teams aligned along solving specific problems.

What do those teams look like now? Where I've seen them in use they have typically resembled the following:

Product or project manager
Engineering lead
Frontend developer(s)
Backend developer(s)
Product designer and/or UX researcher (often the same person)

The product or project manager (PM) is responsible for owning and representing the needs of the business. The PM’s job is to turn the needs of the business into clear objectives and goals, while also leading the team effort in coming up with ideas to achieve success. The product designer or UX researcher works with the PM to gather user data and turn ideas into designs and prototypes. The tech lead is responsible for leading the engineering effort by estimating the technical work involved and guiding frontend and backend engineers appropriately.

What you end up with is a single team with multiple capabilities all moving in the same direction who are a part of the process from start to finish. The team is made stronger by their cross-functional skill set, which leads to the delivery of better solutions and services.

Operations, however, was often left out of that realignment. (Though sometimes operations became their own cross-functional team delivering services to the other teams.) The needs of operating infrastructure were often too big for a single person on a team to handle. So while other parts of the organization realigned, operations remained as a separate capability-aligned team.

This has worked well enough for a long time. Infrastructure was not easy enough for many teams to reliably deliver and operate without detracting from their primary problem domain.

But serverless disrupts that relationship. It’s now easy enough for a developer to deliver their own cloud infrastructure. In fact, they need to, since serverless combines both infrastructure configuration and application code together.

A development team doesn’t need the operations team to deliver a solution. There’s no way for a separate operations team to insert itself into the service-process without regressing to the role of gatekeeper. And that gatekeeper role has been going away in many organizations for years.

The need for operations teams to change is driven not by the technical effects of serverless but by how serverless will affect the way organizations and their people function and carry out their role.

Remaining as a capability-aligned operations team when your devs no longer need you for infrastructure means you'll largely become invisible. They'll also stop going to you for smaller problems as they encounter them and largely choose to solve those problems on their own.

Sooner or later, the team is no longer a part of the service delivery process. And eventually, someone will ask why the team exists at all. You're in a bad spot professionally when people are questioning why your job exists.

But operations, as in the responsibility and tasks, is still important. Those functions are still required for building serverless systems. The decreased usefulness and capability to perform by an operations team but the need for their skills means it’s time to rethink where operations people belong. That’s why it’s time for operations teams to dissolve and its members to join product pods and feature teams.

The Ops Role in a Product Pod

What will be the role of the operations engineer as a product pod member be? Their high-level responsibility will be the health of the team's services and systems. That doesn’t mean they’re the first one paged every time. It means that they will be the domain expert in those areas.

Software developers remain focused on the individual components, and the operations engineer focuses on the system as a whole. They’ll take a holistic approach to ensuring that the entire system is running reliably and functioning correctly. In turn, by spending less time on operations, developers spend more time on feature development.

The operations engineer also serves as a team utility player. While their primary role is ensuring the reliability of the team’s services, they will be good enough to offload, augment, or fill in for other roles when needed.

There are tons of definitions and implementations out there for the word DevOps, but this new team formation is, to me, the greatest expression of that word. DevOps is the people, process, and tools for achieving outcomes and value.

We’ve long realized the value of collaboration and cross-functional teams in promoting success. To me, dissolving the operations team and adding its members to a cross-functional team aligned around a problem domain is the most efficient means of delivering value.

How much closer can you make collaboration than placing people on a singularly aligned team? Serverless will help us to fulfill what many of us have been trying to achieve for years.

There's still more in our Serverless DevOps series! Read the next piece in our series Why Serverless For Operations People.

Read The Serverless DevOps Book!

But wait, there's more! We've also released the Serverless DevOps series as a free downloadable book, too. This comprehensive 80-page book describes the future of operations as more organizations go serverless.

Whether you're an individual operations engineer or managing an operations team, this book is meant for you. Get a copy, no form required.