Currently, platform engineering is a topic that is causing a lot of reactions in the vastness of the World Wide Web. Especially for customers from the enterprise environment, it leads to interesting side effects when DevOps teams suddenly turn into Platform Engineering teams. With this blog post, I would like to demystify the wording and show possibilities that arise from it.
But first, let’s go back a few years in codecentric’s history. To be more precise, to the year 2014. At that time, we had the idea of the Agile Software Factory, which was supposed to enable teams to quickly implement the idea of a software product. This includes the implementation of an entire toolchain for software development. In this way, we were already indirectly addressing topics such as developer experience and governance, without naming them specifically. Thus, deliverability was established in a relatively short time, at least with regard to a first increment. As I said, that was 2014!
Nowadays, we are dealing with many tools in the software development lifecycle. Especially in large companies, this leads to a problem, as each department brings its own idea about the software lifecycle into the mix. Consequently, it is worth thinking about unifying this large amount of tools. This leads to the idea of supporting developers with self-service approaches more and more. Over time, companies need more rules and guidelines for the development of products or even a platform. This is precisely the first lever that Platform Engineering would like to apply, in which the developers in a company are offered the opportunity to move along established paths or along a Golden Path, in order to focus again on the original aspect of software development – implementing ideas in a way that can be tested quickly.
Spotify also took the steps towards the Golden Path in 2014. This shows that codecentric was on the cutting edge with the idea of the Agile Software Factory, but was not yet able to summarize the whole topic into one term. One suspects that Spotify borrowed the term Golden Path from the Dune trilogy. According to the Dune Fandom explanation, the Golden Path represents an optimal path through the countless threads of cause and effect that humanity has encountered. This optimal path was what Spotify was trying to achieve in the spirit of growth at the time, so as not to lose speed in the development of software components. But it’s not about bullying a developer or enforcing standards. Rather, teams shouldn’t have to reinvent the wheel or make fewer decisions. Companies should also set up platform offerings with this in mind: as visible and tangible support for developers.
Thus, the idea of the Golden Path is not limited to CI/CD processes, but has the whole chain of deployment processes in the sense of platform engineering in mind, such as
– Adding environment variables and changing configurations
– Adding services and dependencies
– Rollback and debugging
– Setting up a new environment
– Adding/changing resources
– Implementing role-based access control
However, the focus here is always on the self-service aspect. This leads to an Internal Developer Platform, which, according to Evan Bottcher, is “a foundation of self-service APIs, tools, services, knowledge and support.” Such a platform is a corresponding second vector of platform engineering, which is now being used by a number of manufacturers.
A look at the tool landscape around platform engineering shows that two products are currently very present in the market: Backstage and Humanitec. In his last blog post, my colleague Jonas presented another tool, Crossplane, which I will not discuss in detail in this post.
Spotify has developed Backstage and made it available to the market as an open source product. However, as my colleague Pascal Sochaki has said,, Backstage should be understood more as a framework that enables companies to deliver a front-end to their internal development platform. For this purpose, Backstage offers the possibility of providing software components through software templates. In concrete terms, this means that a Git repo including Docker and pipeline files is created. After successful deployment, the component is then listed in Backstage. In addition, the framework can be extended by plugins to include further functionalities, also with regard to the visibility of the deployment.
In comparison to Backstage, Humanitec sees itself as a platform orchestrator and thus as the central unit of an Internal Developer Platform. It represents the basis for dynamic configuration management, which is described by the manufacturer as a Declarative Application Model. This model describes the workload of a deployment as agnostically as possible. A basis for this kind of the description develops straight with the Platform Agnostic Workload Specification (PAWS).
With Backstage, Humanitec and Crossplane, we now see different tools in the context of platform engineering. Their effectiveness is limited to visibility on the one hand and deployment orchestration of services on the other. But exactly these two points should be automated within the work of a developer and also the automation should be done in a simple way. Thus, these mentioned tools show a representative way to an Internal Developer Platform, which can guarantee the often mentioned Developer Experience.
Platform Engineering is thus not really a new idea, but rather considers the processes around CI/CD in the development of software end-2-end. Likewise, it is also about creating a kind of uniformity in terms of the tool landscape, the components and their corresponding use. This also requires communication between individuals and teams.
Let’s feel free to discuss this- What is your understanding of platform engineering? What are you already doing? What would you like to adapt to your situation?