Platform as a Product: True DevOps?

Platform engineering is taking the DevOps and infrastructure world by storm. Many consider it the natural evolution of the “you build it, you run it” paradigm at the foundation of DevOps itself. Gartner recently added it to its Hype Cycle for Software Engineering as one of the up-and-coming key trends in the industry.

The Gartner Hype Cycle for Software Engineering 2022 is published! Notable changes this year include Machine Learning Code Generation entering the Hype Cycle, many technologies at the Peak, and Microservices finally escaping the Trough of Disillusionment https://t.co/Eexx8YnXeg pic.twitter.com/KDWDt4NZ4e

— Mark O’Neill (@TheMarkONeill) August 11, 2022

The community around it has been exploding over the past two years. Nineteen Meetup groups popped up all over the globe, with individual groups like Platform Engineers Austin with more than 2,000 members. The Platform Engineering Slack has well over 5,000 engaged contributors, and this year the first PlatformCon was held in June, with more than 6,000 attendees on the Day 1 stream.

Some leaders in the cloud native space are calling platform engineering the DevOps killer. Sid Palas, host of the DevOps Directive, recently chimed in:

DevOps is dead 💀, long live Platform Engineering!

1) Developers don’t like dealing with infra
2) Companies need control of their infra as they grow

Platform Engineering (and Internal Developer Platforms) enable these two facts to coexist. Here’s how:

(1/n)

— Sid Palas (@sidpalas) July 26, 2022

All right, this might be getting heated already. Let’s take a step back. What is platform engineering anyway? Gartner’s Bill Blosen, senior director analyst, and Paul Delory, research vice president, describe it as “the discipline of building and operating self-service internal developer platforms (IDPs) for software delivery and life cycle management.” They explain that “platform engineering improves the developer experience, thus reducing employee frustration and attrition.”

While analysts and other established players in the industry are helping to define the overarching concept, there’s still some confusion when it comes to the core principles at the heart of this new discipline. If you look closely enough, however, it quickly becomes clear that the fundamental tenet of platform engineering is Platform as a Product.

Humanitec is the Platform Orchestrator at the core of your Internal Developer Platform. It lets platform teams remove bottlenecks by letting them build golden paths for developers. Developers self-serve the tech they need to deploy and operate their apps, driving productivity and velocity.

Learn More

The latest from Humanitec

Manuel Pais, co-author of the influential book “Team Topologies,” has been hammering at this for a while now: You need to treat your internal developer platform as any other product your engineering teams are building. A product mindset is essential in successfully designing and rolling out a platform across your organization. As Gregor Hohpe, AWS enterprise strategist and author, explained in his PlatformCon keynote, you can try to “be smarter than everyone else and anticipate all of their needs, or you evolve the platform based on user needs.”

That requires you to build a platform team that conducts user research and gathers user feedback from their internal customers, the developers. Building a tight feedback loop between the platform engineering organization and the development teams is essential to ensuring that the IDP continues to be useful for all users. More on that later.

It is important to remember that platform teams are not your DevOps or infrastructure team. Back in 2017, Thoughtworks Technology Radar pointed out that “organizations that consider establishing such a platform team should be very cautious not to accidentally create a separate DevOps team, nor should they simply relabel their existing hosting and operations structure as a platform.”

In his latest Gartner report, Manjunath Bhat, focuses on three key pillars around why and how to build your IDP:

1. Improve developer experience by building internal developer platforms to reduce cognitive load, developer toil and repetitive manual work.
2. Platforms don’t enforce a specific toolset or approach. It is about making it easy for developers to build and deliver software while not abstracting away useful and differentiated capabilities of the underlying core services.
3. Platform engineering teams treat platforms as a product (used by developers) and design the platform to be consumed in a self-service manner.

Let’s dive deeper.

How to Apply Product Management Best Practices When Platforming Your Setup

What does Platform as a Product really mean in practice? It means you should apply the principles and best practices well established in traditional product management.

1. Do user research! At PlatformCon, Michael Galloway of Netflix laid out how to interview engineering teams to get the right amount of context around their workflows and challenges to ensure you build stuff people will actually use. He also shared some docs with questions in the Platform Engineering Slack channel.

