I have a personal niggle with DevOps, as for some reason, the industry has latched onto the term and turned it into a job role. Technically the role doesn't exist, it's a culture, a way of working. It helps development teams get in the mindset of delivering at high velocity.
As a Job Function
Alas, we live in the real world. Where words are defined by the way they are used in society, and not necessarily in the way the author originally intended.
When a company advertises, a DevOps engineer position, they are normally wanting someone who is familiar with cloud services (AWS, Azure or GCP). They will also be capable of creating/updating CI/CD (Continuous Integration/Continuous Deployment), have the ability to create or manage containers (Kubernetes, Docker) and they should have some scripting abilities, such as Python, JavaScript or Go.
Now bear in mind, the above isn't a hard and fast rule. Depending on the history of the business, they may have many weird and wonderful tools they use. Anyone who takes a position with them would be required to either have the skills, or pick them up on the job.
Although, a company can call a position whatever it wants. Having a DevOps position may impact the business in negative ways. It could stop the business from becoming truly DevOps focused, as non-DevOps engineers will see that DevOps is not their responsibility.
Platforms Engineer
Personally, I prefer the title Platform's engineer. It's simple, doesn't overlap with anything else, and it's descriptive.
The image below shows where a platforms engineer would roughly sit within a development team. Don't worry if you don't know what all the heading's mean, I'll be covering the sections in future articles.
The DevOps culture stretches across the whole stack, as everyone within the development team, would work to a DevOps mindset.
The difficulty for companies to use the Platforms title instead of DevOps, is that the market for the most part is set on using DevOps instead of Platforms. The Platforms title does exist, but it's a lot less prevalent in the market.
If a company was insistent on using the DevOps title, They would hire DevOps engineer instead of Platforms engineer. They would need to be clear to everyone in the development team, that they are all following the DevOps culture and the DevOps engineer is here to support that process. The key responsibility for the DevOps engineer is CI/CD, as this enables the company to start delivering at high velocity.
As a culture
As a basis, DevOps is concerned with practices, guidelines and culture. Its main drive is to speed up delivery and reduce waste by modifying the culture of the development team.
The key ideas are as follows:
No more Silos Mixing of team skills within a single development team, such as operations and development.
Accidents are normal Remove blame from issues to encourage people to share more freely and without fear.
Change should be gradual Change is risk, so it should be broken down into smaller chunks with the support of CI/CD.
Tools and culture are interrelated Tooling is important, but culture is more important. Culture eats strategy for breakfast.
Measurement Change should be measurable and comparable.
The culture of DevOps is designed to bring teams together, break down barriers and make the process of developing software reactive to change and market conditions.
It removes the separation of distinct teams with distinct responsibilities, and allows all members of the team to have visibility of the wider stack.
CA(L)MS
For anyone interesting in applying DevOps culture to their organization, there is a handy framework for assessing your companies' readiness.
Culture
Automation
Lean
Measurement
Sharing
In a future article, I will be looking to explore the CA(L)MS framework, so be sure to add your name to the mailing list if you are interested.
Conclusion
It's possible to have a job role of DevOps engineer, but in some sense that takes away from the DevOps culture. I believe a more apt title would be Platforms Engineer. Leaving DevOps to be a culture, which everyone follows.
I've also listed the key ideas for DevOps culture, that when applied can help teams get into the mindset of high velocity delivery.
If you read my previous article on https://www.serverdevs.com/post/what-is-an-sre. You may have noticed there are some similarities. Next week I'll be comparing SRE and DevOps.
Comments