High availability for SaaS: from day one or can it wait?
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?
Lead Platform Architect at the day job, Ethical Hacker/Bug Bounty Hunter on the side
Comments
Maybe setup a failover instead of high availablity to start. If things gain traction then switch to HA.
Free Hosting at YetiNode | Cryptid Security | URL Shortener | LaunchVPS | ExtraVM | Host-C | In the Node, or Out of the Loop?
A digression:
It is interesting to see how the term "static website" no longer means what it used to.
Relja of House Novović, the First of His Name, King of the Plains, the Breaker of Chains, WirMach Wolves pack member
BikeGremlin's web-hosting reviews
HA from day one
be the cool kid in the town
I believe in good luck. Harder that I work ,luckier i get.
If I have to do that then I might as well just set up K8s with the tooling I am 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.
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...
Lead Platform Architect at the day job, Ethical Hacker/Bug Bounty Hunter on the side
Static vs dynamic websites, as defined before WordPress and the 10-second attention span.
Relja of House Novović, the First of His Name, King of the Plains, the Breaker of Chains, WirMach Wolves pack member
BikeGremlin's web-hosting reviews
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
I believe in good luck. Harder that I work ,luckier i get.
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
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.
Lead Platform Architect at the day job, Ethical Hacker/Bug Bounty Hunter on the side
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.
BillingServ - Easy, simple, and hassle-free online invoicing solution. Contact us today.
BaseServ Certified to ISO/IEC 27001:2013