2. Come up with a roadmap — not to be confused with a backlog of “nice to haves” — that is aligned with your mission statement. A clear mission and vision is key.

3. As mentioned above, it is important you establish early on that your platform team is not to be seen as an extension of the site reliability engineering or ops organization, but rather as its own product team, working to ship an application (the IDP) to its internal customers (the developers).

4. Build a compelling product. What makes a platform compelling you ask? Here are a few ideas by Evan Bottcher from Thoughtworks:

• The platform is self-service for the overwhelming majority of use cases.
• The platform is composable, containing discrete services that can be used independently.
• The platform does not force an inflexible way of working on the delivery team.
• The platform is quick and cheap to start using, with an easy on-ramp (Quickstart guides, documentation, code samples, etc.).
• The platform has a rich internal user community for sharing.
• The platform is secure and compliant by default.
• The platform is up to date.

Ultimately, the delivery infrastructure platform is compelling when it is easier to consume the platform capability than building and maintaining your own thing.

5. Market your platform. Both to build and especially to roll out your IDP. You need a strong platform team that feels responsible for their product. Good product management not only refers to building a great product, it also means good product marketing. You need to win over all stakeholders: the executives for project support, the infra teams (pro tip: Position the platform as something that helps them in their day to day and does not replace them), and finally your end users — the developers.

For more pro tips by someone who actually did this, check out Galo Navarro’s salesman tricks, where he covers his strategy to get both executive buy-in and bottom-up developer adoption for his platform. In a nutshell:

• Executives — Sell them on how the platform can help them achieve their overall organizational objectives in a measurable way. Focus on value creation over cost reduction.
• DevOps and sysadmins — Make clear that the platform is an opportunity, not a threat.
• Developers — Make sure that they understand the platform is for them, so they can win the race.

6. Finally, a point that is often overlooked: maintenance. Teams can often get excited about building something new and focus on the shiny new tech, but long-term maintenance and continuous improvement are even more important to guarantee a stable and evolving product.

Build vs. Buy

I can almost hear you. Platform as a Product and all, sounds great. But do I really need to build an IDP from scratch or should I just be buying one?

Let me be clear, Platform as a Product doesn’t mean you buy something that claims to cover the entire software development and delivery life cycle and call it a day. There are a number of solutions out there that make promises of such end-to-end solutions, so let’s be more precise.

If you are a small team or a startup at seed stage, a Platform as a Service (PaaS) like Heroku can be a great way to build and ship an MVP without the need to hire a DevOps team.

If you are a midsize engineering team of 20 developers, an end-to-end DevOps platform might be able to solve most of your problems.

But if you are any larger than that, and certainly if you are an enterprise, it’s extremely unlikely you’ll find a one-size-fits-all solution that will be able to integrate with your legacy tech, while allowing you to design the modern cloud native workflows you want to establish.

Many vendors label themselves as “DevOps platforms” or “software delivery platforms,” trying to appeal to the enterprise buyer as complete “one-size fits all” solutions. In reality, these tools are only components of a team’s IDP. They are usually taking over specialized areas such as continuous integration, continuous delivery or continuous deployment, or syncing states in a git repo with a cluster.

But, especially for complex brownfield setups, you need to build an internal developer platform. This, however, doesn’t mean you need to start from scratch.

According to our CEO Kaspar von Grünberg, “an internal developer platform (IDP) is the sum of all the tech and tools that a platform engineering team binds together to pave golden paths for developers.”

That includes everything from IDE to production, including a version control system, a CI tool, cloud infrastructure like Kubernetes clusters, DNS, databases, etc.

If you decide to build an IDP instead of buying an end-to-end PaaS or a PaaS-like DevOps solution, it still doesn’t mean you would seriously consider building your own IDE or CI tool. For all these categories, there are great open source tools or products from commercial vendors available.

So instead of the good, old build vs. buy debate, it is really about build and buy. The hard work is to find a good combination of tools that interplay nicely with each other and glue them together in a meaningful way.

