You may have heard about Platform Engineering. That is the new buzzword, since a while, after the hit of DevOps.

What about Product Platform Engineering? Have you ever considered treating your Platform as a Product?

In today’s issue, I will address:

Status Quo
What is a Product Platform Engineering team?
What is a Platform Service?
When a Product Platform Engineering team is needed?

📸 Status Quo

We are used to see an organization that responds to this picture:

In words, that picture means:

Feature Team. This is the developer team that implements the features for the product. The features that the customers will happily use.
Platform Engineering Team. This is the team that provides the underlying infrastructure, such as databases, cloud environments, brokers, queues, storage, etc. All these services are used, in raw, by the Feature teams to implement their features.

Even though this model works pretty well in many scenarios, it has some drawbacks

☢️ Feature Teams will have to deal with the complexity of dealing with infrastructure, like Terraform or Ansible scripts, run Jenkins pipelines for provisioning services, etc.
☢️ Feature Teams will still have to implement code, like auditing, authentication, configurations, etc, that are not in their domain.
☢️ As part of that, Feature Teams will, as expected, need to continue delivering Product features to bring money to the company!

These drawbacks are solved when you put in place your horde of Product Platform Engineering teams.

So… next question.

🎋 What is a Product Platform Engineering team?

It is a team of Software Engineers, same as Feature Teams, with a very concrete mission:

Providing Feature Teams with the right interface to implement their features seamlessly.

More in detail, Product Platform Engineering teams will treat the Platform, where the features are living, as a Product, by:

Abstracting the complexity of using the infrastructure, provided by the Platform Engineering team, through APIs. No more Terraform, Ansible, or Jenkins pipelines.
Providing configurable Platform Services, for Feature Teams to use them using their own language. For example, if all Feature Teams are using Kubernetes, leveraging the Kubernetes Custom Resource API to configure those Platform Services is a good approach.
Encapsulating as Platform Services the work for common tasks like auditing, authentication, telemetry, etc. No more code duplicated across 100 Github repositories and they can invest their time in their domain.
Having a roadmap, as any other developer team, but focused on the Platform that has to support the features of the Product.

The picture would look like this:

In the picture above you can see that a new layer appeared between the Feature Teams and the Platform Engineering teams, which is the Product Platform Engineering teams. In sequence:

Feature Teams use Platform Services from Product Platform teams.
Product Platform teams use Infrastructure from Platform Engineering teams.

There is an interesting talk from Manuel Pais from PlatformCon 2022, about treating your Platform as a Product, and you can find the video of that talk at the bottom of this essay.

I said before that Product Platform teams will provide Platform Services but, what is that?

👩‍🌾 What is a Platform Service?

A Platform Service is used by the services that provide features to customers. You saw it in the picture above.

A Platform Service has some characteristics:

It is configurable by Feature Teams.
It is doing work that is not in the domain of the Feature Teams.
It does not expose underlying infrastructure to Feature Teams.
It has one responsibility.
It is replacing the implementation by each Feature Team individually.

Here are a couple of good examples of Platform Services:

Audit service. This service will be configured by Feature Teams, to do work that is not in the domain of the Feature Teams, it will care of just auditing actions, and it will replace the code that every Feature Team would have to implement to audit their actions.
Authentication service. This service will be configured by Feature Teams, to do work that is not in the domain of the Feature Teams, it will care of just authenticate, and it’s replacing the code that every Feature Team would have to implement to authenticate their actions.

I guess you can see that one of the adjectives that defines this kind of service is decoupled. These services allow you to decouple your system and permit Feature Teams to focus on their business: Implement features.

💡 When a Product Platform Engineering team is needed?

Product Platform Engineering is not always needed. I realized that is needed when my teams had to invest a lot of time dealing with the infrastructure and all of them were duplicating code here and there. This usually happens when your organization grows up to 30 dev teams.

So, more formally, a Product Platform Engineering team becomes essential:

When the complexity of managing infrastructure begins to slow down your ability to deliver new features quickly.
When your organization grows to a point where it’s no longer feasible for all Feature Teams to implement the same code (such as authentication or auditing), especially when these aspects don't belong to their domain.

Let’s close up for today.

✨ Takeaways

Let’s write down the main takeaways from today’s essay:

Product Platform Engineering teams are needed when the complexity of dealing with the infrastructure holds you back from delivering new functionalities faster.
Product Platform Engineering teams provide services and API for Feature Teams to use them instead of managing infrastructure directly.
Product Platform Engineering teams are focused on platformize the system and treating it as a Product.