Live data from Hacker News

Domain-Oriented Microservice Architecture

eng.uber.com

71–80 of 116 posts

Re: Domain-Oriented Microservice Architecture

#71
post #54

I'm looking forward to the article about the problems DOMA introduced for them and what they came up with next. Wonder if we will see a full circle back to monoliths. 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 hea…

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

Re: Domain-Oriented Microservice Architecture

#72
post #54

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…

Alright, you've piqued my interest; any pointers for where to learn this stuff, or should I just Google all those terms?

Here are some pointers:

"Large-Scale C++ Software Design"

https://www.amazon.com/Large-Scale-Software-Design-John-Lako...

Although oriented towards C++, many architecture tips apply to other languages as well.

John Lakos is in the process of writing updated versions of the book.

"Large-Scale C++ Volume I: Process and Architecture"

https://www.amazon.com/Large-Scale-Architecture-Addison-Wesl...

"Large-Scale C++ Volume II: Design and Implementation"

https://www.amazon.com/Large-Scale-Implementation-Addison-We...

Then going back into the old days, you have

"Software Engineering in Modula 2: An Object Oriented Approach"

https://www.amazon.de/-/en/Jill-Hewitt/dp/0333515188

"Data Structures and Program Design in Modula-2"

https://www.amazon.de/Larry-R-Nyhoff/dp/0023886218/ref=sr_1_...

"Code Complete: A Practical Handbook of Software Construction"

https://www.amazon.com/dp/0735619670/ref=sr_1_1

"AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis"

https://www.amazon.com/AntiPatterns-William-J-Brown/dp/04711...

"Component Software: Beyond Object-Oriented Programming"

https://www.amazon.com/Component-Software-Object-Oriented-Pr...

"Use Cases Combined With Booch/Omt/Uml: Process and Products"

https://www.amazon.com/Use-Cases-Combined-Booch-Omt/dp/01372...

Just some pointers to get you started.

Re: Domain-Oriented Microservice Architecture

#73
post #54

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…

Can you recommend amytging to read? Lakos seems to be C++ oriented.

It is, but many of the ideas apply to other languages as well.

I have posted some links to books on sibling comment.

Re: Domain-Oriented Microservice Architecture

#75

Earlier quoted context omitted.

I'm a fool who has done microservices first and is very happy about it. Just want to throw that out there into the sea of negativity I see towards microservices.

I was hired and was told I'll be building ONE of the microservises for their upcoming kubernetes platform. A year later I have written 5 microservises and I am responsible for managing all 5 of them. It is hell.

[deleted]

Re: Domain-Oriented Microservice Architecture

#76

Earlier quoted context omitted.

Monoliths don't run on a single box. My entire current business runs on a single monolithic application, and it's running across multiple AZs with five different instance roles (consumer site, API endpoint, admin site, background jobs, and reporting), sized by memory demand and contention efficiency, then scaled horizontally according to workload demand. They are all, however, running exactly the same code, just in d…

It seems you should revise your concept of monolith because your description is anything but it. I mean, you yourself talk about "different instance roles". You should pay attention to your own claims: if you have a distributed deployment comprised of different nodes, and you have specialized nodes that you yourself state that are ran to handle limited and very specific responsibilities, then just because you decided…

Absolutely. Having a single binary that runs different services depending on the configuration and is deployed as such creates a distributed system, not a "monolith". I am not clear about the advantages of doing that.

Re: Domain-Oriented Microservice Architecture

#77
post #29

I’m honestly not trying to be snarky here but I didn’t know there was any other way to design microservices (with intention) that weren’t domain oriented.

I’ve seen one service per database table, and have had architects seriously think that a table equals a bounded context. Then they try to work out how to do two-phase commit across micro services.

Re: Domain-Oriented Microservice Architecture

#78
post #29

I’m honestly not trying to be snarky here but I didn’t know there was any other way to design microservices (with intention) that weren’t domain oriented.

I'm on the same boat.

"Previously product teams would have to call numerous downstream services to leverage a domain; they now have to call just one....Furthermore, we were able to classify 2200 microservices into 70 domains."

So they went from 2200 to 70 microservices? One extreme to the other. The answer is somewhere in the middle.

Re: Domain-Oriented Microservice Architecture

#79
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?

Hmm, would it be easier to imagine PayPal or Stripe requiring a lot of services? Given its volume of payments, Uber has basically had to re-implement PayPal internally, custom-tailored to its own flow. Companies at this size/scale basically contain multiple whole companies within them. Think of like all the SAAS services that your company relies on, and then imagine that your company now owns all of them and all the services that come with them.

Re: Domain-Oriented Microservice Architecture

#80
STOP WASTING UR TIME AND START HIRING REAL PROs based on their real SKILLZzzzZzzz!

I would go this way... (am technical not commercial...)

U keep your stuff in production while I study your environment & take notes...

And then changes propositions happens! (I may offer to rewrite full or part of a stack for the purpose... and also technology change for independence...)

Then conception, testing, validation...

PRODUCTION in the long term without headaches and clear understanding!

o/

Post reply on HN