High availability for SaaS: from day one or can it wait?

vitobotta

I am planning to relaunch my SaaS in around 3 months, but I haven't decided yet what to do about infrastructure. When I was running the previous iteration of the project I set up a proper Kubernetes cluster with autoscaling and everything, absolutely everything, was set up in highly available configuration to minimise risks of downtime.

However at the moment, during development, I am using a single VPS with Dokku to deploy the app and I just love the simplicity, and this is coming from a die hard Kubernetes fan.

So the question I have for you is, do you think that I should have a highly available setup from day 1 considering that it's a SaaS to build and host static sites and blogs? Or would it be OK to keep this ridiculously simple single-server configuration for now, until I gain some traction?

To be honest I would like to keep this simpler setup for a while, but I am worried of what people might say if they experience downtime. I mean, I know that even massive companies suffer from outages but still....

What do you think?

AuroraZero

Maybe setup a failover instead of high availablity to start. If things gain traction then switch to HA.

bikegremlin

A digression:
It is interesting to see how the term "static website" no longer means what it used to.

Chievo

HA from day one be the cool kid in the town

vitobotta

@AuroraZero said:
Maybe setup a failover instead of high availablity to start. If things gain traction then switch to HA.

If I have to do that then I might as well just set up K8s with the tooling I am used to.

@bikegremlin said:
A digression:
It is interesting to see how the term "static website" no longer means what it used to.

Yeah it's a bit weird in this case since you are able to compose pages with templates shared by multiple pages and things like that... so perhaps I shouldn't use the "Static" wording.

@Chievo said:
HA from day one be the cool kid in the town

The thing is, last time I invested a lot of time and money to make the infra very resilient and scalable and then I was disappointed by the demand early on... that's why I wonder whether I should just keep it simple until I see if there is real demand...

bikegremlin

@vitobotta said:

Yeah it's a bit weird in this case since you are able to compose pages with templates shared by multiple pages and things like that... so perhaps I shouldn't use the "Static" wording.

Static vs dynamic websites, as defined before WordPress and the 10-second attention span.

Chievo

@vitobotta said:

@AuroraZero said:
Maybe setup a failover instead of high availablity to start. If things gain traction then switch to HA.

If I have to do that then I might as well just set up K8s with the tooling I am used to.

@bikegremlin said:
A digression:
It is interesting to see how the term "static website" no longer means what it used to.

Yeah it's a bit weird in this case since you are able to compose pages with templates shared by multiple pages and things like that... so perhaps I shouldn't use the "Static" wording.

@Chievo said:
HA from day one be the cool kid in the town

The thing is, last time I invested a lot of time and money to make the infra very resilient and scalable and then I was disappointed by the demand early on... that's why I wonder whether I should just keep it simple until I see if there is real demand...

True you must save money and time but the product would not be "finished" .You must think about it and well what you select would be OKish in any case

havoc

Unless you're very clued up on k8s it's more likely to reduce availability than increase it. Too many footguns

I prefer using a CDN for the primary hosting and something serverless to deliver the dynamic bits but very dependent on the nature of the SaaS

vitobotta

@havoc said:
Unless you're very clued up on k8s it's more likely to reduce availability than increase it. Too many footguns

That's not an issue, I have been working with it for years and it's actually what I am mostly comfortable with these days in terms of severs and infrastructure.

Jord

We started with just two servers, which would power our platform, one for the control panel to set up the service and one to run it. But we noticed that we quickly outgrew that set-up.

We then started to get questions about different regions, so we created Pods, one for the US and one for the EU; multiple servers in each pod would communicate with each other, and keep each other synced for example the databases, but everything was separate. EU businesses would use our EU Pod which means no data is then transferred away from the EU. Our ID system takes care of SSLs, custom domains, and keeps that synced between the pods.

We used to use GDNSD for our geodns, which would send our users to the closest server, this would also remove the server from rotation if it was detected down. We've since switched to BunnyDNS for this, as it provides us with a better way to streamline how we do our DNS. Removing the need for GDNSD.

We have high availability now for all systems, each pods are independent from each other, multiple servers in each pod so we can lose a few servers and keep our uptime high. Processing Payments/Invoices means we need to provide as much uptime as we can. It also allows us to do maintenance without affecting our users.