Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Domain-Oriented Microservice Architecture

eng.uber.com

Post reply on HN
Print view View original

21–30 of 116 posts

Re: Domain-Oriented Microservice Architecture

#21

Post by Ozzie_osman »

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?

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.

Re: Domain-Oriented Microservice Architecture

#22

Post by dkersten »

Ozzie_osman wrote: post #21
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?

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.

Re: Domain-Oriented Microservice Architecture

#23

Post by adamkl »

gen220 wrote: post #20
adamkl wrote: post #5

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…

I was lucky enough to be in the right place, at the right time, to lead a group that scaled this approach across half a dozen different development teams.

Fortunately everyone bought into the architecture, and respected the boundaries. Not everyone was senior, and not all the code was great, but we adopted the viewpoint that so long as the bad code is in the right spot (and not talking to things it shouldn’t) everything would be ok in the end. And it was.

Half a dozen teams working in one codebase was definitely pushing it though, and the need to scale much beyond that would have definitely required some service-level compartmentalization to keep the ship from sinking, as you said.

Even then, it would still be a far cry from the “microservices should be small enough to re-write in 2 weeks” approach.

Re: Domain-Oriented Microservice Architecture

#24

Post by deltaeerie »

sdan wrote: post #4

Basically clumping microservices

I believe this is only the first point. It's also establishing a hierarchy of these "clumps" (layers), strict APIs representing a single clump for other clumps to consume (gateways), and a pattern for clumps to extend functionality of other clumps without polluting their models (extension architecture).

Re: Domain-Oriented Microservice Architecture

#25

Post by daxfohl »

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?

For every important service there is the current one, the old one that is still in use, the previous previous version that one dumb team still hasn't migrated from, the next gen prototype, the service that deploys the service, the service that monitors it, the data analysis tool, data migration services, the intern project, several upstream services that continuously test the integration points, blah blah blah.

Then you look at the verticals and there's maps, payments, analytics, hosting, marketing, security, identity, partnerships, third party integrations, and a million other things you don't think about.

It's pretty easy to get into those numbers if you want zero downtime and code your own verticals, and have the resources to do it.

Re: Domain-Oriented Microservice Architecture

#26

Post by kopos »

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 collaborate more not build more micro services.

Re: Domain-Oriented Microservice Architecture

#28

Post by jeswin »

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 don't find this surprising at all. Uber operates across 5 dozen countries (or more) each with different regulations and offerings.

For instance, in India you get autorickshaws (called "Autos" sometimes) in addition to cabs as a seperate option. Autos have different rules, billing, driver compliance and safety standards. There are probably a bunch of services around Autos.

Similarly, safety regulatons differ in each country, and in some cases teams are forced to act quickly. Having them in separate microservices again makes sense. Same goes for offers, eats etc.

2000 services is not inconceivable for a company operating across the world.

Re: Domain-Oriented Microservice Architecture

#30

Post by etxm »

gen220 wrote: post #20
adamkl wrote: post #5

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…

It’s important to respect the boundaries, but also have the flexibility to change them as the business changes.

I’ve seen many times where people were afraid to change boundaries because they assumed the first person got the architecture exactly right.

Post reply on HN