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

351–356 of 356 posts

Re: Monolith First (2015)

#351

Post by 1penny42cents »

hcarvalhoalves wrote: post #315
1penny42cents wrote: post #312

Earlier quoted context omitted.

The programming model is fundamentally different between local vs distributed. Imagine if every local function call in your monolith significantly increased in error rate and latency. Your optimal algorithms would change - you can't just loop over a network call like you can with a local function call. That's what happens when you take a local invocation and put it across a network boundary. The probability of things…

I'm not proposing to code like a monolith - but I don't see a reason there can't be a programming model that unifies that. APIs like Spark, for instance, make it largely transparent - processes are scheduled by the driver in nodes w/ hot data caches, and processes that fail are transparently retried; and yet this doesn't impact how you write your query. Effects systems are another thing can help us reason around i/o…

It's not a theoretical impossibility: you can wrap every function call in a monad today if you want. It's just a practical nightmare.

Re: Monolith First (2015)

#352

Post by mac01021 »

I just wonder what kind of organization or project faces this kind of decision.

I've worked on workflow/crud-type web applications whose computational needs could be met using a single server with a couple of GB of RAM using a single database, indefinitely into the future. I don't see why it would occur to someone to split one of those into multiple services.

I've worked on systems for which many such servers were required in order to provide the expected throughput and, in such a case, writing a monolith is really not an option.

Is there a significant middle ground?

Re: Monolith First (2015)

#353

Post by mbrodersen »

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.

Not at all. That’s what libraries are for. Most applications already use lots of libraries to get anything done. Just use the same idea for your own organisations code.

Re: Monolith First (2015)

#354

Post by xwolfi »

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…

I've noticed after many optimization project in my investment bank that most architectures are fine, and rarely a source of or solution to problems.

The source of most of our problems is always that we started too small to understand the implication of our laziness at the start (I'll loop over this thing - oops it's now a nested loop with 1 million elements because a guy 3 years ago made it nested to fix something and the business grew). Most times, we simply have to profile / fix / profile / fix until we reach the sub millisecond. Then we can discuss strategic architecture.

Interestingly most of the architecture problem we actually had to solve were because someone 20 years ago chose an event-based micro service architecture that could not scale once we reach millions upon millions of event and has no simple stupid way to query state but to replay in every location the entire stream. Every location means also the C# desktop application 1000 users use. In this case yes, we change the architecture to have basic indexed search somehow with a queriable state rather than a reconstructed one client-side.

Re: Monolith First (2015)

#355

Post by OvermindDL1 »

deckard1 wrote: post #263
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…

> putting things behind a network can, counter intuitively, lead to more resilient systems Erlang without a network and distribution is going to be more resilient than Erlang with a network. If you're talking about the challenges of distributed computing impacting the design of Erlang, then I agree. Erlang has a wonderful design for certain use cases. I'm not sure Erlang can replace all uses of microservices, however…

Playing a bit of devil's advocate, erlang is more reliable with more nodes by its design because it is expecting hardware to fail, and when that hardware does fail it migrates the functionality that was running on it to another node. With only a single node then you have a single point of failure, which is the antithesis of erlangs design.

Re: Monolith First (2015)

#356

Post by collyw »

gqewogpdqa wrote: post #264
collyw wrote: post #163

Earlier quoted context omitted.

Yep. I am working on a Mongo system, started right about when Mongo was peak hype. This application should be using a relational database, but no resume padding for the original developer, and a ton of tech debt and a crappy database for me to work with.

What are the characteristics that make it more relational than non-relational?

Well we effectively have foreign keys between tables / collections. Just none of the benefits.
Post reply on HN