A study towards understanding the job titles in a DevOps world
This article is about several job titles/roles which developed in the IT market around the DevOps concept, such as - Build Engineer, Release Engineer, DevOps Engineer, Site Reliability Engineer, [Cloud] Platform Engineer - what do they mean in terms of responsibilities and required technical skills; and how did they evolved over the last couple of years.
DevOps is an IT related concept heavily debated, marketed, talked-about in the industry for quite some years. What I love most about it is that it continuously improves; it is like a living organism, as any IT company built on people’s creativity, passion and knowledge.
As I see it, if DevOps would be a person, automation would be its heart, communication and knowledge sharing would be its blood, agile product management would be its brain while servant leadership (or even further — transformational leadership) would be its breathing air.
In this article I am going to have a look on the DevOps heart and how could we keep it pumping.
In a DevOps environment, practices such as continuous integration, continuous delivery, continuous deployment, continuous monitoring, continuous testing, self-healing, auto-scaling are a must; and all these can only be achieved by automating workflows, operations, whatever repetitive task that implies human effort.
In order to cover this automation need, several job titles appeared in the market: Build Engineer, Release Engineer, DevOps Engineer, Site Reliability Engineer, [Cloud] Platform Engineer and some other flavors of these ones. Of course passionate debates and quite very well documented papers appeared on what exactly does it mean one or the other, how do they overlap, how do they complement and in which kind of organizational structure do they fit (if curious about it, please see the references of this article).
The understanding and the usage of these job titles depend also on the geographical location, in direct correlation with how many companies/teams have adopted DevOps (culture, methodology, processes, and tools). As reference, in the 2017 State of DevOps Report done by Puppet & DORA, it is stated that 54% of the software teams have adopted already DevOps in North America, 27% in Europe and Russia and 10% in Asia, so I expect some differences in the maturity level, thus in the job related titles (implicitly, in roles & responsibilities).
From my observations on the Romanian jobs market, I have built the following picture with regards to these job titles topology:
As a story line, I would put it like this:
· two ~ three years ago, when I first made an analysis of the market, there were many job requests for Build Engineers, meaning someone with technical expertise in automating the build process, who would be able to implement continuous code integration, as a first step towards building a Continuous Delivery Pipeline (CDP). Specific technical skills that are mostly required for this role: source control management and tools (e.g GIT, SVN), scripting languages for packing the source code (e.g Ant, Maven, Makefile), CDP related tools (e.g Jenkins, Groovy, TeamCity, Artifactory, Nexus); knowledge on CDP workflow and technical components;
· then, for quite a small period of time, I have observed an increase of requests for so called Release Engineers, from whom the companies demanded same knowledge as for Build Engineers and, in addition, strong knowledge also on managing environments/platforms, configuration management & deployment automation, agile-specific tooling configuration/ administration/management. They were expected to build a complete, reliable Continuous Delivery Pipeline, connecting all the technical pieces together (e.g. integrating Selenium for test automation, Docker or Cloud Providers SDKs), implementing best practices in the workflow. The term is not that used anymore, at least on Romanian market. Searching through LinkedIn Jobs, I can observe that also worldwide is not heavily used, in comparison with Build Engineer (few times more job requests) or DevOps Engineer (which is requested like 10~15 times more). Maybe the word “release” was not that inspiring and everyone in the industry was thinking about the old release policies with long feedback loops and that is why it was more or less dropped off. On the other hand, Google mentions Release Engineer role in “Site Reliability Engineering. How Google runs production systems” book as defining “best practices for using [their] tools in order to make sure projects are released using consistent and repeatable methodologies. Examples include compiler flags, formats for build identification tags, and required steps during a build.”
· There is also an increasing number of requests for [Site] Reliability Engineers (SRE). This is a role launched by Google, heavily sustained by one of the top DevOps researchers, Jez Humble, which is rapidly gaining adoption, in a direct correlation also with Google Cloud Platform increase in the market share. SRE, as Google defines it, is a team with both coding and system engineering skills, which “is fundamentally doing work that has historically been done by an operations team, but using engineers with software expertise”. The team is expected to be responsible for the availability, latency, performance, efficiency, change management, continuous monitoring, emergency response, building up strategies for rollbacks, auto-scaling or self-healing. The required technical expertise is referring to performance monitoring tools (e.g DataDog, OMD, Grafana), Linux scripting, programming languages (e.g Go, Python, Java, JavaScript), cloud technologies (e.g Google Cloud Platform, AWS, OpenStack), microservices architecture.
· Even if two years ago, a DevOps Engineer job title was heavily criticized by many of the reference speakers, it is nowadays by far the most wanted job when someone mentions DevOps. The initial concern was not to create an additional silo inside the organization. Nevertheless the complexity and the amount of the automation tasks proved that they require focus as well and not creating an additional silo out of it is [just] an organizational structure and leadership matter. In the DevOps Engineer job ads we can find either the expectations for any of the above mentioned roles/jobs (i.e build engineer, release engineer, reliability engineer), but companies decided to call it “DevOps Engineer”- maybe for inspirational reasons; either all these expectations plus, in some cases, some additional requirements related to networking, security, setting up IAAS or PAAS, cloud computing, open source projects, DBs (SQL and NoSQL), APIs and services: RESTfull, RESTful-like, API gateways, Lambda functions, serverless computing. From my personal opinion, all these technical requirements from one person are too much (even if such super-heroes do exist and they are, of course, highly valuable for their organizations). I would see it, indeed, as a needed capability in the organization, but most likely feasible to be achieved by sharing it between different people in different roles.
Analyzing these job titles also on Google Trends, for the last 2 years, we can observe as well that “Release engineer” has not that much interest, that “Build engineer” was intriguing two years ago, but now it lost some ground to “DevOps engineer” which has now the biggest popularity.
If that was not complex enough, another job title, having quite the same trend as Site Reliability Engineer is also part of the game: [Cloud] Platform Engineer.
There are many argued opinions that having a platform engineering team, building PAAS which enables the feature teams to API driven self-service, deploy systems in a more productive way. In other words having managed services/tools (e.g. runtime environments, databases, queuing services, delivery & deployment pipeline, Agile specific tools like JIRA & Confluence) it’s an approach that scales better. As advantages — the division of responsibilities, meaning focus, meaning more speed, but also ensuring the flexibility of working with several infrastructure / cloud providers, are placed on the table. The concerns that are being raised regarding this approach are, again, not creating an additional silo inside the organization, a risk that can be mitigated in quite different ways.
I would like to end my journey through the DevOps related jobs or roles, by emphasizing the continuous improvement core value of the DevOps culture. As a conclusion, no matter what job title, or role, you have inside your organization having as scope to automate as much as possible, I would say: do it, live it, assess it frequently and change it as frequent as needed, keep it pumping.
If you found this article useful, I am grateful for your feedback! I am available for discussions on LinkedIn. How do you see the job titles in the DevOps field in the future? How is it now in your organization?
References:
https://landing.google.com/sre/book.html
http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7830891
https://www2.swc.rwth-aachen.de/docs/RELENG2015/DevOpsVsRelEng.pdf
https://puppet.com/blog/what-a-devops-engineer
https://www.thoughtworks.com/radar/techniques/platform-engineering-product-teams
https://alexgaynor.net/2015/mar/06/devops-vs-platform-engineering/
https://www.reddit.com/r/devops/comments/36b3f8/devops_engineer_vs_sre/
https://hackernoon.com/are-you-qualified-to-be-a-devops-engineer-d06fe4b8325a
