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

  • AuroraZeroAuroraZero ModeratorHosting Provider

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

    Thanked by (2)FrankZ skorous

    Free Hosting at YetiNode | Cryptid Security | URL Shortener | LaunchVPS | ExtraVM | Host-C | In the Node, or Out of the Loop?

  • bikegremlinbikegremlin ModeratorOGContent Writer

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

    Thanked by (1)yoursunny

    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.

  • @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...

    Thanked by (2)bikegremlin Chievo

    Lead Platform Architect at the day job, Ethical Hacker/Bug Bounty Hunter on the side

  • bikegremlinbikegremlin ModeratorOGContent Writer

    @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. :)

    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

  • @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

    I believe in good luck. Harder that I work ,luckier i get.

  • havochavoc OGContent Writer

    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

  • @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.

    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.

    Thanked by (2)Chievo FrankZ

    BillingServ - Easy, simple, and hassle-free online invoicing solution. Contact us today.
    BaseServ Certified to ISO/IEC 27001:2013

Sign In or Register to comment.