Photo by CHUTTERSNAP on Unsplash

One Platform, Infinite Possibilities: The Era of Connected Infrastructure

This article explores the transformative potential of Internal Developer Platforms (IDPs). It illustrates how they can reshape software development by streamlining processes, fostering collaboration, and significantly enhancing efficiency and innovation within your organization’s developer teams.

IDP: Internal Developer Platform not Identity Service Provider

Consider the modern software developer who is no longer just a coder writing software, but a navigator of a vast sea of technologies. For instance, creating a service for an e-commerce checkout process is more than just integrating various payment providers. It involves managing code collaboration, automated tests, continuous integration and deployments, service containerization, the orchestration of these containers in different stages using engines like Kubernetes, monitoring the checkout service at all stages, creating alarms and dashboards.

Each step requires different infrastructure providers, programming languages, and automation technologies. This complexity makes it crucial for developers and organizations to continuously aim for optimal resource utilization and efficient processes.

The transition to DevOps has improved teams’ ownership of their products. However, it has also burdened them with technologies that are essential but not directly tied to a customer’s value offering. Recognizing this issue, many organizations have started to reduce developers’ workload by forming teams dedicated to enhancing the Developer Experience. This approach essentially creates a centralized source of best practices, standards, and templates. These resources enable product developers to focus more on the core task of software development; writing software.

By combining resources from the Developer Experience, tech organizations have adopted what is described as platform engineering. This concept involves creating an internal foundation of standards, infrastructure, resources, and components for use by anyone in an organization looking to deploy or develop services and products.

Introducing the Internal Developer Platform (IDP), an output of platform engineering. The scope of the IDP can vary depending on the definition. For instance, “internaldeveloperplatform.org” highlights the use of a GitOps process, while Microsoft offers a slightly broader interpretation. However, some characteristics are common across definitions:

1. The platform engineering team is responsible for the IDP.
2. IDPs standardize the configurations of resources, components, or infrastructure. This standardization offers a guideline to how an organization creates digital products and services.
3. An IDP provides self-service capabilities for all sorts of resource provisioning, empowering developers by minimizing dependence on centralized platform teams.

The high-level idea of Internal Developer Platforms: Platform Teams provide “managed” components for Product Teams to consume.

Case Study: A Real-World Application of Internal Developer Platforms

Let’s talk about our learnings of building IDPs by examining a fictive company called “Ziggy”, an e-commerce platform specializing in unique and quirky gifts and gadgets. Business has been good for Ziggy over the last few years, enabling it to carve out a substantial niche in the market for unusual and innovative products. This success allowed the company to expand its tech organization to 2,500 people. However, this growth also introduced challenges in coordinating development efforts and managing a multitude of technologies.

From Chaos to Cohesion

As the tech division of Ziggy rapidly grew, it faced significant challenges due to prolonged development cycles, inconsistent processes, and inefficient allocation of resources. Developers found themselves entangled in a complex web of independent “platform-provider” teams, each responsible for managing infrastructure and services, like databases, servers, and network resources. These elements are crucial for developers building and deploying applications, yet the lack of a centralized system for managing these resources resulted in coordination and efficiency issues.

Without a centralized overview of the available infrastructure, services, and their corresponding providers, developers had to navigate through a maze of these provider teams. Each team had its own offerings and processes, significantly slowing down the development process as developers need to deal with manual ticket operations, endure long waiting times, and put in extra effort to manually coordinate the interdependencies of their infrastructure and services. These hurdles often led to delays of more than a week for developers to access the necessary infrastructure and services. The mounting frustration and delays among Ziggy’s growing tech division has been calling for a unified solution.

Bob the dev struggling to find, request and coordinate necessary resources to build and deploy his application.

Efficiency through Automation

Automation efforts were, to some extent, already in place at the provider level, employing tools like GitOps or RESTful APIs to streamline operations. However, automation is triggered only after navigating through manual ticket operations, and practices varied significantly across the provider teams. Some providers might utilize RESTful APIs for their operations, while others adopt GitOps strategies. This lack of consistency and standardization hindered the effective use of automation, preventing Ziggy from realizing the full potential of these technologies to simplify and accelerate development processes.

Establishing Cohesion: App Stack Orchestration Layer

Recognizing the challenges, Ziggy saw the need for an IDP that could build upon the existing automation solutions by integrating various tools and processes into a unified framework, creating a more interconnected ecosystem. A key component of this initiative was the introduction of an App Stack Orchestration Layer.

