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

101–110 of 116 posts

Re: Domain-Oriented Microservice Architecture

#101

Post by ct520 »

fiddlerwoaroof wrote: post #45
ct520 wrote: post #41

Earlier quoted context omitted.

I’ll take the latter any day with good patterns of aggregating to a grey log. Having to triage production issues in a multiple application saas environment, The latter has always been easier to me. Don’t get me started on trouble shooting someone else’s crazy event queues

This is really interesting to me: I’ve always found dealing with code preferable to dealing with network communication. It might be because the languages I work with (common lisp, Clojure and Scala/Java/Kotlin) all have excellent code navigation abilities.

That would make sense in a perfect world to me. I would prefer it too. This company I worked for was leader in its industry and many vertices. It had legacy apps from 80s still running through today. Probably 30 SAAS based applications or so. Many many different languages used. Many using internal services and queues to communicate with each other. With 100's if not 1000's of B2B integrations, pumping millions of requests through their portal at any given time. (they also maintained their own data centers.) Anyways, given my experience and troubleshooting message queuing etc and jumping in new code bases all the time. I was more like a blend of SRE / Dev / IT / Product manager. (yeah I know). Given I worked across the SDLC I always found it easiest to, establish the problem statement and the behavior around it. The expected behavior, then dive into the gray log with a unique piece of information that should be logged and trace it from there. To each their own. Unfortunetly with architecture this way I commonly see "segmentation" between Support/Ops/Dev were a problem can end up in limbo. That's were I would hop in.

Re: Domain-Oriented Microservice Architecture

#102

Post by wpnx »

jmchuster wrote: post #99
clintonb wrote: post #95

Earlier quoted context omitted.

Uber uses Stripe and PayPal to process payments. They don’t need to reimplement either, and doing so would be a bit of a waste. It’s worth pointing out that not all of the 2200 services may be user-facing. Some may be internal, such as admin tooling or CI services. That said, 2200 seems like a lot!

Sorry, I think you are a bit mistaken about how payment platforms work. Stripe and PayPal provide an interface to a country's banks. In exchange for abstracting away the underlying bank infrastructure, you pay them a fee for every transaction. Stripe and PayPal support a limited number of countries and a subset of the bank's functionality. So if you want to interact with any new countries or access any non-supported…

Curious; where did you get the 10% number from

Re: Domain-Oriented Microservice Architecture

#103

Post by fiddlerwoaroof »

gen220 wrote: post #98
fiddlerwoaroof wrote: post #45

Earlier quoted context omitted.

This is really interesting to me: I’ve always found dealing with code preferable to dealing with network communication. It might be because the languages I work with (common lisp, Clojure and Scala/Java/Kotlin) all have excellent code navigation abilities.

If you have a monorepo, you get both! (You can grep for logging messages in the services you’re calling).

What would be even better is some way to use swagger/graphql to jump from frontend api calls to backend code

Re: Domain-Oriented Microservice Architecture

#104

Post by etxm »

timclark wrote: post #77
etxm wrote: 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.

Oh that. I’ve had to merge services like that.

People are always grabbing nouns and thinking they’re microservices.

Re: Domain-Oriented Microservice Architecture

#105

Post by jmchuster »

wpnx wrote: post #102
jmchuster wrote: post #99

Earlier quoted context omitted.

Sorry, I think you are a bit mistaken about how payment platforms work. Stripe and PayPal provide an interface to a country's banks. In exchange for abstracting away the underlying bank infrastructure, you pay them a fee for every transaction. Stripe and PayPal support a limited number of countries and a subset of the bank's functionality. So if you want to interact with any new countries or access any non-supported…

Curious; where did you get the 10% number from

Here's an estimate of Stripe's yearly transaction volume at $200 billion https://www.forbes.com/sites/christianowens/2019/09/21/strip...

Here's Uber's announced results of $18 billion in gross bookings https://investor.uber.com/news-events/news/press-release-det...

