[HN Gopher] A bank runs serverless with PHP and AWS Lambda
___________________________________________________________________
A bank runs serverless with PHP and AWS Lambda
Author : mnapoli
Score : 81 points
Date : 2023-11-01 13:53 UTC (9 hours ago)
(HTM) web link (bref.sh)
(TXT) w3m dump (bref.sh)
| willsmith72 wrote:
| 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.
| ceejayoz wrote:
| 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.
| jackconsidine wrote:
| 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?
| ceejayoz wrote:
| 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.
| ndriscoll wrote:
| 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.
| me_graf wrote:
| 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).
| cogman10 wrote:
| This was my thought. Lambda works well for infrequent tasks.
| But hosting an API? That seems like it could get expensive
| pretty fast.
| deleugpn wrote:
| 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.
| ndriscoll wrote:
| 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.
| cebert wrote:
| A single lambda can only handle one request at a time,
| but you can scale up 1,000s of instances if needed.
| ndriscoll wrote:
| 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.
| WatchDog wrote:
| 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.
| Sohcahtoa82 wrote:
| 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.
| deleugpn wrote:
| 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.
| willsmith72 wrote:
| 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.
| Sohcahtoa82 wrote:
| Good points all around.
|
| The costs certainly are not as cut-and-dry as I
| originally expressed it.
| cebert wrote:
| 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.
| ndriscoll wrote:
| 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/gettingsta
| rted-...
| mnapoli wrote:
| 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
| tomrod wrote:
| 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.
| chx wrote:
| 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.
| Supermancho wrote:
| > 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).
| mikece wrote:
| 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?
| yaseer wrote:
| 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.
| kypro wrote:
| 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.
| justinsaccount wrote:
| 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
| mikece wrote:
| 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?
| djbusby wrote:
| 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
| bogota wrote:
| hur dur php bad because they told me
| romanhn wrote:
| 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.
| munk-a wrote:
| 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.
| rob wrote:
| 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.
| Muromec wrote:
| 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.
| smrtinsert wrote:
| I don't know a single dev across the years who has ever
| made php their first choice.
| munk-a wrote:
| 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.
| Implicated wrote:
| /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.
| stronglikedan wrote:
| 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.
| zelon88 wrote:
| 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.
| Muromec wrote:
| I'm the usual suspect for shi^W questioning php and I think
| you are wrong about demographics.
| solardev wrote:
| 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?
| distantsounds wrote:
| 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.
| solardev wrote:
| 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.
| gumballindie wrote:
| I think it's more about people ignoring PHP. I worked with
| PHP for a long time and was extremely happy to move away from
| it. PHP developers usually lack understanding of engineering
| practices and make things up that sound like engineering.
| Generally speaking I now advice everyone to avoid that
| language. Use python or nodejs if you want something cool for
| the web. PHP is dead.
| mikece wrote:
| 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.
| mjburgess wrote:
| 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
| mikece wrote:
| 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!
| solardev wrote:
| 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)
| neatze wrote:
| In second part (Refactoring to serverless microservices) where is
| database in there ?
| mikece wrote:
| 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.
| ThinkBeat wrote:
| "" 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?
| herpderperator wrote:
| I feel like the naming of the bank (Treezor) is slightly
| unfortunate since it's so close to the "Trezor" bitcoin hardware
| wallet...
| ganoushoreilly wrote:
| I agree, it's what I thought when I read it.
| The_Colonel wrote:
| Tresor means safe / vault, it's a quite natural name for a
| bank.
| djbusby wrote:
| Tresor -> Treasure
| munk-a wrote:
| 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.
| The_Colonel wrote:
| My point was that both of these companies/products are
| named after the "Tresor".
| solardev wrote:
| It sounds like hacker-speak for a forest.
|
| "Let's go h4x0r all the tr33z0r5 for the logz"
| joshstrange wrote:
| 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.
| mnapoli wrote:
| You can deploy using the CDK for example:
| https://bref.sh/docs/deploy/aws-cdk
| joshstrange wrote:
| 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.
| solardev wrote:
| 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...
| joshstrange wrote:
| 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.
| solardev wrote:
| 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.
| joshstrange wrote:
| 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.
| agentultra wrote:
| 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.
| AndrewDucker wrote:
| I'd love to know how much the cost changed.
| padjo wrote:
| > The migration to microservices is still an ongoing work.
|
| Ain't that always the way
| Muromec wrote:
| On schedule to be complyted in year, as of three years ago and
| still 80% in progress
| GaelFG wrote:
| 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.
| orangepurple wrote:
| It's way worse than you think. A large number of Swiss banks
| including Swiss banking regulators store all their data on
| Google Cloud.
| mellowagain wrote:
| 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"
| solardev wrote:
| We have your data, you have our money, sounds fair =)
| orangepurple wrote:
| 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.
| kevinventullo wrote:
| Isn't the point of a Swiss bank account that the IRS
| doesn't know about it?
| orangepurple wrote:
| 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).
| wing-_-nuts wrote:
| 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.
| helsinkiandrew wrote:
| 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/
| SamuelAdams wrote:
| 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...
| solardev wrote:
| 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.
| wil421 wrote:
| 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.
| solardev wrote:
| 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 :(
| xeromal wrote:
| Me too. It helped me wrangle a budget where YNAB and all
| others failed
| lawlessone wrote:
| 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.
| uxp8u61q wrote:
| 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).
| vladvasiliu wrote:
| 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
| EUR?". 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.
| tomwojcik wrote:
| 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.
| mvdwoord wrote:
| 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.
| jmorenoamor wrote:
| 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.
| cameronh90 wrote:
| 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?
| solardev wrote:
| 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?
| solardev wrote:
| 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).
| deleugpn wrote:
| As you can see on the website (https://bref.sh/) there's 13
| billion monthly AWS Lambda invocations using Bref (PHP).
| solardev wrote:
| 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.)
| deleugpn wrote:
| 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
| solardev wrote:
| 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?
| deleugpn wrote:
| 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
| solardev wrote:
| I see, thank you for the explanation! Sorry for my
| mistaken assumptions.
| mnapoli wrote:
| 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).
| solardev wrote:
| 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.
| reese_john wrote:
| 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.
| solardev wrote:
| Sorry, I didn't mean that as a challenge to AWS, just
| wondering what the pros/cons/tradeoffs are to each approach.
| witnesser2 wrote:
| 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.
| mschuster91 wrote:
| > 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.
| jackconsidine wrote:
| 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
| Implicated wrote:
| 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.
| ceejayoz wrote:
| That's for a large, fairly consistently loaded project.
|
| For a smaller site with bursty traffic, Lambda may be very
| relevant still.
| greatgib wrote:
| 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.
| mannyv wrote:
| 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.
| marcus0x62 wrote:
| > 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.
| rewmie wrote:
| 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.
| cebert wrote:
| What specifically makes it ludicrous to you?
| JohnMakin wrote:
| 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.
___________________________________________________________________
(page generated 2023-11-01 23:00 UTC)