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

11–20 of 356 posts

Re: Monolith First (2015)

#11

Post by zimpenfish »

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…

Another issue I've seen is that people push all the problems onto the monolith even if they're external - one place had a Perl monolith (which was bad, sure) but their main issue was an overloaded database which could have been addressed with moving some queries out of the (awful homegrown) ORM and using e.g. signed session cookies instead of every request causing a session table hit.

Re: Monolith First (2015)

#12

Post by wwww4all »

Monoliths are solution in search of problems. Micro services are solution in search of problems.

Generally, focus on solving the problems first.

Can the problem be solved by some static rendering of data? Monolith is better solution.

Does the problem require constant data updates from many sources and dynamic rendering of data changes? Micro services and reactive architecture are better solutions.

There’s no one size fits all solution. The better software engineers recognizes the pros and cons of many architecture patterns and mix match portions that make sense for the solution, given schedule, engineering resources, and budget.

Re: Monolith First (2015)

#13

Post by marcus_holmes »

BillinghamJ wrote: post #2

> I feel that you shouldn't start with microservices unless you have reasonable experience of building a microservices system in the team Well, yeah... obviously. That's not the same thing as it being bad to start with microservices generally. I just don't agree with this at all. The designer of the architecture clearly does need to know how to design service-based architectures and needs to have a very strong unders…

What if those boundaries change because an initial assumption turns out to be wrong?

In a monolith, no biggy. With microservices, huge pain.

Moving to microservices is something you do to optimise scability, but it comes with costs. A major cost is the reduction in flexibility. Starting a new not-very-well-understood thing needs massive flexibility.

Re: Monolith First (2015)

#14

Post by ngngngng »

With this in mind, if I were to start a new project today (using Go, which is all I use anymore). I would segment my code inside of a monolith using interfaces. This would incur a very slight initial cost in the organization of the codebase prior to building. As your usage goes up and the need to scale parts of it increases, you could swap these interfaces out little by little by reimplementing the interface to contact your new external microservice.

I've worked at several companies where microservices were necessary, and I can't believe how clunky they are to work with. I feel like in 2021 I should be able to write a monolith that is capable of horizontally scaling parts of itself.

Re: Monolith First (2015)

#15

Post by pjmlp »

ngngngng wrote: post #14

With this in mind, if I were to start a new project today (using Go, which is all I use anymore). I would segment my code inside of a monolith using interfaces. This would incur a very slight initial cost in the organization of the codebase prior to building. As your usage goes up and the need to scale parts of it increases, you could swap these interfaces out little by little by reimplementing the interface to conta…

Yep, that is the right approach, modular code.

Re: Monolith First (2015)

#16

Post by Chyzwar »

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 implemented in other lang/frameworks as well.

[1] https://elixirschool.com/en/lessons/advanced/umbrella-projec...

Re: Monolith First (2015)

#17

Post by mstipetic »

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 now, it's amazing.

Things can get tricky if you need to spread out to hundreds of machines, but 99%+ of projects wont get to that scale.

[1] https://elixir-lang.org/blog/2016/07/14/announcing-genstage/

Re: Monolith First (2015)

#18

Post by trabant00 »

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. Orchestrating infrastructure, deployments, dependencies, monitoring, logging, etc, goes from "scp .tar.gz" to rocket science fast as the number of services grows to tens and hundreds.

In the end the only way to truly simplify a product's development and maintenance is to reduce its scope. Moving complexity from inside the code to the pipelines solves nothing.

Re: Monolith First (2015)

#19

Post by xxs »

spectramax wrote: post #8
foreigner wrote: post #3

I'm embarrassed to say that I recently built microservices first, and am now kicking myself as I merge them back in to a monolith.

You can still build a "monolith" but in a very modular way. Can't scale independently like microservices, but what if you don't need scale! Compile times are higher but what if you don't need to compile that much code! One error can bring down all "monolith services" but what if your app is not that big! I'd wager, something like 90% of software projects in companies can just get by with monoliths. You know...there a…

>Can't scale independently like microservices, but what if you don't need scale!

What do you mean? Aside from deployed codebase, I don't quite see it - if you need memory, allocate - start small/empty for any datastructure. If managed/gc setup delallocating is inherent, so no special case about freeing memory. Don't create unnecessary threads - but even then dormant threads are very cheap nowadays. There you go - it scales vertically nicely, make sure the application can scale horizontally (say, partitioning by user) and you have all the benefits with close to no drawbacks

Re: Monolith First (2015)

#20

Post by monsieurbanana »

wwww4all wrote: post #12

Monoliths are solution in search of problems. Micro services are solution in search of problems. Generally, focus on solving the problems first. Can the problem be solved by some static rendering of data? Monolith is better solution. Does the problem require constant data updates from many sources and dynamic rendering of data changes? Micro services and reactive architecture are better solutions. There’s no one size…

I don't understand what you mean by "static rendering" vs "dynamic rendering", but I suspect I wouldn't agree on that.

Monolith vs microservice IMO depends more on team size/structure, stage of the project (POC/beta/stable/etc.), how well defined the specs are, … Rather than the nature of the problem itself.

Post reply on HN