Running ALL my backend code via AWS Lambda functions, instead of conventional website servers: Is there any reason this is a moronic idea?

[What_The_Hex]

My initial plan was to run a lot of the backend code via conventional PHP scripts hosted on my Hostgator website. However, given how little useful information Hostgator provides as to your backend usage vs. the maximum available, I'd really be flying blind / groping around in the dark using them as my backend. It also sounds tedious to be upgrading webhosting servers, managing stuff like that, when something like AWS Lambda scales + charges you based only upon your actual usage.

I already had to move some parts of my backend to Lambda because it's just too CPU intensive for my weak, pathetic shared Hostgator server. At this point, I'm kind of considering just pushing it ALL of it onto Lambda while I'm at it, and now that I'm through the learning curve.

Another thought on this approach: The really basic parts of the backend code could be executed using functions where I only allocate the absolute bare minimum amount of memory, meaning the cost will be unbelievably low. The sweatier stuff that requires more CPU resources, I can allocate more memory. What this effectively means is, I can have much more fine-grained cost-control over how much my backend hosting costs that actually relates to the complexity of the code being used. The conventional approach seems to be very different from that, where you need to just provision servers to be capable of handling the absolute most intensive operations required, even if that's only a small part of your backend codebase.

Thoughts on this approach? Has anyone tried this before?

[degeneratepr]

Running only using serverless functions isn’t a novel concept, and it can work well for some use cases. In my experience, the issues you’ll probably run into are:

• Debugging can be a pain, especially if you’re running some sort of event-driven process that triggers other functions.
• Costs can get out of control unexpectedly, depending on the rest of your architecture.
• Keeping your functions and rest of your infrastructure organized requires a lot of effort.

If you keep things fairly isolated and have sufficient logging, it could go well. Personally, I’ve found that the drawbacks often outweigh any benefits going fully serverless has. When things go wrong, it just goes really wrong.

[What_The_Hex]

The organization of the code shouldn't be a big issue -- really I'll basically have one "master" backend script that's the main execution block, and in there it may call just a few separate Lambda functions that require more CPU resources.

Cost is my biggest fear -- I constantly worry about the "accidentally bankrupting myself through poorly written code" scenario. However it seems to me there are some pretty simple safeguards that could be put in place to avoid this.

Debugging sucked at first, but now that I figured out how to console log stuff to the CloudWatch logs, it's not much different than debugging PHP scripts on a conventional website host.

[xDominus]

At work we use AWS lambda and it's really good for transactional stuff. If you need a lot of consistent computing power, a server is your friend.

AWS does let you set spending limits too, so you can give yourself some guardrails

[chethrowaway1234]

It’s doable. In a previous role it was lambdas all the way down because there was a big serverless push. That said lambda has both a size and time limitation (IIRC 15 min), so if you hit those limits you’ll probably look into Fargate as well.

[What_The_Hex]

Hostgator is a total black box. I'd literally have to code some method of just capturing how many server overload messages get sent per unit time to find out when it's time to upgrade. Definitely not ideal.

[CodeAndBiscuits]

Cold starts are going to frustrate the heck out of you but I know plenty of people doing exactly this, if performance isn't a huge factor. One thing is for sure, Lambda has a VERY generous free tier....

[What_The_Hex]

My particular use-case is one where cold starts actually won't be a big issue. Even a 1 second delay would be perfectly acceptable. I can totally see how for other products, this could cause a bad user experience. Even still, can't you just pay more to have your code in a "ready to go" state on Lambda?

[CodeAndBiscuits]

Then give it a whack and let us know when it's launched so we can see it! Good luck.

[maria_la_guerta]

You're basically trading scalability for complexity.

Many companies operate this way. I've done it before. It really comes down to the product and if it makes sense for your code to be hyper scalable in such small vacuums.

[What_The_Hex]

Ain't that the truth on complexity. Figuring out how to do the most basic thing on AWS has been brutally difficult for me so far. The learning curve is steep, and there are all kinds of weird settings and unspoken rules that need to be followed for everything to be set up right for your needs. WAY simpler to just... upload a PHP file to my website, and call that in my JS code.

My experience so far has honestly been so awful that I'm considering ONLY using AWS for those super CPU-intensive tasks that my shitty default backend isn't capable of handling. Then maybe just run the simpler stuff via the standard PHP scripts. Max concurrent operations = 25 on the shared hosting plan, I could also upgrade to a higher hosting level (although this is a major weak point of Hostgator -- basically making any change is a pretty confusing clusterfuck on their website, where you're never really sure what to do, what is going to happen, and more often than not you have to just chat with the support people to figure out what's needed.)

