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

321–330 of 356 posts

Re: Monolith First (2015)

#321

Post by Kinrany »

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…

The difference between separate threads and separate machines should not be abstracted away, but managing them as part of the application through compile-time magic would be cool.

Re: Monolith First (2015)

#322

Post by playing_colours »

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…

Can you please elaborate on specific principles behind Erlang operation model that other platforms can embrace?

Re: Monolith First (2015)

#323

Post by Kinrany »

Kinrany wrote: post #321
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…

The difference between separate threads and separate machines should not be abstracted away, but managing them as part of the application through compile-time magic would be cool.

One could use something like Rust feature macros, plus a tool on top of Cargo that automatically picks the set of features required by each deployment.

Re: Monolith First (2015)

#324

Post by ex_amazon_sde »

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…

It's way more than "just a configuration".

> A function call or a remote call won't change the domain logic

Understanding performance and minimizing failure modes and their impact on larger systems makes for a whole career as "SRE". Making remote calls all over a codebase creates behaviors that are practically impossible to debug or optimize. But the blocker is the network impact of large applications and the emergence of cascading failures.

Re: Monolith First (2015)

#325

Post by staticassertion »

andrewflnr wrote: post #318
staticassertion wrote: post #313

Earlier quoted context omitted.

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.

In his initial thesis on Erlang, and in any talk I've seen him give, or anything I've seen him write, he attributes reliability to the model, not to BEAM.

Re: Monolith First (2015)

#326

Post by rudnevr »

it's surprising to be _so_ disagree.

The value of microservices is to isolate risks and have some manageable entity to reason about, to have an understandable scope of lifecycle, test coverage and relations with other services. The larger the piece, the harder it is to do.

Splitting up is normally harder than building up, and often impossible to agree on. Any monolyth I worked on was coupled more than necessary because of regular developer dynamics to use all code available in classpath. I've never even saw a successful monolyth split - you just usually rewrite from scratch, lift-n-shifting pieces here and there.

Re: Monolith First (2015)

#327

Post by [deleted] »

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.

[deleted]

Re: Monolith First (2015)

#328

Post by fendy3002 »

spion wrote: post #284
LargeWu wrote: post #228

Earlier quoted context omitted.

I'm not reading this as "Don't do distributed work". It's "distributed systems have nontrivial hidden costs". Sure, monoliths are often synonymous with single points of failure. In theory, distributed systems are built to mitigate this. But unfortunately, in reality, distributed systems often introduce many additional single points of failure, because building resilient systems takes extra effort, effort that oftenti…

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.

Re: Monolith First (2015)

#329

Post by fendy3002 »

haakonhr wrote: post #77
Chyzwar wrote: post #16

Earlier quoted context omitted.

There is one approach Fowler suggested is SacrificialArchitecture. You build your monolith quickly, get to market fit and once you understand service boundaries you move to microservices. Personally I would like to try Umbrella Projects[1]. You can design it as microservices but deploy and build as monolith. Overhead is lower, and it is easier to figure out right services when in one codebase. It can be easy implemen…

I like the idea of SacrificialArchitecture. The big downside is to really communicate to management/other departments that it is meant to be a kind of prototype. If it looks good enough and gets paying customers it is hard to find the time to stop, take a step back and re-write

"Nothing is more permanent than a temporary solution"

Re: Monolith First (2015)

#330

Post by fendy3002 »

spaetzleesser wrote: post #251
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…

That’s what I am always saying. If you can’t manage libraries you will fail at microservices too, just harder. I am working on a project right now that was designed as microservices from the start. It’s really hard to change design when every change impacts several independent components. It seems to me that microservices are good for very stable and well understood use cases but evolving a design with microservices…

Especially if in new requirement, microservice A need to interact with service C which originally accessed via B. You can either:

* Make additional changes in B which also takes resources, times and introducing overhead + point of failure, or

* Make A interact directly with C which breaks the boundary

Post reply on HN