Operations engineering is moving in the direction of platform engineering according to Charity Majors, CTO at Honeycomb. Majors sees platform teams tending to work higher up the stack than operations, DevOps, and SRE teams do. This shift in focus enables organizations to focus their limited development resources on their core product to drive maximum business value.
Majors notes that the past three to five years have been focused on enabling software engineers to own their code in production. This shift has seen a reduction in dedicated operations teams and a move to outsourcing as much infrastructure as possible to third party providers. Shawn "Swyx" Wang, head of developer experience at Airbyte, shared similar ideas in a recent podcast with InfoQ:
I will give over control to someone who knows more than me, I'll pay them money, I'll exchange fixed costs up front for variable costs that I know [are] higher in the long run, but total cost of ownership is lower. I'll do all those trade offs for my size and until such time as I need to bring it in-house.
This shift has seen a move from siloing developers from operations to engineers running the code that they write. According to Majors, this has led to software engineers feeling that they have to know everything about everything. Paula Kennedy, COO at Syntasso, shares that:
With the evolution of "DevOps" and the mantra "you build it, you run it", we've seen a huge increase in cognitive load on the developers tasked with delivering customer-facing products and services.
Reducing the cognitive pressure on development teams enables them to focus more readily on the core business code. Majors feels that "the more swiftly and easily developers can move, the better your platform team". In a recent Twitter thread, Majors elaborated on the relationship platform teams have with infrastructure and business code:
Platform teams uniquely sit between these two tectonic plates -- infra code and business code, each moving at different speeds -- allowing other engineers to completely abstract infrastructure away.
Majors draws a clear line between DevOps and platform engineering in stating "DevOps is about automation and managing infrastructure. Platform is about not having infra to run." This definition aligns to another statement made by Majors in that platform teams should focus on paying other people to run infrastructure, and conserve their development cycles for the development platform. Majors states that the goal of the platform team is to "run less software".
Sid Palas, engineer with DevOps Directives LLC, describes platform engineering as arising out of two core concepts:
- Developers don't like dealing with infra
- Companies need control of their infra as they grow
Palas has stated that DevOps principles apply to platform engineering, but the chief goal of platform engineering is to provide control over the company's infrastructure while enabling software engineers to remain within the "Developer Comfort Zone".
Vlad Ionescu shares a differing opinion that in fact platform teams are "expensive and hard to do, offer a mediocre service at best, destroy velocity, and create bad incentives". Ionescu feels that a focus on guardrails and company-specific developer experience tooling is a better investment. This avoids the risk of attempting to "build an internal platform that "abstracts the cloud" and "makes things easier for developers"".
Reddit user MrScotchyScotch feels that DevOps is misunderstood in these comparisons to platform engineering stating that many forget what the definition of DevOps is:
A combination of specific practices, culture change, and tools intended to shorten SDLC by reducing the time between committing a change to a system and it being continuously delivered into normal production while ensuring high quality and reliability.
This definition aligns with how others view the goals and benefits of platform engineering. Majors believes that platform teams succeed when "developers can easily choose good defaults, self-serve their infra, and own their own code in production." This shares similarities with the paved (or golden) path approach leveraged by companies like Spotify. According to Gary Niemen, product manager at Spotify, "the Golden Path is the opinionated and supported path to build your system and the Golden Path tutorial walks you through this path".
In Team Topologies, Manuel Pais and Matthew Skelton define the idea of the Thinnest Viable Platform:
A TVP is a careful balance between keeping the platform small and ensuring that the platform is helping to accelerate and simplify software delivery for teams building on the platform.
DevOps, SRE, and platform engineering all share a desire to simplify delivering high quality software quickly. Majors indicates that "developer cycles are the scarcest resource in your company, and you want to spend as many of those as possible on your core product". A focus on the thinnest viable platform, which as Ionescu states may be guardrails built on top of public cloud tooling, may be all that is required to enable fast flow.