Developer Tooling for Kubernetes in 2021: Skaffold, Tilt, and Garden (Part 2)

If you have been keeping track, I recently started a series of blog posts about the state of developer tooling in the Kubernetes ecosystem in 2021. The first blog post covered the topic of defining Kubernetes applications, i.e., how you go about declaring, packaging, customizing, and deploying them. You can check out that up-to-date comparison between category leaders Helm and Kustomize right here.

In that previous blog post, I also mentioned another tool – Skaffold. While Skaffold has limited ability to define Kubernetes applications and build and deploy them in CI/CD pipelines, its core functionality is creating a development environment for Kubernetes. In this blog post, I’ll discuss the alternative tools for doing just that – spinning up a development environment on Kubernetes. So let’s go into an in-depth comparison of Skaffold, Tilt, and Garden. I will not be covering Microsoft Draft, as the GitHub repository appears to be archived and has had no new versions in 2020.

Skaffold

Skaffold is an open-source CLI tool by Google. Its main selling point is a unified approach for building, pushing, and deploying your Kubernetes applications for dev workflows and CI/CD pipelines. 

To configure Skaffold, you use the somewhat intimidating skaffold.yaml. Here’s a simplified outline of what the workflow looks like:

1. Watch - Skaffold watches your source code directories for any changes and then triggers the pipeline. This stage doesn’t apply when running in CI/CD mode.
2. Build- Skaffold builds the container images for your application. This stage is where many useful features come in:
   1. Skaffold supports various configurations, including Dockerfile, jib, Buildpacks, Bazel, and even custom scripts.
   2. Skaffold can run the build process locally, on the remote Kubernetes cluster, or Google Cloud Builder.
   3. Skaffold will tag your images automatically based on configurable policies.
   4. Skaffold supports static testing of the built container images using container-structure-test.
   5. Skaffold may skip the build process and directly sync source files to running containers where appropriate.
3. Deploy - Skaffold binds the Kubernetes manifests for your application with the appropriate container images and deploys them to a local or remote cluster. Here you can use Skaffold’s built-in minimal templating mechanism, Helm, and Kustomize.
4. Execute - Skaffold monitors the application's pods post-deployment per your specification. The highlights here include logs tailing and port forwarding.

What’s New With Skaffold?

As powerful as Skaffold can be, getting it up and running with simple configuration can be an intimidating task to the uninitiated. The Skaffold team has been hard at work on the Skaffold init command to get new users over the hurdle. When using this alpha feature, Skaffold will search your repository for build configuration files such as Dockerfile and pom.xml. It will then create a default configuration file that should get you up and running in seconds. 

Additionally, Skaffold has added built-in support for integrating with traditional debuggers via the (beta) Skaffold debug command. When used, Skaffold attempts to configure the application runtime for remote debugging automatically. While this is a neat feature, using traditional debuggers in a microservices environment is tricky at best, especially when working with remote clusters. If you are having trouble with that, we highly recommend you check out non-breaking debuggers such as Rookout.

Tilt

Tilt, a commercial open-source offering by Windmill Engineering, takes a different approach, focusing on creating the best developer experience. Tilt doesn’t settle for a simple CLI tool and provides a powerful web-based UI to give you detailed feedback on everything that is going on behind the scenes. Tilt's web-UI will allow you to navigate each of your services’ health status, and their build and runtime logs, among other things.

Configuring Tilt takes place via a Tiltfile, written in a dialect of Python called Starlark. Getting started with Tilt is a painless experience, and your first Hello World application Tiltfile will probably only be 3-5 lines long. When you want to get fancy, features such as manually controlled updates, remote builds, Helm charts, and manual update control are all there for you. 

Like any commercial open source software, Tilt also has an enterprise edition. If you require vendor support or have more complex requirements, that may be worth checking out.

What’s New With Tilt?

In the Kubernetes ecosystem, it often seems that Windows is shunned, regardless of Microsoft’s progress with the open-source community, not to mention the fantastic work they have been doing with WSL. Well, Windows is still the most common operating system on this planet, and if you or someone on your team happens to be using it, you’ll be glad to learn Tilt has released support for Windows in 2020.

Another prominent feature you might find interesting is a new plugin mechanism known as Tilt extensions. Check out publicly available Tilt extensions from this Github repo or consider writing an extension yourself to enhance your Tilt experience. By the way, we have been wondering about adding a Tilt extension for Rookout, so feel free to give us a shout if that’s relevant.

Last but not least, Tilt has released a SaaS service known as Tilt Cloud to improve team collaboration even further. Tilt Cloud’s first feature is Snapshots, which allow you to share your live environment state with a team member to get his feedback. Check out an example of that right here.

Garden

If you read through Tilt’s docs, you will see they are great proponents of local deployment of Kubernetes applications during development. However, Garden’s team are firm believers in the opposite approach - you should always deploy to a remote, production-like cluster. If you are still debating what process works best for you, we have discussed the pros and cons of going local vs. going remote in the past, so please check it out.

Garden is a commercial open-source tool for “development automation.” Garden spins up Kubernetes applications in a (remote) cluster for development, automated testing, as well as manual testing and review. 

Garden allows you to get started by using CLI helper commands such as garden create project. You will manage the Garden configuration through a graph of YAML configuration files. That’s a very flexible and modular approach, but it will require a bit of learning on your part. The key elements you will define in those files include:

• Modules - Modules serve as Garden’s unit of building. Here you will specify how to build your containers.
• Services - Services serve Garden’s unit of deployment. Here you will define how to run your containers on Kubernetes.
• Tests - In Garden, tests are first-class citizens. There’s built-in support for both unit tests as well as integration tests.

Just like the other tools in this review, Garden has its own set of advanced features such as templating, predefined tasks, custom workflows, and more.

To achieve the best results, Garden recommends deploying a Garden service into a shared cluster. Once that’s up and running, Garden will spin up two types of environments:

1. Each developer will spin up a development environment based on the source code he has checked out on his laptop.
2. The CI will spin up environments for testing and review for every PR in the relevant repositories.

What’s New With Garden?

In mid-2020, Garden announced their Enterprise product, a commercial offering of the Garden product. The key features include central management, provisioning of users and secrets, and direct integration with GitHub and GitLab. If any of those features seem essential to you, the enterprise version may be the way to go.

Overall, Garden is the youngest of the three tools, with the company behind it (also named Garden) announcing their seed funding round in November 2020.

Summary

For software engineers adopting new technologies, such as cloud-native, the question is always the same: how can I test my code while I’m developing it? And trust me, expecting every developer in your team to be a Kubernetes expert is not the right way to go.

Each of the tools described in this blog post will provide your engineers with a shareable, consistent, easy to use, method to spin up their development environment. Those are all excellent choices, each with its pros and cons, and the right option for you will probably depend on your unique needs.

Regardless of which development workflow tool you end up choosing (if any at all), keep in mind that debugging in a (remote) microservices environment is far from a trivial task, so make sure to pick up some non-breaking breakpoints.