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

Monolith First (2015)

martinfowler.com

Post reply on HN
Print view View original

131–140 of 356 posts

Re: Monolith First (2015)

#131

Post by bulleyashah »

5600k wrote: post #100
disgruntledphd2 wrote: post #97

Earlier quoted context omitted.

But the network is so slooooooowwwwwwwww. Don't get me wrong, sometimes it's worth it (I particularly like Spark's facilities for distributed statistical modelling), but I really don't get (and have never gotten) why you would want to inflict that pain upon yourself if you don't have to.

This. One million times this. I’ve been developing for more years than dime if you have lived, and the best thing I’ve heard in years was that Google interviews were requiring developers to understand the overhead of requests. In addition, they should require understanding of design complexity of asynchronous queues, needing and suffering from management overhead of dead letter, scaling by sharding queues if it makes…

I mean, you can always deploy your microsevices on the same host, it would just be a service mesh.

Adding network is not a limitation. And frankly, I don't understand why you say things like understanding network. Like reliability is taken care of, routing is taken care of. The remaining problems of unboundedness and causal ordering are taken care of (by various frameworks and protocols).

For dlq management, you can simply use a persistent dead letter queue. I mean it's a good thing to have dlq because failures will always happen. About which order to procese queue etc. These are trivial questions.

You say things as if you have been doing software development for ages, but you're missing out on some very simple things.

Re: Monolith First (2015)

#132

Post by tibbetts »

tutfbhuf wrote: post #40
pjmlp wrote: post #31

Earlier quoted context omitted.

When the same practices used to sell microservices get applied to modules, packages and libraries, there is no need to put a network in the middle to do the linker's job. But too many are eager to jump into distributed computing without understanding what they are bring into their development workflow and debugging scenarios.

When I started programming, linking was the only way of packaging software in mainstream computing, if it was so superior we wouldn't have moved away from it.

Microservices architectures are like the Navy using nuclear reactors to power aircraft carriers. It’s really compelling in certain circumstances. But it comes with staggering and hard to understand costs that only make sense at certain scales.

Re: Monolith First (2015)

#133

Post by bosswipe »

fvdessen wrote: post #60
pjmlp wrote: post #31

Earlier quoted context omitted.

When the same practices used to sell microservices get applied to modules, packages and libraries, there is no need to put a network in the middle to do the linker's job. But too many are eager to jump into distributed computing without understanding what they are bring into their development workflow and debugging scenarios.

It is much harder to enforce the discipline of those practices across modules boundaries than around network boundaries. So in theory yes you could have a well modularized monolith. In practice it is seldom the case. The other advantage of the network boundary is that you can use different languages / technologies for each of your modules / services.

If you're using microservice to enforce stronger interface boundaries what you're really relying on are separate git repos with separate access control to make it difficult to refactor across codebases. A much simpler way to achieve that same benefit is to create libraries developed in separate repos.

Re: Monolith First (2015)

#134

Post by bulleyashah »

lmilcin wrote: post #93
Mandatum wrote: post #79

Earlier quoted context omitted.

I think my biggest gripe with orgs that adopt microservices is they don't build out any of the testing, CI/CD, monitoring and debugging workflows to support it. It goes from shitty, slow monolithic application that super-pro can debug in a few minutes to.. Slow, shitty disparate services that are managed by different teams who don't share anything, suddenly you've got a Cuckoo's Egg situation where 1 guy needs to get…

That is EXACTLY what I have observed, time and time again. If you have trouble managing ONE application what makes you think you will be better at managing multiple? Also, running distributed system is way more complicated than having all logic in a single application. Ideally you want to delay switching to distributed system until it is inevitable that you are not going to be able to fulfill the demand using monolit…

Monoliths are also distributed systems and will run on multiple hosts, most probably co-ordinating on some sort of state (and that state management will need to take care of concurrency, consistency). Some hosts will go down. Service traffic will increase.

I understand your point. You are using distributed in the sense of "how is one big work distributed", you probably also hate overly "Object Oriented code" for similar reasons.

But distributed systems is a well understood thing in the industry. If I call you and you tell me this, then you're directly responsible for hurting how successful I would be by giving me a misleading sense of what a distributed systems is.

Re: Monolith First (2015)

#135

Post by pc86 »

We are in the middle of the first production-scale deployment of a greenfield microservice-based application now and there are certainly a lot of pain points. On the flip side, I've been a part of about half a dozen extremely successful strangler migrations[0], some of which were downright easy even with a complicated business domain. I often wonder if we would have been better off deploying a monolith in half the time and immediately starting a strangler migration once the rate of business changes slows down. I've become more and more convinced over the past decade that Monolith First + Strangler Migration is most stable, safest way to deliver mid-sized software projects.

[0] https://microservices.io/patterns/refactoring/strangler-appl...

Re: Monolith First (2015)

#136

Post by wg0 »

bosswipe wrote: post #133
fvdessen wrote: post #60

Earlier quoted context omitted.

It is much harder to enforce the discipline of those practices across modules boundaries than around network boundaries. So in theory yes you could have a well modularized monolith. In practice it is seldom the case. The other advantage of the network boundary is that you can use different languages / technologies for each of your modules / services.

If you're using microservice to enforce stronger interface boundaries what you're really relying on are separate git repos with separate access control to make it difficult to refactor across codebases. A much simpler way to achieve that same benefit is to create libraries developed in separate repos.

Wow. That's an interesting take on the problem of scaling a monolith without introducing the network between the system interactions.

Re: Monolith First (2015)

#138

Post by darkstar_16 »

There is no one size fits all solution here. In my experience it is sometimes good to start (conceptually) as a monolith and then divide the service into Microservices, eventually. Also depends on the maturity and experience of the team handling the services because micro services do like a different temperament both to develop and to manage.

I'm not from the camp that believes in creating services for every single thing - It's the same camp that believes in starting with distributed databases and then moving in the same direction. I believe in PostgreSQL everything and then moving to distributed only if the application demands ... Wait did I just start another war in here !

Re: Monolith First (2015)

#139

Post by chriswarbo »

diroussel wrote: post #83
tutfbhuf wrote: post #65

Earlier quoted context omitted.

> But is linking the right way to couple business logic from two different organisational units I think it's not, but I would like to hear other opinions.

I'm not sure why you are being down voted. In context of calling business logic we have moved away from linking. I guess the context is only implelied in your parent post. The rise of the network API in the last 20 years has proven it's own benefits. Whether you are calling a monolith of a microservice, it's easier to upgrade the logic without recompiling and re-linking all dependencies.

I think there's too much being conflated to make such a statement.

For example, microservices tend to communicate via strings of bytes (e.g. containing HTTP requests with JSON payloads, or whatever). We could do a similar thing with `void` in C, or `byte[]` in Java, etc.

Languages which support 'separate compilation' only need to recompile modules which have changed; if all of our modules communicate using `void` then only the module containing our change will be recompiled.

It's also easy to share a `void` between modules written in different languages, e.g. using a memory-mapped file, a foreign function interface, etc.

It's also relatively* easy to hook such systems into a network; it introduces headaches regarding disconnection, packet loss, etc. but those are all standard problems with anything networked. The actual logic would work as-is (since all of the required parsing, validation, serialisation, etc. is already there, for shoehorning our data in and out of `void*`).

If these benefits were so clear, I would expect to see compiled applications moving in this direction. Yet instead I see the opposite: stronger, more elaborate contracts between modules (e.g. generic/parametric types, algebraic data types, recursive types, higher-kinded types, existential types, borrow checkers, linear types, dependent types, etc.)

Post reply on HN