At Endava, we’ve been helping our customers shape and deliver their strategic technology platforms for many years. By embracing excellent design, build and operations practices, and taking care to align well with application development teams, we’ve helped our customers establish a wide range of modern platform capabilities. These are increasingly recognised as critical to delivering high-quality software – from API economies to data platforms, containers and developer PaaS platforms, from on-premises infrastructure to hybrid and multi-cloud landing zones.
Since 2020, a whole cross-industry platform engineering movement has emerged in the wild. This movement is a broad church, attracting followers and advocates from various DevOps, SRE (site reliability engineering) and cloud communities, and it is driven by many of the same strategic and technical concepts we’ve implemented with our customers.
However, despite the huge diversity of useful platform concepts we see in practice, there’s a notable undercurrent in this community pushing for a focus on just one particular kind of platform: the self-serve ‘internal developer platform’, or IDP.
In this article, we’ll discuss the IDP concept and how it relates to a broader view of platform engineering. We’ll consider the motivation for IDP adoption, some cases where they’re most useful and some where they might not be. We’ll then place IDPs on a wider spectrum of platform architectures and outline a few key considerations we use to help our customers choose the right approach.
Internal developer platforms
According to one influential definition, platform engineering is “the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era”.
The same source states that the role of platform engineers is to “provide an integrated product most often referred to as an ‘Internal Developer Platform’ covering the operational necessities of the entire lifecycle of an application”.
The point of such IDPs is to provide a better experience for developers who need access to hosting environments, infrastructure and support tooling. An IDP does this by offering fast, self-service access to these platform capabilities while hiding a lot of the underlying technical complexity behind a tailored developer portal and a clean API. Often, the IDP is the result of nesting or layering multiple logical platforms on top of one another, combining a range of technology functions, platforms and tools into a one-stop shop for developers.
This concept contrasts with more traditional enterprise systems and processes, which, even if self-serve, tend not to be primarily organised around development workflows, priorities and personas. And while the IDP service model is comparable to public cloud platforms, the idea of an IDP is that it’s not just providing generic self-serve platform resources but rather capabilities that are deliberately tailored to the needs of your organisation.
So, the idea is that, rather than raising loads of IT service requests and waiting for them to be fulfilled in turn, or expecting teams to design and build entire cloud environments from scratch, an IDP gives development teams exactly what they need in an automatic, quick and organised way that makes sense to them. An IDP supports your organisation’s most common technology choices and joins up a lot of important infrastructure and operational services.
But most importantly, the whole platform should be designed with a smooth development workflow in mind, codifying knowledge of how things work specifically at your company. This often extends to a ‘Golden Path’ design, where platform teams identify and automate the most common developer onboarding workflows. “From new app to production in one hour”, as one customer puts it.
An IDP is, therefore, a heavily productised internal platform. A company’s development teams are the IDP’s customers, and the platform’s developer experience (DX) is central to its design and operation. Customer satisfaction is the IDP’s key measure of success, so the team behind the platform should closely collaborate with developers, actively solicit their feedback and make sure that they get what they need from the platform.
Yet the fundamental service model for an IDP is fully automated, self-service delivery of just what the developers need, without requiring input or supervision from the platform team and avoiding any hard dependency on their time. This is because, ultimately, the point of investing in an IDP, and in DX, is to improve ‘flow’ – which is DevOps-speak for getting more and better code shipped to production faster. An IDP delivers this by removing handoffs and impediments in the development cycle, reducing operational toil and packaging the organisation’s platform know-how into a self-serve product.
Beyond IDPs
This vision of platform engineering has generated a lot of excitement. And although some newer technologies – such as backstage.io, an open source project aiming to simplify the creation of IDPs – have driven interest and made the IDP concept more workable, technology choices are not nearly as important to this vision as its DX-centric product and service model.
In fact, there seems to be little on a technical level that differentiates IDPs from the older Platform-as-a-Service (PaaS) concept. The central difference is really the way the platform is tailored and served as a user-centric internal product. While it’s certainly easier to do this with some technologies than others, the step up from PaaS to IDP is first and foremost a case of evolving your internal product strategy.
In other words, platform engineering is less about technology choices than design choices, continuous feedback, automation that works for its users and a commitment to high-quality engineering.
This broader idea means that, while we’re excited about the possibilities of IDPs, at Endava, we see platform engineering as a far broader spread of activities than building IDPs. Often, doing great platform work means deciding to build an IDP.
For us, the essence of platform engineering is not IDPs – it’s the conscientious approach to platform design, build and operations concerns that sometimes leads us to create them. It’s the deliberate, business-oriented focus on how platform infrastructure and lifecycle services should be used, by whom, for what and why, regardless of whether an IDP is the best way to deliver them.
So, we view platform engineering as a wider spectrum of engineering activities and architectures that are independently beneficial to our customers. That list absolutely includes IDPs, but whether an IDP is the right solution depends, of course, on the actual context.
IDPs in reality
The point of building an IDP is to maximise flow, to enable developers to ship good-quality software to production as quickly and easily as possible. The IDP is meant to eliminate bottlenecks and handovers in the value stream by tailoring many aspects of IT operations and infrastructure engineering for a self-serve model, which places more responsibility for how the live system will look and be operated into the hands of developers.
This is no mean feat and requires significant investment. But even then, sometimes, maximising the flow of change to production isn’t the highest priority, or an IDP might not be the best way to achieve it. It might be more important to optimise for cost, or to improve flow through close, direct collaboration between platform engineers and developers, rather than by creating a self-serve interface between them. It might be that one business domain has quite different platform requirements from another, requires dedicated infrastructure or even an operating model that affords their teams more control of the platform internals ‘under the hood’.
We’ve seen all of these challenges in the wild with real customers, and building an IDP was not obviously the best solution to any of them.
So, deciding to build an IDP means identifying it as a good solution for your company or business domain, which means first identifying whether you have the kind of problem an IDP could solve. By contrast, any system can benefit from better platform engineering practices: a stronger focus on the lifecycle of an application’s supporting infrastructure, automation-first practices that drive down operational toil within the platform, and design and leadership that consider how humans need to consume and evolve the platform’s capabilities, self-serve or otherwise.
Modes of platform engineering
When customers ask us for help with platform engineering or IDPs, we encourage them to think about their requirements from a few different perspectives. A good place to start is often to think about how far the platform approach needs to be optimised for flow of change or cost-effective consumption of resources. In the graphic below, you can see some examples of where different platform architectures might sit along that continuum.
IDPs are highly optimised for flow of change – but we don’t always want to maximise flow above all other concerns.
So, while an IDP optimises for flow, an app-specific cloud solution might present a better overall balance of flow and resource optimisation. A shared Kubernetes container platform might yield many of the benefits of an IDP at a lower total cost of ownership, depending on the skillsets, requirements and priorities of the development teams using it. At the other end of the spectrum, a computationally intensive application might be best served by a performance-optimised bare-metal hardware solution that uses no cloud technologies at all.
Alongside flow and cost optimisation, we might also think about:
- Scale: How broad a range of stakeholders will the platform architecture need to serve, and how many? Are we solving the needs of a single system or product, working across a few different business domains, or are we building a platform for the whole company?
- Operating model: What kind of relationships will there have to be between people who use the platform, people who build the platform and people who operate the platform? Does everything need to be built for self-serve, or will some users want more direct control of platform internals? What kinds of overlaps and interfaces should there be between these groups?
- Data: How will the systems and stakeholders that the platform serves need to manage their data? Should this be part of the platform, held on a different platform or somewhere else entirely?
- Cardinality: How many platforms should there be? Should we build one big platform that delivers the same capabilities and quality attributes for everyone, or should we define several platforms that are more optimised for groups of users with similar requirements?
There are many more dimensions besides these, but this list illustrates why we like to take a flexible, broader view of platform engineering. Looking more closely at our immediate delivery context and handling platform work as a focus area in its own right allows us to deliver on the promise of the platform engineering movement – better outcomes, higher quality, smarter and more agile interactions – without treating IDPs as a catch-all solution.
Conclusion
At Endava, we’ve come to view platform engineering as a critical capability – and one that is wholly separable from the industry buzz around internal developer platforms.
While IDPs have amazing potential, what differentiates them from the previous generation of internal PaaS platforms is really a question of service design philosophy over technology: IDPs are optimised for fast flow through their commitment to true self-serve capabilities, workflow automation and a great developer experience.
To us, the underlying idea that it’s important to build great platforms that are tailored to the needs of the people who use them extends beyond the narrow concept of a self-serve IDP. There are many other ways to optimise for flow, and sometimes, flow isn’t even the biggest priority.
By contrast, a better focus on how, why and for whom we build platform capabilities can be useful in practically any customer delivery context. This is the essence of platform engineering at Endava.