Does Serverless make DevOps jobs less relevant in the long run?

NoOps movement and the DevOps role

When I share the concept and development cycle I have seen in the serverless architecture environment with my DevOps friends, they often ask the question ‘then how many DevOps persons do you still need in that environment?’, and some even go one step further asking ‘is DevOps job still needed in that environment?’

As this newsletter is meant to help engineers in traditional environment to transition (or consider to transitioning) to modern cloud environment, I’d like to share my thoughts on this question.

Edit 9/1/2021: we added a post talking about how to build serverless data analytics pipeline here.

My perspectives of this writing — a hands-on technologist

First I wanted to clarify that my writing in this post is not from the perspective of an industry analyst — there are a lot of great articles there (for example, this article says serverless architecture market will grow globally from $7B to $21B in 5 years) — I feel I don’t have enough industry-wide data to share or give any value-added first hand deep dive from that perspective.

Instead, I feel I have enough hands-on observations to concrete problem solving to share — from both the perspective of an engineering manager and the perspective of someone who entertains himself with some hands-on developer practice in cloud environment.

The areas where traditional DevOps staff has less (sometimes even any at all) contribution in the serverless paradigm

As an engineering manager, I observed that senior engineers can launch a new services with little DevOps personnel’s help primarily for the following reasons:

1. in the serverless environment, a lot of CI/CD pipeline work can be done purely by development team (e.g., see example practices briefly mentioned here and here);

2. in the serverless environment, application engineers are not blocked by understanding docker engine version, OS version and etc. (this used to be a specialized skill-set and development team must get helps from DevOps / SRE team);

3. in the serverless environment, a lot of infrastructure reliability and auto-recovery problems have been taken care by (or to the in-house team, it has been ‘outsourced’ to) cloud vendors

   1. a service can achieve its high-availability and self-healingness from its architecture design; and the development team’s code itself is fully responsible to attain the architecture design;

4. in the serverless environment, it has become the trend that infrastructure as code (IaC) logics are and will be owned by the development team

   1. the development team codifies the architecture and infrastructure through tools like serverless (sls), AWS Development Kit (CDK) — this used to be a big part of DevOps / SRE team’s responsibility, but not anymore in the new serverless computing paradigm

The areas that traditional ‘DevOps’ staff still play important roles in the serverless paradigm

Though the above section seemed to suggest that the development team can release the service without too much DevOps team’s hand-holding, it does not mean we don’t need DevOps personnel in the team. And I’d argue that DevOps / SRE thinking becomes even more important and critical in a company building product on top of serverless paradigm.

But ‘DevOps / SRE thinking’ is not a job description, right? Where will the DevOps / SRE be contributing in? Here is something I can share from my experience (and it by no means a full list):

• A centralized DevSecOps practice: a company needs hands-on security staff to make sure the serverless application engineer’s architecture is secure and well protected;

  1. serverless paradigm made development team much more self-reliant to develop and launch product much more agile, but great powers come with great responsibility. And a central team to set the boundary for them so that the development team and the service launched by that development team does not cross the legitimate boundary is necessary — that central team is responsible for giving the feature team enough autonomy yet having enough clarity what individual team can do and can’t do. And this job should be codified (security as code). Here I draw an extremely simple diagram:

     

• Observability engineering: though the developers launched a service and codified not only the application logic but also the IaC logic into his project, building a robust monitoring, alerting and escalating pipeline still remains an important thesis to production services;

  1. The following diagram gives a high level idea SRE needs for a serverless production service — in the AWS world, it entails to AWS services such as Cloudwatch Metrics, Cloudwatch Log, X-Ray…, and typically development team needs SRE / DevOps experts to make this level of design ‘simple but not simpler’;

• Developing Platform Services: this is somewhat related to the previous point. Application developers want to roll out new functionalities quick and iterate in high velocity. But they may want to ‘outsource’ supporting services to a helping team and focusing on developing new functionalities;

  1. Here we just mention an example of this kind of services. For example, DevOps team can build central service to enable lambdas pre-warming (to avoid cold-start issue), like this article described.

What does all these mean to DevOps professionals in a serverless paradigm team?

This is my prediction based upon my own experience. And since serverless is still a new paradigm to build SaaS and online consumer services, we will see where the industry move toward and revisit these predictions easily in the next 2-3 years:

1. The ratio of SRE / DevOps engineers and software engineers will become smaller (because a large portion of DevOps / SRE responsibility has been either ‘outsourced’ to cloud vendors or ‘assumed’ by the development team);

2. The SRE / DevOps team will be asked to take more roles such as codified security definition and operation (because in the cloud, especially serverless paradigm, everything needs to be codified and versioned)

3. Most application level services will evolved into ‘NoOps’ stage, but SRE / DevOps team will be responsible to build the plumbing to give the app team the sense of ‘NoOps’. For the services that developed by SRE / DevOps team (see the point listed in previous section ‘Developing Platform Services’), they themselves are also “NoOps” — in this sense, the DevOps / SRE team evolves an internal common service team;

What is your prediction, mind to share your thoughts and experience? Please sign up and leave a comment below.