How Internal Developer Platforms Impact Your DevOps Team Success

The last decade has seen an acceleration of software technology such as progressive web apps, cloud computing, and APIs. This has led to fundamental changes in software engineering roles, teams, tools, and processes. As teams have shifted from monoliths to microservices and seek to streamline and automate processes for speed, continuous delivery, competitive advantage, and satisfied end-users, developers are reconfiguring not only their workflow but their workplace. An example of this is the use of Internal Developer Platforms (IDPs). 

What is an Internal Developer Platform? 

Evan Bottcher, Head of Engineering at ThoughtWorks Australia defines an IDP as:

 "A foundation of self-service APIs, tools, services, knowledge, and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination."

IDPs aim to improve the developer workflow and internal development processes. They use tools that integrate with each other and typically include the use of a dedicated platform team distinct from the operations team. This creates a self-service environment where developers can work autonomously on feature development instead of waiting for the operations team to answer tickets. This leads to increased deployment frequency, greater visibility and transparency across teams, and reduced lead times. 

However, as Scott Carey, UK Group Editor at InfoWorld notes, "Internal developer platforms are like snowflakes, in that no two are the same. Each platform varies from organization to organization depending on their stack, culture, codebase, and toolset."

What are the benefits of an IDP? 

An IDP streamlines the internal development process to relieve pressure on Ops, improving productivity and speeding up business processes. It offers a way to compartmentalize the complexity involved in DevOps by creating a standardized developer workflow on top of all infrastructure and tools. This allows for developer self-serving and tasks are automated where practical, leaving developers to focus on the most mission-critical tasks.

The importance of self-service 

The IDP should provide a team with self-service provisioning, configuration and management of the platform capabilities. According to a whitepaper by Container Solutions, self-service is fundamental to internal developer platforms. 

"This can be eased by providing the developers with practical user interfaces, either CLI or GUI. The most obvious way is to use, build, or buy some sort of interface that can help users provision services or infrastructure, check their real-time stats and logs, as well as simplifying debugging."

The platform model is often associated with cloud-native environments but is also appropriate for many other types of architecture, ranging from modern to legacy. 

Who uses Internal Developer Platforms?

Top engineers in companies such as Google, Netflix, Github, and Amazon built their own IDPs. Puppet and CircleCI's ninth annual State of DevOps annual report of over 2,400 participants found that 63 percent of respondents say  their company has at least one self-service internal platform, with almost a third of respondents having 25 to 50 percent of developers using an internal platform. It also found that 48% of teams with a high DevOps evolution have IDPs.

IDP use correlates strongly with high-functioning teams who have evolved to self-serving where: 

• Incident responses are automated
• Resources are available via self-service 
• Applications are rearchitected based on business needs 
• Security teams are involved in technology design and deployment

At last December's KubeCon, GoSpotCheck's Senior DevOps Engineer, David Sufia, shared his team's experience building a Kubernetes-based IDP. He used Cloud Native Computing Foundation (CNCF) tools such as Buildpacks, Helm, OpenTelemetry, Prometheus, Envoy, LinkerD, and gRPC to make a much smoother experience for developers. 

David shared that his company had outgrown Heroku PaaS which was causing all kinds of problems. He notes:

"We could deploy fast, but we maxed out the number of servers and needed more control and customization. We're too big for platform-as-a-service, but we need to buy as we can't be running it all ourselves."  

For many companies, Heroku PaaS is/was a traditional place to start building services due to being quick and easy, but the costs build very quickly. There comes a point that many companies outgrow their one-size-fits-all PaaS. They may be planning to adopt a microservices architecture. Their number of developers may have increased with the introduction of a dedicated DevOps engineer. Features such as service discovery, traffic routing, and secret management may have become a priority. 

People want personalised control, but that takes time to build and resources to maintain. Despite the initial look of high cost, does something-as-a-service that gives you control but ties with common patterns fit into that gap perfectly? You also need to know what outcome you are trying to achieve. According to David, "Just because something is a good idea doesn't mean the process is easy or painless." He shared,

"We could do whatever we want, but what do we actually want, and do we have the resources to do it all?" 

Companies have the option to either buy or build their own internal developer platform with a plethora of pros and cons for each choice.

As Kelsey Hightower asserts “I'm convinced the majority of people managing infrastructure just want a PaaS. The only requirement: it has to be built by them.”

Internal Developer Platform as a product 

Global software consultants Thoughtworks assert that companies that are most successful in introducing an Internal Development Platform are those that apply product management to internal platforms: “This means establishing empathy with internal consumers (the development teams) and collaborating with them on the design.”

David Sufia also emphasizes the importance of the platform as a product. He notes that Conway's Law, where any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure, is a problem in platform teams.

 "One of the biggest pitfalls of platform teams that I've seen is that they build things for themselves and platform teams tend to be composed of some of the wonkiest teams who build things that are not what everyone consuming the platform wants to use." 

In response, GoSpotCheck viewed their IDP as something that needed to be designed, managed, and operated just like any other product within an organization. This correlates with Puppet's research that found highly evolved firms are nearly twice as likely to be highly product-oriented as firms in the middle of their DevOps evolution. They assert that organizational buy-in is crucial to the success of a platform, such as ongoing development and funding. 

"Over the longer term, you'll build a competency that will become a serious competitive advantage for rolling out future revenue-producing products that can drive your business forward."

David's team utilized cross-functional reference groups and made an effort to represent user personas, including senior and junior developers, and created a library of tools. 

He asserts that CNCF tooling "is at a point of maturity and interoperability where you can dive in as a midsize org and compose something that is going to serve your needs probably pretty well."

Getting started with your own Internal Developer Platform

Moving to an IDP is best achieved through gradual, incremental processes where the platform capabilities you need will emerge as you test various approaches. Evan Bottcher suggests starting small based on genuine proven needs:

"Harvest already proven solutions from application teams, and try joint-ventures to create and test capabilities with the teams that will use them."

Further, any platform is only as good as its makers and users, and the decision to build an IDP may result in a company realizing a lack of capabilities or specialist skills. Implementing an IDP is all about interpersonal team relationships. Resources such as Manuel Pais and Matthew Skelton's Team Topologies bring together different frameworks, models, and case studies to provide a functional and team-centered approach to building complex software systems.

Container Solutions suggest starting with a system's less critical, smaller applications. 

"By looking at these components, we can examine the dependencies and create a structure that eliminates many of them or consider tools to achieve the self-service aspects (such as a mixture of Kubernetes IDEs and Operators). Once all the core components are in place for this kind of setup, we can look at migrating this component, working with the engineers in charge of it to understand the engineers' needs and workflows. Once those steps are undertaken, you now have a starting point for your platform."

They suggest using a dedicated team that will gradually move more significant, more critical components to the internal developer platform as the Platform Team increases their understanding of the company's specific needs.

Looking for more information? 

The crowdsourced, curated site Internal Developer Platform provides a central repository for IDP resources including articles, experts, and companies, and tools that can help.