Platform Engineering Series: Editorial brief & scope

What is platform engineering? 

We can define this by term by calling it an operational discipline that centralises developers, architects, operations professionals and other team members on the design, construction and maintenance of workflows and processes that can provide a consistent route to effective toolchains that streamline development, eliminate waste and enhance efficiency.

As has been widely document, platform engineering makes extensive use of Internal Developer Platforms (IDPs), which TechTarget defines as a collection of self-service tools and services development teams can use to configure and deploy application infrastructure without direct help from the operations team so that developers can independently spin up environments for tasks such as automated testing and deployments as needed.

Why the popularisation?

There are many reasons why platform engineering is currently becoming popularised, not least of which is the fact that software development lifecycles are being shortened all the time. 

This tightening is happening at the same time as platform-centric itself actually becoming more complex i.e. some have called Kubernetes “opaque” and akin to a black box, not everything happening in the orchestration layer is observable, despite the rise of observability platforms themselves.

Inconsistencies & misconfigurations

Add these challenges to new regulator pressures and increased inconsistencies and bottlenecks occurring in “traditional” developer environments and you can see why the technology industry is looking for some “higher form of truth” or route to managing the wealth of codebases beneath it.

The trouble is, while platform engineering exists to eliminate Inconsistencies, bottlenecks & misconfigurations, it’s compartmentalisation of some tools into internal developer platforms can lead to (yes, you guessed it) Inconsistencies, bottlenecks & misconfigurations, so how do teams get around this?

Did DevOps die?

Back to the death of DevOps and the rise of platform engineering, what really is the difference then?

According to TechTarget senior technology editor Stephen Bigelow, “DevOps is a software development approach that promotes collaboration between development and operations teams, whereas platform engineering gives DevOps teams a centralised platform for their tools and workflows. At first glance, the two ideas might seem similar or even interchangeable. DevOps principles are often involved in the creation of centralised platforms; likewise, platform engineering is typically implemented after an organisation successfully adopts a DevOps environment.”

However, says Bigelow, platform engineering’s purpose is fundamentally to support DevOps by providing consistent, reliable tools and workflows to build software. Whereas DevOps teams can take on any business project, platform engineers focus on creating and maintaining the specific platforms that DevOps teams use.

CWDN series

The Computer Weekly Developer Network starts a series of guest posts to deconstruct platform engineering and examine the issues that matter most. Questions to ask here include whether or not platform engineering leads us towards so-called “golden paths” for software development.

Does a platform engineering mean we need to treat the platform itself as a product? 

Writing on platformengineering.com Luca Galante thinks so. He says that, “Expanding on the product focus, the platform team needs to be driven by a product mindset. The [team] needs to focus on what provides real value to internal customers, the app developers, based on the feedback they gave them. Make sure they ship features based on this feedback loop and don’t get distracted by playing around with a shiny new technology that just came out.”

What other challenges does platform engineering throw up? Many say that “complexity and overhead” is too much of a burden here, because it the IDP itself takes so many person-hours to build and maintain. 

Other platform engineering commentators argue that the one-size-fits-all platform may not always address the specific needs of all development teams, resulting in inevitable inefficiencies and siloed teams without focus.

Naysayers say that platform engineering risks skewing developers away from established industry standards and may even introduce the coding team to an environment that is so foreign that they find it overwhelming. 

Developers develop (not play platform)

Will developers naturally gravitate towards platform engineering acceleration, or – because developers actually like to develop and don’t always welcome abstractions, even when they are designed for efficiency – will they baulk when presented with a platform that they don’t fully understand the working of?

There’s a lot of (software) engineering in platform engineering, so how do we convince developers that this is not a case of over-engineering or engineering for engineering’s sake? In this environment, how can we keep the team focused on a single goal and how do we set about integrating platform engineering with existing legacy systems?

There are so many questions to ask here. How do we define goals for platform engineering, how do we measure delivery cycle acceleration (if indeed it does happen), how do we maintain security inside platform engineering, how well does the platform engineering design always reflect real developer needs, how do we inject new tools into platform engineering workflows if they are missing, how abstracted is good abstraction, how reusable should golden path software components be and do they have a shelf life, how senior do developers need to be to use platform engineering tools and is it okay for newbies, what about observability for platform engineering in terms of logging, metrics, tracing and health dashboards… how about compliance and identity and access management and to what level should platform engineering feature policy-as-code to enforce consistent security standards..?

NOTE: This is “not” a Q&A exercise, these questions are posed to (hopefully) encourage analytical thought.

Perhaps most of all, is platform engineering a cultural shift that we’re culturally ready for… and did DevOps actually die somewhere along the way? We want answers and deconstructed opinionated progressive thought spanning the whole spectrum here, let the series commence.

Free image source: Wikipedia.