Over the last couple of months, I have noticed a trend for Recruiters to reach out and tout a new role, the Platform Engineer; this prompted me to think is the age of the DevOps Engineer over, and we must now bow down and worship the new god of IT the Platform Engineer.
Wait, what. What the heck is a Platform Engineer?
According to Gartner: – Platform engineering is an emerging technology approach that can accelerate the delivery of applications and the pace at which they produce business value. I think that we will all agree that statement is a typical Gartner word mash and, as usual, says lots and means nothing. So what is Platform Engineering? At its base level, those in the role provide developers with a standardised platform. The development team will use the platforms teams output to deliver their developed application without worrying about underlying dependencies. Another benefit is that the code can move through the development cycle (development, test, staging and production), without worrying about whether any core libraries or pre-requirements are missing or out of specification. Ohhh, I can see the ears of the developers pricking up. A stable environment for us to develop on, that would be great.
Other than a stable platform for developers to develop on; which is a worthy end-result in and of itself. What value to the business does Platform Engineering deliver above and beyond a subset of the value of true DevOps?
The astute among you will have noticed that there is not a lot of meat on these bones, and the role seems to only focus on the developer’s needs and not the business as a whole. So what exactly does Platform Engineering deliver in terms of reducing toil, elevating constraints and optimising work centers?
What the heck are you talking out, Tom? I hear you shout, DevOps is all about codifying infrastructure and standardising deployments isn’t it? Well, the answer to his question, is one of those dreaded consultants Yes-No answers. It all depends on your definition of DevOps.
What is My Definition of DevOps?
DevOps is an ethos; it is not a technology; it is about elevating the flow of work from inception to retirement. It is about reducing unnecessary toil, identifying pain points and reducing rework and delivering value to the business. It is not and has never been about tooling, like Terraform, Git, Pipelines, etc. these are a method of providing value; they are not the value regardless of what the relevant vendors will attempt to tell you. So if that is the case, where is the value?
The Real Value of DevOps.
As already mentioned, the real value in DevOps is not in Terraform, or Ansible; it is in the industrialisation of IT.
There I said it, DevOps is, in reality, a business process, not a technical process. It is about elevating workflow within the IT Function. It is all about eliminating waste, be that duplication or rework; it is about creating standardisation that results in repeatable processes that drive down deployment costs, improve stability and allow your workforce to do much more with what you have. It removes the boring and mundane, allowing your staff to engage with processes that further elevate the business’s capabilities.
I feel that the underlying principle of DevOps, its unique selling point, has been lost, drowned out by the vendors’ need to control the narrative with their messaging around “it’s all about tooling.” We have Arguments about whether you should use non-opinionated tools like Terraform, or cloud-opinionated tools like ARM templates, or Bicep on Azure or Cloud formation on AWS. Is declarative better than procedural? Is Chef better than Ansible or Puppet? What pipeline tooling to use, Azure DevOps or GitHub actions; this is just noise. Does the choice of tooling add value to a business’s bottom line? The answer is No; it is the process that matters.
This noise is just bad practice. As any IT architect will tell you. You begin with the business need, and only when you understand those facts and can define a business case that adds value or increase the bottom line, can you then start defining the functional and non-functional requirements, and only then do you start to think about the technology that you will use to deliver that potential value back to the business. So why do we start with technology when discussing DevOps; or any of the other plethora of xxxOps that have been defined by vendor marketeers to differentiate their product from any number of other products? It is because the monologue has been hijacked by the vendors touting their wares.
People have forgotten that DevOps started as a reaction to Waterfall methodology, this was a methodology that proposed long development cycles, coupled with full feature releases that quarterly, bi-annually or even annual cadences. Projects would often overrun due to badly estimated timings on how long the piece of work would take, coupled with an ever-increasing backlog of dropped features and chaotic practices. DevOps was revolutionary, it proposed crazy things like multiple release a day, it sounded like crazy talk, it talked about industrialising the flow of work and identifying the flow of work, minimising rework (work that flows backwards). It talked about reducing batch sizes, and other things that IT folk who thought of their work as a knowledge based and artisan in nature, were more at home on a manufacturing flow. As I said crazy talk.
DevOps built its core ethos from the lean processes that we’re (The Goal) espoused by the likes of Goldratt in his seminal Book “” which focused on the improvements in production in a manufacturing plant, it talked about the Toyota effect and the Three ways.
The fact is that all the vendor noise lessens the true value of DevOps, and further it allows Vendors to drive the monologue. When you are stuck in the weeds of product selection, you lose sight of the real reason for DevOps.
DevOps is about business agility; it is about improvement. It is about scaling what you have to deliver more. It is about removing repetitive work, streamlining processes and preventing waste in the work pipeline, but most of all, it is about communication and building trust in others’ work.
So is DevOps dead? Are we all platform engineers now?
No we are not all platform engineers, well some may be; but the fact is that Platform Engineering is just a small part of DevOps, it is a single work stream, it is a single improvement, Platform Engineering is a good start, but it is not the end point. If you are on the journey, and have just paused at the diner in he town called platform engineering, enjoy your time there, but remember that the journey continues. DevOps is all about continual Improvement. Platform Engineering is just a loop on the infinity cycle; feed back your lessons, and improve the next cycle round the loop.
Happy continual DevOps’ing People.
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to sales@amazic.com.
