[metzby]

Hey, I'm CEO of Tilt. Thanks for the feedback.

The problem this solves is that distsys devs don't get enough feedback. You say you use docker-compose. Compared to docker-compose, Tilt has two advantages: 1) It updates the services as you edit them 2) Its UI makes it easy to see where errors are occurring, without you having to play 20 questions on the command-line or worry about things scrolling off-screen.

The Tiltfile doesn't redefine your k8s definitions; it reuses your existing k8s definitions. The Tiltfile just tells Tilt how to get them. (Many teams don't just use yaml files, but generate them, so Tilt has to be able to do that, too.)

There is a landing page at https://tilt.build which has more of the "why Tilt". Also, we're adding native support for docker-compose next week. I'd love to understand your case more, because at a high level you sound like exactly the kind of dev we want to help.

[karakanb]

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.

[metzby]

Yes, please don't use Tilt to update your production cluster!

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.

[johnmarcus]

It looks like your basically recompiling/rebuilding the container and just updating what’s running (in what I assume is a k8s cluster on OS X). This all seems like a terrible idea. No way devs want to wait for a container rebuild to see updated code changes, that’s highly unproductive. They usually don’t run k8s locally either, because it’s an abstraction later they hardly want/need to concern themselves with while writing code. And as a say admin, truthfully I don’t really want them to try because it would double my own already heavy workload. This seems to solve a problem in a way that only works in the most ideal enterprise (slow moving) work environment. I currently solve the problem with carefully built containers which permit volume mounting and and code reload natively using typical dev flags for the run command. It requires more thought upfront than is ideal, but does typically solve the problem. Cheers.

[metzby]

That's why we have fast_build, which does something more clever. I just published a Blog Post "How Tilt Updates Kubernetes in Seconds, not Minutes": https://medium.com/windmill-engineering/how-tilt-updates-kub...

[jacques_chester]

> There is a landing page at https://tilt.build which has more of the "why Tilt".

As a tangential by-the-way, I notice you're based in NYC. Of interest, Googlers working on Knative Build (hi Jason!) and Pivots working on Cloud Native Buildpacks (including me) are based in NYC also.

[puzzle]

Dan himself used to work at Google NYC...

[metzby]

As puzzle mentioned, yep. I know Jason pretty well. Happy to chat; want to get coffee? I'm dan at windmill dot engineering for scheduling.

[hodgesrm]

Hi! Thanks for checking in on HN. I'm very interested in k8s productivity but had some trouble understanding what Tilt is actually doing--is it a replacement for minikube, hosted kubernetes, etc.?

Is there an architecture diagram that shows what runs where?

[metzby]

There isn't an architecture diagram, and there should be. Thanks.

Tilt replaces `docker build && kubectl apply` or `docker-compose`. It watches your files, updates automatically, and gives you a UI that shows you error so you don't have to spelunk with kubectl.

It uses minikube or docker-for-desktop or a cloud k8s cluster (AKS, EKS, GKE, whatever).

It's like skaffold or draft or garden.

Does that help?

[sytse]

"Tilt replaces `docker build && kubectl apply` or `docker-compose`. It watches your files, updates automatically, and gives you a UI that shows you error so you don't have to spelunk with kubectl." => that is very clear, consider merging https://github.com/windmilleng/tilt/pull/930 to add it to your readme

[Nullabillity]

Does it allow you to replace the `docker build` step? Currently we use Nix's buildLayeredImage[0] to build our images and some custom machinery to generate our Kubernetes definitions from this, but I really like Tilt's status TUI.

[0]: https://grahamc.com/blog/nix-and-layered-docker-images

[metzby]

We don't yet, but we're considering it. If you email me (dan at windmill dot engineering) I'd love to hear more of how you use it.

[hodgesrm]

Got it. So I bring the k8s and tilt keeps things refreshed as I'm making changes. Thanks!

[shaklee3]

Can you explain how it's different from skaffold? I use that heavily.

[metzby]

It's a lot like skaffold. Main improvements (for now): ) a better UI that keeps errors on-screen. Check out our demo video: https://www.youtube.com/watch?v=MGeUUmdtdKA ) fast_build allows you to do iterative container builds

If you use skaffold for local dev, a Tiltfile will take 10 minutes to write. Email me at dan at windmill dot engineering and we can pair to get you going. You're the user who would benefit from Tilt immediately.

[techntoke]

How is that different from Skaffold or Draft?

[GarMan]

> (Many teams don't just use yaml files, but generate them, so Tilt has to be able to do that, too.)

Tell me more about this? I have my own helm like product and I had issues getting that to work with skaffold.

[metzby]

Helm is one way to generate k8s yaml. There's also kustomize, or ksonnet, or custom scripts (sed!).