Powering productivity with Tilt
It's really common to have multiple (micro)services running under your infrastructure and many engineers working across them. All those engineers need to build and run these services locally to test their daily tasks. Here is where the problems begin:
How do we run locally an environment with multiple (micro)services and ensure that everything is working well?
I've seen companies adopting contract-based strategies and mocking services responses. And it's ok, it works well and it has a very low cost! You don't have dependencies to run your particular service locally, you can just run your service and test what you need. But this simplicity comes with risks:
How do you know all other services you have will keep working as pretended after your new changes?
Here at Avenue, we went further in this theme, trying to have a local environment closer to what we have in production.
- We adopted a monorepo codebase. From the beginning, it has made things easier for us because all services are together in the same repository, so we just needed to figure out how to orchestrate the execution of them.
- Our infrastructure runs on Kubernetes and we release new versions of our services using Helm. So it'd be nice if we could use all configurations we already have for that.
Uber has also decided to move forward in a monorepo strategy, here you can find a post in their engineering blog.
Ok, the introduction is over. Let's see some code!
Tilt is a toolkit designed to resolve this kind of problem. You can use it to apply the same Kubernetes YAMLs you would apply in a production cluster in your machine. It's awesome because it helped us to bring the Kubernetes world closer to our daily life.
Let's use this example project:
BTC communicates with Quotations to get the current USD price over an HTTP request. For every new request, Quotations saves a new log entry on a Postgres database. It's our project layout, who is also using a monorepo codebase:
A simple thing we could do to run it locally is to set up a simple docker-compose file (as you can see in the picture above), but it would disconnect us from our production way to release software. Instead, we configured this simple helm chart. The chart configures both of our services and also runs a Postgres instance. It'd be exactly what we'd use in a production use case.
After that, you need to have some Kubernetes running locally. There are many options. In this post, we gonna use Minikube. You need to install it. After that, just execute the command below:
minikube startIt'll download all dependencies it needs and start your local Kubernetes. Also, you gonna need to install Tilt.
To run our services, I wrote this simple Tiltfile:
With our Minikube running and our Tiltfile ready, let's make the magic happen, executing the command below:
➜ tilt-demo git:(main) ✗ tilt upTilt started on http://localhost:10350/
v0.22.4, built 2021-08-13(space) to open the browser
(s) to stream logs (--stream=true)
(t) to open legacy terminal mode (--legacy=true)
(ctrl-c) to exit
Tilt'll start the build process and it'll create the resources you need in your local cluster. You can see it through kubectl
➜ tilt-demo git:(main) ✗ kubectl get pods
NAME READY STATUS RESTARTS AGE
btc-58fd98c5-wlkd7 1/1 Running 0 9m58s
demo-postgresql-0 1/1 Running 0 28m
quotations-768c4b87c8-568f7 1/1 Running 0 9m39sOr you can also access http://localhost:10350/ on your local browser and you can see Tilt UI, which is very powerful and gives engineers a great experience dealing with Kubernetes:
Tilt UI is an amazing feature, it's much easier to see application logs, switch contexts, follow communication between services, etc. It's a big 👍 for Tilt! Everything you need to work is concentrated in one place.
Pros
- It’s very, very easy to run complex environments using Tilt.
- It can help you to have a faster onboarding process for new engineers
- Tilt gives you Live Reload when some code changes, it’s a great productivity benefit
- Tilt UI will be one of your best friends. It takes the experience of running code locally to a new level.
- Your engineering team will be much closer to Kubernetes/Helm
Cons
- It’s heavy. Here at Avenue, to run something around 40 services we need at least 4GB RAM and 4 CPUs in our Minikube.
- Tiltfile is Starlark script. You can do everything you want there. I may get too complex.
- If you never had the opportunity to give a closer look at Kubernetes and understand how it works, I’m sure I’ll be a little scary.
Guys, I'm sorry if I won't deeper enough on some particular point. But you can find all code in this GitHub repository. Also, you can watch a tech talk on our YouTube channel:
