ihcsim

The project that I work on depends directly on the Kubernetes API, admission webhooks and API extensions. I do my daily development on a GKE cluster, because local k8s environments are slow and inconsistent. What I really like about tilt is that it enables the continuous development experience, where code changes are continuously built and deployed to my remote cluster as I made them in my editor. It helps to shorten my feedback loop by replacing the series of `docker build`, `docker push`, `kubectl apply` etc. commands with just a single `tilt up` command.

I can sympathize with what the author said. A while ago, I worked as the only devops engineer on a team of 10 full stack developers. The tl;dr is that management decided to migrate their existing workloads to k8s for reasons. The developers were not too keen about all the new concepts, tools and techniques they needed to learn as a result of that decision. They knew they had to own their code from dev to prod, and couldn't just throw it over the fence (because there was no fence). The issues that were brought up in the post definitely reasonated with some of the concerns the developers brought up. I do think a tool like tilt would have made the transition easier for that team.

Finally, I think the post could have been made simpler if it stays focus on just one tool, and how that tool helps to solve the problems that non-ops developers have, when writing code that needs to run on k8s.

It will be helpful for testing your retries, and getting insights into your client's behaviour in the event of service failures.