Platform Engineering - GigaOm: It’s no quick fix, it’s a state of mind

Platform engineering defined

Platform engineering is the craft and science of managing core capabilities so developers can be effective. We want our teams to be creating new products and features, not wrangling libraries, syncing between development tools or staring down YAML configuration files.

There’s a mindset change that takes place using platform thinking – that mindset needs to be realigned to maintain and improve what’s within, based on need, while still be able to innovate and extend on top. This attitude enables better budget allocation and planning – platforms and their component parts need to be efficient, change decisions need to be controlled, tooling needs to be consistent… and so on.

This doesn’t mean that we can “solve” the complexities of the platform. Even if that was achievable (it isn’t), it would be financially pointless. Some refactoring and rationalisation is fine – switch libraries, consolidate tools, clean up the codebase. But as a rule: if it ain’t broke, don’t fix it.

From an infrastructure perspective, platform engineering is not about creating wonderfully well-crafted software stacks on top of which everything just works. Rather, it leans on the façade design pattern – surfacing a subset of functionality that minimises perceived complexity for development teams. The platform becomes a product, with release cycles and an assurance of stability.

This concept extends across both newer, cloud-native and older, virtualised infrastructure. It’s a truism that an application becomes legacy the moment it has been deployed; it’s also true that decades-old Java and COBOL systems are likely to be around for a few years yet. All can benefit from an integration layer.

Internal Developer Platforms

Ideally, this goes hand in hand with a standardised way of working. Internal Developer Platforms (IDPs) offer a similar façade onto development, testing and deployment activity, for similar reasons of customer focus without distraction. But again, let’s not see IDPs as some kind of solve-all.

The priority is standardisation, not just bringing in a tool and hoping it does the job.

From experience, standardisation is almost entirely a people issue – if you have one group (or even individual) that decides to use a different CI tool or library, all your efforts to standardise will fall in a ditch. The platform engineering mindset does, therefore, require the ability to say no. Nobody wants to go back to pre-DevOps days of restrictive, long-winded processes, in which applications were already out of date on delivery.

However, we have replaced curmudgeonly controls with move-fast-and-break-things approaches, adopting new tools along the way. The result: a lot of broken things to maintain, interfaces to manage… and so on.

The river of constant change

The only continuous things are change, human behaviour and complexity resulting from both. Change has been relentless for decades and it isn’t suddenly going to go away.

LLMs are already changing how developers work – dramatically… and with few controls. The cycle continues.

Dependency spaghetti, no sauce

GigaOm field CTO Collins: Platform engineering is gaining traction as a response to fragmented pipelines, bloated codebases and spiralling costs.

By adopting a platform engineering mindset, you can separate core from context and plan your time and money accordingly. I say “you”: this mindset is as true for the CIO as the developer. We can all go down rabbit holes where we start tinkering with integrations and before we know it, we’re in dependency spaghetti and a day has gone.

So, don’t see platform engineering as a technology, or a role, or an initiative. See it as a fundamental step in helping software development shops to mature, to get a handle on the complexity they have caused, and create a space where innovation can continue.

It’s that simple.