Comment by sigmonsays
2 days ago
i don't get the value of a tool like this.
Do we really struggle bringing up services as containers and applying kube configs?
For my development of services that run in kube, I don't dev with kube, you shouldn't have to. I also use docker-compose for most dev env services.
Perhaps i'm not developing the right kind of software. Whoever finds this type of tool useful, when would you use it?
Our team switched from Docker Compose (without Kubernetes) to Tilt for a distributed systems development environment. (Think platform engineering work on a system that scales from zero to several hundred thousand instances). Our time to go from code change to testable, running code on our laptops went from about a minute to a couple of seconds, using some Tiltfile recipes to do automatic incremental recompilation on our host laptops as we edit source files, and live-reload the new artifacts into running Kubernetes containers. The reload happens so fast that we configured our environment to compile+deploy+run on save, and the new code is already running by the time you reach for the "run tests" button.
I think if you told our team to go back to Docker Compose they'd revolt on the spot haha
If you have sidecar containers that feed your regular containers, or you need to test a Dask KubeCluster, or deploy Helm charts, this kind of lets you work with the real lifecycle. Tilt is kinda better at watching for code changes in all your containers than docker-compose too, and has a nice UI to watch logs and see what succeeded or failed.
Tilt can also help validate things like:
- Service discovery
- Volume mounts
- Ingress and Certificates
- Metrics scraping and configuration
- Dashboards
It’s really quite powerful and replaces the need to mock things out with docker compose. If you’re deploying to Kubernetes, Tilt gives you the option to avoid “development-only” setups like docker compose.
I think if you ever have highly dynamic infrastructure requirements -- think along the lines of a control plane that's spinning up additional workers -- it's really helpful to be able to run your infra provisioning logic locally. There's nothing worse than having to wait on cloud builds to test your iterations.
What would be the difference between eg Tilt and Pulumi for this?
Tilt is for your laptop, where you're editing code. Pulumi is for your cloud environments.
1 reply →
I never used tilt, but it looks very useful for anything that needs kube API to work, like some operator or something that needs to discover configuration from config maps.
otherwise I think it's meant for systems where system that you need for testing is to big to work on your local machine.
Yes, Tilt really shines when you’re testing interactions with Kubernetes, such a APIs. But also things like your services’ ingress configuration and metrics scraping.
By default, Tilt is actually intended for local development using kind, minikube or other similar tooling. It supports developing against a multi-node cluster but it requires extra configuration and slows down iteration time.
How do you make everything reproducible on the dev machines then? And manage versions of all the software?
The value is papering over previous over-engineering. No need to reflect if we might’ve effed up - and we get to keep all the toys!