e-Commerce, POS Software
Before adopting Spacelift, Lightspeed managed its Terraform code using an in-house solution, which helped the team plan and apply changes. But when their needs outgrew its capabilities they began to look elsewhere.
Alex Jurkiewicz, senior site reliability engineer at Lightspeed, explains how Spacelift has helped his team expand their Infrastructure-as-Code capabilities and work better together across global time zones.
Our own simple tool didn’t give us a lot of control or visibility about changes. Developers made changes directly on their local machines, and our tool logged those changes, without any way of standardizing access or changes to infrastructure.
It didn’t give us the more advanced functionality we were after, either; things like privilege levels for accounts accessing our cloud infrastructure, or the ability to audit or do security scans of our Terraform code before we made changes. That’s why we decided it was time to look for something that better suited our needs.
Spacelift was recommended to me in a Slack group full of SREs much like myself, and I included it in a big list we compiled of potential Terraform continuous delivery providers. We went through the list, comparing and contrasting them, and deploying a few stacks with each to see how they worked.
I was impressed with Spacelift. It felt much more coherent than the competition; it was well designed and it felt like it would easily fit into our existing workflows. I like that it isn’t designed to be overly opinionated about how you should do things; it’s extremely flexible. With a lot of the technologies Spacelift uses around its policies, you can really do whatever you want to do, and that was a big selling point for us.
And it’s been really great to use. Onboarding developers and less infrastructure-oriented technical staff was easy. Whether or not they use Terraform heavily in their day-to-day job, they’re comfortable and productive using Spacelift.
We use it in two major ways. Firstly for traditional Terraform tasks like deploying Infrastructure-as-Code, deploying our Kubernetes clusters, and deploying our Amazon resources in general. That’s working really well. It’s a big step up from our older internal platform.
The other way we use Spacelift is as a continuous delivery platform for applications. We’re deploying production changes to our application code with Spacelift and it works extremely well for us. We deploy our serverless applications directly with Spacelift too, running AWS DynamoDB and AppSync.
The Spacelift team has been really supportive. They’ve addressed any issues we’ve had quickly, which is exactly what you want from such a critical technology partner.
One of the big advantages of Spacelift is it’s given us the ability to deploy whenever we want to. We have this great pipeline where we commit code and it comes out the other end as a deployment into production. We don’t have to worry about fiddly, error-prone, manual deployment processes, which used to plague us like they plague many companies.
Being able to move beyond that and standardize on Spacelift, which really fits into any workflow we want, has had a huge positive effect on our error rate and the lead time for changes.
Beyond that, it’s been fantastic to be able to provide standards for our infrastructure across our whole company division. We can apply policies like ‘every Amazon resource must include one of these tags’. If anyone tries to submit a pull request which doesn’t have a tagged resource there’ll be an error and they can just go and fix that themselves. It’s automating a lot of that grunt work and getting rid of a lot of the toil involved in managing infrastructure systems.
Our team includes developers distributed around the world across American, Australian, and European time zones. Spacelift has given us a lot of additional trust in each other. Because we have guardrails and defined workflows set up it allows us to have shared visibility into what we’re all doing.