Latest Posts
Why Most Kubernetes Dashboards Are Failing You (and What Is The Future)
Most Kubernetes dashboards got it wrong. Most did not understand the limitations of Kubernetes API and, as a result, act as glorified file explorers rather than tools that help us find what we’re looking for, especially when dealing with large scale.
Today we are going to explore the mistakes Kubernetes dashboards are making and try to figure out how they might be able to get onto the right path, even though that might require some drastic changes in their design.
By the end of today’s story you should see what we need to navigate, search, debug, and do whatever we might need to do in Kubernetes clusters. We’ll feel like we are using Google Search rather than navigating through Kubernetes resources in a similar way we are traversing files and directories.
Neon - Never Share Databases Again!
Take a look at this.
That is GitHub actions run that executed hopefully typical tasks anyone is executing every time a pull request is opened. It run unit tests, it build a container image and pushed it to a registry, it update manifests so that, later on Argo CD or Flux can deploy the new release to production when that PR is merged to mainline. But, before that happens, it created an ephemeral Kubernetes cluster and run integration tests to confirm that everything works as expected.
I hope that’s what everyone is doing and, if that’s not the case, please let me know in the comments and I’ll do my best to make a video about the whole process.
There is one “special” part of that workflow run that I did not yet mention. There is something that hadly anyone does, yet something very important.
Past, Present, and Future of Internal Developer Platforms
Can you guess which tool I used to build my first Internal Developer Platform?
Let me give you a few tips before you try to guess.
- It performed most of the tasks people needed to do, like deployments of applications, execution of tests, and creation of new and management of existing servers and databases.
- It was very easy to use.
- It had a graphical user interface but it could be used without it through an API or a CLI.
- It had nothing to do with Kubernetes, or containers, or Cloud.
- The tool used to create it was one of the most popular tools back then, and is still one of the most widely tools used in enterprises.
- Almost no one used that platform after the initial excitement dried out.
Which tool do you think I used? Which tool fits that description?
Say Goodbye to Tedious Docker Commands: Embrace Docker to Bake Images
Building and pushing container image with Docker is easy. Right? We define a Dockerfile and we execute a command like docker image build .... Docker file is easy to define and the rest is just a CLI command. How hard can it be?
Well… It can be hard or, at least, tedious.
Imagine that we have to build images for multiple platforms, that each of those images should be released both as a specific version but also as latest. Then add to that the situation that we need to build more than one image, let’s say a backend and a frontend.
How many commands do we need to execute and how many arguments should each of those commands have? Can we remember all those arguments and are we willing to execute a bunch of commands?
That simple example already shows that building and pushing container images can be hard and tedious. The good news is that there is a better way. There is a declarative way to do all that.
From Zero to Fully Operational Developer Platform in 5 Steps!
Internal Developer Platforms or IDPs are not hard to create. Anyone can do it, as long as that someone knows everything about everything.
Today I’ll show you everything you should know about developer platforms. We’ll go through all the principles behind them, through all the components they should have, and I’ll even show you how to build one. This will be a tutorial on how to build a platform in 4 mandatory and 1 optional step.
At the end of today’s journey, we’ll have a fully operational IDP with everything you might need. Most likely…
Why I Changed My Mind About Backstage? A Brutally Honest Opinion
I was very negative towards Backstage. Some of the architectural choices are, in my opinion, bad. The way to install plugins is just silly. The quality of most of the plugins is very low. The need to rebuild container image every time we make a change is something I thought we will never see again. And so on and so forth.
Now, however, my impressions about Backstage changed. Actually, that’s not true. I still stand behind everything I said about it. What changed is the additional impression. Now I think I get it. Now I think I understand why Backstage makes sense, why it is one of the most contributed project and why it might make sense to adopt it even though it’s bad.
From UX to API: Mastering Platform Validations with Kubernetes Validating Admission Policies
Validations are extremely important when building Internal Developer Platforms, or any platforms for that matter. They serve two primary purposes. They help us ensure that user’s requests are valid before they are processed by the platform and they make user experience better. The problem, however, is that people mix those two all the time. One is ensuring that something is valid and the other is improving user experience without guaranteering validity of the requests. The first group are “real” policies while the other is just UX.