Domain-Oriented Microservice Architecture • Hacker News Board

Re: Domain-Oriented Microservice Architecture

#61

Post by yjftsjthsd-h » Sat, Jul 25, 2020, 8:15 AM UTC

pjmlp wrote: post #54

systematical wrote: post #39

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…

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

Re: Domain-Oriented Microservice Architecture

#62

Post by inopinatus » Sat, Jul 25, 2020, 8:22 AM UTC

rumanator wrote: post #60

inopinatus wrote: post #53

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…

> you should

> you yourself

> You should pay attention

> you decided

> you yourself state

> even if you somehow believed it was a good idea

This isn't language anyone should respond to, and not merely because it's staking out a fine example of the No True Scotsman fallacy.

> you yourself state that are ran to handle limited and very specific responsibilities

I didn't.

> Just to be absolutely clear, "monolith" is not a reference to how you chose to organize your source tree

Again, that's a straw man - I never said it was. Although I can certainly see how someone who was absolutely determined to make an unnecessarily bitter remonstration as personal as possible might - through either branch of Hanlon's razor - misconstrue the words "the same repository" adversarially for the purposes of their ego trip.

It's a monolithic application because any of the instances could perform any of the roles, and they're all running exactly the same code. They're distinguished in production for the purposes of operational sanity, because only a flaming idiot would, say, run reporting workloads on the API host.

But when I stand up a demo / showcase environment, for example, it has exactly one instance that does everything, and we can (and do) develop with the whole thing running single process on our laptops.

I shouldn't need to clarify any of this, because the point being made was a rebuttal to the "single box" thesis, not whether I met some gatekeeper's opinion about my standing to discuss the topic.

Re: Domain-Oriented Microservice Architecture

#63

Post by ianamartin » Sat, Jul 25, 2020, 8:27 AM UTC

I despise Uber as a company, but I've always loved them as a technology group ever since I used to go to their meetups in NYC. You can always count on Uber to throw a great party and also come up with the worst possible technology.

If you want to know how not to do things, Uber is a very good place to look.

Re: Domain-Oriented Microservice Architecture

#64

Post by exnuber » Sat, Jul 25, 2020, 8:32 AM UTC

They say they draw inspiration from DDD and CQRS, yet seem to miss one crucial factor. And no, I'm not talking about bounded contexts. They still focus in re-use of commodity rather than addressing why their microservice approach didn't work. Their strategy for defining how functionality moves down the stack is not bad, but it's not anchored towards the right thing. It's the consistency boundary (or aggregate root if you will). It's the circle you draw around your business rules and say "this group needs to remain consistently enforced". This defines your unit of scale, not re-use. So while they are headed in the right direction, I fear that they are still missing a fundamental piece of information to steer on.

I was employed by Uber (I quit after a couple months), and the idea's that they now hint towards were largely rejected by the engineers, and that was less than a year ago. Uber is just in the position to throw a large sum of money at making wrong decisions and getting away with it, because it's not their money. It's VC funny money.

DISCLAIMER: Yes, I did indeed create this account to be able to reply anonymously.

Re: Domain-Oriented Microservice Architecture

#65

Post by mytailorisrich » Sat, Jul 25, 2020, 8:44 AM UTC

inopinatus wrote: post #53

rumanator wrote: post #50

Earlier quoted context omitted.

> Wonder if we will see a full circle back to monoliths. For global-scale web applications? Obviously you won't. High-availability, low latency, resilience, scalability, performance. You don't get any of that by running your app on a single box. That ship has sailed two or three decades ago. Physics establishes all the limits, not software architects. Distributed system critics, where they fixate on trendy microservi…

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…

A monolith does run on a single box. If you split it in order to run on several boxes you have by definition turned your monolith into a distributed system.

Re: Domain-Oriented Microservice Architecture

#66

Post by serhatozgel » Sat, Jul 25, 2020, 9:07 AM UTC

random_kris wrote: post #57

staticassertion wrote: post #48

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.

We broke a monolith to mini-services 3 years ago. We went from 3 deployments (dev, stg, prod) to over 200. I think we've gone a bit too far and will cut down a bit but could not be happier overall. The move allowed the business to massively scale.

Re: Domain-Oriented Microservice Architecture

#67

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

mytailorisrich wrote: post #65

inopinatus wrote: post #53

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…

A monolith does run on a single box. If you split it in order to run on several boxes you have by definition turned your monolith into a distributed system.

Deployment architecture does not define monolithic.

The empirical example is that, say, Shopify and Basecamp both described their applications as monolithic.

However, there's a more comprehensive demonstration, in that we can't define "box" without contradiction. When you consider the many shells of virtualisation we use, the fact that any web application is by definition accessed over a network (and therefore distributed), and the internal architecture of a modern server, which is practically a distributed federation, or even the coordination between threads in a single process, it leads inevitably to contradiction (if you're careful) or just a messy quagmire of conflicting definitions.

The final nail in this dichotomous coffin is that the converse is also untrue, since any microservice-based application can be deployed on one box. Whichever way you look through the scope, deployment model turns out orthogonal to the taxonomy of software architecture.

Re: Domain-Oriented Microservice Architecture

#68

Post by playing_colours » Sat, Jul 25, 2020, 9:22 AM UTC

pjmlp wrote: post #54

systematical wrote: post #39

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…

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

Re: Domain-Oriented Microservice Architecture

#69

Post by mytailorisrich » Sat, Jul 25, 2020, 9:31 AM UTC

inopinatus wrote: post #67

mytailorisrich wrote: post #65

Earlier quoted context omitted.

A monolith does run on a single box. If you split it in order to run on several boxes you have by definition turned your monolith into a distributed system.

Deployment architecture does not define monolithic. The empirical example is that, say, Shopify and Basecamp both described their applications as monolithic. However, there's a more comprehensive demonstration, in that we can't define "box" without contradiction. When you consider the many shells of virtualisation we use, the fact that any web application is by definition accessed over a network (and therefore distri…

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.

Re: Domain-Oriented Microservice Architecture

#70

Post by inopinatus » Sat, Jul 25, 2020, 9:53 AM UTC

mytailorisrich wrote: post #69

inopinatus wrote: post #67

Earlier quoted context omitted.

Deployment architecture does not define monolithic. The empirical example is that, say, Shopify and Basecamp both described their applications as monolithic. However, there's a more comprehensive demonstration, in that we can't define "box" without contradiction. When you consider the many shells of virtualisation we use, the fact that any web application is by definition accessed over a network (and therefore distri…

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.