I always love a story about a successful strangler pattern migration.<p>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.
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.<p>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.
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 <i>why</i> 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?
Treezor is not really directly a bank but more a "bank as a service" company.<p>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.<p>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.<p>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.
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)<p>I have immense respect for the author, but I'm perplexed about the decision to build a bank on this stack.<p>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 (<a href="https://twitter.com/themsaid/status/1716844479817154589" rel="nofollow noreferrer">https://twitter.com/themsaid/status/1716844479817154589</a>).<p>I really do wonder what the bullet points of pros/cons in choosing to go serverless for something like this were.
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.
""
<a href="https://www.crunchbase.com/organization/treezor" rel="nofollow noreferrer">https://www.crunchbase.com/organization/treezor</a><p>So, is this a payment processor much like Stripe?
Wow, that is just amazing.<p>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?<p>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?<p>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!<p>/s<p>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.
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 )<p>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.
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?<p>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.
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).<p>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?
banks have low requirements with no technical challenges...<p>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.<p>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
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.<p>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 ?<p>that seems such a change from some years ago were cost were totally the last of the issues against security.
> 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.<p>Why? Why do people insist on doing this? Move something less important first, prove you can operate in production, then move the crown jewels.