Platform Design: Click-Oops vs. Git-Based Workflows

What does “meaningful” mean, and how should you approach designing your IDP? There are two main approaches in the market today: Git-based workflows vs. so-called click-ops and UI heavy workflows (or click-oops, as I like to call them).

When you build your IDP, you need to consider both and understand what level of abstraction is the right one for your organization — what is the preferred amount of context you want to provide for your developers?

While a platform setup with a click-ops user interface might be a good first step for less experienced developers or small startups without DevOps capabilities, it becomes increasingly hard to manage in large enterprise setups.

We are all familiar with the notoriously bad UI experience of cloud vendor platforms (fun rants on AWS, GCP, Microsoft Azure, if you are missing that in your day). The problem is UIs for complex systems quickly become very hard to navigate, require a lot of specialized expertise and a lot of guessing (and fear) goes into, “What happens when I click this button?” And that’s not even the main issue. The ugly truth is developers simply hate UIs, and such setups don’t scale across organizations with multiple teams. So be careful not to pigeonhole yourself into a click-oops-only approach, or you risk ending up like this.

UIs are also extremely inflexible and make things hard to track and trace back. In a click-oops setup, a growing number of tools usually means an equally growing number of UIs or, alternatively, an increasingly unusable single UI. This will lead to a lot of context switching for developers and increased cognitive load, waiting times, etc. And you are back at square one.

A different approach is using git-based workflows with a clear separation of concerns. Platform teams own the toolchain and establish baseline configurations. Developers stay in their IDE and git and apply changes to app configs, the underlying infrastructure, etc., in a declarative way.

Teams can get the same advantages as when working with IaC or GitOps but applied across their entire delivery setup:

1. Reusability and shareability: Configurations and baseline templates are shared across the entire organization, preventing different teams from continually reinventing, while the platform team stays in control.
2. Versioning and traceability: Application and infrastructure config files are versioned the same way you version your code, allowing you to easily roll back, debug or promote a hot fix to production.
3. Standardization by design: Configuration templates enable platform teams to drive standardization across the entire organization while still letting developers choose their preferred interface and level of abstraction.
4. Scalability: Git-based workflows allow for a much more flexible and scalable enterprise setup whose complexity doesn’t grow linearly with the toolchain or amount of users.

Building a Dynamic IDP with a Platform Orchestrator

As you might have noticed, I lean more toward git-based over UI-based workflows, especially for enterprise setups (did the click-oops give it away?). However, at Humanitec we believe in providing teams with an unopinionated engine to build your own opinionated workflows. Because it’s up to you to figure out the ideal combination of tools your teams need and their preferred interface and level of context.

That engine is called Platform Orchestrator, and it’s the heart of a dynamic IDP, a platform that supports dynamic configuration management in a declarative way.

A dynamic IDP built with Platform Orchestrator provides you with all the flexibility you can wish for when it comes to access points and interfaces. This setup can integrate with UIs and supports GitOps and git-based workflows. You can easily wire up a service catalog like Backstage to your IDP or build dedicated user interfaces for certain user groups. This would even allow you to go down a full click-ops path if you really want to.

A dynamic IDP documents all config changes automatically. With every deployment, manifests and IaC files are created and stored in a repository. You get a full version history of all your app and infrastructure config changes, allowing for high traceability and easy rollbacks.

Designing your Platform as a Product gives you full control over your toolchain — unlike when using PaaS or end-to-end DevOps solutions — letting you integrate with both legacy and new tools as needed. It also allows you to define workflows, whether UI- or git-based, so that the end product, your IDP, really fits the needs of your organization and your developers.

If you want to dig deeper in the platform tooling landscape and platform best practices, as well as find out how much more platform engineers make than their DevOps counterparts, check out our latest “State of Platform Engineering Report.”

Luca Galante is a product manager at Humanitec. He routinely speaks to tens of engineering teams every month. He summarizes his learnings and takeaways from looking at hundreds of DevOps setups into crisp, insightful reads for everyone in the industry,...

Read more from Luca Galante