Live data from Hacker News

Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?

rehanvdm.com

111–120 of 131 posts

Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?

#111
post #84

Earlier quoted context omitted.

always-on EC2 instances start at like $20/mo? I don't understand this argument whatsoever. > Seeing your costs drop below a dollar/month on a project you are building is amazing. Honestly, this just means you don't have any users

> Honestly, this just means you don't have any users Which is where many small ideas start. My buddy had an idea for a few SaaS products and I've helped him develop them. The initial costs were small, but give it was an expense with no income in the near future, finding a way to scale to zero was the only way this became something he'd consider. It's got _very_ sporadic use currently and his bill for each service is…

And that’s totally fine. I have similar stuff setup for hobby projects. But my impression is that this thread is mainly about “real” architecture (for lack of a better word”

Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?

#112

Earlier quoted context omitted.

I just can't get my head around this argument of 'scales to zero'. If you have one or more professional developers working on a project how can you be bothered about an extra $20-$200/month when you know you'll also be spending a couple of engineering hours (worth more than $200) on migrating later?

Scales to zero means you can span as many environments as you want and don’t bother. Every dev can have multiple environments to demo features and do experiments.

Isn’t that what local machines are for?

If you’re in territory where running locally isn’t feasible you’ve either done something horribly wrong or have scaled way past the point where either a single lambda or single ec2 instance is sufficient.

Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?

#113

Earlier quoted context omitted.

Good old HN, "just self-host with onprem". Who monitors it 24/7 and checks the alerts? Who drives to the data center to fix broken hardware on Christmas Day? It has to be multiple "whos" or one sick leave will leave you completely vulnerable. For small-medium companies whose main business isn't hosting software this makes it untenable from a financial point of view. For the monthly salary of a single SRE/devops/admin…

Basecamp is a small-medium company and leaving the cloud was a huge win for them: https://world.hey.com/dhh/we-have-left-the-cloud-251760fb

Basecamp is an anomaly on pretty much every vector imaginable.

They have been remote-first (remote-only?) since forever, they still use Ruby in production, have never taken VC money and they've never even tried to do a hockey stick growth unicorn hack. They're still under 40 people.

Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?

#114

Earlier quoted context omitted.

Sounds like a cool hack, but why not just self-host with on-premises hardware, or rent a cloud server from a hosting provider like e.g. Digitalocean? Then you wouldn't have to worry so much about what Microsoft wants, no?

Good old HN, "just self-host with onprem". Who monitors it 24/7 and checks the alerts? Who drives to the data center to fix broken hardware on Christmas Day? It has to be multiple "whos" or one sick leave will leave you completely vulnerable. For small-medium companies whose main business isn't hosting software this makes it untenable from a financial point of view. For the monthly salary of a single SRE/devops/admin…

It's basically impossible to make managed hosting more expensive than cloud. Marginally easier for actual on prem or colocated setups because there is more room for error.

The devops time you need to provide to manage most cloud setups is generally far higher than what it'd cost you to get someone to manage your managed servers both in time and retainers to have someone to escalate to. When I was consulting, cloud focused customers were gold dust because they needed so much more help and had no notion of cost control.

The idea that cloud is cheap is pure fiction from people who haven't run and costed both.

Put another way: The notion that anyone needs to drive to the data centre reflects a very outdated idea of both.the alternatives and the support options available if you actually choose to own the servers rather than rent managed servers.

I used to manage a setup spread over multiple data centers, and the only visits to the data centre were scheduled trips 3-4 times a year. We regularly priced out cloud alternatives, and every time it'd have bankrupted the company if we'd switched.

I love using cloud when working places with margins enough to afford it, but it's an expensive luxury and the idea it's a cost saving really needs to die, because it takes a really large setup where you have power to demand crazy discounts, and a lot of engineering, to even get close to break even against a moderately competently set up managed setup.

Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?

#115
post #114

Earlier quoted context omitted.

Good old HN, "just self-host with onprem". Who monitors it 24/7 and checks the alerts? Who drives to the data center to fix broken hardware on Christmas Day? It has to be multiple "whos" or one sick leave will leave you completely vulnerable. For small-medium companies whose main business isn't hosting software this makes it untenable from a financial point of view. For the monthly salary of a single SRE/devops/admin…

It's basically impossible to make managed hosting more expensive than cloud. Marginally easier for actual on prem or colocated setups because there is more room for error. The devops time you need to provide to manage most cloud setups is generally far higher than what it'd cost you to get someone to manage your managed servers both in time and retainers to have someone to escalate to. When I was consulting, cloud fo…

> It's basically impossible to make managed hosting more expensive than cloud.

So, I've got 6 different backend services running as monolithic Lambda functions. They all must be up for a number of nines per year, each going down will cost our company actual money for every second of downtime. They've never been down except when AWS broke something - and then the customers couldn't have accessed them anyway.

Can you tell me how I can host 6 services that can't be on the same machine in a managed system cheaper than my current setup? 6 servers, preferably each duplicated.

We'll assume that all the other AWS services we use can "just" be replicated in managed hosting too. (DynamoDB, S3, Aurora and a bunch of others).

Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?

#116

Earlier quoted context omitted.

ECS doesn't a) scale to zero b) scale up to infinity near-instantly. Source: I've rand both a Lambda Monolith and ECS on production and would pick Lambda any day

Just FYI: You can totally scale ECS down to zero. Our ECS bill hovers around $1/mo because we spin it up on demand based on queue size (It takes a painfully long time to spin up, though).

Yea, in practice you need at least one node up at all times to process stuff, then start scaling up when queues start filling up.

Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?

#117

Earlier quoted context omitted.

It’s fiction that configuring the cloud is easier than configuring a computer. I’ve worked at big companies with smart people who burn days and weeks trying to get IAM, gateways, vpcs, firewalls and lambda to play together. Let alone the ongoing nightmare of ops/dev interaction. Complete cloud fiction. The worst problem is the giant pile of cloud spaghetti you end up with and no one has any idea what connects to what…

To be blunt that sounds like operator inexperience. Throw someone who's spent their life setting up Windows servers on a Linux box and you'd hear similar resentments. At the end of the day you still need to configure the instances for things like auto scaling, security patches, logging and so on. IAM & VPC still come into the mix when running on EC2, so you've avoided nothing.

Having made money supporting both on prem, managed servers and cloud instances, my billable hours for cloud setups always ended up far higher, because the setups were invariable more complex.

You haven't avoided much of you replace lambdas with ec2. You do if you replace it with a rented managed server or even a colo.

Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?

#118
post #114

Earlier quoted context omitted.

It's basically impossible to make managed hosting more expensive than cloud. Marginally easier for actual on prem or colocated setups because there is more room for error. The devops time you need to provide to manage most cloud setups is generally far higher than what it'd cost you to get someone to manage your managed servers both in time and retainers to have someone to escalate to. When I was consulting, cloud fo…

> It's basically impossible to make managed hosting more expensive than cloud. So, I've got 6 different backend services running as monolithic Lambda functions. They all must be up for a number of nines per year, each going down will cost our company actual money for every second of downtime. They've never been down except when AWS broke something - and then the customers couldn't have accessed them anyway. Can you t…

Without more details I can't give you numbers, but I've gone through this with countless customers. Every time I offered to do the work for a percentage of savings. Unfortunately most of them did the maths and had me bill by the hour instead.

I've yet to come across a setup where we couldn't trivially halve costs. Often you can halve costs over a well optimized AWS setup (most AWS setups are nowhere near well optimized, and most AWS customers haven't even caught on to the ability to start pushing for discounts once their bills are high enough; you can still beat that with more traditional setups) even while just migrating to cheaper cloud services elsewhere. Often the cheapest is a hybrid, because it allows you to benefit from the resiliency of cloud providers while only rarely having to put any load that costs on them.

I get that you've left out a lot of details, but what you describe is not a complex setup. Try thousands of VMs over multiple countries with dozens of database and everything replicated at minimum in three locations, and with zero downtime migration of loads between countries on a hybrid setup across multiple providers, several colo facilities and managed hosting providers.

Even with the fully loaded devops cost a setup like that came out at less than just the egress bandwidth would've cost us at AWS.

There are plenty of loads where cloud providers are the right choices, but they are almost never a cheap choice, and when they are, AWS and tge other big ones are rarely even breaking the top 5 cheapest cloud options.

Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?

#119

Earlier quoted context omitted.

Basecamp is a small-medium company and leaving the cloud was a huge win for them: https://world.hey.com/dhh/we-have-left-the-cloud-251760fb

Basecamp is an anomaly on pretty much every vector imaginable. They have been remote-first (remote-only?) since forever, they still use Ruby in production, have never taken VC money and they've never even tried to do a hockey stick growth unicorn hack. They're still under 40 people.

None of which provide any legitimate reason for dismissing their savings.

Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?

#120

Earlier quoted context omitted.

Good old HN, "just self-host with onprem". Who monitors it 24/7 and checks the alerts? Who drives to the data center to fix broken hardware on Christmas Day? It has to be multiple "whos" or one sick leave will leave you completely vulnerable. For small-medium companies whose main business isn't hosting software this makes it untenable from a financial point of view. For the monthly salary of a single SRE/devops/admin…

Basecamp is a small-medium company and leaving the cloud was a huge win for them: https://world.hey.com/dhh/we-have-left-the-cloud-251760fb

But Basecamp's business is hosting software.
Post reply on HN