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

161–170 of 356 posts

Re: Monolith First (2015)

#161

Post by mstipetic »

runeks wrote: post #121
mstipetic wrote: post #17

I keep saying this every time this topic comes up, have a look at elixir/erlang. The OTP library gives some great reusable patterns (and elixir project is adding new ones[1]) out of the box. You're basically developing a single codebase microservice project which feels like a monolith. You can spread out on multiple machines easily if you need to, the introspection tooling is better than anything you can buy right no…

How does versioning work? Is it required that all VM instances run the same version?

I'm gonna assume you're talking about versions of application code. Obviously it's not a trivial problem and you have to keep it in mind while architecting your application, but Hot Code reloading is a well supported thing [1]

https://blog.appsignal.com/2018/10/16/elixir-alchemy-hot-cod...

Re: Monolith First (2015)

#162

Post by collyw »

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.

I have worked on some horrendously coupled micro-service architectures.

Re: Monolith First (2015)

#163

Post by collyw »

a_imho wrote: post #129
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.

More generous take on the meta: people do understand (some of) the problems involved but are less worried about debugging scenarios than resume padding. The most useful property of microservices is architecturing CVs.

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.

Re: Monolith First (2015)

#164

Post by theshrike79 »

MattyMc wrote: post #150
lmilcin wrote: post #71

Hahaha. I have been saying the same for years but have either been punished by my managers or mercilessly downvoted on HN. Somehow mentioning that microservices might not be perfect solution in every case triggers a lot of people. I have actually helped save at least one project in a huge bank which got rolled from 140 services into one. The team got also scaled down to third of its size but was able to work on this…

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

You need 500 karma for the downvote button to appear: https://jacquesmattheij.com/the-unofficial-hn-faq/#karma

Re: Monolith First (2015)

#165

Post by 100-xyz »

I work for a small company that uses microservices architecture. The product is simple where a user registers, enters preferences, selects from courses and submits a form. A monolith would be doable with 5 good engineers. Instead we have about 50 engineers+QA releasing bug filled code.

The company's design philosophy is based more on what is fashionable that what is suitable.

Re: Monolith First (2015)

#166

Post by lllr_finger »

Chyzwar wrote: post #16
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…

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…

This is what I do in several of my backend Kotlin code bases and it's worked very well. I've also heard it called "distributed monorepo". There are a handful of ways to share code, and the tradeoffs of this approach are very manageable.

The biggest downside I've encountered is that you need to figure out the deployment abstraction and then figure out how that impacts CI/CD. You'll probably do some form of templating YAML, and things like canaries and hotfixes can be a bit trickier than normal.

Re: Monolith First (2015)

#167

Post by pjc50 »

bulleyashah wrote: post #134
lmilcin wrote: post #93

Earlier quoted context omitted.

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 simi…

> Monoliths are also distributed systems and will run on multiple hosts

... not necessarily. Although the big SPOF monolith has gone out of fashion, do not underestimate the throughput possible from one single very fast server.

Re: Monolith First (2015)

#168

Post by pjc50 »

trabant00 wrote: post #18

I see services (not micro) as an organizational solution more than a technical one. Multiple teams working on the same service tend to have coordination problems. From this perspective starting with a monolith as you start with one team seems natural. Now the trend of breaking things up for the sake of it - going micro - seems to benefit the cloud, consultancy and solution providers more than anybody else. Orchestrat…

Yes, that's the "Conway's Law" argument; microservices exist to replicate the team structure in the code, not the other way round.

Re: Monolith First (2015)

#169

Post by pjmlp »

jameshart wrote: post #152
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.

If you think of microservices as a modularization tool - a way to put reusable code in one place and call it from other places - then you are missing the point. Microservices don’t help solve DRY code problems. Monoliths aren’t merely monolithic in terms of having a monolithic set of addressable functionality; they are also monolithic in terms of how they access resources, how they take dependencies, how they are bui…

Monoliths don't have to be deployed as single instance.

In any case, too many rush for micro-services with the intent reason to use the network as a package boundary.

Have you ever tried to debug spaghetti RPC calls across the network?

I sadly have.

Re: Monolith First (2015)

#170

Post by jjjeii3 »

I heard so many horror stories that some company tried to break up a large monolith to microservices and after X years of working on it, they give up. For example, in monolith you can use transactions and change millions of rows. If something goes wrong, the entire transaction will be rolled back. If you use microservices, you can only use transactions within a single service.
Post reply on HN