Hacker News Reader

Comment by Narkov | Hacker News Reader

> more than 20,000 containerised workloads across more than 2000 microservices to date.

This is insane. What am I missing here that an organization is bragging about having 2000 moving parts?

They seem to be operating very well with the 2000 services (the number doesn't seem to have changed much in the last few years which is interesting, despite them adding new features, etc).

The domain is obviously very complex as its not just a ledger, but risk, loans, overdrafts, savings, etc as well as premium offerings, interacting with different payments networks like FasterPayments and Mastercard. Then there are the budgeting features, payments between friends, support system (Which is probably quite complex in its self), card issuing, internal dashboards and metric services, etc, etc, etc. I can easily see how this gets to 2000 services and I didn't even begin to think about the business accounts, US accounts, etc.

How is it insane? Do you think factories don't have 2000 total pieces of equipment that go into manufacturing widgets?

Quantity of moving parts is a nearly worthless metric on its own without describing the scale and complexity of those moving parts.

Those moving parts are defined by the complexity of the business. Banking software with 20000 classes deployed in J2EE application server on a mainframe would not be much different.

That's not really true, since microservices involve what boils down to RPC over a network. There are so many more failure modes involved when you have 2000 asynchronous processes talking to one.

That is true, but it also allows for much more orderly start-up and shut-down as well as automatic recovery. A service is a pretty well defined entity that can be exhaustively tested far easier than the corresponding monolith with 2000 classes and tons of non-local effects. To use processes for that purpose has definitive advantages. See "Erlang/OTP" for an example of how this can give you incredibly solid distributed architectures.

They are the actual inspiration for my blog post against microservices 2 years ago (https://blog.matthieud.me/2019/microservices-considered-harm...).

At least, they've only added 500 microservices in 2 years (not even 1 per day, how sad!)

A friend of mine working for a rival neobank was telling me about a tiny piece of the whole thing that used 5 microservices to achieve it. This was a security related piece, and when I pressed him why something as simple as what he was describing needed 5 services, he went somewhat into detail, and it sort of made sense.

I can imagine 2000 microservices being rather low for a bank.

Not sure they're bragging about it - they're just stating it as context for their blog post.

And is 2000 moving parts too many? How many moving parts do you need to run a bank? I can imagine they're having to comply with ~2000 legislation clauses, for example. Isn't that just the complexity of their domain?

From my understanding the approach to microservices was more or less a day 1 thing due to some of the early engineering hires being very experienced with them; so the number of them was comparatively high pretty early on.

What’s insane about it? Tooling provides what’s needed to build, test, scan, deploy, manage and monitor.

Reply on news.ycombinator.com