There is no doubt that Kubernetes popularity is growing very fast. I base my opinion on the trend I noticed in London since 2018, but a quick search on Google will confirm that.

My first experience with Kubernetes was in early 2017, when I attempted to create a Kubernetes cluster on AWS, and honestly I got discouraged at the time. That was before discovering Kops, and I wasn't ready to move to GCP (which actually would have been a good choice).

For the reason that I found Docker Swarm easier to install on AWS, I gave up on Kubernetes for a while. But things have changed since then, and starting from late 2018, all major cloud providers, including AWS, offer a managed Kubernetes service.

Eventually, I decided to recycle my previous experience and use Vagrant and Ansible to provision a standalone Kubernetes cluster for development.

But we already have Minikube, so why would I do that? My opinion is that Minikube is good, but it doesn't support all the interesting configurations which I want to test.

I need a Kubernetes environment which is like an actual cluster, but still runs on my laptop.

In my career as software developer, I have seen different styles of Agile and I have repeatedly noticed that estimating stories with story points is more difficult than I expected.

Some teams decide to live without estimates, and other teams try estimating stories at the cost of requiring an additional effort and spending more time in meetings.

How many times did you run out of time during a planning meeting and had to schedule a new meeting to finish estimating enough stories for starting the sprint? Even after spending long time in meetings, how many stories are still lacking of details and acceptance criteria?

In my experience, most of the times the reason for such problems was that too little work was done for preparing the stories before the meeting, and people were arguing too much about estimates.

If you think that your estimates are good, then you can stop right here, and continue doing what you are doing.

Instead, if you think that your estimates aren't working, or you feel that you are spending to much time estimating stories, then you might want to know what is my recommendation for quick estimates.

Docker changed how I approach software development for many aspects. One of them is how I maintain software dependencies on my developer's machine. I use Docker for installing and configuring my dependencies, usually required for testing my applications.

Docker provides a tool for defining a repeatable process for creating an environment with the expected configuration. Very common use cases are installing a database such as MySQL or PostgresSQL, creating schemas and users, and populating tables.

Docker helps in automating such processes and it can be combined easily with many CI/CD tools. We can run Docker as part of a Jenkins pipeline or we can run Docker when testing a Java application with Apache Maven.

Every time I need to compile some library or application downloaded from the Internet, I have to spend a lot of time installing tools and libraries. Every time I need to cross-compile some code or patch a library, I have to configure a build environment which occupies space on my disk. Sometimes I need to install a specific version of a compiler, which might conflict with other tools.

What if I could easily and reliably re-create the environment when I need?

Docker represents a versatile tool which can help to simplify and eliminate tedious operations such as preparing a build environment. Some companies, such as CircleCI, have already adopted Docker for their CI/CD solution. Jenkins can use Docker for executing isolated pipelines and for running integration tests in parallel without worrying about ports clash.