A bank runs serverless with PHP and AWS Lambda

At my last job, we had an architecture that ran hundreds of thousands of individual jobs with internal API calls for nightly account updates and reporting work, and it was a major battle to finally get it replaced with some simple SQL scripts which ran orders of magnitude faster while being a lot more reliable.

As I understand it, banking commonly uses JVM where you can easily do async or multithreaded processing and task scheduling, so lambda doesn't offer much over ECS, and the timeout could be a real killer.

What's your experience with Vapor? We played around with it and thought about switching from Forge, but it was too complicated for our codebase. I love the idea though.

How expensive our your cloud costs? CI/CD pretty good?

Lambdas are amazing at clearing queues.

You can have a single queue gathering workloads and then have Lambda functions grab a bunch of tasks, handle them, grab more etc. until the max runtime is met and they're automatically rebooted.

It's also pretty trivial to add more processing capacity when the queue goes over a specified limit just by allowing for more concurrent Lambdas.

And when there's nothing to process, you've got one idling Lambda doing nothing and costing nothing.

I did some fintech work as a junior / kinda non junior dev. This is correct. I think 90% of the work was taking pictures of checks, and setting up batch jobs. all batch: - money movement (between accounts) - transfers - wires - etc.

even the 'non' batch things were done in batch (even if it's do now, and only 1).

It's cheaper than most options where you need to pay a human to manage something with the same level of scalability and security that AWS provides.

Lambda is $0.0000166667 for every GB-second, which works out to ~$43.20 for 30 days. For a little more ($49/month), you could get a c6g.large and get two dedicated CPU cores (ie, not the shared burstable t2/t3) and 4 GB of RAM.

So yes, very expensive fast if you get much traffic at all. That c6g.large should easily be able to handle dozens (if not hundreds) of requests in parallel, especially if many of those requests are going to have to wait for results from a database.

If you have more than ~800 hours of Lambda execution time per month (30 days being 720 hours), then you're better off with the c6g.large. The only reason to choose the Lambda is if your traffic is extremely bursty and the c6g.large can't handle the load.

Of course, this is all assuming you're using a 1 GB Lambda. Likely, your Lambda needs less, in which case the amount of traffic needed to make the EC2 more worthwhile higher.

I've been working with Lambda across a few large projects for their API's, with each endpoint being its own lambda.

This has been scaling really well for us and affordability wise it makes the development and testing phase basically free, with the final deployed costs almost never exceeding double digits monthly. This is for multi-az + multi-region deployments too.

the beauty of bref is you work with the same php engine as before. I am a (very) long time PHP developer, my primary work is still Drupal so the ability to make a small serverless app in PHP was very handy for me. My app implements a webhook and I feel Lambda is made for this: the script is small and quite fast, it checks the payload and puts an item into SQS as appropriate. Then another infra can slowly empty the SQS queue. The problem here is the load is insanely spikey -- sometimes tens of thousands of requests in a very short time frame, sometimes nothing. Directly writing this into a transactional database would require very costly infra. The Lambda-SQS model smooths it out. It's fine if some changes take minutes or even hours to be recorded.

Oh wow, that’s almost exactly what I need. Thank you! I don’t know if this is newer or if I just totally missed it the last time I looked.

Sorry I wasn’t clear.

Yes, that’s the correct SST. Yes, we could host our PHP anywhere and there are options like Cloud Run. We are on AWS and so I was talking about AWS Lambda but I understand that wasn’t clear at all.

The reason for wanting to use Lambda is for bursty/inconsistent workloads. We have EC2 servers that handle all our traffic right now but some are oversized to handle the peaks. There are parts of our system that we could easily offload to lambda to reduce the load on the main servers if we could easily run PHP in lambdas.

I’m going to take a look at the CDK example OP posted (sibling comment to yours) since SST is just a layer over CDK and you can reach down into CDK easily.

It genuinely amazes me that Node is as popular as it is, especially within large mission critical businesses. If this bank was using TypeScript no one would have questioned it, but you're right, TypeScript is a nightmare to maintain. I probably only use about half of packages I used 5 years ago because either those packages are no longer maintained or the community has switched to some other package that basically does the same thing just in a slightly different way. There's also no real industry standard ways to do anything in Node. You find 10 different Node CRUD projects and they'll all do things completely differently.

The PHP ecosystem on the other hand tends to be less fragmented and these days with frameworks like Laravel the code is generally also pretty good. I think it gets a bad reputation because in the 00s there were some truly horrific PHP projects out there and the language itself was quite immature and poorly designed. That's not the case anymore though. These days I struggle to understand the hate it gets. It's certainly no worse than than Node.

I think most of that was coming from the (then) next generation JS crowd who was trying to fit everything into one neat little box. They've since burnt themselves out and found the limitations in their approach during the process.

[flagged]

Just a perspective:

PHP 7+ (the language) was wonderful, especially compared to Javascript's woefully inadequate standard library. It had so many helper functions that made even working with JSON and big data objects much easier.

But having to manage its buildchain wasn't fun (meaning needing to containerize a web server, PHP-FPM, etc. for every trivial deployment). Then needing to support an OS behind it with updates and such, even Dockerized.

For serverless in particular, the availability of V8 isolates (like in CF Workers) or other "just run this snippet of code and don't bother me about the infra" services (like Lambda) or "I can host my serverless in a file alongside my other frontend stuff" (like on Vercel/Netlify) means that JS functions are pretty much zero-config 1-click deploys.

Is there anything like that in the PHP world? For Bref, for example, you have to set up a lot of stuff before the serverless will run: https://bref.sh/docs/setup

For Google Cloud Run (which supports auto-scaling containerized PHP, not true serverless but closer to it than a full VM), you have to manage docker: https://cloud.google.com/run/docs/quickstarts/build-and-depl...

Maybe the closest one I know of is a Google Cloud Function (https://cloud.google.com/functions/docs/create-deploy-http-p...) which comes close to the "function as a service" of JS serverless, but you still at a minimum have to deal with a tiny folder structure (index.php + composer.json).

Is there anything similar on AWS or elsewhere?

Interesting to re-read that article again and see that technologies he cites as so cutting edge you're spending innovation tokens on them are now mainstream and very well understood. What would the new "you can use those but you're spending innovation tokens!" technologies would be. Rust? AI? CGP?

it would be nice if HN had a random "explain your vote" mode where voters had to choose from, eg., agree, helpful, insightful, etc. vs. disagree, unhelpful, provocative

I mean, it's not like that sentiment is totally baseless. I've used PHP years ago and both language and core libraries were not well-designed and came with many footguns. I've heard that modern PHP with frameworks like Laravel fixed a bunch of this, so presumably it's quite capable these days. But PHP certainly wouldn't be anywhere near the top of my go-to list at this point.

App reliability is different from payment service reliability.

Of course us Nerds know that "serverless" is just a BS marketing term.

I am nitpicking because there are technically uneducated people (managers) who actually believe in these BS marketing terms. People who already thought that such a thing as a "cloud" exists, resulting in us now having to look at our personal data getting stolen once per week because some manager thought you no longer need competent system administrators, because you are just pushing that personal data "to the cloud", so no risks involved.

And in this regard, the term "serverless" is even worse. It's basically the flat earthers of technology.

These BS marketing terms like "cloud" and "serverless" are an excuse for managers to act in an irresponsible fashion, thinking competence is no longer needed in-house. But competence IS needed.

And that's why every single person of "us" in each and every conversation should point out "you are putting the data of your customers and your businesses existence into the hands of someone you don't know at all" and avoid the BS marketing terms. If we go along with them, we are just hurting us, our employers, customers and/or clients, and humanity.

So, in this case the article should be translated into:

"Our intern wrote some crappy PHP shit because he is not really a programmer but a baseball player, and we have decided to just upload and expose all our stuff to some random organization at an unknown location under unknown control so we don't have to deal with this stuff anymore once the intern has left."

:)