brief overview
Even the most advanced organizations struggle to scale their development output in the face of growing talent shortages. As a result, enterprises and development teams are starting to look at their infrastructure from the perspective of internal development platforms to master these challenges and accelerate delivery at scale. Leading analyst firms like Gartner , thought leaders like Martin Fowler , vendors like Humanitec and Upbound , and technology giants like Apple , Netflix , and Twitter have all started discussions around in-house development platforms. This review article summarizes the different voices and provides a full story, along with practical advice and relevant references. We will also highlight several suggested foci for planning, implementing, and operating an IDP at the enterprise level.
The internal developer platform is an important new concept because it addresses three key challenges in the software delivery lifecycle. it
- Provides environment management, from development to production, and integrates CI/CD
- Integrate repeatable patterns that development teams can leverage for their applications
- Reduced transactional burden between development and operations teams
Often, simply hiring more engineers is not enough to solve the problems faced, nor is it enough to support the growth of the enterprise organization. We will examine this issue in more detail later.
Cloud computing, containerization, and microservices architectures provide organizations with a wide choice of in-house tools and systems to accomplish the requirements of the new environment. Internal developer platforms promise to provide development teams with ample choice of tools and resources while abstracting away the operational burden. Intuitively or intentionally, many development teams are aware of these benefits, while the responsibility for the infrastructure falls to a small number of different individuals who provide this abstraction. Oftentimes, businesses don't know they're actually building an in-house development platform, or at least variations of it. InfoWorld's Scott Carey captured this concept when he described in-house development platforms as "snowflakes," noting that "no two are the same. Each platform differs depending on the organization's stack, culture, codebase, and toolset." different.
We believe that the adaptability of the in-house development platform is a core element of the concept. This is one of the reasons why the concept of an internal developer platform is so powerful and attractive for software development organizations. Therefore, we will avoid academic definitions and instead highlight the different functions and modes of implementation that we have seen in the literature to facilitate further adaptation.
What is an internal developer platform
The community-driven website internaldeveloperplatform.org provides a great starting point for understanding what an internal developer platform is .
Internal Developer Platforms (IDPs) are configured by the operations team and used by developers. The operations team specifies what resources are started under what circumstances or under what requirements. They also set baseline templates for application configuration and manage permissions. This helps them automate recurring tasks like launching environments and resources, and makes their setup easier to maintain by enforcing standards.
Brendan Kamp and his team at Container Solutions see IDP "as a system of tools that can be integrated with each other into a central platform that supports internal development processes. Developers see it as an 'internal platform as a service'".
The aforementioned InfoWord article by Scott Carey also highlights the nature of IDP's service in terms of the specific preferences of development teams.
A good internal developer platform should abstract infrastructure decisions, enable self-service environment builds, integrate with existing continuous integration and delivery (CI/CD ) and deployment processes, and assign role-based access controls, all of which Neither requires developers to learn YAML.
Valuable features of an internal developer platform
Watts S. Humphrey 's iconic quote: "Every business is a software business" has been around for nearly two decades and has been reiterated by many CEOs and strategic leaders, including Microsoft's Satya Nadella This sentence, and put forward a different view. This quote underscores the need for any organization—regardless of its actual industry vertical—to provide its software development teams with the right environment to address the critical challenges of being competitive in modern application development.
Classic supply and demand problem
Many organizations have reached unprecedented levels of growth in cloud adoption projects, digital-first initiatives, and digital transformation. These moves put a huge burden on the operations teams traditionally responsible for building and maintaining the platform for the development teams.
Simply hiring more engineers or developers to reduce the overall backlog and distribute the workload more evenly won't solve the problem. Without a clear process and shared understanding, this leads to "more people" that may not be immediately effective as every organization's internal tech stack is different; it will take time for new engineers to "fill" their skill sets gaps before you can start adding value to the team.
Reduce the cognitive load on your team
Teams involved in software delivery often have many tasks and responsibilities to juggle in their day-to-day work. In-house development platforms elevate some of the cognitive load associated with various day-to-day tasks . The cognitive load caused by context switching is often cited as a lost developer productivity problem. Developer productivity experts Matthew Skelton and Manuel Pais cite the cognitive load of context switching as the main reason why teams appear overwhelmed. In their bestseller " Team Topology ", the authors explain this very well. "Without accounting for cognitive load, teams spread out trying to cover too many responsibilities and domains. Such teams lack the bandwidth to pursue mastery of their industry and struggle with the cost of switching contexts." Again, from Puppet The 2020 DevOps report states, "Most software developers and operations engineers understand that switching back and forth between two contexts is a huge cognitive drain. There are reasons for this, aside from the normal human challenges of context switching : the details and ways of thinking are so different in each field".
Yet cognitive load is rarely considered during organizational or project planning. This puts the development team at a huge disadvantage and prevents the organization from achieving productive victories. The internal developer platform provides teams with a collection of reusable patterns to consume their characters at a single point of interaction. This reduces the number of context switches, thereby reducing the cognitive load on the team.
The challenge of autonomy and tool diversity
Writing on Martin Fowler's blog, Evan Bottcher does a great job of explaining the challenges that development and operations teams in organizations face and how internal developer platforms can help them.
...Obviously, a good platform must be characterized by the amount of coupling it reduces backlog. The platform must provide services that do not require raising tickets and assigning work. Self-service is a key defining characteristic of a good platform...the platform should provide teams with self-service access. Specifically, it should allow for self-service provisioning , self-service provisioning , self-service management and operation of platform capabilities and assets ... finding the right balance between autonomous diversification and forced integration, while This is even more difficult to predict in the early stage.
Allow teams to deliver faster
Delivering high-quality software at higher speeds has been a focus for development teams and the businesses they support for many years, largely due to consumer demand for new features, and competition within the marketplace. Some very well-known examples of the pressure organizations are facing in their respective markets are AirBnB disrupting the hospitality industry , or Uber and the taxi industry . This shows that companies need to be able to react in order to maintain their relative position in a changing market, which gave birth to Agile and DevOps, and companies started to "kick the tires of DevOps " as early as 2015.
Since then, many companies, both cloud and more traditional, have become known as "high-performing DevOps organizations," as Puppet puts it in its annual DevOps report. The term takes into account the opinions of many industry leaders and analysts on what these companies can do to deliver software faster and outperform their constituents in their respective business areas. Some of the key metrics used to assess whether an organization can be considered a high-performing DevOps company are. Deployment frequency/schedule, lead time, wait time, and mean time to repair (MTTR).
In the 2020 edition of the State of DevOps report, there is a clear trend between these high-performing companies and the adoption of internal developer platforms. Puppet found "a strong relationship between the evolution of DevOps and the use of internal platforms. Highly evolved companies were nearly twice as likely as mid-tier organizations to report high usage of internal platforms, and lower-tier organizations were less likely to report high usage." organization six times".
Participate in the team that develops the platform internally
Internal developer platforms are traditionally built and managed by a dedicated team, which we call the platform team. Along with the platform team, the operations team is responsible for the technical needs of the organization, while the development team is responsible for delivering the software. We break down each team, their needs, and challenges in more detail below.
platform team
The formation of the platform team is a key factor in the success of the internal developer platform within the organization, and the mission of the team must be clear and defined. By defining the platform team as a separate entity within the organization, their focus becomes centralized, which should reduce some of the transactional burden that their previous roles within the organization might have brought on. Evan Bocher emphasized again.
"The platform team builds, deploys, monitors, and is on call for the platform components and underlying platform infrastructure.... Ideally, the platform team doesn't even know what applications are running on the platform, they are only responsible for the platform services themselves Availability."
In the construction and maintenance of the platform, the platform needs to adopt a product thinking. We'll dive into this further down the blog.
Operations team
Traditionally, operations teams are responsible for some key elements of an organization's IT infrastructure. Unlike a development team, which may have a handful of concurrent projects, an operations team typically has a much larger scope of work, managing multiple environments, databases, networks, cloud infrastructure, and the many other elements that make up a software solution.
At the same time, the operations team is also responsible for the real-time environment of the organization, where consumers and internal users typically interact with the company on a daily basis. This requires an interesting balance between enabling the development team and "keeping the light on" to keep the business running. These teams typically work on a first-in-first-out (FIFO) basis, managed by a ticketing system, with failures taking precedence over other tasks.
The 2020 DevOps report highlights that effective DevOps organizations need to invest in internal developer platforms to enable developer self-service and reduce project and transactional load on operations teams. Many organizations unknowingly begin the process of providing internal developer platforms to teams. Organizations will start to standardize on specific clouds, or deploy to specialized container platforms like Kubernetes or Openshift. On the road to building an internal developer platform, organizations play one game after another of breaking dependencies in an attempt to improve the delivery of software throughout its lifecycle. " If you need to release faster, you play the game of unblocking and removing bottlenecks, and build a strategy to address the root cause," writes Jan Loeffler, former platform director at Zalando.
In his talk at AmbassadorFest, Gene Kim, author of The Phoenix Project and The Unicorn Project , provided some useful metrics that operations teams can use to understand the effectiveness of their internal platforms. Daniel Bryant at Kim was quoted as saying on Twitter.
"For operations teams, a good measure is how many 'thanks' you receive on a regular basis from the application delivery team. The ultimate goal is to resolve recurring roadblocks, reduce deployment friction, and make it easy to deliver value to customers" @RealGeneKim speaking at #AmbassadorFest pic.twitter.com/bQfpAPvPA
— Daniel Bryant (@danielbryantuk) November 17, 2020
development team
The core team that benefits from an internal developer platform is the organization's development team. Development teams often have huge tasks, they bring new features to market, or build the core internal systems of an organization's day-to-day business.
Development teams often need to wait for operations or DevOps teams to create environments for them to deploy and test their applications. Without a centralized platform responsible for CI/CD of a specific application, development teams tend to choose what works best for them. This results in "limited control or audit capabilities across the organization", explains Jan Loeffler . This often results in a lot of tool sprawl throughout the organization as individual teams adopt and build their workflows on the tools they know best or happen to love. In addition to the tool sprawl this can create, it can cause a lot of problems for organizations with strict regional or PCI requirements.
At KubeCon North America 2020, many attendees highlighted developers' need for infrastructure self-service, Dave Sudia said .
In the context of building a platform, app developers are key customers, and usability is an important part of the developer experience. The value of cloud-native platforms will not be fully realized unless developers have the ability to quickly and securely configure how the platform runs their services—and at the same time configure how applications are released to end users.
How to get started with the internal developer platform
Typically, teams formalize and standardize approaches to CI/CD, infrastructure as code , and Kubernetes first. These technologies form the building blocks of most in-house development platforms. Establishing the platform as a product is a key component of building a successful internally developed platform.
Evan Bottcher highlights three key prerequisites for building a successful IDP .
- A platform is a product that requires a long-term and stable product team responsible for building and running it.
- You must be willing to offload some or all of the responsibility for running the application to the application team, rather than centralized operations and support.
- Third, you must be willing to trade off strict execution consistency with the freedom and responsibility you give to the autonomous application team.
Meanwhile, Micheal Coté, in his report on "Business Bottlenecks, " highlights why a product approach is key to success, establishing the internal developer platform as a product.
A product approach looks at the entire lifecycle of software: is the software useful, does it help customers and users, and thus the business? Everything revolves around gathering customer and market feedback and constantly changing the software accordingly.
While this is written for companies whose business depends on delivering software, it applies to internal products as well, giving teams a task to manage their deliverables as if they were interacting with external customers.
Camille Fournier writes in her Medium article "Products for Internal Platforms "
Whether you are a platform engineer, engineering manager, or PM, remember that you still need to strategize your platform offering with a customer focus. Without a clear strategy to demonstrate impact and value, you end up being overlooked, understaffed, and no cool new technology can fix that.
Key Components of an Internal Developer Platform
An internal development platform (IDP) is a collection of tools and systems that are tightly coupled to provide a consistent experience for development teams.
These platforms are often unique, as are the teams that build them, but there are components and patterns that are seen across many different businesses. The team at Internaldeveloperplatform.org has compiled these into a neat list (application configuration management, infrastructure orchestration, environment management, deployment management, role-based access control). We'll delve into each of these and highlight some of the key areas.
Application configuration management
Managing the configuration of an application in many different environments can easily become complicated, especially when the application is composed of a number of different services and platforms. Internal developer platforms typically manage application configuration in the same way as code: maintaining application configuration through the use of a source control platform allows for several key functions, such as version and change management.
As the complexity of the application increases, so does the complexity of the configuration required to run, deploy, and manage the application. By extending the scope of configuration stored in the SCM, it allows configuration of external dependencies from a central location and version management of their associated applications.
infrastructure coordination
Internal developer platforms need to be compatible with existing and future infrastructure within the organization. This is achieved by building an extensible platform. Internal developer platforms typically have extensive integration across an organization's toolchain, including pipelines, clusters/servers, networking (DNS, firewalls, routing), registries, artifact repositories, and more.
Ideally, an internal developer platform becomes the driving force behind infrastructure as code, allowing components in a solution to be defined and managed programmatically. Typically, individual teams or DevOps teams have built and deployed their infrastructure through Terraform or similar. However, integrating existing scripts into the internal developer platform allows teams to use directories with known schemas.
environmental management
Often, creating a new environment is a mixed challenge between platform capabilities, team bottlenecks, and sometimes even cost constraints. Teams often need to wait days or weeks for an environment, even just to test small things. The internal developer platform handles the new application environment in a holistic manner, bringing together all the dependencies of the application to run in a single environment. This enables development teams to access a self-service environment when needed. This greatly reduces bottlenecks and enables development teams to deliver faster.
By leveraging this capability of an in-house development platform, the benefits far outweigh the need for a new test environment for the development team. It allows teams to bring up the entire application stack and all its dependencies when needed, and destroy them when no longer needed. This is often particularly beneficial in cloud environments, where service usage is based on a consumption model, and large environments, such as performance testing environments, tend to be expensive to idle.
deployment management
Delivering software to consumers is a critical role for any development team within an organization, and the need for rapid delivery is a well-known challenge. The adoption of continuous integration and continuous deployment has given development faster and more frequent deployments, which often come with their own challenges and issues.
By bringing an internal developer platform into the development lifecycle, it becomes the central point for all automated deployments to target environments. The internal developer platform becomes the automated automaton responsible for the version deployed, and related projects around the deployment. This integration is usually done by using webhooks .
As the application and related elements are deployed, the internal developer platform typically provides a centralized point for debugging of all deployments, serving as a centralized point for application versions, allowing rollbacks to be performed from the same location as the deployment.
Role-Based Access Control
Role-based access control (RBAC) is a factor that cannot be ignored, and one that cannot be ruled out by any platform, as multiple teams will utilize a shared platform. An effective RBAC policy will limit the scope of interactions that individual teams have with the platform, and members can also be segregated based on their roles within the organization.
While governing which teams are allowed to interact with the platform, it also limits the blast radius that unauthorized individuals can gain. In their presentation at Kubecon EU 2021 , Ellen Körbes and Tabitha Sable delved into some of the risks associated with flawed organizations' Kubernetes RBAC policies. A quote from the meeting was: "We are made of stars, but your RBAC shouldn't be", meaning that there should be no open access to systems or resources in an environment.
in conclusion
Finally, an internal developer platform is a key element of an organization's digital transformation and growth. By allowing development teams to focus on building solutions that delight customers and grow the company in its target market. However, like any project within an organization, it needs to be measured to understand its impact on consuming and building teams. In-house development platforms are no exception in this respect.
The biggest driver of a successful internal developer platform is adopting a product mindset in the creation and management of the platform, by gathering feedback from end users (developers) and incorporating that feedback as the platform grows.
At each step of the journey, the key is to find the next task or problem that takes the attention of the development and operations teams away from their deliverables. For operations teams, this empowers them to tackle real business-critical problems, and for development teams, it empowers them to build features or products that ultimately grow the business.
