Your Internal Developer Platform Sucks

Your current software engineering-focused internal developer platform is mediocre and aging rapidly. You want to make a better one. You are going to spend 18-24 months making your new platform and train all 100+ software engineers on learning Kubernetes, kubectl, and Istio. Mission accomplished? Nope, you failed real hard over a long time and taught a bunch of people what should have been an implementation detail.

You need an actual “internal developer platform” and that could be composed of many things but first and foremost you need to start with enabling your developers to do their job quickly without hand-offs, tickets, or other teams causing bottlenecks. If you are not focused on self-service you will fail. Kubernetes is not magic fairy dust that will fix all your problems. You need to understand your users and what they are trying to achieve.

What’s stopping you from building a kick-ass internal developer platform on top of Kubernetes? Inertia, a captive audience, a lack of vision, and potentially more. You might be lucky enough to be in an organization that does not think twice about using cloud services and you can cobble together what you need to get the job done. Is the solution affordable for your organization? Will it require significant maintenance over the long run? The benefit of Kubernetes is that you have a stable long-lasting API to provide this infrastructure substrate that you can control when you upgrade. When you use the cloud you are bound by the whims of public cloud providers.


Is this your first time building a platform? You are highly likely to fail unless you seek help. What is the point of the effort and what outcomes are you seeking? You need to get help and talk to someone, anyone, about what your plans are because you will be blindsided. You might be lucky 100% of leadership is aligned and trusts you to make all the right decisions but that is rare. Talk to someone like Postlight if they cannot help you they will at least send you in the right direction.

Your problem might be as simple as, “We have an internal team well-versed in CI and can get their code in containers we just need an easy place for them to deploy and iterate on their ideas”. In that case, take a look at Humanitec’s rapidly provisioned isolated Kubernetes environments in the public cloud. That is only the beginning you have lots of different pieces to connect, a small team, and not enough time to accomplish it all.

An “Internal Developer Platform” is meant to make the internal software engineers more effective at their jobs by providing tools that add leverage for them. Your team could be composed of “Platform Engineering” or it could be called something entirely different. According to an Adobe blog, around 100 engineers is the inflection point when this type of platform is necessary.

Internal Platform Product Management is key to success

Since stepping into my role as an internal platform product owner I struggled to know what the right terms to type into a search engine to find the help I was looking for. I stumbled upon material by Netflix, Will Larson, and Camille Fournier and all their writing is incredibly helpful but I imagine there are a lot of other people out their managing products like this without a clue in the world on where to start.

Start here

  1. Get help, these are made all the time anyone’s experience will help you
  2. Cast a big vision and focus on the outcomes, not the specific technologies you are implementing
  3. Listen to your stakeholders and do not implement exactly what they want