Opinionated account on a micro SaaS currently processing ~53k api requests daily and ~£3k monthly. Actual code, real lessons learnt the hard way.

I wrote about SaaS based architectures earlier in 2020 which goes into detail on the tradeoffs around multi tenancy.

We reject: kings, presidents and voting.We believe in: rough consensus and running code- Dr. David D. Clark

Contrasting with large enterprise AWS based deployments with > £350k monthly budgets. These SaaS costs are negligible per customer onboarding.

Good SaaS goals

The micro SaaS has implemented the following goals (your goals may be different):

• Customers can join themselves and use the product without human intervention (this is a key tenant of SaaS)
• Vendor agnostic, it runs anywhere, no specific cloud is required. Useful if you have customers on differing platforms (on cloud / on-prem- or just different clouds)
• Cheap to run, mostly as a consequence of being vendor agnostic, provided that:
• The SaaS is operationally simple to manage and run. Upgrading existing customers whilst allowing new customers to join. See Operational Simplicity (Abhashkumar et al, 2021)
• Each customer is deployed independently, with their own database. Almost nothing is shared. We're not quite a "shared nothing architecture", but close.
  

Why not multi tenancy?

This is a choice. I don't like multi tenancy because it makes upgrades harder, downtime is for every customer, and separating* customer data may be harder. Go find the talk on Youtube where Bitbucket engineering walk through these growth pains.

"Multi tenancy" for some applications, comes from a time when there wasn't the commodity of tools to orchestrate many single tenants. The argument used to be, "gee, we can't possibly manage that many individual deployments", except that argument no longer holds water so-long-as you're willing to embrace the tooling available. Better tools.

*Separating customer data is unclear, motivated mainly by cost and compliance requirements (e.g. data separated by a database field? Or separated by a physical machine?)

How do you define SaaS?

Firstly let's define what I mean by SaaS, because there's different views on what this means.

I define it to include:

• Little to no human intervention required. A new customer can be onboarded without human intervention.
  Stark contrast: It takes human intervention (perhaps even an internal 'ticket' is created before a customer can use your product. 'Contact us' 🤢)
• Instant onboarding. The time for a customer to create a new account and start using the product is minutes, ideally seconds.
  Stark contrast: It takes many hours/days (weeks?) for a new customer to begin* getting value from your product

"But I'm an enterprise" this can't work for me, our product is complex

Rubbish. Either you can operate at scale or you cannot. This is about fast feedback loops.

If your system is complex, there's still no excuse. You can onboard new customers into a shell of your application as additional features are ready. This is a great place to collect mandatory information which is needed to provision a more complex system once the requirements are clear, rather than outside of (said another way: stop building your core product inside Jira).

But due diligence and KYC. Again, look at challenger banks like Starling (UK), N26 (Germany), or ride sharing companies like Bolt, they all have strict regulatory and safety concerns. They all use SaaS know-your-customer (KYC) services to onboard their customers.  

But why no Kubernetes?

I love Kubernetes (I'm a certified Kubernetes administrator), we even implemented it, but at the time is was too expensive for me to justify the costs. Note the goals defined earlier.

The rules of cloud native without vendor lock-in

• Standardise on compute and storage this means don't use managed services which lock you into a certain vendor. Instead, limit yourself to ec2 instances (aws), bare metal instances (on-prem) , cloud compute (gcp) and install a container orchestrator on them (e.g. Kubernetes, nomad). This frees you up to be able to deploy to different customers, regardless of their environment. No, it's not a silver bullet, but if you go all-in on managed services with a particular cloud vendor you've already lost the ability to serve customers on different platforms.
• Avoid using sticky managed services. Standardise on compute, and storage.