I find managing the AWS API Gateway to be too cumbersome. We use a proxy lambda that handles authentication and has routing logic to other lambdas (or SQS | State Machine).
Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?
31–40 of 131 posts
Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?
#32Surely if you're reimplementing an HTTP server inside a function running on an HTTP server then something somewhere has gone horribly wrong.
I _just recently_ ported a hobby fastapi project into a lambda container and I can't speak highly enough about it. My costs went to zero, deployment is just as easy, performance went up (lambda is pretty good once warm), and my local dev build matches the API perfectly now. I could get some of that on vercel, but not the docker containerization, which makes all the local/remote stuff work the same.
Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?
#33Surely if you're reimplementing an HTTP server inside a function running on an HTTP server then something somewhere has gone horribly wrong.
Do you feel the same about a load balancer being an HTTP server proxying requests to another HTTP server?
Because it doesn't have to be this way, there's php-fpm and such that could eliminate the http->http step
Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?
#34Why lambda? Just run nodejs. The cloud has made otherwise smart people into unthinking drones. You don’t need any of the cloud stuff , except a Linux virtual machine. Stop drinking the cloud kool ade, it’s making things much more complex and expensive for questionable gain. Learn how to, you know, run software on a Linux computer.
I have done both, for many years.
I hate managing a server, unless it's running a DB, relay, or other long-running service.
For most my backend work, it's "Please calculate this", and that fits so well into a lambda I don't understand why people hate it so much.
Zero maintenance, zero costs until used, much less security to manage, etc. It all works very well for me.
I still run all kinds of stuff on a linux server, but the comment seems a little gatekeepy. There's nothing strictly better (or even simpler) about running on a server.
Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?
#35Earlier quoted context omitted.
My company doesn't make more $$$ because i decided to spend a day setting up an EC2 over Lambda or a similar PaaS solution. If anything i've lost valuable time that could be spent elsewhere. Especially when stuff starts going wrong or i have to schedule time to manually apply OS/Runtime security updates. > The cloud has made otherwise smart people into unthinking drones. The cloud has allowed smart people to focus th…
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…
> It’s fiction that configuring the cloud is easier than configuring a computer.
We're arguing opinions and trying to apply logic.
Some people find lambda easier and it must be true that lambda fits certain workloads better. Some people prefer VMs or on-prem or other long-running services. I prefer both in different cases.
> The worst problem is the giant pile of cloud spaghetti you end up with and no one has any idea what connects to what and what depends on what.
Yes, it takes discipline to use the best tool for the job. "You should do X for everyting" is not the right approach, however. This argument is moot.
Right now I support:
* Lambdas for some very expensive infrequent number crunching
* Lambda-like on edge for fast response services that require low latency
* VMs for always-on services
* Computer in a closet for backups, logging, metrics, etc.
Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?
#36Earlier quoted context omitted.
My company doesn't make more $$$ because i decided to spend a day setting up an EC2 over Lambda or a similar PaaS solution. If anything i've lost valuable time that could be spent elsewhere. Especially when stuff starts going wrong or i have to schedule time to manually apply OS/Runtime security updates. > The cloud has made otherwise smart people into unthinking drones. The cloud has allowed smart people to focus th…
They probably do make more money… actually. At least in net profit. Cost in time to setup a bare metal, production quality k8s cluster with all the bells and whistles from the cloud: 2 weeks and a skill I will have forever. In fact, the second cluster took 4 hours. Monthly cost: $240 per month. Time to spin up a new worker, using cloud compute for elastic load beyond base load: 5 minutes. Base load capabilities: 120i…
> They probably do make more money… actually. At least in net profit.
It's my company so I think I'd know :)
Also what exactly are your estimates here? Where are you getting that kind of capacity for $240 a month?
Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?
#37I would argue that instead of starting with a Lambda Monolith and splitting routes out when they need to scale separately, you should be starting with an actual monolith and using Lambdas _only_ when a single route needs to scale separately (in a way that fits lambda). The Lambda Monolith is an unnecessary architecture as far as I'm concerned.
So a separate server running a monolith is not "unnecessary architecture", but a simple Lambda function is?
With a Lambda function you can have a dozen different versions of the same code running simultaneously with zero extra cost and none of them will affect each other's performance. Every one of them will be versioned and you can instantly roll back to any version or pick any version to be "production".
Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?
#38If you're going to put everything in a single lambda function that's continually serving HTTP requests, you might as well look at ECS.
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
Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?
#39Earlier quoted context omitted.
There are plenty of cases where lambda is a better fit than hosting a server. Just like there are plenty of cases where it's not an appropriate fit. By flat out refusing to consider it, you become as much of a "drone" as the people you call out.
>> There are plenty of cases where lambda is a better fit than hosting a server. Such as? If it’s regional latency then run a machine in the region.
You can have a dev team of 20, everyone has their own Lambda function running at all times so they can run their own branch without affecting others.
When people go home, the dev Lambda cost instantly becomes zero.
You can't do that with (virtual) servers, the cost is exactly the same 24/7. In some cases it's a good thing, some not.
You can't also trivially handle Hug Of Death level load spikes.
Not to mention Lambda uptime vs everything else.
Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?
#40Surely if you're reimplementing an HTTP server inside a function running on an HTTP server then something somewhere has gone horribly wrong.
Do you feel the same about a load balancer being an HTTP server proxying requests to another HTTP server? Because it doesn't have to be this way, there's php-fpm and such that could eliminate the http->http step
I'm confused, how does php-fpm connect someone to the right machine? It just looks like basic multiprocessing to me, which should be a basic feature of any decent http server.
Unless you're referring to the 'load balancer' in the comments where someone builds their own multiprocessing by launching multiple servers and putting nginx in front of it. I mean do what you need to do but at least be aware you're hacking together something that should be a basic feature of the http server.
If you wish to push me I'd be forced to admit that I don't like load balancers either, but that's because they're doing routing on the application layer which is not ideal and creates a single point of failure. That ship has sailed though.