A bank runs serverless with PHP and AWS Lambda | Hacker News Reader

A bank runs serverless with PHP and AWS Lambda

bref.sh

111 pointsmnapoli126 comments

I always love a story about a successful strangler pattern migration.

I do wonder how they came to Lambda though. I love it for small workloads and highly variable demand services, but something like Treezor you'd think has relatively flat and high demand. The cloud cost for Lambda would be much higher than running the equivalent compute, even with something also highly scalable like ECS.

We use Lambda (via Laravel Vapor; https://vapor.laravel.com/) for a big analytics batch processing job every night; it spawns hundreds of thousands of individual jobs that make various API calls, but only for a few minutes. For the rest of the day it's doing very little.

I'd imagine a bank has quite a few of these sorts of bursty bash processing needs; ACHes, end-of-day reconciliation, etc.

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?

Overall quite good. We use their Docker container support (to get ffmpeg, mostly) and it's been pretty smooth running throughout. I'd previously used a lot of Heroku so the habits developed there paid off in our codebase for Vapor; only a few tweaks were really needed.

Cost-wise we're pretty bursty, so it's saved us quite a bit. Lambda runtime is money, so a little bit of performance optimization can go a long way. CI we run through Github Actions; an environment secret plus `vapor deploy` and it's on its way up after a successful run.

Wasn't a fan of Forge; for that style of things I'd use Ploi nowadays.

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.

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).

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.

This was my thought. Lambda works well for infrequent tasks. But hosting an API? That seems like it could get expensive pretty fast.

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 scalability for an API is awful; it can't run concurrent requests (of course PHP largely can't do this either). An ECS service with pretty much any other language (for async/multithreaded runtimes) will scale far better.

A single lambda can only handle one request at a time, but you can scale up 1,000s of instances if needed.

A single minimal ECS instance can handle thousands of concurrent requests with an async runtime without running into so many cold starts that your p25 time is in the hundreds of ms.

1000 lambdas with 1000 database connections is also going to be a horrible way to do things on the backend. Add in the cost of RDS proxy for lambda and the ECS solution becomes even better.

ECS fargate is pretty easy to scale, and much more cost effective.

I personally don’t think running on EC2 is particularly difficult to manage, and it’s even cheaper again.

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.

Then your EC2 instance suddenly stops working and your downtime cost you a fat contract that makes the cost of serverless a pocket change.

If you want to compare AWS Lambda with EC2, you need to bring in AWS Load Balancer, Auto Scaling, Security Upgrades for the OS, Healthcheck and many more.

Yes, Lambda is not needed in a lot of context, but if you have the expertise to use it and you want to provide enterprise-grade compliance, it's a walk in the park.

Everything you listed is why I mentioned ECS though. To me it's a perfect in-between.

Bringing the long-lived server back also makes things like long-lived connections, memory caching, cold starts and database connections a non-issue again.

Good points all around.

The costs certainly are not as cut-and-dry as I originally expressed it.

With Lambda you’re in three different Availability Zones by default, so you also need to factor running your proposed EC2 solution in 3 AZs too.

2 cores and 4GB RAM should have no problem handling thousands or tens of thousands of concurrent requests on the JVM. Lambda's documented concurrency maximum is "tens of thousands"[0], which means an 8GB m6g.large or ECS instance can probably handle larger bursts than lambda can. If you had extreme bursts, you'd also be having almost every request hit a cold start.

[0] https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-...

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.

Their clients have very variable traffic patterns because they are in very different industries. They have traffic spikes at lunch, or at the end of every month for example:

> infrastructure must be able to scale and be resilient to accommodate various usage patterns. Whether it's a luncheon voucher transaction spike at lunchtime or a monthly batch of transactions by corporate clients

I'd be more worried about decimal data types being interpreted as floats. That could get gnarly fast on the wrong language runtime, and is partially why Cobol programmers are still in demand in the financial sector.

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.

> I do wonder how they came to Lambda though.

Probably some security certification that AWS Lambda comes with. I worked at Cambia Health that used Lambda (Javascript) for dealing with customer mobile data. It was a nightmare solution (cost and complexity) for what should have been a simple fan out queue and process system. They hired me to help fix it. Every other solution was a flat no. AWS Lambda was was HIPPA compliant (for whatever that's worth) and some other security assurances that I don't remember, so I was basically just another developer (with a moron for a manager).

> I do wonder how they came to Lambda though

Probably misplaced hype about being fully serverless.

As you said, ECS would be much more suitable while also addressing the issue that they had (spikes in traffic).

Lambdas behind API Gateway sounds like a good idea and even looks like one if you don't have experience with ECS and don't do a proper cost comparison analysis.

My team uses ECS' autoscaling to scale up to tens (or even hundreds) of thousands of tasks in minutes without issues.

I'd really like to play with Bref but it more or less requires using serverless framework from what I understand as there are no guides on how to get it working with something like SST. I've used serverless framework before and I won't touch it again. It seems like a complete dead end with the team behind it more or less giving up on it to go work on a cloud backend alternative to lambda/etc. Docs were a mess, lot's of half-implemented things, etc.

I wouldn't lift-and-shift the PHP app I work on, it requires too many FreeBSD-specific/custom underlying services but I could make use of lambda for certain tasks while leveraging the PHP code we already have. We use SST for for some NodeJS (TypeScript) lambdas that have been very popular but PHP isn't going anywhere in our stack so I'd love to find a way to move the bursty parts of it to lambda.

You can deploy using the CDK for example: https://bref.sh/docs/deploy/aws-cdk

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.

What is "SST" in this context? Is it this thing? https://sst.dev/

I'm having trouble understanding where PHP fits into this scenario. If your cloud backend is in PHP, can't you just host that anywhere, separate from your frontends? Where does the serverless come in? And which did you use? (There are so many out there now, from AWS Lambda to Cloudflare to Fastly, etc.)

If you're not limited to AWS, Google's Cloud Run lets you containerize a PHP app and auto-scale it up and back down to zero in bursts, for example. It's not really serverless, just an auto-scaling VM that goes up and down as needed.

edit: google cloud functions might be even closer: https://cloud.google.com/functions/docs/create-deploy-http-p...

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.

I see, thanks for explaining!

Have you also looked into Elastic Beanstalk? It's an older AWS service but it's made to help you handle bursts or scheduled peaks.

I was about to say that wouldn't work but EB does appear to let you use a custom AMI which means we could have a FreeBSD host and make use of our full existing stack. I had written it off thinking it was little more constrained, or at least constrained to AL2/linux hosts. Thank you for bringing that to my attention.

I don't know which surprises me more: that they continued to use PHP in their move to serverless/microservices or that nobody else on HN has questioned this point yet. I totally get why they would keep PHP: they have the language/platform experience already and AWS supports it (which is really more than enough to silence the "You should have switched to {other_language}!" partisans). Plus, I imaging non-trivial amounts of copy & paste of proven functions was key to moving from monolith to Lambdas... why change the code if it works?

I'm wondering if PHP's reputation has been rehabilitated somewhat in recent years. At least amongst those who understand the significant changes in modern PHP, and the difference a stable framework like Laravel makes.

I've found PHP with Laravel a stable and solid workhorse. Good for getting things done quickly, and then a stable system over time.

In contrast, I've gradually become disillusioned with the node.js and JavaScript/TypeScript ecosystem over the years. You can build quickly, but the systems turns into a pain to maintain and update.

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.

It also makes sense if you look at things in the context of Choose Boring Technology [1]. If you have a working PHP app and want to scale into the cloud, you can use a single innovation token to move the app into lambda. This is the key sentence:

> To do a controlled migration, the team deployed the application both to the servers and to AWS Lambda. Only 10 lines of code needed to be changed to run the monolith on AWS Lambda.

[1] https://mcfunley.com/choose-boring-technology

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?

AI for sure. Rust maybe less. The big thing about these tokens is, folk spend them too early and try to use them for everything.

Part of choose boring is more about choose the right tool.

Would you build a PoC webapp by having AI generate Rust? Or, just bang out a few lines of PHP or JS? If the objective is to build a working business tool it's choice B; if the objective is to test AI making Rust then A

hur dur php bad because they told me

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.

Eh, at this point can we just stop with the echoing of old memes? I used PHP4 and have used it continuously up to the modern day. If it's not your choice of language that's fine - language choice is pretty unimportant in the grant scheme of things... that said, it can do everything you need it to do (outside of low level memory control). If you need bit-efficient data structures it isn't going to be a good fit... but compared with most other system programming languages it's fine. I'd even go so far as to say it's one of the leading language in terms of meta-programming at this point with an excellent Reflection suite and great built-in magic methods.

It's alright. I'll be busy getting some easy WordPress work that's fun to do (especially if you use Laravel with it with the roots.io ecosystem) while people are trying to get their obscure Rust blog with leptos/X to compile to WASM so they can deploy it to fly.io and use their remote hosted database for 5 users/month.

I think the point of making the blog on whatever cool tech of the day, instead of wordpress is later getting a job involving said cool tech, not the blog itself.

I don't know a single dev across the years who has ever made php their first choice.

Hi, I'm munk-a. It's good to meet you!

I really enjoy PHP because it's easy to prototype in, there are a plethora of highly useful libraries for it, it has quite a few mature frameworks[1] and the language syntax is quite powerful.

1. Laravel gets a lot of attention but I'm a huge fan of Zend/Laminas.

/wave

I've tried to leave, I've explored outside the relationship. I've dealt with thorns and rough edges. But I've grown, the language and ecosystem have grown and it's been _wonderful_. I truly consider _not leaving_ the PHP ecosystem when I gave an earnest effort to explore elsewhere one of the best decisions I've ever made.

I love to build cool shit and PHP makes that _ridiculously_ easy.

Perhaps we're finally at a point on HN where people realize there's no need to question the use of PHP. it's a robust, capable language that's just as, or more, suitable for the majority of use cases as any other language.

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.

I’m the usual suspect for shi^W questioning php and I think you are wrong about demographics.

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?

your container running the web server and php-fpm should only need to be deployed once. the point of PHP is that to update your code you just... replace the file. this sounds like a poorly designed CI pipeline that is of no fault of PHP.

What? There was no CI involved. It's more a matter of being able to spin up separate environments for different teams, projects, or especially clients. Both for security and billing and resource allocation etc.

Did I get voted down because I actually agreed with keeping PHP rather than changing languages? I don't care about the karma points, just curious if someone thought I was attacking PHP because they didn't read the whole comment.

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 will admit that I've made trolling comments from time to time which get well-deserved vote-downs, but there are certainly times where I would like to know what the point of disagreement is because if I'm missing a point of view from which I could learn I would like to know!

If only there was some other famous tech forum with a descriptive voting system that we could learn from...

(https://slashdot.org/faq/mod-metamod.shtml)

Treezor is not really directly a bank but more a "bank as a service" company.

Lots of companies or "neobank" that want to offer a kind of bank account, for personal or corporate use, but that don't have an official banking agreement, and not really a banking infrastructure, can use them as "white label" solutions.

All the bank accounts and banking operations will be done by treezor, but from the user point of view, he will only interact with the company and company frontend, and almost never see that it is Treezor that is operating in the background.

That being said, I don't know if their "serverless" move is a good one, because their solution is commonly known to be unreliable, and I think a lot of customers would be happy to go to another provider if it was possible.

As a customer of US Bank in the US, I can attest to the fact that they aren’t as reliable as I’d want. Their website and app tend to be “under maintenance” quite often. I think you overestimate the reliability of many bank operations.

App reliability is different from payment service reliability.

I've been elbow deep in PHP for well over a decade, and I was genuinely surprised when I first saw this on Twitter. (Insert swaggy p meme here)

I have immense respect for the author, but I'm perplexed about the decision to build a bank on this stack.

Especially considering that the person who created Laravel Vapor (a serverless Laravel service) has since discussed the advantages of moving a large project from Lambda to EC2 (https://twitter.com/themsaid/status/1716844479817154589).

I really do wonder what the bullet points of pros/cons in choosing to go serverless for something like this were.

That's for a large, fairly consistently loaded project.

For a smaller site with bursty traffic, Lambda may be very relevant still.

> The migration to microservices is still an ongoing work.

Ain’t that always the way

On schedule to be complyted in year, as of three years ago and still 80% in progress

A more accurate title here is "bank moves PHP app to Amazon servers"

I'd love to know how much the cost changed.

Love a good lift-and-shift. I wish bref was this well-supported about 3-5 years ago. At that point I was trying to move some PHP services over to serverless. I think I remember seeing bref but it didn't appear to have the clout then. I even think Laravel Vapor didn't use bref when they were setting up PHP runtime configurations etc

"" Treezor is an independent provider of outsourcing and white label solutions for electronic payments. "" https://www.crunchbase.com/organization/treezor

So, is this a payment processor much like Stripe?

Wow, that is just amazing.

So it means that if I connect to treezor.com, I am not talking to a server, but it's direct communication with god in heaven?

And it's not a badly configured server, but the Content "Security" Policy allowing FOURTY different sites, including unsafe inlines (!) is beamed into my brain from a different universe?

And the PHP "software" also clearly is running on a server, because PHP isn't a server-side scripting language, it's all happening in your mind!

Hint: The whole point of a bank is BEING a server, be a central trusted authority accepting and executing transactions from and between clients. A serverless bank is a bank that no longer exists, but got replaced by peer-to-peer transactions.

I don’t understand why people nit-pick the wording “serverless” when the benefits of not having to manage servers is very real.

Yes, there is a computer. Good job, you pointed it out. No one is paying AWS money because they think amazon is somehow running code without computers being involved. They’re paying to run lambdas to avoid dealing with the computers that run the code.

Banks specifically have much higher operational costs due to regulatory requirements. Banks like to focus on their financial strategy and outsource the rest.

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."

at Rosaly.com we've been using bref since 2021 and we're extremly happy with it, even if we've stopped to the php-fpm integration. We haven't seen a reason yet to move out of the monolith and bref.sh allow us to have the best of both world (php + lambda )

1. we're a small team and we want to manage as less infra as possible 2. with their "dev mode" docker images, we can a local version which replicate 99% of the production environment (same runtime, same readonly filesystems etc.) 3. deploying is as simple as doing a zip , uploading to s3, and calling lambda update. 4. we have cronjobs with cloudwatch , Symfony's Command.

I feel like the naming of the bank (Treezor) is slightly unfortunate since it's so close to the "Trezor" bitcoin hardware wallet...

I agree, it's what I thought when I read it.

Tresor means safe / vault, it's a quite natural name for a bank.

Tresor -> Treasure

Also a cognate of thesaurus. Like the Trésor de la langue française.

The bank isn't named Tresor - it's named Treezor. That's quite a bit closer to Trezor than Tresor.

Anyways, if companies are going to use made up words for their names I'm happy to always deny them the benefit of the doubt.

My point was that both of these companies/products are named after the "Tresor".

Aren't all words made up?

It sounds like hacker-speak for a forest.

"Let's go h4x0r all the tr33z0r5 for the logz"

Curious if they have spikey latency from cold starts? The authorization calls have a time budget but it's pretty generous so maybe a nothing-burger there? How do they keep authorization context fresh enough for the lambda performing it?

Also... what has the bill been like? I've used Lambda for side-car data migration projects but I'd be surprised if it saved money over a beefy co-located or cloud server if your volume is generally constant.

There was once upon a time a discussion about bank/finance software system. You have to keep long history of audit records / logs. It is difficult to peruse such consideration here with the database ballooned to the cloud.

> You have to keep long history of audit records / logs. It is difficult to peruse such consideration here with the database ballooned to the cloud.

Actually, it's easier. AWS RDS with multi-zone failover and replication + backups with retention schedules, deletion protection and legal holds... easy as a cake, less than 100 lines of Terraform code. And no risk of insider threats deleting, manipulating or ransoming the backups.

I wonder why they went with AWS Lambda and PHP instead of something serverless-native like Cloudflare Workers? I guess they still have some critical parts of the legacy stack on AWS (DBs especially, but also other AWS services).

I wonder if you can build something like this entirely greenfield today, like what you'd use as a permanent data store for all the transactions, without having to manage the scaling of each individual microservice. Would CF Workers + Durable Objects be able to handle something like that?

Also, I just realized "Bref" is its own project that lets you run PHP on serverless Lambdas... like a Google Cloud Run on Amazon?

Is this really such a big niche? It's weird to me to you'd want to use PHP for something like this (and I love PHP, it just doesn't strike me as the best tool for serverless).

As you can see on the website (https://bref.sh/) there's 13 billion monthly AWS Lambda invocations using Bref (PHP).

That doesn't really say much. Isn't the whole point of serverless to support high-volume, individually-inexpensive, invocations?

For context, 13B is like roughly a <strike>$2000</strike> (edit: more like $4000, sorry) spend on Cloudflare Workers, similar cost (harder to calculate but ballpark similar) on Lambda. That could be a single company spending the bulk of that.

(Further edit: Lambda pricing is way off too. See reply below.)

That ballpark is not even close to the park. My company spends ~$500/month on AWS Lambda and we're doing about 2M/req/day with Bref. There's still 12B 940M requests to account for

Thank you, and sorry about that!

How come Lambda is so expensive for you?

At 13000M invocations/mo, that's $2600 in requests. Is it the GB-seconds duration charge that get you?

The GB-second is the relevant cost of AWS Lambda. # of invocations is pretty irrelevant.

60'000'000 requests

1536MB RAM

300ms response avg

(calculation includes free tier):

Request costs: $11.80/month

Execution costs: $443.42/month

Total AWS Lambda costs: $455.22/month

I see, thank you for the explanation! Sorry for my mistaken assumptions.

PHP is great for serverless because its execution model is compatible with it.

Unlike Node, Python, Java, etc. that start a long-lived server, each request is handled by PHP in a separate process.

That's what makes it really to use with serverless (and lift-and-shift, like what Treezor did).

Does that really matter when JS can be isolated in V8?

Comparing Bref (https://bref.sh/docs#maturity-matrix) which inherits Lambda's 200ms+ cold starts vs Cloudflare's 5ms (https://blog.cloudflare.com/eliminating-cold-starts-with-clo...), for example, is a pretty big difference.

But I guess if performance isn't a critical use (or you just have so many invocations all the time in every data center that cold start isn't an issue), it's nice to be able to ~port~ copy and paste over your existing PHP code.

DynamoDB as a data store for transactions works just fine, as long as you are aware of the trade-offs and design a good data model.

Sorry, I didn't mean that as a challenge to AWS, just wondering what the pros/cons/tradeoffs are to each approach.

banks have low requirements with no technical challenges...

im honestly amazed how bad almost every bank service is with their tech usage... and this has been true for all of my living memory.

i might have to look into these guys... maybe i can have a service thats only millions of times worse than i expected as a child, instead of trillions of times worse

Where's the database staying on? You migrated to AWS RDS or it's elsewhere?

In second part (Refactoring to serverless microservices) where is database in there ?

I'm going to guess that that database moved to RDS and, once there, was likely refactored as services were decomposed to microservices... but that's not mentioned in the article.

I have no clues about what's better but as a french I'm amazed by the idea to delegate banking operations to a cloud provider. Last time I worked in bank IT political requirement and good practices were using their own private physical network infrastructure over all the country and data storage server rooms were literally bunkers with armed security.

Is it that common around the world and 'we' just happen to have been overkill on security or do they are not really a true 'bank' and more a payment provider ?

that seems such a change from some years ago were cost were totally the last of the issues against security.

It's way worse than you think. A large number of Swiss banks including Swiss banking regulators store all their data on Google Cloud.

A lot of swiss government data is also stored in AWS, made a few headlines during covid because we "delegate our data to the americans"

We have your data, you have our money, sounds fair =)

They don't though. Swiss tax wealth (though its a tiny fraction). IRS makes it a massive PITA to hold substantial financial stakes in foreign companies. See FATCA and GILTI. And many tax deferred foreign retirement funds are not treated as being tax deferred by the IRS. It only gets more complicated from here. It's by far easier to earn and hold cash in America.

Isn’t the point of a Swiss bank account that the IRS doesn’t know about it?

That was many years ago. The entire Western world is compromised and reports to the IRS -or- the bank kicks out anybody who MIGHT be a US Citizen to avoid being sanctioned. The end result is only the few most central banks in the country take American clients -or- they are hopelessly behind on regulatory compliance (YOLO).

I mean it's all encrypted, right? Most cloud providers even allow you to specify your own encryption keys. Sure, the NRO isn't going to start uploading all their sat imagery to a gcp bucket, but I'd imagine it's fine for everything that's not classified.

Heck, even for the classified stuff, I heard Azure built a government owned datacenter running a self hosted copy of their software. Much better quality than asking some Gen Dynamics contractor to manage everything for you.

These are public facing bank services - so at some point have to be connected to the internet, quite a few banks use AWS for this [1]. I don’t know about Treezor but most of them will still have their own data centres for some or all of their ‘secure’ systems (if only because it’s running on some legacy hardware)

[1] https://aws.amazon.com/financial-services/banking/

What makes a physical server so much more secure than a cloud-provided one? AWS services are very secure: they have a list of compliances and security controls for banking-related services here:

https://aws.amazon.com/financial-services/security-complianc...

In the US at least, I never thought of banks as particularly tech-savvy, just change-averse. They tend to be the big companies with the worst websites and apps, transactions take days to clear, their secure messaging is a mess, everything about the UX is terrible, fraud handling and benefits usage seem like separate apps altogether... I dunno if any of that translates to their security handling, but I would imagine big cloud providers with huge security teams would be better equipped to deal with those concerns than any single bank would?

Certainly I would trust AWS with my information more than my bank. My bank is only trustworthy because we have regulations limiting my liability for unauthorized charges... without that I would never trust my bank (or Paypal, for that matter) to hold my funds. These are the same people that still use magstripes and publicly-visible numbers to authorize transactions, after all. Of all the services I've used, my bank is the only one that regularly gets its info stolen (credit card fraud). Thankfully the law doesn't let them hold me responsible for the charges.

Some banks have so much tech (legacy mainframe to cloud providers) I’ve head them describe themselves as an IT company that makes money off banking.

My credit union is lackluster but that’s expected I’m not there for their mobile apps.

On the other hand, there a bunch of fintech startups now that only build fancy apps with nice UX on top of existing banking infra (often partnering with some legacy bank).

I miss Simple :(

Me too. It helped me wrangle a budget where YNAB and all others failed

By any chance does the name of this bank sound the noun you'd use to describe a large urban area?. I've heard it too.

No it was Chase.

Banking in the US is very different from banking in France. USA has all these tiny banks, credit union and such, in addition to the mastodons like chase, boa etc. In France, there are maybe five or six huge banks, and their subsidiaries. As far as I know, most of Europe runs on the same model (a few huge banks rather than a plethora of small banks).

Which bank was that? As someone living in France, I bank with one of the "big banks" and even though I have no idea how their internal networks are laid out, I can't help but shake my head in disbelief whenever they send me an SMS to confirm some operation "for my security". Think adding a new transfer beneficiary, making a "large" bank transfer, or paying online with my credit card. The SMS doesn't even have all the details of the operation. It's something like "are you trying to pay X €?". No word to whom, from where, etc.

This isn't a step up from "nothing", mind. Initially, I used to have some kind of OTP fob for paying online. They then moved to SMS. Then to their app attached to my iphone. Now, back to SMS. I still have the app installed on the same iphone, and I use it regularly.

(Probably, why take risk) Can't tell the bank name (but yeah, in the top 4 by size) and not trying to defend your bank but the SMS validation thing is actually on the state 'fault' and you are in fact legally covered in most cases, I don't have the legal text on hand but by typing in google : https://www.moneyvox.fr/banque/actualites/77237/fraude-sur-c... Look for Code SMS and you have a link to the european reglementation. I assume one of the reason is that in fact in case of phishing wire transfert are heavily monitored and reversible. Without giving technical details, in fact 'a lot of peoples' have actually large right to move sums of money around. The trick is that's it reviewed and reversible for days.

I heard it used to be similar in ING but they slowly migrate some services to Azure for quite some time now.

I bet they will never fully migrate (and they don't want to).

Not affiliated with ING in any way, its just what I heard.

They did manage to get rid of their mainframes though ...

A imho healthy aspect of the move towards public cloud is to start with an exit strategy. This is turning out to be quite tricky. Some services though can be sourced from public cloud (ci/cd, ticketing, planning etc) but core workloads not so easy.

I've worked for a bank in Europe, and the core banking system is as you describe it.

Other satellite services and applications are migrated to the cloud or SaaS, but the core is an old school mainframe, solid and tested to the last bit.

In the UK, it’s relatively common. Some of the older systems at legacy banks will still run on premise, but more because AWS lacks a mainframe instance type than anything else.

The main concern from the regulator perspective isn’t security as much as concentration of risk in a small number of providers: if AWS goes down, will it take the whole financial sector with it?

> In October 2021, they successfully migrated their first API route to AWS Lambda, the most critical one handling all live credit card transactions. Over the following year, more and more API endpoints were migrated away from the servers to AWS Lambda.

Why? Why do people insist on doing this? Move something less important first, prove you can operate in production, then move the crown jewels.

I'd love to hear about the rationale behind this decision, because operational cost certainly isn't it. It's ludicrous to migrate a high-traffic, high-risk API to a function-as-a-service solution like AWS Lambda. Either they have a very unique requirement or it sounds like this might very well be the poster child of clueless resume-driven development.

What specifically makes it ludicrous to you?

IME the rationale behind such decisions is what I call the "sinking ship" phenomenon in infrastructure. Maybe their system was failing in weird ways, hard to maintain, causing all sorts of issues, etc. In that "sinking ship" it's always gonna be "women and children first," or rather, their most critical systems first.

Reply on news.ycombinator.com