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 Containers won the battle, but will lose the war to serverless.
Can you see less and less DevOps roles being available in the age of serverless?
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:
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).
Disclosure: I work as a devops coach 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. Continuously improving how your product runs, and is monitored, and tested, and patched, and secured while continuously expanding and adding new business features requires discipline, skill and hard effort.
It 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 continuously 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 open-sourced all the scripts that we use to sync yaml in git into our Kubernetes on AWS as a project called OCD. (Our business doesn't use functions yet so currently, it's OKD Kubernetes automation but the principle would be the same). I migrated the startup to the open-source version in the evenings. So during the day I was doing devops coaching work with traditional tools (Git, Jenkins, Ansible et al) and in the evenings I do devops work with the very latest tools (Git Circleci, Helmfile). 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”. To distinguish between old and new sets of tools we might call the new style "no ops" or "git ops".
The same can be said about Site Reliability Engineering. With the old tools, you are watching VMs. With new tools, you are watching higher-level metrics such as service mesh traffic. A cloud provider cannot gift you large set of dashboards that show you how your business is running under load and diagnose and rebalance things when an intermittant bug is put live.
Finally
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 and deployment 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 plain old ops. When you replace that team with self-service automaton it becomes devops.
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.
What will happen with developers is same that will happen with ops. And a true DevOps is a role that actually governs the whole process it's quite harder than regular ops or development, it's just that people didn't reach the mental phase to understand it globally. It's in the end the engineer that will both code and do everything else. But hey you are missing something, you are talking about the cloud, but you are missing the decentralization part where private clouds will be hiring as insane. How many engineers you think it takes AWS to support this? It's true that regular Ops is shifting to cloud, but in reality it's more of the rapid technology evolution. A DevOps/Ops is a subject of hundreds of technologies and currently developer scope is keep quite limited in small companies. Developers will be forced in the end to take more of the operation aspect in their culture, it's just another form. Code is also getting automated, it's that it's a limited mean of expression, which would always make it subjective to complete optimization from AI. The real question here is that both developers and ops will get obsoleted in different phases if they don't acquire machine learning/optimization skills.
