Skip to main content

Building platforms–Strike the right balance

There is a lot of hype around platform engineering these days. The concept of creating platform teams and building platforms to deliver software at scale is not new as companies like Google, Facebook, Netflix etc. have a long history of building developer platforms. And also the much quoted Team Topologies book by Matthew Skelton and Manuel Pais was already released in 2019.

Some wonder if this is just a fancy new name for existing practices and if there is a risk that these developer platforms become a bottleneck, exactly what they are supposed to alleviate. Some dare even say that we made today’s development landscape so horrendously complex that we need these platforms to hide all this complexity.

No matter if you think Platform Engineering is overhyped or not, before you go on this journey I would like to share the following quote:

If your users haven’t build something that surprised you, you probably didn’t build a platform

I saw this quote in the Build abstractions not illusions talk by Gregor Hophe where he shared the following visual:

 

From the Build Abstractions not Illusions talk by Gregor Hophe

I think this is the most important design consideration when you start creating your own developer platform. You’ve successfully build a platform when you strike the right balance between hiding complexity and developer productivity without compromising their creativity. In that way it is related to the Paved road concept I talked about before.

So when you decide to go the Developer Platform route don’t forget that the real goal is NOT to deliver the platform but to support our developers allowing them to get more done.

Popular posts from this blog

Kubernetes–Limit your environmental impact

Reducing the carbon footprint and CO2 emission of our (cloud) workloads, is a responsibility of all of us. If you are running a Kubernetes cluster, have a look at Kube-Green . kube-green is a simple Kubernetes operator that automatically shuts down (some of) your pods when you don't need them. A single pod produces about 11 Kg CO2eq per year( here the calculation). Reason enough to give it a try! Installing kube-green in your cluster The easiest way to install the operator in your cluster is through kubectl. We first need to install a cert-manager: kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.5/cert-manager.yaml Remark: Wait a minute before you continue as it can take some time before the cert-manager is up & running inside your cluster. Now we can install the kube-green operator: kubectl apply -f https://github.com/kube-green/kube-green/releases/latest/download/kube-green.yaml Now in the namespace where we want t...

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.

.NET 9 - Goodbye sln!

Although the csproj file evolved and simplified a lot over time, the Visual Studio solution file (.sln) remained an ugly file format full of magic GUIDs. With the latest .NET 9 SDK(9.0.200), we finally got an alternative; a new XML-based solution file(.slnx) got introduced in preview. So say goodbye to this ugly sln file: And meet his better looking slnx brother instead: To use this feature we first have to enable it: Go to Tools -> Options -> Environment -> Preview Features Check the checkbox next to Use Solution File Persistence Model Now we can migrate an existing sln file to slnx using the following command: dotnet sln migrate AICalculator.sln .slnx file D:\Projects\Test\AICalculator\AICalculator.slnx generated. Or create a new Visual Studio solution using the slnx format: dotnet new sln --format slnx The template "Solution File" was created successfully. The new format is not yet recognized by VSCode but it does work in Jetbr...
OSZAR »