The Path to More Affordable Preview Environments

Patrick Wiseman

Empowering teams to collaborate to get quality high code to production faster is our mission at Flowerwork. Preview environments – which are infinite, elastic pre-production environments – are the core way we accomplish that goal.

But cloud provider fees are getting increasingly expensive, and if not handled correctly, this approach could end up costing tens of thousands of dollars annually just for pre-production.

This didn’t jive for our team, so we set out to find a better, more affordable way to manage high availability preview environments. Here’s a look at how we did it.

But first, some context

This discussion actually started internally here at Flowerwork. Our deployment target is Kubernetes clusters, and we wanted to accommodate a cluster for each developer during the pre-production process.

We decided to host these clusters rather than having them live on individual developer laptops, since this allows us to better support team members, more easily troubleshoot issues, and run our pre-production environments closer to how we run our production environment.

It all sounded great – until we realized the cost. High availability Kubernetes clusters are expensive. When it comes to production environments and all that those environments need to handle (massive load, potential 24/7 activity, and so on), the cost is more than palatable. But pre-production infrastructure needs are far different than production infrastructure needs:

  • Uptime: Your staff is online 23.8% of the time if you’re co-located and working 40 hour weeks. So do you really need that 99.99% uptime?
  • Scalability: Since the development team is the only set of users, you likely don’t need the ability to spin up additional instances or do anything else that helps scale the application and make it more available.

This situation led us to the all-important question: How can we create more affordable preview environments while still tapping into the benefits of the cloud?

Take 1: The high availability cluster

The first option we had is the baseline: A high availability cluster that has nodes in different availability zones.

With this setup, you pay SLA fees to get really high uptime, but given the far lower pre-production uptime needs, it’s not really necessary.

Take 2: The regional or zonal cluster

The next tier down is a regional or zonal cluster with a single node. This still offers very high availability and uptime for the Kubernetes control pane, but if something happens to that node, all of your services go down.

Realistically, those nodes don’t go down very often though, and if several nodes do go down, you’ll actually be worried about your production environment – not your pre-production environment.

Take 3: The single node cluster on a VM instance

Taking it a step further, you can run a single node cluster on a VM instance instead of on a managed Kubernetes service, deploying k3s or microk8s.

This gets rid of all the SLA fees associated with having the high availability Kubernetes controller runtime, since you now just have to pay cloud providers for an instance.

Take 4: The VM spot instance

Moving on from there, you can actually use a spot instance for the VM to lower costs even further. Most cloud providers offer a model in which companies can pre-pay to reserve instances for large deployments to guarantee availability. Companies that do this tend to overprovision out of extreme caution. All the instances that they buy but don’t end up using then get sold as “spot instances” in an auction place.

This approach is a great way to get unused capacity at a discount (you can typically save 90% of the cost of running on a dedicated VM), however there is a caveat, since you could get interrupted at some point in time. The risk of this interruption happening is on the lower side, but it is possible.

Take 5: The time-blocked VM spot instance

Finally, there’s one more layer you can peel to cut down costs even more. The last option is to auto-scale by spinning your cluster up and down based on working hours. Essentially, you can assign a spot instance a time to be online, and it will start at the beginning of that window and tear itself down at the end of it.

This approach leaves you paying 10% of an on-demand VM price but only for a set number of hours, which means you only end up paying a fraction of that already reduced amount. It still carries the same risk as noted above for spot instances, but again the odds of this interruption actually happening are relatively low.

So where does that leave us?

On top of all that, the Flowerwork platform also lets you run your own infrastructure for pre-production. So as long as you can talk to the internet and run your own computer at home, that can be your own pre-production cluster, saving on cost compared to running in the cloud – on top of everything else noted above.

Interested in learning more about how you can realize benefits like these with Flowerwork? Sign up here for early access.