What is an Internal Developer Platform?
In August 2022, Gartner® Hype Cycle™ for Software Engineering listed Platform Engineering within it’s growing innovations pillar. Platform Engineering is a growing topic within Organisations and they are seeing the research in the space as directly applicable to their efforts to build an Internal Developer Platform.
You’re now probably thinking “What’s Platform Engineering?” and “What’s an Internal Developer Platform?”
In this short article, I’m going to try and address the “What’s an Internal Developer Platform?” question and hopefully make Internal Developer Platforms a bit less obscure by explaining the basics of what they are and why they’re getting so much attention.
And I’ll begin by saying good DevOps,
is not about running Kubernetes Clusters…
… it’s not about building Containers, it’s not about deployments into IBM Cloud, it’s not about scaling across multiple-regions, or building the best Grafana dashboards, or most complex Jenkins Pipeline, it’s not about any of those things, even if they (unfortunately), have become highly synonymous with it.
So what is good DevOps about?
If you ask me, good DevOps is about giving Developers complete freedom to focus on development without restraints.
That means enabling them to be self-sufficient, to perform whatever actions they require to be able complete their tasks, and to have the freedom to do it on their own terms.
Once you accept that as your goal — you’ll have started down the path that will unleash the true potential of your developers.
The next step is figuring out exactly what we need to do to turn the goal into a reality and why we need to do it.
So, lets start with tools.
The Cloud-Native Computing Foundation (CNCF) Landscape continues to grow (1191 at last count), with new and exciting tools and projects being added each year.
Whilst this is amazing for innovation and freedom of choice, it does bring it’s own challenges and complexities.
When we look at the CNCF Landscape and we read words like Kubernetes, Vault, Jenkins, ArgoCD, Prometheus, Terraform, Kong, Stackrox, and Istio. What’s the first thing you think of?
You probably think “Well they’re DevOps tools. They’re the tools I use”.
Well I’m afraid to say, that’s wrong! They’re Operational tools, they’re the tools that our Operations teams need to use, not our Developers.
Operations teams should NOT, and I stress, should NOT be giving access to those tools to just anyone.
You see — not everyone is going to understand all these tools. They probably won’t understand all the finer details of tools such as Terraform, Istio, or Kubernetes. They probably won’t know how to effectively troubleshoot applications or monitor the infrastructure.
Giving access to these kind of tools to everyone just gives them greater scope to make problems — and so that scope should be reserved for use by your Operations/SRE teams whose primary responsibility and skillset is making sure they are used effectively.
So then what do we do with our Developers? Do we ask them to just focus on writing their code? Having them “sling it over the wall” once complete to our Operations/SRE teams who specialise in Cloud-Native, Automation, Security and Observability technologies?
Or should we be asking our Developers to do those things by themselves? Teach them all the nuance involved in managing their own clusters, servers and infrastructure? Ask them to build their own CI pipelines and deploy their own code?
Or maybe we should combine our Developers and Operation teams together? That will no doubt create self-sufficient teams. I can just picture the conversation now.
“Hey Developer Dave, here’s an IBM Cloud account. Now go and create your infrastructure, don’t forgot those subnets, and then create your Kubernetes cluster and deploy your applications and whilst you’re at it, make sure you set up your Observability stack, I mean, you DO want monitoring don’t you?
You may need to spend a bit of time learning all the skills and tools you require, I’d say 4, maybe 5 years should be enough, but guess what, you’ll be self-sufficient in no time!”
You know that’s not going to work. It’s never worked and it’s never going to work because it’s impossible for every person to know everything that’s required to do both development and operations in a modern digital world.
So then: The focus of good DevOps should be creating Services that are consumed by our Developers.
These Services can be leveraging some or even all the tools we’ve listed above, but importantly, these kind of tools should not be directly exposed to just anyone — our Operations/SRE teams should be creating these Services, to be consumed by our Developers without restraint or room for misuse.
In fact, when the Operations/SRE teams are creating these services, they should realise that everyone in Business has a customer — and theirs are Developers. For them to be successful, they need to make sure their customer is happy and able to self-serve to satisfy their needs.
So how do they do that?
To me, the answer that will delight their customers, by bringing them closer to the “Goal of good DevOps”, is to create an Internal Developer Platform or IDP.
As a bit of a side note, I personally sometimes refer to these as Independent Developer Platforms, as the intentions are to allow the Developers to be Independent of Operations, but for now I’ll stick to the more commonly used term of Internal.
An Internal Developer Platform is a layer of abstraction, arranged as a compelling internal product, on top of all the technology and tooling that our Operations/SRE teams have in place. It enables our Developers to do the operations, without first requiring them to build expertise.
Ultimately an IDP is a Self-Service Platform for everything our Developers would require.
You may now be asking yourself how does building an IDP and enabling our Developers to be self-sufficient get us towards the “Goal of good DevOps”?
Well, there are quite a few benefits you’d get from the IDP, and I’ve listed some below.
The first one is around Freeing Up our Operations/SRE teams.
An IDP lets us free our Operations/SRE teams to do what matters, and what matters most is creating Services that our Developers can consume.
Now, instead of our Developer sitting idle after raising an Operational Request for an Application to be deployed here or for a Cluster deployed there, they are consuming a service that has no delays caused by people-availability and they are getting on with Development!
The second one is Synergy for Developers.
Our Developers now have access to all the Services they need to do their tasks in an expected timeline. A Developer can travel through their workflow without needing to Context Switch between different API’s, Tools and Infrastructure, and without having to contact the teams that manage those things and ask for updates, provisioning or issue resolution.
The third one is Increased Efficiency.
By leveraging an integrated set of Services through the IDP ecosystem, we can measure an increase in businesses software development speed. An improvement in Lead time and Deployment Frequency values, whilst a observing a decrease in Change Failure Rate (CFR) and Mean Time to Recover (MTTR) output.
The fourth one is Improved Compliance and Governance
By having our development process accelerated through that of an Internal Developer Platform, we can leverage tools and services which automatically includes requirements to satisfy Compliance and Governance. For example, we can ensure that code goes through a robust DevSecOps Pipeline and prevent “bad code” from being deployed. Taking an Infrastructure perspective, we can automate the provisioning of resources, and assure that they are hardened and secured automatically.
The fifth and final one I’ll cover is Accelerate Onboarding of New Developers.
As your product grow and scales, or your development team changes through promotions or natural attrition, you are able to onboard new Developers into your organisation at speed. An IDP abstracts the need for a Developer to learn new/different technology stacks. The use of Services created by your Operations teams ensure Developers can be up to speed in a significantly shorter timeframe.
Imagine a world where a business can onboard a new Developer on a Monday and have them pushing code into Production by the Friday. An IDP creates these possibilities.
I hope this brief dive into IDPs has given you a high level understanding of what they are and why they’re getting so much attention. With the view of keeping this article short, I’ll finish up by saying that I plan to dive deeper into Internal Developer Platforms in future articles and will cover topics such as “How should we build an IDP?”, “High Level Architecture and Process of an IDP”, “what is the Developer User Experience of an IDP” and finally present an “Opinionated View on Tooling Choices for an IDP”.
Until then, if the article has given you ideas, I’d love to hear from you!
The best ideas are open-sourced.
Acknowledgements
- Kedar Walimbe, IBM Client Engineering Leader, APAC
- Matthew Goes, Business Technology Leader, IBM Client Engineering, ANZ
