Thanks Jeroen, I’ll look out for your blog.
Whether you use minikube or use a separate kubernetes namespaces per developer, the key is to always be running inside kubernetes really as much as possible for anything above simple unit tests — as then you are running/debugging/testing on as near to production as possible.
The issue with ‘running locally’ when thats not in kubernetes is you are probably running a different operating system, libraries, dependencies, file system, network stack, environment variables and whatnot — which means you are kinda wasting time testing on a totally different platform and could be hiding real issues you will hit when you really run things on linux on kubernetes etc.
There are various ways to do this though. Minikube is one option; custom namespaces are other. When using OpenShift.io / fabric8 4.x or later you can use Che as a cloud based IDE; this feels much like using your local laptop. The massive difference though is every time you run something (e.g. java -jar foo.jar or some npm goal or go binary) its always running inside kubernetes in a docker container — as close to production as possible even in development.
