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

311–320 of 356 posts

Re: Monolith First (2015)

#311

Post by 1penny42cents »

ex_amazon_sde wrote: post #303
hcarvalhoalves wrote: post #188

IMO this is an unnecessary dichotomy that we're currently forced to deal with, because we don't yet have a good solution for programming the "cloud" the same way you program a for a single computer, and that ends up leaking into all the consequent decisions of modularisation, performance, code management, deployment, team organisation, etc. (My holy grail would be programming for distributed environments as if you ha…

> programming for distributed environments as if you had one giant single-thread computer, and function calls could arbitrarily happen over IO or not Ex-Amazon SDE here. Message-passing libs like 0mq tried to push this idea. They never became very popular internally because passing data between green threads vs OS threads vs processes vs hosts vs datacenters is never the same thing. Latencies, bandwidths and probabil…

This point is what so many miss. The conceptual decomposition seems nice, but the physical implications of that decomposition are horrible. The further you split a function caller from its caller, physically, the more chaos you're asking for. It's quite simple to see from a physical perspective but from an abstract perspective it's all lines and boxes.

Re: Monolith First (2015)

#312

Post by 1penny42cents »

hcarvalhoalves wrote: post #309
ex_amazon_sde wrote: post #303

Earlier quoted context omitted.

> programming for distributed environments as if you had one giant single-thread computer, and function calls could arbitrarily happen over IO or not Ex-Amazon SDE here. Message-passing libs like 0mq tried to push this idea. They never became very popular internally because passing data between green threads vs OS threads vs processes vs hosts vs datacenters is never the same thing. Latencies, bandwidths and probabil…

I don't dispute one might want to have this control. At the same time, I don't see a theoretical reason one can't have the same programming model, and choosing what computation runs local vs. distributed is just a configuration. A function call or a remote call won't change the domain logic, it's an implementation detail - but today, this leaks into all kinds of decisions, starting from microservices and working back…

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 going wrong just goes up.

Re: Monolith First (2015)

#313

Post by staticassertion »

winrid wrote: post #298
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…

Why? Because of the engineering work put into BEAM

I don't think that's the case at all, and I don't think that Armstrong would either.

Re: Monolith First (2015)

#314

Post by 1penny42cents »

Monolith First.

The point of this idea isn't that it says "monolith"; it's that it includes time as a factor. Too much of our discussion focuses on one state or another, and not on the evolution between states.

Re: Monolith First (2015)

#315

Post by hcarvalhoalves »

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

Earlier quoted context omitted.

I don't dispute one might want to have this control. At the same time, I don't see a theoretical reason one can't have the same programming model, and choosing what computation runs local vs. distributed is just a configuration. A function call or a remote call won't change the domain logic, it's an implementation detail - but today, this leaks into all kinds of decisions, starting from microservices and working back…

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 as function calls and handle the fail-ability.

I would bet it's a matter of lacking good accepted patterns instead of a theoretical impossibility.

Re: Monolith First (2015)

#316

Post by crb002 »

Using Haskell style IO types - couldn't we lift and shift anything at build time between a network call and a function call? Monolith that could shard at any function boundary into microservices.

Re: Monolith First (2015)

#317

Post by andrewflnr »

throwaway894345 wrote: post #292
andrewflnr wrote: post #258

Earlier quoted context omitted.

It's still a distributed problem if it's going over a network, even if you don't need consensus specifically. I don't think you would get the same benefits as Erlang unless you either actually write in Erlang or replicate the whole fault tolerant culture and ecosystem that Erlang has created to deal with the fact that it is designed around unreliable networks. And while I haven't worked with multi-node BEAM, I bet si…

> replicate the whole fault tolerant culture and ecosystem I think the idea is to move the general SaaS industry from the local monolith optimum to the better global distributed optimum that Erlang currently inhabits. Or rather, beyond the Erlang optimum insofar as we want the benefits of the Erlang operation model without restricting ourselves to the Erlang developer/package ecosystem. So yeah, the broader "micro se…

At the language level, I think you probably need at least the lightweight, crashable processes. I don't think you can just casually just bring the rest of the industry forward to that standard without changing the language.

Re: Monolith First (2015)

#318

Post by andrewflnr »

staticassertion wrote: post #313
winrid wrote: post #298

Earlier quoted context omitted.

Why? Because of the engineering work put into BEAM

I don't think that's the case at all, and I don't think that Armstrong would either.

You're probably right that Armstrong would be too humble to say it, but increased engineering effort is the only conceivable mechanism for unreliable networks to produce more reliable systems. I can't even tell what you think is going on.

Re: Monolith First (2015)

#319

Post by scavenger5 »

I question the relevance of this with cloud based solutions such as AWS Lambda, where you can spin up a production ready auto-scaled service very quickly; it certainly reduces the cost of ownership and operations. Sure if you are a team of 20 developers working on an app - go monolith.

But if you are a 300 person organization launching something from the ground up, I would choose many serverless solutions over a single monolith.

Re: Monolith First (2015)

#320

Post by majormajor »

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 would propose alternative is to fix your monolith first. If the team can't rewrite their ball of mud as a new monolith, then what are the chances of successfully rewriting and changing architecture?

A million times this. If you can't chart the path to fixing what you have, you don't understand the problem space well enough.

The most common reply I've heard to this is "but the old one was in [OLD FRAMEWORK] and we will rewrite in [NEW FRAMEWORK OR LANGUAGE]," blaming the problem not on unclear concepts/hacks or shortcuts taken to patch over fuzzy requirements but on purely "technical" tech debt. But it usually takes wayyyyy longer than they expect to actually finish the rewrite... because of all the surprises from not fully understanding it in the first place.

So even if you want the new language or framework, your roadmap isn't complete until you understand the old one well enough.

Post reply on HN