|
AFAIK, the whole idea behind the cloud-native approaches and tools in the ecosystem, such as Docker, Kubernetes, Helm, Terraform, focus on reproducible builds that are platform-independent, at least that is my understanding of the ideal. I imagine having an application code, my Terraform definitions, k8s resources and helm charts, and basically I should be ready to deploy my application to any of the big cloud providers. This doesn't have to be the case for each and every application, but I believe we should all be moving towards a decoupled infrastructure where the application code itself is independent from where it is running in terms of infra. So, considering the point above, using Tilt for updating production cluster state and resources with hot reloading seems like a no-no, as this may easily cause configuration drift, which would make the whole cluster state independent from the k8s resource definitions. We should be moving towards reproducible builds and infra, so this usecase seems to fall short in my opinion. Replacing docker-compose seems like an exciting point, though the value addition is still not clear for me to abandon a tool I have been using for months for developing the application code, not the infrastructure stuff. I can see all the logs from all the containers on a single terminal, every developer in my team can run the whole application with a single shared docker-compose definition, and everyone in my team is familiar with it already. As far as simplicity goes, I don't see how Tilt simplifies my workflow since it requires a configuration script instead of docker-compose.yml file, and it is yet another tool to learn in that regard. Ideally, I would like to remove all the dependency from docker-compose as keeping it in sync with the k8s resource definitions requires effort, though Tilt also requires a similar configuration AFAICT from the docs. The best workflow for local k8s-based development seems like using minikube with the mounted directories or something similar, which means every change in the k8s resources made locally would also be present on the production setup, hence keeping production setup completely reproducible on every cluster, including local stuff like minikube. Please don't take my words in a bad way, I am really looking forward to replace my docker-compose based setup with something based solely on k8s definitions, therefore I am playing devil's advocate for Tilt in order to clarify its benefits so that I can make an informed decision about employing it or not. Thanks for jumping in on HN to answer questions and accept feedback, I really appreciate that. |
Tilt is just for precommit development.
If you email me (dan @ windmill dot engineering), we can talk more, but we are more reproducible and less config than mounting directories into minikube.