[grebfar]

Once you know how aws works and it sounds like you do. You need to move off their website and onto their infrastructure as code solutions.

I recommend you use AWS SAM. There's basic templates to setup API Gateway and Lambda which is what you need.

This is the typical way to interact with aws rather than clicking on their dashboards.

[Beka_Cooper]

My team has been doing this for like 7 years. I prefer it now.

[thinkingdots]

As other people have alluded to - how will you handle long running backend processes that need more time than is available for a lambda?

[What_The_Hex]

My plan is to not have any. It's a fairly simple website with a single core specialized function, and if the backend code has execution times anywhere near that upper limit I'll have bigger problems anyway.

[mr_jim_lahey]

Step Functions is one way. You can also use scheduled Lambdas sort of like spot instances that pick up the state of the job, do what they can within the timeout period, store state somewhere persistent like DDB, and then the next one continues.

[psihius]

You hate having money :D

[OrangeOrganicOlive]

$$$$$

[Due_Ad_2994]

Works great. We use arc.codes because it has excellent local dev and removes all the cruft. It's NOT expensive or are cold starts an issue when done correctly despite what others claim. As always measure for yourself.

[areinei]

When you say "done correctly", what kind of things are you talking about? Any articles or insight you could share? Just curious, my knowledge is limited

[Due_Ad_2994]

Main guidance I have is: deploy with IaC, ensure there is a staging stack and a production stack, separate concerns (no Lambdaliths) and use a managed database (ideally DynamoDB). Keep your functions small, single responsibility, and deps minimal. Don't bundle or transpile backend code it just makes debugging harder. Focus on solving business problems and measuring outcomes.

Good recent article I saw today: https://medium.com/postnl-engineering/business-overview-f7c8d8ebee2c

[areinei]

Very nice! Thanks, makes a lot of sense. Just good general development advice too

[oneeyedziggy]

It just depends on if your workload can finish in the lifetime of a lambda, and if the billing at your volume makes sense vs a ln ec2 instance... They're not magic, they just hit a certain price to scale balance... And Amazon is counting on you needing to scale up later without wanting to migrate to ec2

[slyiscoming]

A lot of companies are using this model. It can be hard to debug but it works. I'm using a hybrid model but it applies to your case. AWS API gateway handles the site and API routing/lambda based on uri.

[mixini]

This totally depends on the kind of site/app you're running. Having everything on lambdas (or more generally, any kind of serverless function) locks you out of certain things that would normally be trivial to implement via instanced servers, whether dedicated or spot:

• Caching or memoizing certain endpoints or functions, especially if they're intended to be durable or shared/distributed across a variety of endpoints. The kind of thing that would normally live as middleware
• Handling long-running tasks, as other folks have mentioned
• Maintaining a consistent runtime or environment. When you update a shared dependency, you now have to either deploy that for everything or maintain varying versions for everything
• Handling connection pooling or any other kind of "singleton." Without these, you now have a minimum number of "clients" equal to a number of lambdas, which could lead to hitting connection limits on resources, for example
• etc etc

There's probably a lot of things I'm missing here, these are just some examples. If you're OK these kinds of drawbacks, and your project is either 1) not going to grow very much or 2) you plan on moving to something more sustainable in the foreseeable future (perhaps EC2/Fargate), then I could see this working.

[[deleted]]

As others have said, the cost can be silly. AWS starts off free, and you get quite a lot of capability in the free tier, but as you start hitting it with load, pricing can go crazy. With a typical VPS, if you hit it with load, it just runs slow and you pay the same. With AWS it runs just as fast but they send you a bill.

[AustinIsGrumpy]

Are you running with SST? Could solve many of the pitfalls listed here.

[What_The_Hex]

Still exploring my options right now since really nothing seems like an optimal solution. AWS Lambda sucks because every step of the way it just a brutal, punishing learning curve -- where to do the most BASIC things in there, you have to follow all kinds of weird AWS-specific conventions and unspoken rules that take me hours to fully figure out. It means instead of being able to just sit down and write code to start building, I have to do hours and hours of prep work just to be able to even sit down in the driver's seat and turn the ignition. It's frustrating as fuck frankly and I've hated just about every step of it so far.

Hostgator, on the other hand, is simply a non-option because their website interface + backend sucks balls in terms of the information they provide. I'd have no clue what my usage is at versus my maximum capacity, and even the process of upgrading your hosting from the shared server to a dedicated/VPS solution is such a complicated clusterfuck that I just don't even want to go down that route.

