We sat down (virtually, of course) with Tomas Ostasevicius, a software engineer at Luminovo, to discuss how he and his team use Garden, “from building containers, to deploying the configuration and at the same time validating Helm charts, to running tests.” This post is a summary of our conversation.
Are you a Garden user who’s interested in sharing your use case? Feel free to get in touch with Mike! He’d be very happy to speak with you, and we will send you some swag as a token of our appreciation.
Hello Tomas! Thanks for being here today. First, could you tell us a little bit about Luminovo?
Luminovo is based in Munich, Germany. We started out as an AI consulting company, working with customers such as Daimler and Volkswagen. In 2020, we pivoted to become a product company, and now we build software that shortens the time required to bring new electronics products to life.
Specifically, we sit between original equipment manufacturers (OEM) and electronics manufacturing services (EMS), a segment of the supply chain that hasn’t seen much innovation in a long time. Our software aims to make their processes more collaborative, data-driven and automated.
And please tell us a bit about Luminovo’s engineering team and tech stack.
There are nine engineers on our team. We build back-end services in Rust—we took a bit of a chance on a newer programming language, and it turned out to be a good decision. And we use React and TypeScript for our front-end, along with some Python components inspired by our previous machine learning work.
As for infrastructure, currently we run Kubernetes on Azure. While still in the consulting business, we never wanted to be coupled too closely to one cloud vendor (in that regard, Garden is really helpful), and so we made a point to avoid proprietary components like Azure-specific registries. Right now, though, that’s not so much a goal—just a consequence of our experience with Garden.
How did you find Garden, and why did you decide to start using it?
We had no experience with Kubernetes when we started using it, and Timon, one of our co-founders who likes to seek out cool open source projects, happened to come across Garden around the same time we were starting with Kubernetes. It looked like something that could make our lives easier, and we’ve been using Garden since we’ve been using Kubernetes.
We evaluated a couple of alternatives, but Garden had one undeniable advantage: in-cluster building. Hands-down, Garden wins because of that. Especially when we were focused on AI, our images contained multi-gigabyte machine learning models. Building everything on the desktop then pushing it over the wire, with no shared cache, just wasn’t an option. It killed our office internet.
Garden’s been great since our pivot, too—in general, it’s been the right way to introduce Kubernetes to the company. Our engineers don’t have to know how stuff is deployed. They just run <span class="p-color-bg">garden run workflow deploy</span>, and everything will be there, working as expected.
And how exactly does Garden fit into Luminovo’s development process?
Our CI is running Garden, and essentially nothing else. And we use Garden for in-cluster image building, as I mentioned above.
Our front-end developers use Garden to deploy a working back-end that they can use while they’re developing. They just have to run <span class="p-color-bg">garden run workflow deploy</span>, and everything they need is there.
As for the back-end, when we were building in Python, Garden’s hot reloading was super useful, especially when working between the boundaries of two services and changing the API between them.
And now that we’re working with a compiled language, Rust, our back-end developers also sometimes combine Telepresence with Garden to run integration tests locally. To run these tests, we might still need a database that’s deployed elsewhere. So we simply spin up a Telepresence pod with the correct environment variables for the test and connect to it via Telepresence. Then we have the correct environment variables and the proxy to our cluster.
Once you proxy to the Telepresence pod, you can run your local code as if you were inside the cluster - for example using <span class="p-color-bg">cargo test</span>, with the benefit that you can change the code live. You don’t have to create new images and containers and push or pull them.
You can also reduce the scope of the tests if you want to. When we figured out the best way to work with Telepresence, the team was really excited because it was so much faster—you can focus on the test you want. You just start a Telepresence shell, and it’s as if you’re running locally. And nothing changes aside from the connection to the database. That was actually really great.
In both cases, it’s useful to be able to run the full suite of tests from a local command, though we also often rely on CI for that.
At this point, all of our deployments are also done with Garden, and we will explore how to take a GitOps approach in the future, possibly introducing Flux v2 or Argo CD.
One thing I’ve realized is that it’s really important to be able to deploy components according to a dependency graph (a DAG, like Garden’s Stack Graph). Deploying with combinations of nested Helm charts actually feels like a huge downgrade and a hassle, because you’re trying to wrangle something that is actually a DAG into something more linear.
How would you describe Garden to an engineer who understands the space?
There’s nothing better that I’m aware of for Kubernetes development, and if you’re doing it a different way, why?
Garden is very useful because it ties everything together: the building process and the deployment process, whichever way you want to deploy—whether you don’t want to get too involved in the details, or, on the other hand, if you’re hand-tailoring your Helm charts. And in that sense, it’s very nice.
Thanks again to Tomas and the Luminovo team for sharing their story!
If you’re new to Garden and have questions about getting started, we encourage you to ask us on our community forum.
We’re also happy to set up time to talk about Garden Enterprise if you’d like to learn more.