The App Stack Orchestration Layer introduces a systematic approach to streamline and automate the provisioning and deployment of infrastructure and services. It provides a self-service platform to simultaneously configure multiple infrastructure and service components which are then assemblied to a cohesive App Stack when requested by a developer. By offering a centralized endpoint for teams to either provide or configure their components, the layer facilitates the automatic triggering of GitOps or RESTful APIs based on the predefined standards, eliminating the inefficiencies of manual coordination. This standardization not only simplifies the developer’s workflow but also significantly reduces the time required to provision necessary infrastructure and services, thereby addressing the delays and frustrations that had plagued Ziggy’s tech division.

Overview of the App Stack Orchestration Layer

Anyone Who Doesn’t Do This Will Be Fired! How Standardization Enables a Push Architecture of Your IDP

When companies establish their IDPs for the first time, they typically form platform teams. These teams thoroughly assess the developers’ needs and then create a wrapper around cloud services using Infrastructure as Code tools like Terraform. This approach works well if your organization is solely in the cloud, and even better if it leverages only one cloud. However, Ziggy doesn’t. Its infrastructure and services are spread across two clouds and several on-premises server centers, similar to Walmart’s triplets. Over the years, Ziggy has created numerous services and infrastructure abstractions to meet the varied needs of different applications.

Legend has it that one day in the early 2000s, Jeff Bezos had a significant realization. He sent a memo to his employees, stressing the need to standardize communication across all services via network calls. He forbade cross-database reads, shared memory, and all other forms of inter-process communication. Bezos concluded his memo with a final point: “Anyone who doesn’t do this will be fired.” And so, AWS was born. As of Q4 ’23, AWS still holds the leading position in the cloud market, commanding a 31% share.

The point is not to threaten employees with termination if they don’t meet expectations. Ideally, you’ve created a work environment that fosters psychological safety, which can enhance team productivity (as referenced in this book). The focus here is on how Bezos didn’t introduce a new team to act as a bottleneck. Instead, he relied on the transformative power of his existing teams. We suggest a similar approach when building your IDP.

From our perspective, the developer experience improves when you provide standards that don’t hinder developers’ focus on software development. We call this way of architecting your IDP Push-IDP.

The Push-Enabled IDP Workflow

The following workflow and process diagram illustrates the interactions of providers and consumers with a MVP of a App Stack Orchestration Layer, centering around the registration of components and the creation of App Stacks. The workflow demonstrates how an IDP solution can be integrated in order to manage complex IT operations, reducing manual overhead, and ensuring that App Stacks can be provisioned in a consistent and repeatable manner.

In the case of Ziggy, the organization, opted for centralization of power within the App Stack Team. This team is authorized to package components into App Stack Templates for use by others. This decision for centralization was made by Ziggy to ensure that one team has overall responsibility. However, other organizations may have different concepts of trust and ownership, and thus might choose to allow everyone the power to create App Stack Templates. However, it’s important to discuss your organization’s Internal Developer Platform’s governance model from an early stage. This ensures stakeholder engagement and helps find the right fit.

1 — Offering Components

• Component Ownership: Providers own and manage various infrastructure or services, each represented as individual components (e.g., Component 1, 2, 3, etc.).
• Configuration Schema: Every component possesses a specific configuration schema that outlines properties consumers can configure.

2 — Registration

• Component Registration: Providers register each component’s configuration schema with the App Stack Orchestration Layer, typically through a (RESTful) Web API.
• Access Control: The registration incorporates an Access Rights Service for permission validation to retrieve pertinent provider information about services, platforms, and access rights.
• Schema Validation and Storage: The configuration schema for each component undergoes validation and is then stored in a database.

3 — Creation of App Stack Templates

• App Stack Templates: These are blueprints created by the App Stack Team (comprising internal members or advanced providers/users), showcasing combinations of components that can be instantiated to form App Stacks.
• Template Visibility and Request: App Stack Templates are made available for consumers to view and request.

Consumer Process

1 — Select and Request

• Template Selection: Consumers, who are responsible for creating or managing software, choose from the available App Stack Templates via a JSON/HTTPS interface.
• Filtered Access: An Access Rights Service filters the visible App Stack Templates based on the consumer’s credentials, platforms, and product access, ensuring appropriate template visibility.

2 — Provisioning and Orchestration

• Component Configuration: Upon receiving a request, each component is configured in line with the consumer’s specifications, validated against its respective configuration schema.
• Orchestration and Configuration: Valid configurations trigger the central App Stack Orchestrator, which assembles the App Stack by coordinating with the Provider’s automation tools/services (likely through RESTful APIs or GitOps).
• Cohesive Component Assembly: This process results in a cohesive set of configured, deployed, and functional components, collectively forming the App Stack.

