4 ms·

Well, your users are gonna have a fun time when linode has to take down your single vpc for maintenance, or an AZ goes down (does linode even have AZs? There's

by 013a 8y ago

Well, your users are gonna have a fun time when linode has to take down your single vpc for maintenance, or an AZ goes down (does linode even have AZs? There's some evidence that even GCP doesn't have truly redundant AZs, so I doubt Linode could.) Point being: its a balance. I tell any startup who will listen: App Engine or Heroku. That'll get you REALLY far and strike a good balance between autoscaling, simplicity, and redundancy. If you're still using a single server, you're doing something horribly wrong. This random guy's strategy isn't something to be proud of. He just doesn't know that there are better options out there. Simplicity isn't a VM you have to maintain, update, and secure. Its a fully managed PaaS.

michaelbuckbee 8y ago
I'm 100% on board with "start with Heroku or App Engine" and then you can just layer in other services as you need. Where I see teams get caught up is that they compare the price of a single VPS with a handful of Heroku Dynos and think it's much too expensive. As soon as you add in any amount of sysadmin time, security work, etc. it becomes absurdly better.
- 013a 8y ago
  Yup. The cost is so irrelevant, its a little laughable how many other people keep bringing it up. The relevant metrics are People and Risk. If you host your own VM; ok, maybe it works great for you and you don't have to touch it. But the future risk of something bad happening is High. And when that does happen, if an engineer has to take 1 day to fix it, you'll have literally paid the difference for a PaaS for the rest of the year. But, again, cost doesn't matter. What really matters is that engineer had to WASTE a day working on it. That's a day that could have been spent advancing the product toward market fit. That's a day when that engineer wasn't coordinating with the rest of the team. That sets back her work by a day, which might block another engineer by a day, and it ripples down and down. That's not something startups want to happen. Because Engineers are expensive, yes, but more importantly, they're hard to find. You can't just throw money at hiring talent like you can at Heroku (or App Engine, or Lambda, or whatever works best for your business).
  - Chyzwar 8y ago
    These hands-off solutions might be expensive in operational/dev time as well. You might end spend days coding against the arbitrary limitation of managed services or debugging cryptic errors in the distributed application. My experience with lambda as an application platform is pretty bad. EC2 instance gives you plenty of technical flexibility that startup needs as much as velocity to find a market fit.
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 ago
  The 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 ago
    That 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 ago
  Availability 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.
hrktb 8y ago
I know Heroku is pretty painless except when trying to do weird things (use a wildcard certificate from let's encrypt comes to mind, though it might be OK now) where it can become weirdly complicated as we have to think about stuff that was hidden before (how are the request routed ? how is the certificated handled ? how to renew it ? etc) How does App Engine compare ? From a bird's eye, it seems a lot of configuration is still needed to communicate within Google's ecosystem and as Google also pushes k8s, I wondered how much resources they were putting in App Engine to have it run smoothly vs k8s where they are the main driver force and have a natural advantage over the concurrents.
hw 8y ago
> If you're still using a single server, you're doing something horribly wrong This is so far from the truth. If you built your (fairly new) app, especially a new app, such that it requires multiple servers, then you're overthinking infrastructure at a time when you don't need it. Having multiple servers is great, but having a lean app that can run on a single server requires a different skillset. You don't need HA, multi-AZ AWS deployments behind a load balancer with route 53 DNS load balancing powered by auto scaling fleets with ci/cd jenkins and slack chat ops when you only have a small number of users.
- 013a 8y ago
  You can pick one sentence out of my comment and tear it apart, or actually read and understand the whole thing. Your choice. Managing servers is something no startup should be doing. Period. If you can SSH into it, you're wasting time on infrastructure that could be spent finding product-market fit. The number of servers isn't the relevant points; its the fact that he's using ANY servers.
  - hw 8y ago
    I get that part. If only all startups could afford managed PaaS services. I might be biased given I've spun up and managed my own infrastructure without much difficulty, and I can see how some startups would prefer spending the dough on PaaS instead of say hiring or putting it towards marketing. I just had an issue with that blanket statement that it's not kosher to be using a server still. It's totally fine for a startup to be managing their own infrastructure if they've done the cost benefit analysis on it.
    - spookthesunset 8y ago
      Startups can’t afford not to use PaaS. Every second of time they piss away managing their home brew platform is a second they aren’t spending time making their product something people actually want. Managing infrastructure is a solved problem for any startup. Simply spin something up on a heroku-like platform and be done. Anything else is wasting precious time and money.
JohnFen 8y ago
> Simplicity isn't a VM you have to maintain, update, and secure. Its a fully managed PaaS. I disagree with this if you actually intend it in the blanket form you present it as. A fully managed PaaS can be the simplest solution overall, but it can also be overly complex. It all depends on what you're trying to do and what your needs actually are.
jwr 8y ago
The implications of downtime must be considered in a business context — otherwise this kind of discussion makes little sense. You need to set service level objectives (SLOs) for your business. In some businesses, your SLOs will force you to implement high-availability solutions. In other businesses, your users are not paying for high availability, and you are doing nothing wrong by using a single server, assuming you can recover from a failure in a predictable amount of time, meet your SLOs and not lose data in the process. I agree with the article author: engineers tend to go way overboard, and often nobody asks the really important question: who will pay for those tight SLOs?

by 013a 8y ago

michaelbuckbee 8y ago

I'm 100% on board with "start with Heroku or App Engine" and then you can just layer in other services as you need. Where I see teams get caught up is that they compare the price of a single VPS with a handful of Heroku Dynos and think it's much too expensive. As soon as you add in any amount of sysadmin time, security work, etc. it becomes absurdly better.

013a 8y ago
Yup. The cost is so irrelevant, its a little laughable how many other people keep bringing it up. The relevant metrics are People and Risk. If you host your own VM; ok, maybe it works great for you and you don't have to touch it. But the future risk of something bad happening is High. And when that does happen, if an engineer has to take 1 day to fix it, you'll have literally paid the difference for a PaaS for the rest of the year. But, again, cost doesn't matter. What really matters is that engineer had to WASTE a day working on it. That's a day that could have been spent advancing the product toward market fit. That's a day when that engineer wasn't coordinating with the rest of the team. That sets back her work by a day, which might block another engineer by a day, and it ripples down and down. That's not something startups want to happen. Because Engineers are expensive, yes, but more importantly, they're hard to find. You can't just throw money at hiring talent like you can at Heroku (or App Engine, or Lambda, or whatever works best for your business).
- Chyzwar 8y ago
  These hands-off solutions might be expensive in operational/dev time as well. You might end spend days coding against the arbitrary limitation of managed services or debugging cryptic errors in the distributed application. My experience with lambda as an application platform is pretty bad. EC2 instance gives you plenty of technical flexibility that startup needs as much as velocity to find a market fit.

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 ago
The 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 ago
  That 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 ago
Availability 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.

hrktb 8y ago

I know Heroku is pretty painless except when trying to do weird things (use a wildcard certificate from let's encrypt comes to mind, though it might be OK now) where it can become weirdly complicated as we have to think about stuff that was hidden before (how are the request routed ? how is the certificated handled ? how to renew it ? etc) How does App Engine compare ? From a bird's eye, it seems a lot of configuration is still needed to communicate within Google's ecosystem and as Google also pushes k8s, I wondered how much resources they were putting in App Engine to have it run smoothly vs k8s where they are the main driver force and have a natural advantage over the concurrents.

hw 8y ago

> If you're still using a single server, you're doing something horribly wrong This is so far from the truth. If you built your (fairly new) app, especially a new app, such that it requires multiple servers, then you're overthinking infrastructure at a time when you don't need it. Having multiple servers is great, but having a lean app that can run on a single server requires a different skillset. You don't need HA, multi-AZ AWS deployments behind a load balancer with route 53 DNS load balancing powered by auto scaling fleets with ci/cd jenkins and slack chat ops when you only have a small number of users.

013a 8y ago
You can pick one sentence out of my comment and tear it apart, or actually read and understand the whole thing. Your choice. Managing servers is something no startup should be doing. Period. If you can SSH into it, you're wasting time on infrastructure that could be spent finding product-market fit. The number of servers isn't the relevant points; its the fact that he's using ANY servers.
- hw 8y ago
  I get that part. If only all startups could afford managed PaaS services. I might be biased given I've spun up and managed my own infrastructure without much difficulty, and I can see how some startups would prefer spending the dough on PaaS instead of say hiring or putting it towards marketing. I just had an issue with that blanket statement that it's not kosher to be using a server still. It's totally fine for a startup to be managing their own infrastructure if they've done the cost benefit analysis on it.
  - spookthesunset 8y ago
    Startups can’t afford not to use PaaS. Every second of time they piss away managing their home brew platform is a second they aren’t spending time making their product something people actually want. Managing infrastructure is a solved problem for any startup. Simply spin something up on a heroku-like platform and be done. Anything else is wasting precious time and money.

JohnFen 8y ago

> Simplicity isn't a VM you have to maintain, update, and secure. Its a fully managed PaaS. I disagree with this if you actually intend it in the blanket form you present it as. A fully managed PaaS can be the simplest solution overall, but it can also be overly complex. It all depends on what you're trying to do and what your needs actually are.

jwr 8y ago

The implications of downtime must be considered in a business context — otherwise this kind of discussion makes little sense. You need to set service level objectives (SLOs) for your business. In some businesses, your SLOs will force you to implement high-availability solutions. In other businesses, your users are not paying for high availability, and you are doing nothing wrong by using a single server, assuming you can recover from a failure in a predictable amount of time, meet your SLOs and not lose data in the process. I agree with the article author: engineers tend to go way overboard, and often nobody asks the really important question: who will pay for those tight SLOs?