Minikube vs. Docker Desktop for Local Development

Docker desktop and minikube are popular options for local development. Do you need both installed for local development or can you save some RAM and run a only one of them. Below are some questions to help you decide which one to use in your situation.

Which version of Kubernetes are you running in production?

Kuberenets (k8s) is on a three month release cycle with an N-2 support policy. For example in July 2020 k8s 1.18 is the most recent GA release, 1.17 and 1.16 are currently supported. When k8s 1.19 is released 1.16 will fall out of support. Many organizations run the oldest supported k8s to minimize risk to production systems.


Docker Desktop includes a hard coded version of Kubernetes. For example at time of writing the most recent Docker desktop includes k8s 1.16.5 since that is the oldest supported version of k8s.

About dialog box on MacOS

Currently it is not possible to change the version of k8s in Docker desktop. If you need an older version of k8s you will have to install an older version of Docker desktop. Basically Docker is shipping the “most stable, widely used” version of k8s since many organizations run the oldest GA version of k8s in production.

Minikube supports the most recent GA version of k8s plus the previous 6 minor versions. You can pass minikube a command line argument to launch a specific version of k8s. For example, minikube start --kubernetes-version=v1.18.3 will launch k8s 1.18.3

How do you build your container images?

If you use a Dockerfile during development you will need to have Docker desktop installed, otherwise you won’t be able to run docker build to create a container image on your laptop.

If you are building your container image using tools such as JIB that don’t require a local Docker daemon you can run minikube without Docker desktop.

Do you need a local container registry?

Minikube does not ship with a container registry. By default it will try to resolve container images from Docker hub and other public registries. If you need to build containers on your laptop and you want minikube to pull them form your laptop rather than a remote container registry you will benefit from running Docker desktop since it includes a local container registry.

How do you manage local development dependencies?

If your application depends on commonly used OSS databases, message queues, caches you will have to decide how setup these dependencies on your laptop. There are three reasonable choices.

  • Install on laptop
  • Run with docker-compose
  • Run on minikube

Installing directly on a laptop can be time consuming and error prone. If you work on multiple apps or services that need different versions of PostgreSQL or MySQL then development becomes more time consuming and error prone.

You can run dependencies using docker-compose which has a nice developer friendly workflow.

  • checkout code
  • docker-compose up
  • write code / run tests on laptop that use services running in Docker
  • docker-compose down

With docker-compose we are running third party dependencies in simple repeatable manner.

Minikube can also be used to run third party dependencies such as MySQL and other tools. To do so you will have to write k8s deployment manifests and expose the services using a NodePort on the minikube vm ip address.

If you want to use docker-compose for dependencies then you will need docker desktop, otherwise you can get away with minikube.

Are you using JUNIT with test containers ?

If you are using the test containers project for your automated testing you will need to run Docker Desktop since test containers does not currently support Kubernetes.

Which Operating System are you using for local development?

Docker Desktop is available on MacOS and Windows and it includes both k8s and docker . On Linux the docker distribution only includes docker, so you will have to install k8s from another source.

Minikube is available on Mac, Windows, and Linux. If you are looking for the same developer experience across Mac, Windows, and Linux then minikube is a good choice.


Use docker desktop if

  • You need to build container images from Dockerfile
  • You need a local container registry
  • You are managing your local development environment with docker compose
  • You are using test containers with junit
  • The version of Kubernetes included in docker desktop is the version you want to use
  • Your developers are only on MacOS and Windows.

Use minikube if

  • You need to pick a specific version of Kubernetes to work with
  • You don’t need a local container registry
  • You are not using test containers with junit
  • You have developers using Linux, MacOS, and Windows

Based on your answers to the question above it is quite possible that you will need to run both.

Next Generation Session Management with Spring Session

Article I originally published at InfoQ, you can read the full version there.

Session management has been part of enterprise Java for so long that it has faded to the background of our consciousness as a solved problem, and we have not seen any major innovation in that arena in recent memory.

However the modern trend towards micro services and horizontally scalable cloud native applications challenges the assumptions upon which session managers have been designed and built for the past 20 years, and exposes flaws in the design of modern session managers.

This article will demonstrate how the recently released Spring Session APIs help surmount some of the limitations of the current approach to session management, traditionally employed by enterprise Java. We will start with a summary of the problems with current session managers, then dig into the details of how Spring Session solves each of those problems. We will wrap up the article with a detailed explanation of how Spring Session works and how you can use it in your projects.

Read the full article on InfoQ

Spring Framework 4 and Java 8

Article I originally published at InfoQ

Java 8 shipped with new language features and libraries and Spring 4.x is already supporting many of these. Some of the new Java 8 features don’t have an impact on Spring and can just be used as is, while other Java 8 features require Spring to explicitly support them. This article will walk you through the new Java 8 features that are supported by Spring 4.0 and 4.1.

Read full article at InfoQ.