The difference between Platform Engineering and DevOps
We see more talk and requests for Platform Engineering. However, there is still some misunderstanding on what Platform Engineering is and how it differs from other disciplines such as DevOps and Site Reliability Engineering (SRE).
With the transition of DevOps and SRE professionals moving into Platform Engineering roles, it's understandable if the perception is more of a "rebrand" for a better salary rather than a progression of skill sets.
While the difference may seem subtle, they demonstrate not only the transition from DevOps but the importance of Platform Engineering.
What is DevOps?
DevOps combines cultural philosophies, practices and tools designed to increase an organization's ability to deliver applications and services at high volume. The DevOps model moved development from a siloed, "not my problem" approach to a single team that enables engineering teams to work across the application's lifecycle.
Developers should be able to deploy and run their apps and services end-to-end. "You build it; you run it". True DevOps.
The issue with this is that this is not a realistic approach for most businesses. Engineers must have mastered different tools, Helm charts, and Terraform modules to begin with. Previously, the division of tasks and functions has stayed in many other sectors, but the tech sector believed that the combination achieved higher performance.
And for the large tech giants who are advanced in their set-up, for example, Google or Amazon, other companies cannot invest or have access to the same talent pool. The resources and budgets are not at the same level, making the implantation of true DevOps much harder.
As Manual Pais and Matthew Skelton highlight in their book DevOps Topologies, anti-patterns emerge. A referenced example is a business trying to roll out true DevOps and removing an operational function. Eradicating the operational role makes developers responsible for infrastructure, monitoring and their work. Senior high-skilled developers spend more time doing most of the work themselves or supporting junior developers, which ultimately means they cannot ship features as quickly and quickly as needed.
While the DevOps culture showed that a developer could be a self-serving entity to increase productivity, the required knowledge creates a cognitive load on developers, which makes the opposite of what it is trying to achieve. The issues highlighted that there needed to be some structure to work more efficiently.
Doesn't Site Reliability Engineering fix this?
Well, yes and no. According to Benjamin Sloss, SRE is responsible for the availability, latency, performance, efficiency, change management, monitoring, emergency response and capacity planning of their service. The addition of the SRE should help the issue in theory; however, much like a true DevOps, unless you have the resources and talent that the tech giants do, an incorrect adoption can cause many issues.
SREs are expensive and rare, which leads to companies having an SRE role without the skill set to perform in line with the needs of the business. The reality creates a culture of survival, not improving the development experience. The DevOps Topologies say that this moves it back to a pre-DevOps approach "Devs still throw software that is only 'feature-complete' over the wall to SREs. Software operability still suffers because devs are no closer to running the software they build, and the SREs still don't have time to engage with devs to fix problems when they arise."
How is Platform Engineering different?
Luca Galante defines platform engineering as the "discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era. Platform engineers provide an integrated product most often referred to as an 'Internal Developer Platform' covering the operation necessities of the entire life cycle of an application."
Internal developers offer the solution to the problem in both directions. They remove the blockers which have been there from operations allowing developers to get on with the job at hand. On the other side, operations have the security of the standard set, and things are scalable without increasing the workload of developers.
This move creates a culture of a platform-as-a-product approach. This methodology allows Platform engineers to conduct user research, product roadmaps, and feedback loops and communicate developments to internal developers.
By imitating the usual help-desk pitfall, this method helps create the proper buy-in from stakeholders while helping make things easier for developers and effectively communicating constraints and issues so that there is less fire-fighting and more progress.