3 — Creation of App Stack

• Resource Compilation: The App Stack materializes as a collection of instantiated components (resources), tailored to the consumer’s configurations.
• Deployment and Utilization: The final App Stack is a deployable instance, ready for the consumer to run their software applications.

Ziggy’s case study demonstrates the effectiveness of an advanced IDP solution, such as the App Stack Orchestration Layer, in establishing a intricate yet efficient workflow that bridges the gap between providers and consumers. The Orchestration Layer serves as a prime example of the transformative power of IDPs within the domains of software development and infrastructure management. Looking ahead, it is anticipated that the App Stack Orchestration Layer will incorporate enhancements, including REST endpoints, which will allow providers to update the status of components and enable consumers to inquire about the status of their App Stack. This feature is designed to close the communication loop, fostering a more dynamic and responsive interaction between providers and consumers, and thereby improving the management of App Stacks after deployment. This case study highlights the iterative process of developing an IDP that is customized to meet the specific organizational needs and objectives of Ziggy.

Looking Ahead: The Future of Connected Infrastructure

Embracing the era of connected infrastructure opens up limitless possibilities. IDPs, with their robust orchestration capabilities, are not merely tools; they are enablers of transformation, empowering organizations to handle the complexities of modern software development with agility and confidence. This strategic shift towards an orchestrated IDP marks a journey from chaos to cohesion, unlocking boundless potential in the realm of software development.

When thinking about establishing an internal developer platform, it is important to start by identifying the specific needs and goals of your organization. Consider the following steps:

1. Assess the current infrastructure & processes: Evaluate the existing infrastructure and processes, and identify pain points or areas of improvement. Understand the challenges faced by developers and teams when it comes to provisioning and managing infrastructure.
2. Define the desired outcomes: Clearly define the goals and objectives of the internal developer platform. Determine what you want to achieve, such as improved collaboration, increased efficiency, faster development cycles, or better product quality.
3. Engage stakeholders: Involve key stakeholders, including developers, IT teams, project managers, and business leaders. Understand their requirements, gather feedback, and ensure their buy-in for the platform.
4. Research available solutions: Explore different options for internal developer platforms, such as cloud-based solutions, containerization platforms, or Infrastructure as Code (IaC) tools. Consider factors like scalability, ease of use, integration capabilities, and security.
5. Discuss and communicate accountabilities: The success of your organization’s IDP relies on the providers you engage to offer components to developers. This can be achieved by establishing new platform teams that standardize and automate the provision of infrastructure and services. Alternatively, like in the case of Ziggy, existing teams can use newly established standardization methods to offer their automated services.
6. Design the platform: Based on the identified needs and goals, design the architecture, workflow and features of the internal developer platform. Consider aspects like self-service provisioning, automation, monitoring, and collaboration tools.
7. Implement and test: Implement the platform in a controlled environment and conduct thorough testing. Ensure compatibility with existing systems and validate that it meets the requirements defined earlier.
8. Start, Iterate and improve: Start with something to lay a solid foundation, continuously gather feedback from users and monitor the platform’s performance. Regularly assess its effectiveness and make improvements based on user needs and emerging technologies.

In summary, transitioning to an orchestrated internal developer platform represents a significant technological and strategic enhancement, guiding organizations towards a more cohesive, efficient, and innovative development ecosystem.

About the Authors

👩🏻‍💻 Amy is a consultant at Netlight Hamburg and cross-disciplinary tech enthusiast with a strong passion for developing cutting-edge, user-friendly and accessible software solutions for the web and beyond. Combining her background in Psychology and IT, she puts great emphasis on understanding the users’ needs, challenges, and motivation, ensuring the delivery of meaningful products and solutions.

👨🏻‍💻 David is a consultant at Netlight Cologne. He has a passion for coding, management, and transformations. He thrives on making a lasting impact through his work with people. His skills allow him to work hands-on at the code level, while also seamlessly interacting with C-Level stakeholders and others. Aside from his consulting duties, David conducts research on Digital Transformations and Digital Platforms at the University of Bamberg.

Disclaimer

Netlight is a leading digital consultancy company providing a full range of consultancy services from tech and data to design and management. Our 2000+ consultants in our Stockholm, Oslo, Helsinki, Copenhagen, Munich, Hamburg, Berlin, Frankfurt, Zurich, Cologne, and Amsterdam offices help to make aspiring digital leaders successful.