Domain-Oriented Microservice Architecture • Hacker News Board

Re: Domain-Oriented Microservice Architecture

#11

Post by blunderfel » Sat, Jul 25, 2020, 12:12 AM UTC

Twisol wrote: post #2

Depending on what angle you come at this from, you could say that DOMA groups services into clusters ("domains"), as Uber has done here, or that services always should have been domain-driven, and DOMA welcomes the networking layer inside the bounded context as well. I've spent a lot of time trying to understand when a microservices architecture makes sense, what the caveats are, and what philosophy one should take t…

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.

Re: Domain-Oriented Microservice Architecture

#12

Post by jzoch » Sat, Jul 25, 2020, 12:16 AM UTC

bob1029 wrote: post #9

recursivedoubts wrote: post #3

Seems to me that big progress will be made when we can decouple system boundaries from network calls.

I still think the approach of baking the entire enterprise into 1 gigantic binary is the best. Stack traces are so much easier to work with compared to distributed logs and side effects. We are already at a point where you could hypothetically do this for a reasonably-sized organization. A 64 core CPU can support a huge number of clients. Stuff like .NET Core scales really well if you want to build something complex…

This falls apart when you care a lot about availability and therefore want a particular service to be stateless. Then you add some feature that needs a tiny bit of state and suddenly you can't scale up and down as easily and need to start paying attention. This rolls forward into a big ball of mud - a monolith can be tricky too at scale

Re: Domain-Oriented Microservice Architecture

#13

Post by bob1029 » Sat, Jul 25, 2020, 12:27 AM UTC

jzoch wrote: post #12

bob1029 wrote: post #9

Earlier quoted context omitted.

I still think the approach of baking the entire enterprise into 1 gigantic binary is the best. Stack traces are so much easier to work with compared to distributed logs and side effects. We are already at a point where you could hypothetically do this for a reasonably-sized organization. A 64 core CPU can support a huge number of clients. Stuff like .NET Core scales really well if you want to build something complex…

This falls apart when you care a lot about availability and therefore want a particular service to be stateless. Then you add some feature that needs a tiny bit of state and suddenly you can't scale up and down as easily and need to start paying attention. This rolls forward into a big ball of mud - a monolith can be tricky too at scale

One trick is to leverage the fact that you have 1 type domain, and to develop a common persistence abstraction for the entire enterprise. Then, all of your business entities can be pushed through it for a consolidated replication flow. This can be [a]synchronously replicated to additional node(s) as required, potentially with replication rulesets defined in application code as well.

It sounds like a complex monster until you build it one time. Then you are basically done. The leverage you get when you have 1 way to do everything is extremely powerful. I do recognize there are scenarios where you cant force one persistence abstraction on all use cases, but there's no reason you couldn't have a TimeSeriesEntity (keyed by time) in addition to a typical BusinessEntity (keyed by a unique integer). Both could have unique replication implementations, but it would still be standardized and all nodes would be speaking the same protocol because they all derive from the same source.

The monolith only remains a monolith in operational terms until the engineering team develops some imagination.

Re: Domain-Oriented Microservice Architecture

#14

Post by nfoz » Sat, Jul 25, 2020, 12:29 AM UTC

I don't like that they define microservices as components communicating via RPC, because this precludes other models like pub-sub.

Re: Domain-Oriented Microservice Architecture

#15

Post by drol3 » Sat, Jul 25, 2020, 12:42 AM UTC

dkersten wrote: post #7

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 am working for a company that has moved from 3 to 15 backend developers and 25 to 50 services over the last year.

The amount of services is really quite meaninglessness compared to the amount of developers. As with anything the efficiency good down as the amount of people goes up. There is no way that 2000 people can agree on anything. So most likely there is lots and lots of overlap.

You could probably refactor some of this duplication out, but by the time you would be done new duplication would have emerged. Keeping many people in sync is just difficult :)

Anyway the point is that 2200 services is meaningless without telling how many employees are working on said services :)

Re: Domain-Oriented Microservice Architecture

#16

Post by eikenberry » Sat, Jul 25, 2020, 12:48 AM UTC

dkersten wrote: post #7

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?

Remember that those aren't 2200 separate things going on, but 2200 instances of the services. I'm sure that includes very large clusters running many copies of the same service.

Re: Domain-Oriented Microservice Architecture

#17

Post by gen220 » Sat, Jul 25, 2020, 12:50 AM UTC

blunderfel wrote: post #11

Twisol wrote: post #2

Depending on what angle you come at this from, you could say that DOMA groups services into clusters ("domains"), as Uber has done here, or that services always should have been domain-driven, and DOMA welcomes the networking layer inside the bounded context as well. I've spent a lot of time trying to understand when a microservices architecture makes sense, what the caveats are, and what philosophy one should take t…

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 apart.

One of the advantages of the microservices model is it limits the damage people can do. :)

It forces a bounded context on a team of engineers and says “hey, play in this sandbox and follow these SLAs. If your internal designs are awful, good luck.”

Re: Domain-Oriented Microservice Architecture

#18

Post by wikibob » Sat, Jul 25, 2020, 12:51 AM UTC

eikenberry wrote: post #16

dkersten wrote: post #7

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?

Remember that those aren't 2200 separate things going on, but 2200 instances of the services. I'm sure that includes very large clusters running many copies of the same service.

That is an incorrect interpretation.

I assure you there are /significantly/ more than 2200 instances of the services running.

They do indeed mean 2200 separate deployable services.

Re: Domain-Oriented Microservice Architecture

#19

Post by harel » Sat, Jul 25, 2020, 12:59 AM UTC

I'm not entirely sure why this is sold as innovative new approach. Over the last few years, I've seen and developed micro services that are indeed cut down to specific functionality, and I've done ones where the domain was the scope. The latter has proven to produce bigger services, but a more maintainable ecosystem. Also, the division for micro services should also be dictated by the context of the business, and not just the current whims of the devs.

Re: Domain-Oriented Microservice Architecture

#20

Post by gen220 » Sat, Jul 25, 2020, 1:03 AM UTC

adamkl wrote: post #5

Twisol wrote: post #2

Depending on what angle you come at this from, you could say that DOMA groups services into clusters ("domains"), as Uber has done here, or that services always should have been domain-driven, and DOMA welcomes the networking layer inside the bounded context as well. I've spent a lot of time trying to understand when a microservices architecture makes sense, what the caveats are, and what philosophy one should take t…

> 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 the ship, so to speak. I think this risk compartmentalization is a benefit that must be weighed against the costs (in terms of latency, maintenance of shared libs, opentracing, etc). These days the costs are vanishing, as tools are quite good and becoming easier to manage.

All that said, if you’re a small team of senior engineers working with a shared mental model, a single binary with internally-bounded contexts works really well and I agree with you, having seen it done well.