Do You Need an Internal Developer Platform? – InApps 2022

Computing trends often seem like a game of “follow the leader.” If Google, Microsoft or another titanic tech company do it, shouldn’t we do it too?

This logic plays out with semi-regularity. Site reliability engineering (SRE) spawned from Google practices, and a book by the same name, for example. The SRE role has subsequently proliferated on tech teams across industries.

As long as we’re on the topic of reliability, chaos engineering started as an internal tool and practice at Netflix; now it’s a set of codified principles, open source tools and commercial tools used in a widening range of enterprises.

This pattern is emerging again with internal developer platforms, or IDPs. Initially the purview of the web giants and other massive firms, IDPs, which give developers a wealth of self-service capabilities for quickly provisioning the various environments and other resources they need, are gaining traction on a broader range of software teams.

It’s not merely a follow-the-leader trend. Rather, IDPs are a natural byproduct of the massive growth of the cloud and cloud native ecosystem, and the corresponding rise of DevOps and DevSecOps, CI/CD pipelines, and other modern tools and disciplines. Puppet’s 2020 State of DevOps report even cited the use of self-service platforms as a common characteristic of high-performing teams.

“Modern development requires information from many different domains such as quality, hygiene, security, licensing of not only your first-party code, but also third-party code,” Brian Fox, chief technology officer at Sonatype, told InApps.

“The only sane way to scale this up is via a systematic approach that can integrate the appropriate tooling into the development process in a way that results in more uniformity across projects.”

Reducing Turnaround Time

For a growing number of organizations, that systematic approach is an internal developer platform. IDPs go by various other names, such as self-service platform and Kubernetes platform. By any name, they essentially consolidate virtually everything an organization’s development teams need into a single place

If you’re building containerized apps, guess where devs will find approved container registries? In the IDP. Ditto for new environments: Need a new test or sandbox machine? Devs can spin that up quickly for themselves — no lead time of days or weeks or, in some particularly painful legacy processes, months. The platform approach enables this and more within defined parameters, usually set with input from DevOps or Ops, security and other domain experts.

“Thinking about your development pipelines as a platform is how you achieve consistency and completeness of analysis at scale,” Fox said.

IDPs are typically implemented “where there is a compelling need to increase developer productivity and autonomy, whereby the turnaround time for new features for services and products is reduced significantly,” Raghu Kishore Vempati, director of innovation at Capgemini Engineering, told us.

That proposition would seem to sell itself given the frenetic pace of software development today. But IDPs aren’t necessarily for every team or organization. There can be a significant overhead in terms of getting up and running, and with ongoing development and maintenance of the platform. As a result, they naturally favor large organizations, especially those with complex, heterogeneous environments.

A lot of the cost-benefit analysis can be distilled down into simple terms: What will an IDP allow us to do tomorrow that we can’t do today? If your answer is worth more than the initial and ongoing cost of an IDP, then you should probably give it serious consideration.

In terms of overhead, that starts with the platform itself: You have to build it.

While debatable, the classic IT build-versus-buy doesn’t necessarily apply here: A purist may tell you that a “real” IDP is built in-house, from scratch, even if it likely uses key components such as the open source Kubernetes in its construction. A commercial PaaS is just that, and a viable option for many teams, but off the shelf, it’s not an IDP per se.

Building your own platform requires a platform engineering team. Even at the smallest scale, you need to start with one platform engineer. The IDP model usually entails a separate platform team that includes multiple engineers, distinct from your developer or DevOps teams, as Weaveworks Chief Operations Officer Steve George described recently in InApps. It requires an ongoing investment in people, not just in technology.

A cost-benefit analysis should determine whether your organization is a good fit for an IDP. To that end, ask these six questions. The more that you’re answering “yes,” “that’s us,” or similar, the more likely it is that you’ll find a return on the investment.

1. Is Your Infrastructure Ready?

IDPs are not just a cost-benefit consideration. They’re also a “cart-before-the-horse” concern: If you’re running on creaky infrastructure and processes that are crying out for an update, then you’re probably not ready for the IDP plunge.

The infrastructure question is where organizations should start when evaluating whether they’d benefit from an IDP, according to Brian Sathianathan, chief technology officer at Iterate.ai.

“Number one: Is your infrastructure modernized? Are you working with a cloud stack?” Sathianathan asked. “If you have significant legacy pieces in your deployment pipeline, then you’re going to be doing more work to even get to the IDP starting line.”

2. Do You Have a LOT of Developers?

It’s a bit of a loaded question, but it’s an important one: Does your organization have a lot of developers? Meaning: so many that you’ve got multiple, distinct developer or DevOps teams, each with their own distinct needs, codebases, infrastructure requirements and so forth?

IDPs make sense, Sathianathan said, when “you have a large enough developer base in your organization to handle diverse requirements and different languages, codebases and infrastructure needs.”

There’s no magic threshold you need to reach. But as the number of developers and/or development teams in your organization grows, then the likelihood that they’ll benefit from an IDP typically increases as well. A single, relatively small team that can standardize on the same languages, tools and so forth might not reap the benefits.

3. How Well Are Your Build-Deploy Processes Working?

An IDP should be an evolutionary phase for a team that’s already firing on most cylinders. In the DevOps or DevSecOps context, this is sometimes referred to as maturity.

If you’ve got a lot of known, and possibly unknown, bottlenecks in your software delivery pipeline, Sathianathan said, then you’re better served alleviating and improving those first. An  IDP can add an order of magnitude in terms of speed and deployment frequency, but it won’t on its own solve broken processes or culture problems.

4. How Much Autonomy Do Your Dev Teams Have?

Developer autonomy is one of the most commonly cited benefits of the IDP approach. The nature of self-service is to facilitate and encourage autonomy, with some guardrails in place to keep things running reliably, securely, and without breaking the budget.

“You need to have a good sense of whether self-service will bring order-of-magnitude benefits, or fractional ones — and understand how benefits might, or might not, outweigh the costs,” Sathianathan said.

A different version of this question is: How much autonomy do we want our development teams to have? If the answer isn’t “a lot!” or close to it, give some thought to why you’re considering an IDP. One of the reasons they can be a good fit for DevOps teams is that the trust necessary for autonomy should already be in place.

5. How Well Is Your Ops Governance Working?

This is another cart-before-horse issue: If your answer to this question is something along the lines of “our what?” then you might not be ready for an IDP.

Self-service is not a synonym for “do whatever we please.” The guardrails have to come from somewhere, and if your current IT governance model resembles a gold-rush town in the Wild West, then you might want to press pause on the IDP project.

“Is it a centralized model?” Sathianathan asked. “If there isn’t a centralized model and different parts of the enterprise are doing different things, that governance absolutely needs to be fixed before pursuing an IDP strategy.”

6. How Big of a Deal Are Your SLAs?

OK, most organizations might answer, “they’re a big deal” here. But with this question about service-level agreements (SLAs), Vempati is specifically referring to businesses where high availability and resiliency are bottom-line issues, or similarly high stakes, such as in public health or safety contexts.

If speed is also a fundamental issue, of the sort where seconds matter, then an IDP may also be beneficial. Vempati shares examples of more specific versions of this question:

• Does our company deal with delivering services to customers, internal or external, that require rapid turnaround time?
• Is our company a partner to multiple large organizations for whom the turnaround time to deliver features and resolve errors must be significantly less than ours?
• Are there SLAs that require high availability and resilience?

The more of these questions you answer affirmatively, Vempati said, “the greater is the value and compelling case for an IDP.”

Featured image by Image by IADE-Michoko via Pixabay.