Also the cost of those services vs. a few well-configured basic VPS hosts is nuts. I was shocked to learn that to get MySQL/Postgres in GCP it's often >$40/month - even for the insanely tiny instance sizes. We're talking for like 20G storage...

In contrast I've ran some pretty hot-and-heavy MySQL/Postgres databases on basic DO/Linode VPS's for half of that cost with much success. I get these cloud tools give a ton of "out of box" features - but you are paying for it at the end of the day.

Anecdotally I've noticed a huge shift away from general devs/engineers having general CLI/Linux/sysadmin knowledge.

If you had no knowledge on standing up a DB server (installing, configuring, monitoring, logging, access control, and backups, restricting network access), how much time would that take you to learn? That and your VPS requires setup for access control, patches, updates, monitoring, logging.

Point taken, upvote given, but for a lot of people standing up a standard redundant DB config for MySQL and Postgres isn't that big of a deal.

I say this as an engineer who has a ton of relational DB experience. Before cloud providers w/DB options were so plentiful devs/engineers/sysadmins would have to set this up by hand.

---

> If you had no knowledge on standing up a DB server

My point is, "but yea what if you do?" There's actual value in that I've found, especially when I'm looking to save pennies at the early-stage of a startup while in the customer aq phase. Many folks have expertise in those areas without needing a cloud provider.

I do get the "but all of these things!" argument (access control, patches, updates, monitoring, logging) but often those are easily solved/solvable problems even without leveraging cloud offerings. I can get very far along with an ELK/TIG stack + uptime robot and basic VPS networking features... all for a very affordable monthly bill on the infra.

Starting a db on a web-server and running apt update/upgrade are fundamental parts of working on the web.

If you or any of your developers don't know how to do that, you/they should seriously seriously spend the 40 minutes it takes to learn.

I feel like that’s where you separate the pre-cloud and post-cloud devs.

It’s not hard to imagine a dev being brought up 5 years ago into a React world, with JS in the backend and something like Vercel or Netlify to deploy their app.

Someone like that might be entirely uncomfortable when dumped into a plain old Linux server, and would definitely take longer than 40 minutes to even get their head wrapped around what’s going on.

That’s not a knock on them - they get their job done, and to the business that’s all that matters. But yeah, just trying to, I don’t even know, empathise? Try to understand? Who knows. It’s just a different world now.

Symapthy, is more like it. Theyve been convinced by the cloud rental services that it's different now and too hard, when it's really not because all that SaaS is still running on a webserver. There's just a new gate keeper with a huge marketing budget that charges by the minute now.

> and would definitely take longer than 40 minutes to even get their head wrapped around what’s going on.

If a grown up person (who is presumably making a good money in their React/JS thing) can't figure on how to install a web server in 40 minutes (with all SO, Google and a bazillion of articles on how to do so) then...

Like come on, twenty years ago you still needed to get your ass off the chair and go to the bookstore, find and buy a proper book and actually read it. Now you just need to type "Ubuntu 20 install webserver" in to the search and voila.

The same amount of time if I would need to "stand up" a rented DB, including figuring out a bazillion of providers and options, configuring proper instance sizes, turning needed knobs for backups to work... Or you suppose what a rented service doesn't need anything at all?

Serverless is almost always a trivial cost compared to VPS. With lambda, you get like 1M free invocations per month and the price per ms is `$0.0000000017` for 128MB on ARM.

If your endpoint takes 10ms to run and you're running it constantly for a month, it will cost you less than $0.05 (it will actually be about half of that because you get the first 1M invocations free each month, but ignoring that...).

As you point out, running RDS is more expensive, but RDS isn't serverless. You would probably want to look at DynamoDB for a serverless database, which is considerably more affordable than RDS.

Moreover, the serverless stuff is considerably easier to configure and operate than a VM.

A 10ms invocation sounds like a myth. I've certainly never seen one that low for a lambda that actually does anything. All the serverless stuff I've worked with (mostly in Python) operates slower than a CGI script. 100's of milliseconds minimum. When your serverless endpoint needs to integrate with other AWS services, the configuration can get complicated fast. VPC endpoints, IAM roles, security groups... it goes on and on.

If your lambda runs very infrequently, you'll see more cold starts which will take hundreds of ms, but warm starts are pretty easily in the single-digit milliseconds (at least for a Go lambda). If you're doing a bunch of compute or sync I/O in a loop then your functions will take longer.

But less frequent invocations are actually an even better case for Lambda versus a VPS because it suggests less wasted time (yeah, you have to pay for cold starts, but with a VPS you're paying for all of that time your service is up irrespective of whether or not it's being used).

> 100's of milliseconds minimum. When your serverless endpoint needs to integrate with other AWS services, the configuration can get complicated fast. VPC endpoints, IAM roles, security groups... it goes on and on.

This is all true for a VPS as well. Assuming you care about reliability, you need to run multiple instances of your VPS behind a load balancer which implies a fair bit of networking. Moreover, you need to manage the hosts themselves, so configuring log aggregation, metrics collection, process management, SSH, deployment, hardening, etc, etc, etc.

