31–40 of 116 posts
Seems to me that big progress will be made when we can decouple system boundaries from network calls.
[1]: https://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-archit...
Somewhat off topic but maybe someone can enlighten me: > Uber has grown to around 2,200 critical microservices Even thinking about the very largest systems I’ve worked on, I can’t think of what could possibly be split into 2000 separate individual services. What are these thousands of microservices and how micro are they?
Seems to me that big progress will be made when we can decouple system boundaries from network calls.
Indeed - this is the premise of the "4+1 View Model of Software Architecture" paper from 1995 [1]. [1]: https://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-archit...
I must be honest: aside from the context in which it was linked, I came away terribly unimpressed by this paper. I found myself disagreeing on a number of points. Having only spent half an hour on it, I can't claim to have a major problem with it, but I wouldn't couch my architectural work against it.
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.
Heck, simple auto insurance systems with multiple products in a single large state can hit 5k really easy.
Somewhat off topic but maybe someone can enlighten me: > Uber has grown to around 2,200 critical microservices Even thinking about the very largest systems I’ve worked on, I can’t think of what could possibly be split into 2000 separate individual services. What are these thousands of microservices and how micro are they?
I'd be curious how that compares to Amazon's count of services (my guess is 10k+)
...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 affecting product velocity. Microservices are a way to release that organizational/logistical friction, at great technical cost.
With that said, the domain-oriented bounded context is indeed the right way to think about service delineation.
Earlier quoted context omitted.
I'm a big fan of the modular monolith pattern. I usually make domain modules as independent as possible and invert dependencies for web and persistence layers. If you design well you can break off domain-based services whenever the advantages warrant it.
If you ever have to start a big company from scratch, this is how to do it. There aren’t any major drawbacks to this model when a business is young (first couple years). The downsides appear when you have different parts of your application with very different load requirements. It also takes a lot of discipline to write code this way. Without strict code review and more experienced hands, the bounded contexts fall a…
> 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…
We went microservices for the canonical reason you should - to be able to release and scale independently.
I know I'm being snarky and I have used micro-services myself, but only when it was smacking me in the face as the best tool for the job. Is the fools-gold rush still on to do everything as a micro-service from the get-go?
Side note, I can't wait to hear my boss use "DOMA" in a meeting in the coming months. FML.
Feels like a lot of old knowledge was discounted / ignored and the mistakes are being rediscovered. Feels a bit like the Hexagonal Architecture being rediscovered. Micro service with half life of 1.5 years? Does that mean that enough planning is not being done? Or leadership failure at software planning level? Collaboration between teams at scale is very hard but that is what the leadership layer is for - to collabor…
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 and being learned through this innovation. I do feel we should be more careful on the cutting edge, to see how it relates to where we came from.
Put another way, reinventing the wheel is not pointless if you come out with a better thing, or better wheel. But don't forget what was good about the previous wheel before you throw it out?