Organizations must be agile and innovative to stay competitive in today’s software development era, which has led to changes in how applications are built, deployed, and managed.
This necessitates the transformation of static CI/CD setups into modern Internal Developer Platforms (IDPs) that provide developers with the tools needed to innovate and move quickly.
While every platform looks different, specific common patterns emerge. To help simplify things, I’ve consolidated the platform designs of dozens of setups into standard patterns based on real-world experiences, which have been proven to work effectively. By adopting these patterns, organizations can create IDPs that keep them ahead of the competition and deliver innovative applications faster.
This diagram provides an overview of one reference architecture for a dynamic IDP using AWS EKS, RDS, Backstage, Humanitec, GitHub Actions, Terraform, and several other technologies.
Design principles.
01 Focus on the user. The most important customers of a developer platform
are developers. Developers need to be heavily involved in the design,
prioritization of features, and testing to ensure the platform is fit for purpose
and fully self-service.
02 Run your platform team like a start-up. Establish a small central team that
owns the platform and is responsible for marketing it, ensuring it is easily consumable and fulfills developers’ needs.
03 Build golden paths vs cages. Developers should be free to choose their
abstraction level. While your IDP should provide a set of golden paths for developers to follow, it should never force their use.
04 Drive standardization by design. Enabling self-service means platform
engineers must define how to vend resources and configuration. This ensures
every resource is built securely, compliant, and well-architected.
05 Implement Dynamic Configuration Management. Dynamic Configuration Management significantly reduces config complexity and enforces standardization by continuously generating app and infrastructure configs with every single deployment. This allows you to enforce policies and standards with every git-push.
06 Let developers decide on their platform interface. The developer
platform should never break your developer’s workflow or force them to use a
specific interface. To support this, a code-based workflow by default works
best, with the option to use a UI, CLI, or API.
07 Keep code as the single source of truth. This ensures everyone is working
from the same version, reducing the risk of errors.
08 Assume a brownfield scenario. Use tools that have already been
productized and adopted by the organization (such as backlog management,
CI/CD toolchain, and container platform) and let the existing teams pursue
integration through plug-ins into the platform. Where applicable, organizations
should use open-source tooling and a cloud-native approach.
