Garden Automates Kubernetes Building, Deploying, Testing
Many startup founders will tell you their companies grew out of frustration, but in the case of Garden.io, it was the product of anger, according to CEO Jon Edvald.
So much time is wasted in a developer’s day setting up Kubernetes environments and waiting around for tests to finish.
While working at Berlin-based Clue back in 2017, “I ended up building custom in-house tools to try and keep the developer experience sane, to make it easy for our team to test their changes, get their development environments. A lot of tools didn’t exist that we now maybe take for granted. This was pretty rough,” he explained.
“I talked to talk to a bunch of CTOs and people in DevOps. They shared similar stories … and therein lies the opportunity.”
Back then the process was a series of git commit, push and wait. There was little knowledge of how everything comes together in CI/CD systems, and the development and testing environment was not necessarily anything like the production environment.
“The sheer amount of time that goes into that sort of tedious feedback loop across the industry is a source of a lot of frustration and a lot of wasted hours,” he said.
“I think Garden solves a real need in the cloud native space, which is that the more sophisticated the platform gets, and the more developers you onboard, the bigger the gap there is between developer and production. But if you want rapid feature development and high-quality code, it’s critical to get that gap as small as possible. Garden solves this and does it in a very nice way that fits into the Kubernetes model and doesn’t feel heavy-handed,” said William Morgan, CEO of Buoyant.
Taking a Page from Infrastructure-as-Code
With Garden automation, developers can spin up ephemeral testing and preview environments for integration tests, manual QA and continuous integration workflows and get feedback faster. They no longer have to be bogged down with provisioning and managing ad hoc environments.
“From your laptop, as a developer, you can spin up an entire environment from scratch. You can tear it down, spin it up again, and you have good tooling that just resolves whatever you have changed as quickly as possible into the running environment. You can run the exact same tooling and configuration from your CI and CD. So that you lose the friction between the two,” he explained.
“And that basically means you have the full power of your CI/CD automation at your fingertips at any point in time. And this, I think, is really the only sane way to deal with ever more distributed, ever more complex cloud systems with all these different moving parts that they need to get together to really have a fully running system.”
It’s very similar to Terraform in its relationship to declarative infrastructure-as-code, Edvald said.
It uses what the company calls the Stack Graph, a directed acyclic graph (DAG)-based framework that allows you to codify a complete description of your stack as intuitive YAML declarations, capturing the relationships between all the components.
Configuration files are located next to each module, the basic unit building. It can correspond to a Dockerfile and its associated code, a remote Docker image, a Helm chart, an OpenFaaS function, etc. Garden scans for these configuration files, even across multiple repositories, validates them and compiles them into a graph that describes all the steps involved in building, deploying and testing your application.
Garden uses the graph to detect when modules need to be re-built or re-tested or services re-deployed by comparing your current code with previously built, deployed and tested versions.
It works the same way, whether on a developer laptop or in a CI/CD system.
When you run Garden with a shared Kubernetes cluster, Garden has its own namespace with a small set of services and every developer has a private namespace in the cluster where they can spin up a full instance of the application running in that namespace where they can develop and test.
“Garden.io is an integral part of our cloud native development environment. It solves the inner loop of our development process. It allows us to free resources on developers’ machines and run in a remote Kubernetes cluster. Not only does the code change get deployed in these remote clusters, but we are also able to continuously integrate it with other services that make up the product — all of this in a dev’s individual environment,” said Patricia (Pat) Gaughen, engineering manager for deployments at InfluxData.
“We looked at other solutions, and it felt like Garden would help us ease the burden on developer systems, and allow our developers to move quickly. Additionally, Garden was incredibly easy to work with throughout our evaluation with them. They’ve been fantastic open source partners on this journey, quick to address any issues raised and work with us on solutions for our devs.”
Built on TypeScript
While the company to date has been focused on Kubernetes development, its decision to take a wider view led to making Typescript its primary language.
“We’re still able to distribute it as a single binary, so the user generally shouldn’t have to care. That’s sort of abstracted away,” he said. “[But] first of all, we’re not just thinking about Kubernetes as the target platform. That’s very much our bread and butter today. But we wanted to take a longer view towards serverless platforms, and really a wide variety of different target platforms.”
Though Golang is dominant in the space, the decision was partly personal preference.
“And we wanted the consistency of having the same types and language on the website and the UI side as in the engine itself, that basically shortcuts a lot of potential issues for us during development.”
Many of its users come from tools such as Docker Compose, and the Kubernetes ecosystem has grown in the interim, giving rise to competitors including Okteto, Tilt and DevSpace. However, Garden is looking more broadly, Edvald said.
“We wanted to build something that works equally during CI, and from your inner loop from your laptop. We wanted something that is pluggable for more platforms than just Kubernetes. … We’re taking a longer view, thinking about what’s happening on the serverless side. I see a lot of interesting things happening with server-side WebAssembly. …[we’re] also thinking quite a bit about testing and how we can improve testing workflows… A lot of tools, they help you spin up an environment, they take care of the builds and deploys. But we wanted to take an active interest in the testing side of it as well and make it faster and easier to run integration tests.”
Looking Beyond Kubernetes
Edvald, along with co-founders Thor Sigurdsson and Bas Peters, released Garden as an open source project in 2018 under a “copyleft” Mozilla Public License 2.0 license. That core will always be open source, Edvald said, though the company also offers an enterprise version and a hosted version.
The company just raised a $16 million Series A, bringing its funding total to $20.9 million. Eighty percent of its business is in the United States, with customers including payroll technology Gusto, sales demo vendor Reprise, UK bank OakNorth and German electronics technology vendor Luminovo.ai.
The new funding will allow the company to expand in the United States, while research and development will remain in Germany.
Going forward it wants to simplify the open core to make it more accessible to new users and increase the integrations with third-party systems, such as security tools.
“We’re working on a suite integration that you just basically provide an API key [that] Garden already knows for all the container images, our Kubernetes manifests and Helm charts, and can just pipe that data over to a security solution that will scan those for vulnerabilities. And that’s, an example of an avenue that we’re exploring, kind of going beyond just building and deploying an application, but also validating it and understanding it,” Edvald said.
It’s also going into serverless and plans to make some investments in WebAssembly, though Edvald considers that technology still in its early days.