Platform Engineering in 2023

As discussion of developer platforms reaches a fever pitch, the industry still has not converged around a single definition of "platform".

To get a variety of viewpoints, invited a small group of practitioners in the cloud-native development space to join Ambassador's Head of Developer Relations, , to discuss what developer platforms actually are, why platforms are a hot topic now and where these platforms are heading. The group was made up of Humanitec's CEO, Kaspar von Grünberg, nesto's Director of DevOps, Mathieu Frenette, and Syntasso's Chief Operating Officer, Paula Kennedy, each bringing very different experience to the discussion.

Platform engineering, growing fast but relatively new, has not matured to the point that everyone agrees on what a "platform" is. Nevertheless, the idea of building one's own platform to create a "golden path" for developers, reducing complexity, fostering self-service options and increasing speed to production, is driving the platform discussion. With this in mind, what is a platform?

Nesto's Mathieu Frenette, coming from a DevOps point of view, defined a platform as "everything that we can provide as tools, components and foundations to help developers do their job more easily, faster, and ideally with more robustness, predictability, repeatability and confidence." Kaspar von Grünberg, CEO of Humanitec, provided a similar definition, …"a platform is the sum of all tech and tools that a platform engineering team binds together to pave a golden path or paths. Developers leverage this path to self-serve with low cognitive load. That is important to me because it drives standardization by design for the respective organization."

Syntasso COO, Paula Kennedy, cited the desire to create a curated developer experience – whatever that might mean for a given organization, as no single definition fits all companies or needs. "We want to provide just enough to give developers what they need to get the job done – enough capabilities that developers can go fast without worrying about things like infrastructure or security. Providing a good developer experience via a developer platform is about never giving a developer too many choices or adding to cognitive load."

How to start with platforms without a single definition of a platform

Where should organizations begin their platform journeys, if no single definition of a platform exists. Podcasts participants were keen to highlight that this is exactly the point. An organization is free to assess and examine its own needs without getting locked in or having to accept an on-the-shelf and inflexible solution. Several key elements should be kept in mind:

Design with platform-as-commodity in mind

Mathieu insisted, and other podcast guests agreed, that platform design is not about reinventing the wheel. It's about, as Paula described, assessing what is commodity and what is unique about the platform you want to create. If you know you struggle with integration testing, find an existing tool to ease the struggle. If configuration management isn't your specialty, find a solution that relieves you of this burden. Focus the majority of effort and ingenuity on delivering on your unique value.

A combination of following best practices and figuring out the 90-95% out-of-the-box solutions to balance with the unique 5-10% that is your "special sauce" will pave a golden path while providing the freedom to go off-path as needed. By drawing on existing components and tools to solve "commodity problems", you have more resources for bigger-picture or truly unique platform issues.

Think about platform engineering value

Investing in platforms, when planned, will require some justification. All three podcast guests described situations where developer or ops teams have accidentally created platforms, or in which teams didn't communicate internally and ended up with multiple platforms that never solved for their purported need. This "rogue" development frequently happens when organizations have not yet realized the need – the space is, as Kaspar explained, evolving and still immature.

And when they do realize the need, there is not enough data to understand the value of the platform being built and thus approve the investment in platform-building.

Before ever getting started, Paula advocated, it is critical to understand what need(s) the platform aims to meet and define this clearly. At a high level, providing value to the business is the bottom line, but how does an organization get there?

Paula described a workshop in which her organization mapped out the complete journey from application idea to production, and each stakeholder team added in their steps and dependencies to create a clear picture of what steps took the most time, what could be cut, and what steps are actually important to stakeholders. Removing assumptions by mapping the journey enabled a clear view of a platform's value before ever taking any action at all.

Extend platform engineering value to ROI

Once the value and its component parts are understood, it becomes easier to justify costs and calculate a potential return on investment. Kaspar explained how he proposes writing down and calculating the effort and time involved in all activities beyond simple image updates, and using these figures to justify the contribution the platform engineering team and platform itself contribute to the business. Some of these factors are technical, such as the frequency of X activity every 100 deployments and how much time developers and ops teams dedicate to these activities.

Others, as Mathieu pointed out, are less cut and dry, "Some development activity is very complicated, and this takes a toll. That is, it takes time to run, it is difficult to set up when you want to troubleshoot, it is complicated to assemble and configure. By extension, it is extremely difficult to onboard new developers because of this complexity, and we end up losing developers because of this complicated work environment. All of these factors are costs to the business that need to be woven into the ROI equation. How much does the platform cost, but conversely, what is the cost in lost time, developer turnover, etc., if we don't invest in a platform?"

Get the big picture on developer platforms

If the overarching big picture for platforms is to deliver value to the organization by getting value into the hands of customers, how can developer platforms support this?

Delivering real value from a platform depends largely on creating a good developer experience in order to ease cognitive toil and help get software shipped faster. Yet, in developing platforms, it is too easy to get bogged down in the day-to-day. Mathieu explained, "With platforms, people are too often absorbed in their daily work and immediate problems, losing the bigger picture. One key to building and making a developer platform successful is having a platform team that can take a step back from the daily noise and figure out the value stream, bottlenecks and solve at that level, routinely bringing in a fresh perspective."

Another key to stepping away from the daily grind is taking other perspectives into account. Paula recounted experiences in which different teams failed to speak to each other, and were not only creating siloed, duplicative platforms, but were not talking to product teams, looking at user research or validating that what they were building would be used. Platforms that succeed look at the big picture,

knowing that things will scale up, and the limited scope one team brings to a platform won't serve the demands of growth or cross-functional use.

Conclusion: Standardize the platform; innovate with exceptions

Golden paths, Kaspar argued, are great, as "standardization forms the lowest common tech denominators, clearing the way for individual freedom where needed. We cannot get too hung up on the idea of not getting locked in, as Gregor Hohpe has argued, because avoiding lock-in is a kind of lock-in. Instead, focus on the standardizations that reduce complexity and help developers move faster."

Paula agreed, "Standardization is how to gain economies of scale and scope, helping organizations reap many benefits."

Mathieu's experience aligned with Kaspar and Paula's arguments. He explained that golden paths should cover most use cases, but should enable exceptions as needed to prevent getting locked in golden cages. "We make exceptions but afterwards go back and figure out how to introduce that exception into the , maybe make it a new standard. In our case, when we introduced Kafka as an alternate way of doing asynchronous messaging, we decided to make it the new standard. Exceptions are important - for us, they drove innovation and allowed us to move forward."

Listen to the full conversation below

S03E01: Platform Engineering in 2022 - Onramps, Self-Service, and Standardization