Further still, your compute will need to communicate with the comparable services as in your lambda hypothetical, so you still need to deal with IAM and some more networking stuff. Maybe you'd say "gotcha! I would just run my databases on my VPS instances!" which is cool, but now you need to configure monitoring, backups, replication, failover, and so on for your databases versus using DynamoDB (and I would bet a lambda/dynamodb workload than the same workload on a reliable VPS/whatever-database stack).

Of course, if you're running a hobby blog or something that doesn't need reliability of scalability, then a $5 VPS is probably fine (maybe even an S3 bucket behind a CloudFront distribution, which would likely be free).

Yes, cold starts are definitely a problem. One of the advantages of VPSes is its all hot, ready to go, obviously. You pay for that performance, for that lower latency, and I'm fine with that.

My big problem with lambda / serverless is the developer experience is pretty awful. The time between making a change, deploying, and seeing the result of that change is slow. You can work around this (with tools like localstack), but it's often not close enough to the real environment. You'll still waste tons of time debugging permissions issues when you do a real deploy.

Yeah, it depends on the application. If you're very latency sensitive, then you'll probably want to keep your lambda warm or just pay more for VPS. But the original context was cost, not latency.

> My big problem with lambda / serverless is the developer experience is pretty awful. The time between making a change, deploying, and seeing the result of that change is slow. You can work around this (with tools like localstack), but it's often not close enough to the real environment. You'll still waste tons of time debugging permissions issues when you do a real deploy.

I haven't had much of a problem. Once I figure out the shape of the inbound payload, it's pretty easy to test locally. I can't think of any reason the runtime environment would be an issue. Debugging IAM is tedious, but I just created one Terraform module that I use for all of my functions so I don't have to slog through the IAM stuff every time I make a function.

I personally have not had a lot of problems with local lambda development. However, when assisting coworkers, I often see problems where dependencies aren't packaged properly (lambda layers), permissions are missing, code is not properly modularized (everything in one big handler file), people editing code live on AWS to debug problems they can't replicate locally, etc.

> Moreover, the serverless stuff is considerably easier to configure and operate than a VM.

Yep - and to be 100% candid on my current project I'm running 100% with GCP Functions, AppEngine Task Queues, and Firestore for persistence. I'm also AWS certified and have worked as a DevOps engineer in a PCI-regulated environment leveraging things like DyanmoDB, Lambda, etc.

Cool part about running that way is my current billing is near zilch. Woo! Totally on-board with what you're saying... literally living it now =)

I'm just saying that there's a ton of ways to skin a cat. And, personally I wouldn't paint with as large of a brush to say "serverless stuff is considerably easier to configure and operate than a VM." A lot of times this rings true, but I anecdotally wouldn't say it is always the case.

I'm being pedantic, but I'm also trying to make a case that not always do cloud design patterns/"best-practices" make sense.

> Serverless is almost always a trivial cost compared to VPS.

Not my experience. Our AWS lambda cost is close to $1K/month and the usage isn't that much so we could easily host this on a few (for redundancy) of the smallish VPS instances for far less money.

For batch workloads (not latency sensitive, can run at or near full capacity, etc), but most of the time Lambda is more affordable. You'll need to say more about your workload though.

Take for example OS and app upgrades. Quite often you have few requirements, for example 1)all updates should be first tested in test env 2)updates need to be installed in timely manner 3)critical updates need to be installed quickly (30 days is too slow)

When you start thinking these, they are not so easy. (1) means you can’t just run “apt upgrade” on every server - you need to manage the updates to make sure they get tested first. (2) is kind of ok, but requires some work on regular basis (at least checking things) (3) means you need to monitor the updates for your stack and classify them. You can get feeds for example for Ubuntu, but does that cover whole stack. And checking these weekly (or daily) actually gets boring.

All this stuff can be done, but IMHO it is time consuming and takes time from more important things. The weekly/monthly JIRA tickets for checking x, y and z get quite annoying when you also have n other things to finish. Then you start slacking on them and feel the pain when trying to collect evidence for the next procurement process check.

If you have tens or hundreds of servers and can have a separate infra team with professional sysadmins then this is all fine. My rant is mainly for small teams, where same guys are supposed to develop and run things.

Small teams should just configure apt unattended upgrades and call it a day. I do this with my personal server and haven't had any issues for years.

You should probably reboot it then.

I'd rather have to to plan and budget than have to deal with patching (after testing the patch) every piece of software on a system the moment a patch comes out to avoid an undetectable rootkit being installed during that gap

An occasional $4K charge is negligible for a business (almost everyone is better off dealing with this sort of overrun than troubleshooting servers, all else equal), and anyway this is a particularity of AWS CloudFront's billing protections rather than a fundamental flaw with serverless.

In most countries in the world, $4K charge is absolutely not negligible.

I doubt this is true. If you're operating a tech company anywhere in the world, I'm guessing $4K is pretty close to negligible. In whatever case, indexing by country is misleading, "tech companies" in general is more interesting, if there are a handful of tech companies in the third world for which this doesn't hold, it doesn't invalidate the generalization.

In SMB companies around the world "an occasional $4K charge" is definitely not negliable.

Again, we’re not talking about SMBs, we’re talking about tech companies generally. (What share of SMBs are there doing serverless or with any cloud footprint at all?)