Monolith First (2015) • Hacker News Board

Re: Monolith First (2015)

#341

Post by marcosdumay » Sat, Feb 20, 2021, 1:43 PM UTC

bulleyashah wrote: post #191

marcosdumay wrote: post #185

Earlier quoted context omitted.

> But distributed systems is a well understood thing in the industry. Wait, what? Distributed systems are one of the most active areas on CS currently. That's the opposite of "well understood". It's true that most systems people create are required to be distributed. But they are coordinated by a single database layer that satisfies approximately all the requirements. What remains is an atomic facade that developers…

Correct. That doesn't make monolithic systems "not distributed". Secondly, I don't know why you say "distributed systems are an active area of research" and use this as some sort of retort. If I say "Is a monolithic app running on two separate hosts a distributed system or not", if your answer is "We don't know, it's an active area of research" or "It's not. Only microservices are distributed"

Hum... I don't think you understood what I said.

Most of what people call monolithic systems are indeed distributed. There are usually explicit requirements for them to be distributed, so it's not up to the developer.

But ACID databases provide an island of well understood behavior on the hostile area of distributed systems, and most of those programs can do with just an ACID database and no further communication. (Now, whether your database is really ACID is another can of worms.)

Re: Monolith First (2015)

#342

Post by bennysonething » Sat, Feb 20, 2021, 2:11 PM UTC

pjmlp wrote: post #31

ser0 wrote: post #4

A more common scenario I see is that people start with a monolith that ends up inheriting all the conceptual debt that accumulates as a project evolves. All this debt builds up a great desire for change in the maintaining team. A champion will rise with a clean architecture and design in microservice form that addresses all high visibility pain points, attributing forecasted benefits to the perceived strengths of mic…

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.

I'm really thinking this now, I'm responsible for design a reimplantation of a system and for some reason it's taken as a given it will be broken up into services on separate containers, which means network calls which aren't reliable. Which then brings a host of other problems to solve and a load of admin tasks. I'm really thinking I should re design as s monolith. It's a small system anyway.

Re: Monolith First (2015)

#343

Post by lmm » Sat, Feb 20, 2021, 2:36 PM UTC

ergo14 wrote: post #89

lmm wrote: post #45

Earlier quoted context omitted.

As long as you're not using any libraries/frameworks that use them.

I don't think we've ended up with libs that share state in a dangerous way, maybe we got lucky.

Modules are global singletons, class definitions are global singletons. Monkeypatching is less common in Python than Ruby but I'd still consider it a significant risk.

Re: Monolith First (2015)

#344

Post by valand » Sat, Feb 20, 2021, 7:17 PM UTC

staticassertion wrote: post #252

dimitrios1 wrote: post #198

Earlier quoted context omitted.

"microservices turn function calls into distributed computing problems" -- tenderlove

This isn't really true though. It's not like you're suddenly adding consensus problems or something, you don't need to reinvent RAFT every time you add a new service. Microservices put function calls behind a network call. This adds uncertainty to the call - but you could argue this is a good thing. In the actor model, as implemented in Erlang, actors are implemented almost as isolated processes over a network. You c…

> You can't accidentally share memory, you can't bind state through a function call - you have to send a message, and await a response.

These are not strictly a "program on network vs program not on network" issue. "Accidentally sharing memory" can be solved by language design. It is correct that a system that is supposedly designed as inter-actor communication is not ideal when designed and written in a "function call-like" manner, but erlang only partially solves this phenomena by enforcing a type of architecture, which locks away the mentioned bad practice.

> ...despite being extremely similar to service oriented architecture in many ways. Why? Because putting things behind a network can, counter intuitively, lead to more resilient systems.

This is a strange logic. Resilient system is usually achieved by putting a service/module/functionality/whatever in a network of replications, meanwhile service oriented architecture talks about loosening the coupling between different computers that acts differently.

I do agree on microservice != turn function calls into distributed computing problems.

It MAY happen to systems eagerly designed with microservice architecture without a proper prior architectural validations, but it is not always the case.

Re: Monolith First (2015)

#345

Post by MattyMc » Sat, Feb 20, 2021, 9:29 PM UTC

kevsim wrote: post #159

MattyMc wrote: post #150

Earlier quoted context omitted.

I don't think you can downvote on HackerNews. That's reddit.

You can, you just need 501 karma first. Seems like someone wanted to prove you wrong since you've been downvoted.

Haha seems a few people wanted to prove me wrong :) Didn't know that!

Re: Monolith First (2015)

#346

Post by radicalbyte » Sat, Feb 20, 2021, 9:43 PM UTC

hackerfromthefu wrote: post #332

radicalbyte wrote: post #53

Earlier quoted context omitted.

This is why Domain Driven Design should be mandatory reading for all anyone making decisions on Software Architecture.

Unfortunately in actual practise I've encountered significant cargo culting about DDD. Attracts a lot of people with mid level experience who suddenly want to dictate architecture based on theoretical ideals rather than practicalities. There's no substitute for experience, and specifics of adapting architecture to the context of the problem you're trying to solve. In one case I wanted to use a technology that actuall…

