Automation

Do You Need To Build An Internal Developer Platform?

There is currently quite a lot of noise about internal developer platforms <<insert obligatory Garter link>> as an aid to ease complexity and smooth the path to work, productivity and software delivery.

What is an Internal Developer Platform and is it a good idea?

The most popular example of an IDP is Backstage. I’ve seen it in the wild and I’ve also heard the Spotify pitch and I’m on the fence about whether they provide true value or just overcomplicate your estate.

Should you be increasing complexity in your platform infrastructure (essentially another layer on top of your existing tooling) to make up for cognitive load, shortfall of talent or shortage of skills? Is that the reason that we see such an explosion of interest in developer platforms?

A recent thoughtworks tech radar piece rings a similar note of caution.

The two important takeaways from this are:

  1. You don’t just implement Backstage – you implement a whole new system with supporting infrastructure. It’s therefore a long-term investment of people and technology even if the platform itself is free an open-source
  2. Don’t invest in it until you’re sure it’s going to add value to your engineers’ lives and you have sufficient scale to justify it. It’s not going to be for everybody.

IDPs are not new. Good engineers always want to make their lives and the lives of their fellow engineers easier. While implementing an out-of-the-box solution seems like a great idea, just beware of the hidden costs of integration and the overhead of supporting and maintaining the extra complexity. Done right it should make developers’ lives easier, but done wrong it can easily overcomplicate existing processes.



Related articles