Just as the word serverless can be confusing, so can the word operations. When the term comes up in conversation, people think of different things, which can confuse the conversation.

What is serverless? Serverless is an architectural concept described in the latest definition as follows: “The Serverless architecture is an Internet-based system in which application development does not use regular server processes. Instead, they rely solely on a combination of third-party services, client-side logic, and service-hosted remote procedure calls.”

Operation and maintenance has a very broad definition. Often, people will talk about a scenario where operations doesn’t exist, but in reality, what they suggest as an alternative is still operations to me. How do we talk about serverless’s impact on operations when we can’t even agree on what we’re talking about?

Now that we have a common understanding of what we are talking about, let’s take a look at where operations people belong in Serverless. I don’t think operations teams make much sense in a Serverless environment. But operations people are valuable. So where do they fit in?

People’s understanding of operations is often different, but it is usually correct. What definition is chosen depends on a person’s experience, needs and priorities, as well as their perspective. However, these different definitions often lead to disjointed conversations.

At the highest level, operations is the practice of keeping the technology that underpins the business going. But if you dig a little deeper, the term operations can be used in many ways. Because these meanings have been tightly coupled for so long, people tend to lump them together.

What is operations? Operations are:

  • A team

  • A role

  • A kind of responsibility

  • A set of tasks

Typically, this role is filled by operations engineers on operations teams who perform operations related tasks. In recent years, the advent of DevOps has dramatically changed that. The once rigid structure of all these definitions unravels, and the definition itself falls apart.

At one end of the DevOps spectrum, operations teams and individual roles remain largely unchanged. Both developers and operation and maintenance personnel are independent teams, but the development team began to take part of the operation and maintenance responsibilities, and the communication between operation and maintenance team and development team has risen to a higher level than before. When we hear people say, “Developers get alerts first,” or developers can no longer let code “jump the wall,” we know that operations responsibilities have changed.

At the other end of the DevOps spectrum, there are no operations teams or individual roles. Some companies combine engineers with operational and software development skills to create cross-functional teams. These companies have no operations teams and no plans to build one.

In the middle of the DevOps spectrum, operations roles vary. In some enterprises, little has changed except for the addition of automation skills, such as Puppet, Ansible, and Chef. Other teams have seen automation as a way to strengthen operations responsibilities. In some cases, operations engineers are closer to developers — developers who have mastered configuration management and other tools.

What impact does Serverless have on these operations definitions?

Here are my thoughts on the future of Serverless operations:

  • The operations team will disappear.

  • Operations engineers will be recruited by the development team.

  • Operations engineers will be responsible for the deep requirements of the application stack.

Serverless operations is not NoOps, nor is it anti-DevOps. If the traditional operations team is disbanded, the old operations engineers need a new place to go. Their destination will be the development teams, which will be the product or functional teams.

As a result, cross-functional teams that can handle development and operations will quickly emerge. Finally, many operations engineers will find their strengths applied to their applications more than ever before.

Before DevOps, we saw two silos: development and operations, separated by a wall, where it was routine for developers to dump engineering design on unsuspecting operations teams. When DevOps came along, the middle wall came down and the collaboration between the two teams became even closer.

But “tear down the middle wall” actually means different things to different organizations. In some cases, it just means more meetings. Now they are told before someone “throws something” at ops.

However, you still need independent teams working together to deliver solutions. In practice, this may involve more than two teams.

Who else?

  • A project or product manager is required to oversee the delivery process and ensure that what is delivered meets the company’s needs. If you are in a product or SaaS company, you may also need UX and designers to ensure the usability and appearance of the product.

  • Multiple development teams may be involved, and front-end and back-end development may be managed by different teams. All of these independent teams need to work together to provide solutions.

Product and SaaS companies in particular realize that the whole process is inefficient. As a result, organizations begin to realign teams from functional teams to product, feature, or problem areas. These functional teams, product teams, or any other cross-functional team are working on domain-specific problems.

What do these teams look like now? In my opinion, they usually look something like this:

  • Product or project manager

  • Engineering director

  • Front-end developer

  • Backend developers

  • Product Designer and/or User experience researcher (usually the same person)

The product or project manager (PM) is the owner and representative of the business requirements. The PM’s job is to translate business requirements into clear goals while guiding the team to come up with ideas that will drive success. Product designers or UX researchers work with PMS to collect user data and turn ideas into designs and prototypes. The technical leader is responsible for leading engineering tasks, estimating the technical work involved, and providing guidance to front-end and back-end engineers as appropriate.

What you end up with is a multi-competency team that’s all moving in the same direction and is part of the process from start to finish. These cross-functional skills empower teams to deliver better solutions and services.

However, operations are often left out of the realignment (although sometimes operations will form its own cross-functional team and provide services to other teams). Individuals on the team are often unable to shoulder the operational needs of the infrastructure. As a result, operations remains a separate team while the rest of the organization is reorganized.

This has worked well for a long time. For many teams, infrastructure is not simple enough to deliver and operate reliably without impacting the major problem areas.

But Serverless upended that relationship. Developers can now easily deliver their own cloud infrastructure. In fact, they need to, because ServerLess combines infrastructure configuration with application code.

The development team does not need help from the operations team to deliver the solution. A single operations team cannot insert itself into the service process without reverting to the role of gatekeeper. But over the years, the gatekeeper role has disappeared in many organizations.

Change in the operations team is not driven by Serverless technology, but by Serverless’s impact on the way the organization and its employees operate and perform their responsibilities.

When the infrastructure is no longer needed by developers, operations teams become largely dispensable. They don’t come to you when they have small problems, they can solve them themselves.

It is only a matter of time before the operations team is no longer part of the service delivery process. At the end of the day, one wonders why these teams still exist. You’re in an awkward position when people question why your job still exists.

But in terms of responsibilities and tasks, operations are still important. These capabilities are still required to build serverless systems. The role of operations teams is diminishing, but there is still demand for their skills, so there needs to be a rethink of where operations people should be placed. That’s why it’s time to disband the operations team and move people into the product and features teams.

What is the role of the operations engineer as a member of the product team? Their primary responsibility is for team services and the health of the system. That doesn’t mean they’re the first to get an alert every time, they should be experts in these areas.

Software developers still focus on individual components, while operations engineers focus on the entire system. They will take a holistic approach to ensure that the whole system works properly and reliably. Developers can spend less time on operations and more time on feature development.

Operations engineers can also help the team. While their primary responsibility is to ensure the reliability of team services, they can take on other roles as necessary.

There are many definitions and implementations of the term DevOps, but for me, the formation of a DevOps team is the most powerful expression of the term. DevOps is the people, processes, and tools that achieve results and value.

We recognized early on the value of collaboration and cross-functional teams in promoting success. For me, disbanding the operations team and bringing people into the cross-functional team was the most effective way to deliver value.

How much closer would you make collaboration be compared to putting people on separate teams? Serverless will help us achieve what many people have been trying to achieve for years.

English text: https://www.serverlessops.io/blog/serverless-devops-where-does-ops-belong