I have the impression that Kubernetes is growing in popularity. I base my impression on the trend I noticed in London in 2018, in terms of talks about Kubernetes and companies moving to Kubernetes. This impression seems to be confirmed by what people report on the Internet.

My first contact with Kubernetes was in early 2017, when I attempted to deploy Kubernetes on AWS. Honestly, I got discouraged at that time. That was before discovering Kops, and moving to GCP was not an option.

Since I found Docker Swarm easier to install on AWS, I gave up on Kubernetes for a while. But things have changed since then, and all major cloud providers, including AWS, offer a managed Kubernetes service nowadays.

Eventually, I decided to recycle my previous experience and automate the process of provisioning a standalone Kubernetes cluster for development using Vagrant and Ansible.

But we already have Minikube, why would you do that?

My opinion is that Minikube is good, but it doesn't support some interesting configurations. I want to use a Kubernetes environment which is like a production 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? Despite that, 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 before the meeting for preparing the stories, 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 be interested in reading what is my solution 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.