That's very true, and a problem I've also seen. There are an army of mediocre people who've gone full Cargo Cult with it. Usually comes with a big dose of Uncle Bob: The Bad Parts.

Re: Monolith First (2015)

#347

Post by rualca » Sat, Feb 20, 2021, 10:44 PM UTC

pjmlp wrote: post #31

ser0 wrote: post #4

A more common scenario I see is that people start with a monolith that ends up inheriting all the conceptual debt that accumulates as a project evolves. All this debt builds up a great desire for change in the maintaining team. A champion will rise with a clean architecture and design in microservice form that addresses all high visibility pain points, attributing forecasted benefits to the perceived strengths of mic…

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.

> But too many are eager to jump into distributed computing without understanding what they are bring into their development workflow and debugging scenarios.

This fallacy is the distributed computing bogeyman.

Just because you peel off a responsibility out of a monolith that does not mean you suddenly have a complex mess. This is a false premise. Think about it: one of the first things to be peeled off a monolith are expensive fire-and-forget background tasks, which more often than not are already idempotent.

Once these expensive background tasks are peeled off, you gets far more manageable and sane system which is far easier to reason about and develop and maintain and run.

Hell, one of the basic principles of microservices is that you should peel off responsibilities that are totally isolated and independent. Why should you be more concerned about the possibility of 10% of your system being down if the alternative is having 100% of your system down? More often than not you don't even bat an eye if you get your frontend calling your backend and half a dozen third-party services. Why should it bother you if your front-end calls two of your own services instead of just one?

I get the concerns about microservicea, but this irrational monolith-mania has no rational basis either.

Re: Monolith First (2015)

#348

Post by rualca » Sat, Feb 20, 2021, 10:51 PM UTC

PragmaticPulp wrote: post #276

staticassertion wrote: post #252

Earlier quoted context omitted.

This isn't really true though. It's not like you're suddenly adding consensus problems or something, you don't need to reinvent RAFT every time you add a new service. Microservices put function calls behind a network call. This adds uncertainty to the call - but you could argue this is a good thing. In the actor model, as implemented in Erlang, actors are implemented almost as isolated processes over a network. You c…

Distributed systems is more than just consensus protocols. At minimum, you need to start dealing with things like service discovery and accounting for all of the edge cases where one part of your system is up while another part is down, or how to deal with all of the transitional states without losing work. > Why? Because putting things behind a network can, counter intuitively, lead to more resilient systems If you'…

> At minimum, you need to start dealing with things like service discovery and accounting for all of the edge cases where one part of your system is up while another part is down, or how to deal with all of the transitional states without losing work.

I really don't get this phobia. You already have to deal with that everywhere, don't you? I mean, you run a database. You run a web app calling your backend. You run mobile clients calling your backend. You call with services. The distributed system is more often than not already there. Why are we fooling ourselves into believing that just because you choose to bundle everything in a mega-executable that you're not running a distributed system?

If anything,explicitly acknowledging that you already run a distributed system frames the problem ina way that you are forced to face failure modes you opt to ignore.

Re: Monolith First (2015)

#349

Post by staticassertion » Sat, Feb 20, 2021, 11:32 PM UTC

valand wrote: post #344

staticassertion wrote: post #252

Earlier quoted context omitted.

This isn't really true though. It's not like you're suddenly adding consensus problems or something, you don't need to reinvent RAFT every time you add a new service. Microservices put function calls behind a network call. This adds uncertainty to the call - but you could argue this is a good thing. In the actor model, as implemented in Erlang, actors are implemented almost as isolated processes over a network. You c…

> You can't accidentally share memory, you can't bind state through a function call - you have to send a message, and await a response. These are not strictly a "program on network vs program not on network" issue. "Accidentally sharing memory" can be solved by language design. It is correct that a system that is supposedly designed as inter-actor communication is not ideal when designed and written in a "function ca…

> "Accidentally sharing memory" can be solved by language design.

For sure - I am definitely not trying to say that there is "one true approach".

Re: Monolith First (2015)

#350

Post by spion » Sat, Feb 20, 2021, 11:51 PM UTC

fendy3002 wrote: post #328

spion wrote: post #284

Earlier quoted context omitted.

If you are using a database, a server and clients, you already have a distributed system. You'll also likely use multiple databases (caching in e. g. Redis) and a job queue for longer tasks. You'll also probably already have multiple instances talking to the databases, as well as multiple workers processing jobs. Pretending that the monolith is a single thing is sneakily misleading. It's already a distributed system

Indeed. So with monolith usually we already have 3-4 (or more) somewhat reliable systems, and one non-reliable system which is your monolithic app. Why add other non reliable systems if you don't really need it? Making a system to be reliable is really really hard and take many resources, which seldom companies pursuit.

just because all the code is in one place doesn't mean its one system.