We deploy to production over 100 times a day(monzo.com) |
We deploy to production over 100 times a day(monzo.com) |
It's entirely feasible that all incoming requests will hit a single node and stay there.
Still, hitting multiple microservices in a single request will have an overhead when marshalling all the http requests and whatnot.
That being said, there was genuinely need for microservices, to an extent. A bank's architecture is very different from a CRUD web app. Most of the code running wasn't servicing synchronous HTTP requests, but was doing batch or asynchronous work related (usually at two or three degrees of separation) to card payments, transfers, various kinds of fraud prevention, onboarding (which was an absolutely colossal edifice, very very different from ordinary SaaS onboarding), etc.
So we'd have had lots of daemons and crons in any case. And, to be fair, we started on Kubernetes before it was super-trendy and easy to deploy - it very much wasn't the 'default' choice, and we had to do a lot of very fundamental work ourselves.
But yeah, in my view we took it too far, out of ideological fervour. Dozens of - or at most a hundred-ish - microservices would have been the sweet spot. Your architectural structure doesn't need to be isomorphic to your code or team structure.
One of our engineering principals is to avoid premature optimisation, which is possibly one of the reasons our architecture has grown in this way. So far, whenever we've needed to fix a performance issue we've been able to solve it locally rather than change the architecture.
At the business level, we've been optimising for growth rather than costs, but this could change in the future, at which point we may need to reconsider our architecture. But for now it's working for us.
"We don't have time to test" -> Production poopfires -> "We need an out of band code review process"
The faces on these people when one proposes deployment in terms of basic git triggers on protected branches.
Sign-off would take 24 hrs to process, and the mysterious entity that signed off would have no context of our product or the changes, and no way to assess the risk.
Then, due to our lack of trusted regression testing, every damn change would take ~6 developers an entire work day to manually confirm that everything was working.
Why? We were measured on “number of tests.” The tech debt was too high to write quality tests before the next review, so we opted for quantity if we wanted promotion.
This was the hot path in a major (Fortune 10) financial company.
On a high-functioning team, you should have enough logging and monitoring that developers can identify many useful changes without PM involvement.
A deploy could be something as minor as "I noticed an error getting logged in production, here's a one-line change to fix it" or "This operation is running slowly, here's a tweak to the query so that it hits an index".
Done right, it avoids bugs - especially complex hard-to-roll-back state-related bugs - that can arise from discrete waterfall-style releases of big and complex features all at once.
Your comment seems to be making a hell of a lot of assumptions and associations which seem very specific to the environment you work in[0], but stated as though you think the entire world must be working in the same way. It feels a bit like a child insisting that they don't speak with an accent.
[0] "One deploy is one feature", "every company has 'BA's and 'PM's" [we had the latter but I'm scare-quoting both because they are far from universal], "each feature has to be 'identified' by said BA or PM", etc. Also, this seems to be written not only from a staid perspective but from a small-co perspective; for large companies, even 3000 features is not a huge number, and wouldn't be more than maybe 5 or 10 per team.
I'm not sure how many "feature" or stories that is. Maybe we need two to four pull requests per story.
There is already so much work to do consuming data from A, transforming it, and storing it into B.