Tilt: dev environment as code

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?

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.

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.

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.

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.

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

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.

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!

I can use Pulumi on my laptop too... that's precisely what I do... for my use-case I use it more like a "programmable docker-compose" if you want

How do you make everything reproducible on the dev machines then? And manage versions of all the software?

tilt might be nice but I do not develop in containers or kubernetes. Tilt to me looks like more glue on top to make updating kube fast. It might make sense for some but it seems pointless to me.

If I can run external dependencies in docker locally, I can setup my app to run entirely from my laptop. That's all docker-compose does, just runs dev deps like DBs and other services i'm not editing code of.

As far as code reloading goes, there is a million tools to do that already. Go already compiles locally much faster than seconds.

All that being said, why are people choosing to develop in containers/kubernetes?

Maybe apps that need to be more tightly integrated with kube would benefit from this?