Companies rely on high-performance development teams to react quickly to changing market conditions and deliver new products and features to customers more quickly. Such teams are characterized by being small and independent and doing their work largely or completely independently of other teams – they even make most of the decisions themselves, however, their flexibility and development speed must always remain in line with company guidelines, so that security, quality and reliability are guaranteed.
Advertisement
- The increasing complexity of the cloud-native technology stack places a higher cognitive load on development teams.
- Internal developer platforms provide tools, services, and artifacts to reduce complexity and make it easier for development teams to build well-structured applications.
- The Decentralized Developer Platform is a specialized version in which experienced development teams use curated patterns to deploy and operate applications in their own environments.
Developers typically experience the need to comply with company requirements as a breaking factor for their development work – and the list of non-functional requirements keeps growing. At the same time, the cognitive load on teams has increased as they deal with the complex technology stack for building and running cloud-native applications. Companies can reduce this dissonance through platform engineering. The goal: to massively simplify software delivery for product teams. An internal developer platform (IDP), hereafter referred to as a developer platform, forms the basis for this. It provides a series of self-service services that development teams can consume as easily and automatically as possible.
Robert Hoffman is a Senior Solutions Architect at AWS and supports companies moving to the cloud. He is passionate about observability, infrastructure as code, and developer productivity.
Judge in November 2024 IX And dpunkt.verlag CLC Conference – Persistent Lifecycle/ContainerConf – at the Congress Center Rosengarten in Mannheim. Every year since 2014, the event has addressed the most important questions related to Continuous Integration (CI), Continuous Delivery (CD), Dev(sec)Ops and GitOps to provide answers, information and support for everyday project life. This time, from November 12 to 14, the CLC will focus on AI-supported DevOps, security and FinOps as well as sustainability.
Highlights of the programme
Anyone interested can register until September 23 for the early bird price of 1,049 euros To registerThe workshops cost 649 euros (all prices plus VAT).
This article explains how platform engineering evolved from the DevOps movement and what types of developer platforms there are. Special attention is paid to decentralized developer platforms. They enable maximum organizational scalability and self-service and also promote ownership of the development teams involved. An overview of the guiding principles and required technical capabilities of decentralized developer platforms completes the article.
The origin of the developer platform
Companies have been building internal developer platforms for years, even before the term and concept became established in the IT industry. For example, Amazon Web Services (AWS). Cloud platform engineering is being aptly talked about since 2019 when building platforms in the cloud. AWS describes this as adapting the default configuration of AWS services to corporate standards. The customized services are then offered to internal customers (development teams) as self-service products and are continuously improved.
The origins of platform engineering can be traced back to the DevOps methodology. The “you build it, you run it” paradigm was coined by Amazon CTO Werner Vogels in 2006. urged developers to worry about the day-to-day operations of their software and, ultimately, their customers. This began a movement to give development teams more responsibility for the lifecycle of their applications – from writing the code to deploying it to production. At the same time, the complexity of applications and the technologies used also increased: for example, development teams began breaking down monoliths into microservices and running them on distributed platforms such as Kubernetes, with infrastructure and deployment defined “as code.” Additionally, they chose cloud services and software-as-a-service (SaaS) to reduce undifferentiated, cumbersome operational tasks and improve the user experience through low latency, global availability, and additional features.
The adoption of these technologies and the development of cloud-native applications helped teams reduce the time it takes to release new software (versions) and meet the growing expectations of users. In turn, the cognitive load of integrating and running applications increased (see Figure 1).
The constant use of new technologies and methods for software development in companies has increased the cognitive load on developers (Figure 1).
Platform engineering reduces cognitive load by providing tools, services, and artifacts, allowing development teams to focus on product development, ideally with shorter lead times and improved application quality. The specific definition of quality depends on the context, but a common method is Well-Architected Framework from AWSwhich provides guidelines for developing and operating secure and efficient applications based on six pillars (see Figure 2). A highly automated self-service developer platform is beneficial for both the platform teams developing and maintaining it and the users – development teams. Platform teams spend less time onboarding new teams and processing tickets, giving them more time to improve the developer experience when using the platform. Development teams can request resources and services as needed and focus more on product development due to the reduced cognitive load.
Internal developer platforms provide tools, services, and artifacts that help developers build better applications. IDPs also contribute to reducing cognitive load (Figure 2).
Transition to a decentralized operating model
A company typically offers one or more operating models for building and running applications, and these determine the features of the developer platform. A key feature defining the operating models is the division of responsibilities between developer and platform teams:
- In a centralized provisioning model, responsibility for the architecture, deployment, and management of the infrastructure rests primarily with a central platform team. Developers request resources via a ticket, which is processed manually by the platform team – which can take some time.
- Platform-based Golden Path Model An approach that allows development teams some customization while ensuring some consistency by following a set of standards. In this model, platform teams establish preferred standards with meaningful guidelines, guidelines, and best practices in the form of some specific architecture. Development teams use these specifications as a “golden path”. If developers are to be given even more freedom and self-service options, platform teams provide additional services through a clearly defined interface that enable application configuration and deployment. Typically these are one or more managed container clusters, where platform teams manage the infrastructure while development teams can use the cluster’s API to run containers.
- In the embedded DevOps model, more responsibilities shift to development teams when shared or dedicated DevOps engineers join the team. Using central platform standards, DevOps engineers implement tailor-made infrastructure for individual teams, which they can further customize as needed.