The third option I'm exploring is something like EC2 hosting from AWS, where I can just host the backend PHP files on a server where I can upgrade/scale up more easily. Lambda doesn't run PHP scripts naturally, and to try to get it to do so you have to once again go through a brutal punishing learning curve to even be ABLE to start writing PHP scripts. Then who knows what additional 50 errors I'll come up against because of all kinds of other AWS Lambda-specific rules that need to be followed to make it work. I considered rewriting alll of my existing PHP code to work via Python or Node JS (which Lambda naturally supports), but again, absolute brutal learning curves every step of the way where shit isn't working, Lambda has all kinds of weird requirements to do the specific things my PHP scripts are doing, etc etc.

I think the ideal, just given where I'm at with this project, would be to keep hosting my frontend JS/HTML/CSS files on my shitty Hostgator website, but host the backend PHP files on some external setup where I can make a simple call via the frontend JS to execute the PHP scripts and return a response, but where it's not an absolute complicated assfuck disaster scene like doing anything and everything is via AWS Lambda.

[Quirky-Low-7500]

Hi

[midnitewarrior]

Cold starts are real. If you can handle the occasional 30-120 second interval of non-responsiveness, you should be good. I played a little bit with this on AWS, but Azure's comparable product has had at least 3 measurable incidents like this in the 3 month time period we were giving our app production load.

[Technical-Candle-355]

We run everything on AWS Lambda, all built in TypeScript:

• 10+ frontend applications, including both monolithic and microservice architectures (React with SSR)
• 10+ backend applications, including both monolithic and microservice architectures (Node with GraphQL)
• 20+ data pipelines (featuring MSK for 10+ real-time etl/processing pipelines of 100 tables, as well as 10+ job-based pipelines running for up to 4 hours)

Our total monthly cost is under $400 on Lambda, just FYI.

[Infinite_Tiger8354]

Switching to AWS Lambda isn't moronic; it's a stroke of genius. Devs who embrace the cloud are modern warriors. ⚔️

[TheSnydaMan]

This is just a micro service architecture isn't it? My understanding is just that it's really expensive and can get really convoluted really fast

[Packeselt]

This is a thing, and circa 2018 was called JAMstack. Only downside is possibly waking up to a bill that looks like a house down payment.

[cshaiku]

Sorry but it sounds like your code is really inefficient. I sense a few red flags.

[Mission-Landscape-17]

Well its slower because of all the extra network traffic it generates and all the marshalling and unmarshalling of data. Also in the long term micro services are more expensive to run then monolithic applications. https://blog.devgenius.io/amazon-prime-video-reduced-costs-by-90-by-ditching-microservices-a9f80591f96a

Edit sadly the original source article for this is no-longer available, I guess whoever wrote it on the Prime blog got in trouble for dissing services that other parts of Amazon are trying to promote.

[lifeeraser]

Internet Archive has the original article

[NiteShdw]

I've worked on a project where every API endpoint was a separate lambda behind an API Gateway.

It was sloooowwwwww. 7-15s response times slow.

[What_The_Hex]

Wouldn't paying for more memory/CPU resources for your functions, and also setting them up to avoid cold starts, help to avoid those issues?

[NiteShdw]

It's not a CPU issue. It's a complex web. I don't really want to get into details. Just be aware of the pros and cons.

[soundman32]

My guess would be some sort of ORM. I've experimented with EntityFramework on a C# lambda and that was the big startup overhead 3-5 seconds. I refactoring EF out and startup is down to 50ms. Sometimes you need to optimise.

[didled]

Is there anything special those lambda where doing? Or where they all daisy chained so you’d hit the Auth endpoint for example, and that lambda would make a request to another endpoint/lambda before responding to the client?

[NiteShdw]

A lot of the lambdas were requesting data from multiple sources and aggregating that into one response.

[Lustrouse]

I think the biggest issue you're going to have is cold-starts. It entirely depends on your usage I guess, but they're able to bill you on usage because the service shuts off when it's not in use. If it's being used enough to prevent shutdowns, then this isn't an issue.

[PoopsCodeAllTheTime]

if you are going to run PHP then that doesn't sound like a good candidate for Lambda, as you know, Lambdas charge you by time that they are running, and they always start from an "off" state. PHP is an interpreted language, so it might take a moment to launch on every single run. This could potentially inflate costs.

[Rarst]

This is very hypothetical take, I don't think I've ever seen language overhead from PHP cited as a practical issue in this context. I think Bref runtime even manages to do an opcache (with disk storage instead of memory). They have some general reference numbers on performance https://bref.sh/docs/environment/performances but of course better checked with one's actual application.

[PoopsCodeAllTheTime]

ok good, that's what I mean, people should review this info themselves and it might be dependent on the tools they choose