Internal Developer Platforms

From Docker to Kubernetes: Running Backstage in Production!

Backstage is great, or not, depending how you look at it. In any case, the important thing to note is that the only thing we’re getting is source code. Since it’s written in TypeScript, we can run it by executing yarn this and that or node this and something else. While that’s probably okay while developing it, it is silly when running it in production or anywhere else other than our laptops. It’s not 1999 any more. Today we package almost everything into container images and, from there on, you might be runnning it in Docker while I scream at you trying to explain why Docker is not a good idea for anything that should run in production. More likely, you are running your applications in Kubernetes, or as Azure Container Apps, or through Google Cloud Run, or anywhere else. What matters is that OCI images are the standard, no matter whether we run something as containers or anything else.

Internal Developer Platform Day 2 Operations Solved with Kubernetes and Crossplane

I did it. No! We did it. Actually, that’s not correct either. Someone else did it. Doesn’t matter who did it. What matters is that one of, in my opinion, big problems has been solved. Developers can now not only create, update, and remove their applications and infrastructure, but they can also get to know what’s happening with the resources they are managing.

Getting Started with Backstage: From Zero to Operational Dev Portal

Today we’re going to explore Backstage from newbee perspective. We’ll see what it is, what it’s main components are, and how to set it up. We’ll go from nothing to an operational portal in development mode. Unlike other similar tools that often require us to simply configure and run them, with Backstage we have to get the source code, develop or configure what we need, and run it on our laptop to see the result. Later on, once we’re happy with what we did we might explore how to package it all up, run it in production, and do whatever else needs to be done.

Let’s start from the beginning.

Surviving Backstage with Roadie: A Developer Nightmare or Dream?

Today I want to talk about potentially the most important tool in your toolbox. I want to talk about a tool that might enable everyone in your organization to be more productive and self-sufficient. Yet, the tool I want to talk about might win an award for the least user-friendly, hardest to maintain, and, generally speaking, a tool that might cause you to have nightmares and spend a small fortune on a psychologist.

It’s a tool that I recognize as being one of the most impactful tools which, honestly, I do not like at all, yet most of those who use it swear by it.

Did you guess what that tool is?

Automate Everything: How One Manifest Powers Your Entire DevOps Pipeline

Today I want to get back to the first steps when developer platforms are concerned. I want to enable developers to start a new project.

Mastering Developer Portals: Discover & Integrate API Schemas with Port

I am so dissaspointed with developer portal consoles for ignoring the fact that almost everything is discoverable through APIs. Why should I design forms and fields in Backstage if Backstage should be able to ask an API for a schema? Even if that schema is not exactly what I need and I might have to remove parts of it, that’s still easier and better than starting from scratch. It’s a waste of time to do the same thing over and over again. We should define what we have, expose that through an API, and all other tools should just “discover” it. Just as that’s true for, let’s say, kubectl, it should be true for graphical user interfaces.

Hence, I spent months complaining about it and… I got it.

How Platform Engineering Compares to Running a Restaurant

Platform engineering should follow similar patterns as restaurants, yet we often confuse it with a kitchen or a supermarket.

Let me explain.