I'd rather worry about (and fix) those technical problems then having to deal with possible billing-pocalyse.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
> 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.
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.