My journey into platform engineering began around two years ago, when I found myself in an organization in need of streamlining its process for testing new products. We chose barebones Kubernetes, opening up a vast new realm of responsibilities, including certificates, secret management, routing, and deployment management, which went beyond just maintaining the technical infrastructure. This experience made me deeply understand what it means to be a part of a platform team and began my study into the theory and principles of platform engineering.
The grandest tapestry is woven from the smallest threads
In the tech world, we often find ourselves trying to emulate the massive IT corporations with their sophisticated implementations. However, the truth is you don't necessarily need what they have - and getting there requires enormous resources and effort. Instead, I believe in the approach of tackling the most value-adding tasks first. During my first year as a professional software developer, I remember being fascinated and immensely impressed with some tool that my colleague had made. It was a Django-based web application that he had configured to manage AWS VMs and automating repetitive tasks. While I didn't consider it a developer platform at the time, the value it added was immediately obvious, and our efficiency would have suffered greatly without it.
Platform engineering, in essence, revolves around the developer experience. But how do we chart the path to get there, particularly with the overwhelming list of tasks and improvements that comes with the role? That's where I found Manuel Pais and Matthew Skelton's book Team Topologies insightful. They define a platform as anything that helps reduce the cognitive load of developers - even something as simple as a checklist or a wiki page. Their perspective prompts us to ask ourselves: What do we want our development platform to achieve?
There is no lower treshold defining what constitutes a platform. Every organization or team has workflows that should be codified, automated, and streamlined, and the minute you start with this, the development platform is conceived. However, a more advanced platform requires a significant investment in time and resources, requiring a careful balance of usefulness and benefit. I suggest a strategy of gradual, iterative building - starting with the developers themselves. A conscious effort needs to be put into figuring out overarching requirements and not just making ad-hoc improvements. And this process is something that should be done in every tech endeavour, no matter the size.
Getting There™
However, as the platform ambitions increase, dedicated platform engineers might be necessary. And here's the crux: the strategy lies in focusing on prioritization, deciding what not to do now. The laundry list of potential improvements is practically infinite, and it's important not to lose sight of the platform's primary purpose: serving the developers.
This brings me to a crucial warning: avoid building the platform in a vacuum. The platform should not become something foreign, enforcing rules, technologies, and workflows that don't fit developers' needs. Instead, it needs to evolve from the demands of stream-aligned teams. This avoids the disastrous fate of platforms that end up under-utilized or simply unused due to lack of buy-in or involvement from developers.
In conclusion, developing a platform is about balancing provided tooling, platform complexity, and resources. It involves continuous, iterative improvements and maintaining a dynamic equilibrium between developer needs, business requirements concerning compliance regulations, security requirements, and service resilience. Remember, it's not about ticking off checkboxes of tools or workflows, but about fulfilling what your organization needs. This means focusing on the outcomes and capabilities of what you're implementing and ensuring it aligns with the needs of your developers and organization.
