Latest Posts

Debunking Myths and Simplifying Compositions with Crossplane v2

Crossplane is too complicated!” “Crossplane is only for infrastructure! I need something else for applications.”

I hear those and other similar statement very often so I decided to clarify a few things and, hopefully, eliminate some missconceptions.

To be more precise, today I want to debunk one missconception about Crossplane and, at the same time, show how Crossplane addressed one semi-legitimate complaint in the recent v2 release.

So, debunk one missconception and show one improvement with both of those being intertwined.

Full article »


KubeVela & OAM: The Resurrection of Simplified App Management?

Imagine that you are building an Internal Developer Platform.

What would be a good user experience if, for example, one would like to deploy and manage a backend application without spending five years trying to understand all the details about Kubernetes?

Full article »


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.

Full article »


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.

Full article »


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.

  1. 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.
  2. It was very easy to use.
  3. It had a graphical user interface but it could be used without it through an API or a CLI.
  4. It had nothing to do with Kubernetes, or containers, or Cloud.
  5. 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.
  6. Almost no one used that platform after the initial excitement dried out.

Which tool do you think I used? Which tool fits that description?

Full article »


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.

Full article »