3 ms·

I’m going to have to disagree with this. There are different shades of serverless, and you don’t start at an R620 plugged into a colo rack. You grow into it OR

I’m going to have to disagree with this. There are different shades of serverless, and you don’t start at an R620 plugged into a colo rack. You grow into it OR start with a large enough problem to demand it. You start with GitHub pages or Cloudflare pages where all you have is CSS, HTML, and JS served from the equivalent of a global CDN that you didn’t have to build for essentially free. For a mom and pop shop, how many times are they going to have to contact you over the next 20 years for a piece of software doing its job running on GitHub pages? Practically zero, unless it’s a feature request. Can’t say the same for a Linux box plugged into the wall under your desk or an R620 at the colo downtown. Then you graduate to sprinkling a little bit of persistent state in. When you need a little bit of persistent state for a small mom and pop, deciding to vet colo vendors and signing that shop up to be responsible for sysadmining an R620 with a Linux kernel is irresponsible. You find a serverless vendor for your DB layer (like the Firebase of yore) or a set of CRUD handlers written on infra that fully manages the language runtime, operating system, kernel, and infra for your customer (like Cloudflare workers). How many times is the customer going to need to contact you over the next 20 years for your Cloudflare worker? Probably only a handful. Odds are, significantly less than an R620 plugged into a server rack at the colo downtown. If you outgrow this, you probably are starting to look at VMs or colo. Serverless is real. It’s not lambda. It’s pervasive. It’s provides substantial value in ongoing maintenance and engineering costs if you pick the right vendor. And a majority of the market demands it as a starting point. An engineer is expensive and most customers aren’t in a position to practice the craft themselves. The best service we can provide is to minimize their dependence on our field.

danielheath 3y ago
> How many times is the customer going to need to contact you over the next 20 years for your Cloudflare worker? Probably only a handful. Odds are, significantly less than an R620 plugged into a server rack at the colo downtown. This has nothing to do with "serverless". Heroku did the same thing well before serverless was available. Keeping a simple app running on heroku over the past 15 years has required about 3 hours admin total since I set it up (moving from an old stack to a newer one).
- r3trohack3r 3y ago
  Agreed. Serverless is a spectrum. Heroku for sure sits on that spectrum. At it core serverless is about delegation of responsibility and how much responsibility you can push across the vendor boundary.

danielheath 3y ago

> How many times is the customer going to need to contact you over the next 20 years for your Cloudflare worker? Probably only a handful. Odds are, significantly less than an R620 plugged into a server rack at the colo downtown. This has nothing to do with "serverless". Heroku did the same thing well before serverless was available. Keeping a simple app running on heroku over the past 15 years has required about 3 hours admin total since I set it up (moving from an old stack to a newer one).

r3trohack3r 3y ago
Agreed. Serverless is a spectrum. Heroku for sure sits on that spectrum. At it core serverless is about delegation of responsibility and how much responsibility you can push across the vendor boundary.