Flight Engineering is a series about developing and shaping the Volo platform to serve our customers’ needs. This week, Solution Architect Alaric Snell-Pym explores the SaaS model, and explains how we’ve improved it to assess our own design decisions.
Volo has been providing “Software as a Service” (SaaS) since before the term became popular. The SaaS model lets us deliver new features to customers quickly and cheaply, and makes it a lot easier for new customers to get up and running.
But technology is always moving on, so we can’t just sit back and smugly say “Done that”. When we started, the most cost-effective hosting option for our servers was dedicated hardware in a machine room, and although we operate at a scale that means our core platform’s hosting is still somewhat cheaper on dedicated hardware than on Amazon EC2, we’re using our agile development model to aggressively adopt new technology as soon as it becomes useful to us and our customers.
In order to track and guide our progress, we started looking for established SaaS maturity models. Some work was done on this in the community about a decade ago (2006, 2008 and 2014), but their model is too simplistic for our needs. It places a system into a stage on a single proposed evolution through these stages:
1. You install the software separately for each customer, with their own customisations to the codebase. New features get rolled out to different customers individually as they need them, so they all end up running on different versions of the software.
2. You have a separate instance for each customer, but they’re all running the code. All per-customer customisation is in configuration, not code.
3. You run a single instance of the code that’s shared between customers.
4. You run a scalable fault-tolerant pool of instances of the code, shared between customers.
5. As per (4), but you can deploy new/experimental features to slices of your customer base (perhaps for A/B testing, or to do an alpha release of something to a particular customer to get feedback without disrupting others, etc).
Although the above model raises some good points about what makes a good SaaS solution, we wanted something a bit more insightful, so we developed our own.
As we see it, the key things that differentiate SaaS solutions are:
Our model scores a SaaS system into three levels on each of those key differentiators:
Using that scorecard, we can assess our core product as a whole, and also individually look at the components that make it up; and we can use that to make sure our technical roadmap is balanced.
That doesn’t necessarily mean aiming for level three across everything! For instance, our image hosting system is used to serve product images for listings on many channels and on customer eCommerce web sites. It’s highly scalable and has a low cost per customer due to using a cloud content-delivery network for the final image serving, but it’s not very flexible – in fact, it scores a lowly 1 on the flexibility scale.
That’s because all customers get the same version of the software with the same features. However, this isn’t a problem. The task of serving scaled versions of the images is so simple and well-defined that we don’t need that flexibility. We’re always on the lookout for better hosting services, but all our customers need the same thing in the end: images, served. Having a SaaS maturity model allows us to identify those design choices within our system and make sure we’ve considered them properly!