In today's fast-paced software development landscape, developer platforms have become essential for organizations striving to continuously deliver high-quality software more efficiently. Containers offer a consistent and scalable environment for developing, testing, deploying, and operating applications at scale. Many organizations embarking on their journey to gain advantages from leveraging containers, focus on building a Minimum Viable Platform (MVP), a Kubernetes-based platform. However, they neglect the four other areas required to extract value effectively. These often-neglected elements encompass container image lifecycles, onboarding processes, the developer's inner loop, and the development team's outer loop. These and the MVP make up the five container platform primitives.
The five container platform primitives: A holistic view
To extract the most value from container-targeted development, it is first necessary to have a comprehensive understanding of the five primitives of container platforms.
1. Minimum Viable Platform (MVP)
The MVP, founded on Kubernetes and integrated with key IT ecosystem capabilities like security, metrics, and logging, is where containerized workloads run and is the bedrock of a successful contemporary container strategy. It should be developer-focused and provide meaningful availability and the necessary capabilities to support the platform's development, testing, deployment, and operations of containerized workloads. An MVP should include availability, security, observability, operability, and useability capabilities. The MVP will evolve to accommodate future workloads and technological advancements. The evolution happens through iteration and customer feedback. The platform team becomes the "product team" doing continuous discovery of evolving customer needs. The key to continuously delivering the MVP is a dedicated platform team responsible for developing capabilities and operating the platform in alignment with organizational goals and technological trends.
It is not in the scope of this article, but it is essential to mention the role of a product manager on the platform engineering team. They are responsible for this continuous improvement by creating and monitoring the feedback loop.
MVP Definition: Put in basic terms, the minimum viable product, or MVP, is the simplest version of a product that you need to build in order to sell it to a market. The concept of the minimum viable product, or MVP, was first introduced by Lean Startup genius Eric Ries. He defines the MVP as: “The version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
2. Container image lifecycles
Managing container image lifecycles is crucial for maintaining a secure and efficient container platform. Successful organizations leverage robust automation for managing container image creation, static analysis, deployment, dynamic analysis, replacement, and decommission, which reduces human error and increases efficiency. Security must be paramount, keeping container images as small as possible, and ideally, the OS in the container must be immutable. This minimizes vulnerabilities, and implementing governance that ensures development teams regularly grab the latest organizationally certified container images created from vendor-provided source images ensures we reduce risk exposure.
Providing development teams with certified container images that are pre-patched and updated is one of the fundamental benefits of leveraging containers versus virtual machines or bare metal. A discoverable catalog of certified container images ensures that development teams can access secure and optimized images, which is just as crucial as automated lifecycle management.
3. Onboarding
Onboarding is a series of events that encapsulate the transition of developers and their workloads from their current platform onto the MVP. Often overlooked by organizations just starting their container journey, onboarding is a critical component of platform engineering. Remember that an empty platform is simply sunk cost; meaningful workloads must leverage the platform for an organization to realize value. A metrics-based process map that describes the end-to-end onboarding process helps identify bottlenecks and constraints, enabling targeted improvements and efficient investment of time and effort into improvements. Continuous improvement through a feedback loop is essential, as well as regularly reviewing and refining the onboarding process to meet the evolving needs of developers and the organization. Providing comprehensive documentation and support assists developers in smoothly navigating the onboarding process, reducing time and frustration.
Many organizations are beginning to leverage golden paths accessible via an Internal Developer Portal, to enable self-service onboarding, utilization of standards, and application of guardrails to reduce risk. An important capability of a platform is also automation of the application lifecycle in a prescriptive way - the golden path. More on that later.
4. Developer inner loop
The developer inner loop is the cycle of activities where individual developers write and test code, hopefully in alignment with a well-formed user story from the product backlog. Providing a meaningful local development environment is essential for developer productivity, satisfaction, and consistently delivering high-quality software. Equipping developers with the necessary tools and resources allows them to write, test, and debug code efficiently within their local environments, reducing the possibility of untested code getting into a shared development branch. Containerized local development environments enable organizations to provide consistent environments across development teams and Software Delivery Life Cycle (SDLC) environments.
This reduces the risk of bugs and defects introduced due to mismatched environments. Rapid feedback mechanisms in containerized local development environments enable developers to identify and resolve issues quickly during the inner loop and before the code hits the outer loop. Additionally, the inner loop should look and feel like the outer loop. The IDP should facilitate a smooth transition from local development to putting code into the lifecycle for testing and deployment.
5. Development team outer loop
The development team outer loop encompasses continuous integration and deployment (CI/CD) activities, starting with the merge of code written to implement a specific user story from the product backlog, often by an individual developer, and culminating in the verified deployment of the desired software into a production environment. Optimizing these processes is key to achieving faster deployment cycles, reducing change failure rates, and improving the quality and security posture of software delivered.
Many organizations are investing in improving their CI/CD processes due to the growing number of significant incidents attributed to attacks on and failures of the CI/CD processes of software vendors and in-house development teams. Secure software supply chain is the term that has come to represent well-formed CI/CD processes that aim to ensure and attest to the provenance of the bits and stages the bits move through as part of the CI/CD process. Metrics-based process maps are a great way to visualize CI/CD pipelines, enabling an organization to identify and address bottlenecks, defects, and risk areas and facilitating more informed discussions with development teams and leadership about opportunities for improvement.
Embracing declarative configuration with Secure Software Supply Chains and GitOps enhances transparency and security in deployment processes, ensuring an organization understands and has records of what is deployed where.
The best software delivery shops regularly assess and refine the development team outer loop to ensure they remain efficient and aligned with organizational objectives.
Internal developer platforms: Key components and design principles
Internal Developer Platforms (IDPs) provide a foundation for onboarding, developing, testing, and operating workloads at scale. They automate container deployment, scaling, and operations across clusters of compute hosts. As container adoption increases, automating the management of Kubernetes platform life cycle activities becomes critical. This includes automating tasks like cluster provisioning, configuration, integrations, scaling, patching, and updates. Well-formed container platforms provide tools and features to streamline these operations, extending native Kubernetes capabilities.
IDPs aim to remove the complexity of the underlying infrastructure and processes to provide developers with an easy button for a self-service first experience. Simplistically, an IDP makes it easier to use the MVP. MVP hosts & orchestrates the workloads; IDP makes it easy to leverage the MVP in a quick and safe way.
Internal developer platforms typically consist of several key components:
- Orchestration engine: The core component that manages the provisioning and configuration of infrastructure and applications. Solutions like Humanitec's Platform Orchestrator help streamline these processes.
- Developer portal: A centralized interface for developers to access platform services, such as development resources, environment provisioning, workload building, testing, verification and deployment, metrics and logs, and key components for observability.
- Golden paths: Automated workflows for building, testing, and deploying applications.
- Resource catalog: A collection of pre-defined infrastructure and application patterns that developers can consume.
- Policy engine: Enforces security and compliance policies across the platform.
IDPs are often structured into different plane levels, each fulfilling specific functions. While the particular structure can vary, standard planes include a Developer Control Plane, Integration and Delivery Plane, Monitoring and Logging Plane, Security Plane, and Resource Plane.
Example reference architecture on Red Hat OpenShift showcasing standard planes:
Note:
- Dev spaces (containerized local development environment) lives within the Developer Control Plane (inner loop) and can run Visual Studio Code with Dev Spaces.
- Outer loop - Integration & delivery plane, Secure Software Supply Chain would be here, Release Management.
- Container image life cycle management would live in the Security Plane. Actions would be performed in Integration & Delivery as well as Resource Plane.
Key design principles for Internal Developer Platforms include:
- Developer-centricity: The platform should be designed with the developer experience as the top priority.
- Self-service first: Ensuring developers and development teams can consume capabilities without waiting for someone or a team to respond to a ticket-based request.
- Automation: Automating repetitive tasks to reduce manual effort, increase consistency, and improve efficiency.
- Standardization: Making standardization effortless across key software delivery processes, including infrastructure provisioning and configuration, software delivery life cycles, and operational approaches.
- Continuous development: Internal Developer Platforms typically leverage the 80/20 rule and focus on making it easy to leverage organizational standards. This is why it is critical to understand not only your current consumers but also your future consumers. Organizations must add capabilities, such as containers, tools, golden paths, etc., to enable or entice new development teams to the platform.
The above architecture illustrates examples of internal development platform solutions, which provide tools for building internal platforms and automating developer workflows.
Integrating the five container platform primitives into the IDP architecture
An Internal Development Platform, IDP, makes it easier to extract value from a Minimally Viable Platform, MVP, founded on Kubernetes by ensuring the capabilities represented by the other four platform primitives are known and easily consumable. An MVP hosts and orchestrates workloads, increasing consistency and reducing operational overhead. An IDP makes it easy for development teams to leverage the MVP quickly and safely to minimize cycle time and change failure rate while increasing the quality of software delivered by making it easy to incorporate certified container images into SDLCs, making it easy to onboard new developers, development teams and workloads, providing access to tooling for the developer inner loop and development team outer loop. Integrating the five container platform primitives into an IDP is crucial for creating a comprehensive and effective platform. An IDP exists to make it easier for developers and development teams to create value by delivering high-quality user experiences. The ultimate goal is to make it easy to do the right thing by reducing complexity, ensuring the utilization of standards, enforcing guardrails, and promptly enabling the consumption of capabilities without requiring human intervention.
The following section outlines specific integration points and automation strategies within the IDP components, ensuring a cohesive and streamlined developer experience.
Extract value from the MVP
The IDP is the backbone that makes extracting value from the MVP easy. The IDP should automate the provisioning and configuration of core MVP components, such as base infrastructure, namespaces, networking, and initial security settings. This enables developers to begin deploying applications quickly without requiring manual setup or configuration and the knowledge necessary to complete those complex manual tasks successfully. A well-designed resource catalog within the IDP offers ‘golden paths’ and pre-approved and configured access to MVP capabilities, making selection straightforward and consistent.
Automated container image lifecycles
The IDP enables the creation, accessibility, utilization, and decommissioning of container images and integrates with CI/CD pipelines to ensure workloads are using the most up-to-date applicable container image at any given time. A well-formed IDP has automation that enables creating, scanning, and signing certified container images, static scanning for images during the workload build process, and dynamic scanning for containers running on the MVP.
The CI/CD system automatically builds the specific container image needed for the workload, tests it for vulnerabilities using integrated scanning tools, signs it, and stores it in a secure registry. The IDP control plane then manages the deployment of these images, ensuring only secure, up-to-date containers are used. The resource plane might employ Kubernetes-based tools like OpenShift to enforce policies that prevent using outdated or unverified images.
Streamlined onboarding via developer portal
The IDP should be the primary interface for onboarding developers, development teams, and workloads. Developers can use it to gain access, provision pre-configured development environments, and deploy workloads. Documentation, tutorials, and support resources are centralized within the portal, allowing developers to transition through the learning curve more quickly and return to delivering high-quality user experiences.
Developer inner loop enhancements through integrated development environments
The IDP supports the developer inner loop by integrating with popular IDEs and providing containerized local development environments. These environments are automatically configured with the necessary tools, dependencies, and configurations so developers can write, test, and debug code quickly. With a code-first approach, developers can make changes to their code and quickly verify the changes behave as expected. Rapid feedback mechanisms, such as automated testing triggered on code changes, ensure developers can quickly identify and resolve issues, decreasing the time required for inner loop cycles.
Development outer loop automation via GitOps
The IDP enforces a GitOps approach to managing the development team's outer loop. All infrastructure and application changes are managed through Git, and the IDP uses automated pipelines to deploy those changes to different environments. The declarative configuration ensures that the desired system state is always defined in code, and automated reconciliation processes detect and correct any deviations from the desired state. The integration and delivery plane manages these pipelines, triggering deployments based on Git events and automating the release process.
By embedding these integration strategies within the IDP architecture, organizations address the five container platform primitives and create a self-service, automated environment that streamlines software delivery and enhances developer productivity.
Internal Developer Platform governance: Policy, compliance, and security
An IDP is a great way to make it easy for platform users and workloads to maintain compliance. It can be used to enforce policies, processes, and tools to manage and control the use of the platform. IDPs can be a governance layer that promotes security, compliance, and alignment with organizational goals. Key aspects of governance an IDP can provide include:
- Policy enforcement: Enforcing resource usage, security, and compliance policies. This can be achieved through policy engines that automatically validate and alert on anomalies or even enforce policies without human intervention.
- Compliance: Ensuring that workloads meet relevant regulatory requirements and industry standards. This can include controls for data protection, access management, image and source code provenance, successful completion of certain stages of CI/CD processes and even capturing attestations and other logging for audits.
- Security: Implementing security measures to protect the platform and its workloads. This can include operations for vulnerability management, access control, and network security.
Internal Developer Platforms often provide features to automate governance tasks. OpenShift, for example, offers capabilities for policy management, compliance scanning, and security monitoring. These capabilities can be integrated into the IDP to provide a comprehensive governance solution. Features such as ACM (Advanced Cluster Management) and ACS (Advanced Cluster Security) offer frameworks to automate policy compliance and drift controls.
Internal Developer Platform adoption strategies: Change management and training
Successful IDP adoption requires careful planning and execution, along with a focus on change management and training. Key strategies for successful IDP adoption include:
Start with a pilot project: Begin by implementing the IDP in a limited scope, focusing on a specific team or application. This allows you to gather feedback and refine the platform before rolling it out more broadly. This limited adoption of the MVP will allow for iterative changes based on the developer community.
Provide comprehensive training: Train developers to use the IDP and its various features. This can include documentation, tutorials, and hands-on workshops. Leveraging an Internal Developer Portal like Red Hat Developer Hub, to provide a central location for developers to access documentation, tutorials, and other resources that enable effective utilization of the platform improves the developer experience by reducing cognitive load.
Focus on automation: Automate as many tasks as possible to reduce the burden on developers. This includes automating infrastructure provisioning, application deployment, and security configuration. Providing self service interfaces to the five container primitives makes IDP adoption seamless.
Establish feedback loops: Create a mechanism for developers to provide feedback on the IDP. This feedback should be used to improve the platform and address any issues or concerns. Some mechanisms for feedback include platform days where teams present to one another about how they are using the platform, net promoter score surveys and even office hours for helping teams leverage the platform. By keeping a pulse on current and potential users and organizations can appropriately invest time and effort in the areas at the right time.
Communicate the benefits: Communicate the IDP's benefits to developers and other stakeholders. These include improved productivity, faster time to market, and enhanced security. Tying these benefits back to business and developer adoption makes the value easy to realize.
Iterative development: An iterative approach to providing an IDP that encapsulates the five container platform primitives allows platform engineering teams to begin small and iteratively increase and enhance capabilities provided by the platform to expand adoption.
An IDP’s value is that it is built with code-first integrations, which allows it to grow the set of provided capabilities to enable the onboarding of an increased variety of workloads within the organization.
Benefits of the IDP architecture
IDPs address several key problems faced by organizations today:
- Slow Time to Market: The architecture reduces the time required to deliver new applications and features by enabling developer self-service and automating repetitive tasks.
- Ops Inefficiency: The architecture reduces the burden on Ops teams by automating infrastructure provisioning, application deployment, and other operational tasks. This allows Ops teams to focus on more strategic initiatives.
- Poor Developer Productivity: The architecture reduces cognitive load and increases developer productivity by providing a unified interface and a streamlined development process.
- Security vulnerabilities: The risk of human error and external threats.
The benefits of implementing an IDP are significant:
- Improved Developer Productivity: Developers can self-serve the needed resources, reducing dependencies and waiting times.
- Increased Ops Efficiency: Automating repetitive tasks frees Ops teams to focus on more strategic initiatives.
- Faster Time to Market: Streamlined development processes and automated deployments lead to faster time to market.
- Enhanced Security: Standardization and automation reduce the risk of human error and improve overall security.
- Standardization: The architecture enforces standardization across infrastructure provisioning and application configuration management, ensuring consistency, efficiency, and compliance.
Conclusion
Realizing the full potential of container platforms requires a holistic approach beyond merely establishing a Kubernetes-based MVP. By strategically integrating the five container platform primitives: MVP, container image lifecycles, onboarding, developer inner loop, and development team outer loop, organizations can create a robust foundation for contemporary software delivery. The Internal Developer Platform (IDP) serves as the linchpin in this ecosystem, streamlining the consumption of these primitives and empowering development teams to leverage the Kubernetes MVP efficiently and securely. The IDP accelerates software delivery, enhances developer productivity, and ensures compliance, maximizing the value derived from containerized applications through automation, standardization, and a self-service approach.