Round that to significant figures and you get 10%.

Re: Domain-Oriented Microservice Architecture

#106

Post by mytailorisrich »

inopinatus wrote: post #70
mytailorisrich wrote: post #69

Earlier quoted context omitted.

There is no conflicting definition and I'm not quite sure what your reply is about. Quite obviously the point is not whether a microservice-based app can be deployed on a single box. It obviously can. The point is that you split your app in order to deploy different pieces to different boxes then you have a distributed system and no longer a monolith.

My point is that this definition has nothing to do with software, and in fact would mean that the last monolithic system was a Burroughs mainframe ca. 1960. This either invalidates the definition reductio ad absurdum , or confirms it but renders the term basically unusable.

This has everything to do with software and is not about any deployment architecture.

A monolith approach means a single program. This is a software architecture approach and implies by definition that the whole app runs as one in a single box.

I don't understand the point of arguing.

Re: Domain-Oriented Microservice Architecture

#107

Post by [deleted] »

sixdimensional wrote: post #90
staticassertion wrote: post #49

Earlier quoted context omitted.

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.

You're not confused, but there is a nuance. I'm trying to walk a fine line of not criticizing them for discovering this late into their process (maybe they knew all along but were busy inventing), but also questioning why they couldn't see this sooner. Trying to get to the heart of what took this innovation/recognition/learning to happen. I am making an observation - when each new "fad" or "hype cycle" tech starts, i…

[deleted]

Re: Domain-Oriented Microservice Architecture

#108

Post by inopinatus »

mytailorisrich wrote: post #106
inopinatus wrote: post #70

Earlier quoted context omitted.

My point is that this definition has nothing to do with software, and in fact would mean that the last monolithic system was a Burroughs mainframe ca. 1960. This either invalidates the definition reductio ad absurdum , or confirms it but renders the term basically unusable.

This has everything to do with software and is not about any deployment architecture. A monolith approach means a single program. This is a software architecture approach and implies by definition that the whole app runs as one in a single box. I don't understand the point of arguing.

Aside from my desktop calculator there is no computing device or application in operation today that meets the definition of a single program on a single box.

There is indeed no point in arguing about that.

And I’m not even sure about the calculator.

Re: Domain-Oriented Microservice Architecture

#109

Post by mytailorisrich »

inopinatus wrote: post #108
mytailorisrich wrote: post #106

Earlier quoted context omitted.

This has everything to do with software and is not about any deployment architecture. A monolith approach means a single program. This is a software architecture approach and implies by definition that the whole app runs as one in a single box. I don't understand the point of arguing.

Aside from my desktop calculator there is no computing device or application in operation today that meets the definition of a single program on a single box. There is indeed no point in arguing about that. And I’m not even sure about the calculator.

It is quite clear what a monolith approach means. It is well defined. If you build a webapp as, e.g. a Ruby on Rails app you have for practical purposes the whole of your app in a single program. You cannot have a few functions running here and other functions running there. It's all or nothing in the same place. This is not a judgement on the merits of different approach, just a simple statement of fact and I am surprised that this should trigger so much nitpicking and sarcastic put-downs.

Re: Domain-Oriented Microservice Architecture

#110

Post by inopinatus »

mytailorisrich wrote: post #109
inopinatus wrote: post #108

Earlier quoted context omitted.

Aside from my desktop calculator there is no computing device or application in operation today that meets the definition of a single program on a single box. There is indeed no point in arguing about that. And I’m not even sure about the calculator.

It is quite clear what a monolith approach means. It is well defined. If you build a webapp as, e.g. a Ruby on Rails app you have for practical purposes the whole of your app in a single program. You cannot have a few functions running here and other functions running there. It's all or nothing in the same place. This is not a judgement on the merits of different approach, just a simple statement of fact and I am sur…

It is a Ruby on Rails app.
Post reply on HN