81–90 of 116 posts
I think this is key sentence. Microservices does not make a lot of sense for teams of 10s, while are a great tool for team of 100s.
Earlier quoted context omitted.
Not at Uber, but I've heard a service there can be as small as a database table or two with some CRUD. Or a lambda-style function or two that provides some simple logic when queried or aggregates from a couple other services. Not saying that's a good way to build systems but it's definitely one way.
Who has 2000 database tables though? Or 2000 lambda functions for that matter.
> In other words, organizations adopt microservices for an operational benefit at the expense of performance. ...no, not at all. There are a couple of operational benefits, but vastly more drawbacks, and on balance microservices are phenomenally harder to operate than monoliths. Organizations adopt microservices when the logistical overhead of coordinating teams against a monolith becomes so large that it starts affe…
> Organizations adopt microservices when the logistical overhead of coordinating teams against a monolith becomes so large that it starts affecting product velocity. That's certainly one of the operational limits, but arguably not the most important one. You distribute your system so that parts of it may scale independently, for example. Traffic fluctuates along time and the only option you have to scale your system…
Microservices are a solution to organizational problems, not technical problems. On balance they create far more technical issues than they solve.
One thing that was not touched on - how is security done in DOMA?
* Is auth happening at domain gateways or at each service?
* Similarly for encryption, does it terminate at Domain GW or at each service?
> In other words, organizations adopt microservices for an operational benefit at the expense of performance. ...no, not at all. There are a couple of operational benefits, but vastly more drawbacks, and on balance microservices are phenomenally harder to operate than monoliths. Organizations adopt microservices when the logistical overhead of coordinating teams against a monolith becomes so large that it starts affe…
The last company I worked for was very much an “API first” company. We were a B2B company and our APIs were used by our relatively lightly used website. But they were also used for sporadic and large ETL jobs when files from customers came in and most importantly we sold access to our APIs that were used for our customer’s mobile apps and heavily trafficked website. We went microservices for the canonical reason you…
Earlier quoted context omitted.
Sun RPC marketing message, "The network is the computer". So yeah, we keep going at this, and then people discover that monoliths written in a correct modular way, with libraries, happen to be easier to debug and reason about without a network in the middle. Main problem seems to be that not many developers bother to read about modular programming, large scale development (like Lakos books) and what features their la…
Are you sure that was just a marketing line for "RPC"? I thought the scope was broader. IMO Micro-Services were addressing the skill gap in designing comprehensive schemas, not so much the object layer between user and data. So not modular "programming" but rather "modular design".
Earlier quoted context omitted.
The last company I worked for was very much an “API first” company. We were a B2B company and our APIs were used by our relatively lightly used website. But they were also used for sporadic and large ETL jobs when files from customers came in and most importantly we sold access to our APIs that were used for our customer’s mobile apps and heavily trafficked website. We went microservices for the canonical reason you…
That reason is oft touted but experience has pretty unambiguously revealed that it never pans out in practice. I mean you do get that benefit but the price you pay for it is absolutely disproportionate if that's the only thing you want. Opting in to microservices purely for presumed technical benefits is absolutely a mistake.
We were used by health care networks. Can you imagine the increased use post-Covid?
We even had some that were both hosted on Fargate (Serverless Docker) with lower latency, more expensive but slower scaling for online use and hosted on Lambda for internal batch use - higher latency, faster scaling, less expensive for batch use. The CI/CD pipeline deployed to both.
Earlier quoted context omitted.
> The network should only be tolerated as long as it provides benefits that outweigh the costs. I agree. There should be no need to use network calls to enforce interface boundaries if you have a cohesive bounded context. Or to be snarky about it, welcome to 2004 Uber! Eric Evans sends his regards!
Unfortunately, picking and enforcing bounded contexts is hard work in a big organization, even with strong code review processes. There will always be people who don’t want to respect where the boundaries are drawn (not in a constructive, “it could be better” kind of way, but in a “but this works, too” kind of way). If a group of such people get together, microservices compartmentalizes their capacity to drag down th…
Earlier quoted context omitted.
Or how about plain old onion architecture... even older than hexagonal. This is literally scaled/distributed domain-driven design (DDD). I have felt strongly that folks got so caught up in the hype of yet another new thing they forgot how to extend what came before. It feels like a reinvention of existing ideas at larger scale, and a pattern we keep repeating. I'm not complaining, of course - new things are possible…
I'm confused. You're saying that people are reinventing existing ideas at larger scale, but you also are saying that people don't know how to extend what came before? Those sound like the same exact thing.
I am making an observation - when each new "fad" or "hype cycle" tech starts, it seems as though the pattern knowledge of what came before is discarded, or, disregarded as "legacy" or possibly even just forgotten. It feels like a knowledge transfer is missing. It would be terrible if, we, as an industry aren't passing down knowledge and reinventing hard won pattern discoveries efficiently.
Did this pattern Uber discovered come from studying onion architecture, DDD, etc first, finding the limitations, and then scaling them?
Or did this arise from throwing away everything that came before (or not knowing about it), forging an undiscovered path, and then rediscovering the old patterns could be applied? If the latter, what can be learned to make this process of discovery and linkage to existing patterns more efficient?
I think this article shows innovation is tricky, or, the risk (and potential reward) at the bleeding edge. Leaving behind design constraints of what came before might be necessary.
Maybe I'm trying to say, as an industry we need to balance exploitation of previous knowledge and our attitudes about how we feel about "legacy", with the unquenchable thirst for the next new innovation?