My senior recently argued that DevOps related roles such as DevOps Engineer, SRE, etc, will be less relevant once serverless matures. He pointed me to this article.

Can you see less and less DevOps roles being available in the age of serverless?


DevOps roles will probably be around for some time. Most enterprises and start ups have different needs, server-less is more of an indication of “developers need less focus on the resources and infrastructure for applications” in the sense of applications healing themselves, developers would need to write functions, these functions would often need to change and be adaptable to the applications needs.

When thinking of SRE it’s more of a leadership role. Although the nature of the role is reliability of systems, we may see autonomous development in the near future but that too would also need highly skilled strategic engineers to oversee such critical systems and SREs would play that role.


Also serverless needs some infrastructure and for that you also need software components to develop and rollout.

Beyond yet another website or application server I'd also think of energing advanced ecosystems related to:

  • Internet of things - embedded systems and edge servers
  • Artificial intelligence and data engineering in distributed systems. Could be some ETL (extract, transform, load) stuff or training and logistics for machine learning models.
  • Gaming but also working in virtual environments.

So given the cloud market and these ecosystems will grow, even if servetless would dominate, there will be a DevOps market, maybe smaller than now.

Otherwise it is in general very hard to predict how (IT) world and job market might look like in say 20 years.


What is the future of DevOps in the age of serverless? Can you see less and less DevOps roles being available in the age of serverless?

I personally dislike the DevOps Engineer role as DevOps is a culture! What you probably mean is whether Operations or System Engineers will be phased out. Like the other answers indicate, these activities will still be required, but the number of such activities and roles will decrease.

I personally feel very pressured by the shift to the cloud. Back in the day, I was replacing servers in Datacenter racks, provision them using PXEboot and puppet, monitoring and maintaining them, but now one can just create new servers in the cloud very easily. So basically if I would be stubborn and ignore the cloud I will be substituted in a couple of years. I really feel that I personally should run everything in production in cloud and k8s as soon as possible and that is why I try to get productive with for example Spring Boot to create business value for the company.

I would argue that every engineer should deploy apps in the cloud automatically and should find a way to create business value for the company by complying to industry standards, e.g. terraform, cloud (AWS, GCP, Azure), container-orchestration (Kubernetes, Docker Swarm), containers (Docker or Rockit).

  • In agree when all your points. I am not sure how your 2nd paragraph relates to the others or the question. Being “pressured” sounds like someone might be making you do devops when you don’t want . I am sure that isn’t what is meant? – simbo1905 Jan 12 at 16:24
  • @simbo1905 Thanks for the feedback. I will edit it. – 030 Jan 12 at 16:26
  • @simbo1905 could you check again please? – 030 Jan 12 at 16:30
  • edits look good to me – simbo1905 Jan 12 at 19:15

Disclosure: I work as a devops coach (and player) at a global company with over a thousand developers.

TL;DR It depends whether you think devops is a particular set of skills and tools, or whether you think devops is a culture and way of working. It you look at the “what is devops” questions and answers, in one interesting answer here, they give some insights as to whether it’s just a tick box exercise of using certain sorts of tooling, or more a change in focus, behaviour and responsibilities over the previous ways of developing, releasing and supporting software. Cloud providers can give us better tools but we will still need devops skills to make best use of them. Any set of tools can be used badly and we shouldn’t expect Serverless to be any different.

Long Answer:

I think that your colleague is thinking is that devops is a current set of skills to setup a current set of tools. Then their argument is that with the serverless movement cloud vendors are setting up ci/cd and all the tools with good defaults that means you don’t need to have expertise in setting up such tooling yourself.

Yet you can still end up with a giant ball of configuration mud and inconsistencies between all your components when you get beyond "hello lambda" and are running a business pumping out features. Continously improving how your product runs, and is monitored, and tested, and patched, and secured while continously expanding and adding new business features requires discipline, skill and hard effort.

It’s has often been said in the past “there will be no developers anymore as business people can now buy our tools to design the solution and the tool generates the code”. That will make anyone who has lived through such an implementation flinch or laugh. If the customer of the tools doesn't hire people with the development skills to use the tools they get a giant ball of mud and frustrated end users.

I would argue that just like “developers won’t disappear” as the tooling changes with “devops” we will simply see both old and new problems, and see skills and practices adapt and evolve to the new tools. Some problems go away (elasticity, provisioning VMs) but new ones take their place (chaining functions, monitor business KPIs across the distributed application).

By way of an example one form of serverless in the generic sense, which isn’t only functions or lambda, is to define your entire system in git using yaml and have git webhooks sync the configuration into a cloud provider managed Kubernetes to create your running system. You don't use servers you rent cpu and ram quota a managed cluster to host your containers. Then you can automate both creating releases and promoting releases using a slack chatbot. Whether your yaml is chaining together functions, or starting containers in kubernetes, depends on what you need to run. As soon as you get beyond a simple “hello world” webapp you need to define a whole host of yaml and workflow that “run your business” that a cloud provider cannot just gift you.

I think everyone can agree that that work of “just configuring yaml” to deploy multiple APIs and web frontends you can monitor and continously improve is “devops work”. The fact that that tools are cutting edge and can use SaaS based CI/CD, functions, rent cpu and memory quota on a shared kubernetes, use managed cloud database, etc just means it’s devops with new tools not devops with traditional tools.

I am a tech advisor at a startup where that’s exactly what we have setup. We are in the process of open sourcing the scripts that we use as OCD (our business doesnt use functions yet so currently it's OKD Kubernetes automation). I am migrating the startup to the open source version in the evenings. So during that day I do devops work with traditional tools (Jenkins et al) and in the evenings I do devops work with the very latest tools. Adding a ton of serverless lambda into the things that our startup does won’t suddenly mean that the minimal viable product would magically set itself up. As long we we need to improve our product and deploy new user experiences and configure our use of APIs we will continue to “do devops”.


I personally don’t believe in “devops teams” or “devops roles”. Devops is a way of working and it’s not working if development teams are not empowered to “design, build, deploy and support” what they make. You might hire people with technical specialists skills such as build automation and agile coaching. The tests of whether it’s “devops” or “ops” is whether they automate things so that teams are empowered and made self-sufficient. A “devops” team clicking a mouse setting up IaaS for developer teams isn’t devops it’s ops. When you replace that team with automaton it becomes devops.

  • Could you add an additional paragraph that summarizes all the paragraps, e.g. In summary, ... – 030 Jan 12 at 15:50
  • 1
    That’s what “TL;DR” means. But thanks for the feedback I will make some edits. – simbo1905 Jan 12 at 16:04
  • Sorry. Thanks for explaining. You are right: tl;dr A) "Too long; didn't read.", meaning a post, article, or anything with words was too long, and whoever used the phrase didn't read it for that reason. B) Also used by someone who wrote a large posts/article/whatever to show a brief summary of their post as it might be too long. – 030 Jan 12 at 16:07
  • Hey thanks for the feedback I made some adjustments. It’s not helpful for me to use “TL;DR” if people won’t always get it yet it’s also a way of apologising for making a long post. – simbo1905 Jan 12 at 16:12
  • I checked it again. Looks better. :) I wonder if you could add one sentence that gives an answer to Can you see less and less DevOps roles being available in the age of serverless? like yes there will be less and less DevOps roles. When I read all it looks to me that you are saying this right? Perhaps you could add such an answer to the TL;DR? – 030 Jan 12 at 16:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.