3 ms·
I'm not sure when exactly this shift happened, but people (myself included) fetishize high availability so much nowadays. What would really happen if your start
by nickdandakis 8y ago
I'm not sure when exactly this shift happened, but people (myself included) fetishize high availability so much nowadays. What would really happen if your startup-of-the-year with less than 1k active users was down for five minutes? Or an hour? Do you really think people visiting a site that's down think "I'm dropping my account"? Or do they think "Oh. I'll check back later."?
NomadList and RemoteOK (from the article) have both had downtime before. They're both much more profitable than whatever startup of the day has decided they desperately need complicated infrastructure to run their CRUD app.
I've fallen for this trap also. I've written an article about deploying a Next.js app to Elastic Beanstalk, when I probably could've just stood up a server and SSH'd in to deploy. I've used Firebase when I could've just stood up a simple REST API and PostgreSQL.
There's nothing horribly wrong with using a single server, he knows there are other (not better) options out there.
- sbov 8y agoThe shift started back in the late 2000s when the explosion of NoSQL and AWS made it easier than before for people to pretend they have problems they don't. Before NoSQL you had to do expensive/difficult stuff like manual database sharding and buying expensive dedicated hardware. Now you can instantly spin up a few instances. Considering how much easier it is to put the infrastructure in place IF you ever need it, its odd to me how focused on it people seem to be.
- nickdandakis 8y agoThat makes a lot of sense, and if that's the case, I'd chalk it up to advertising for convincing people they _need_ all of this type of infrastructure.
- 013a 8y agoAvailability is a spectrum. There's a lot of room between "a single VM on a third-tier infrastructure provider" and "google.com". Hell, even "two VMs on a third-tier infrastructure provider" is better than 2x better availability, because there are discrete events which impact a single VM and don't impact two. Startups should be taking the easiest route possible to Happy Customers. That's the goal. There are two parts to that: "Happy" and "Customers". You need Customers. That's product-market fit. You also need them to be Happy. Availability is a part of that. No, a startup does not need a multi-regional strategy behind redundant global ELBs with edge caching. I never said that. You know what's pretty damn easy though? HEROKU. You spin up multiple dynos and you get multi-AZ redundancy, NO EXTRA WORK. App Engine is the same way. Startups, everywhere, for the love of god, stop spinning up servers. If you can SSH into it, that's a smell. If you HAVE to ssh into it, you're wasting resources. There are so many different "serverless" options out there. Focus on the product. The infrastructure can wait. Its not going anywhere.
- secabeen 8y agoYeah, my users really don't care. I have an explicit service availability policy that says any support at all between the local hours of 11pm-7am is on a best effort basis, and support outside of normal business hours is limited. Our services are normally available 24x7, but more than half of them even have pager notifications turned off between midnight and 6am, so that my staff can sleep. As long as things are back and functional by 9am or so, everyone is happy. It's just a different world outside of the startup, "My total possible user-base is all 7 billion people in the world!" world. This is HN, so startups are the correct, default assumption, but I do see a lot of this worldview leaking into the non-startup worlds as well.