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

41–50 of 356 posts

Re: Monolith First (2015)

#41

Post by rollulus »

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…

Exactly with this vision I started beginning of 2020 our Go monolithic backend. Currently, one year later with a few people developing it, it's working very well. And thank god I resisted and pushed back against people who were advocating to split off parts into AWS lambdas, misguided by confusing "physical" separation for logic separation.

And regarding the cost you mention, I don't think there is any. Yes, the components only know each other via their interfaces, not their concrete types. Yes, you need to define these interfaces. But that's in essence plain old school dependency injection. You'd do that anyway for testing, right?

Re: Monolith First (2015)

#42

Post by tappio »

ivanb wrote: post #25

There is no replacement for discipline. If you cannot structure your modules well, what makes you think that your microservice spaghetti would look better?

In my opinion it will become unusable and unmaintainable faster with microservice spaghetti. With monolith you can get by with bad design longer. But anyways, everything boils down to good structure as you said.

Re: Monolith First (2015)

#43

Post by harperlee »

In my main side project what I've done is separate different conceptual components in clojure libraries that I then import into my main program (clojure enables you to seamlessly require a private github repo as a library).

This way you get most of the benefits of separating a codebase (such as testing different things, leaving code that barely works in the repo, pointing to older versions of part of the monolith, smaller repos, etc.) whilst integration between modules is a one-liner, so I don´t need microservices, servers, information transformation, etc.

There's even the possibility to dynamically add library requirements with add-lib, an experimental tools.deps functionality.

Re: Monolith First (2015)

#44

Post by ergo14 »

lmm wrote: post #27
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…

> It can be easy implemented in other lang/frameworks as well. No it can't, it relies on the runtime being capable of fairly strong isolation between parts of the same project, something that is a famous strength of Erlang. If you try to do the same thing in a language like Python or Ruby with monkeypatching and surprise globals, you'll get into a lot of trouble.

Weird, we do it with Python all the time. Just don't use globals/threadlocals everywhere and you will be good.

Re: Monolith First (2015)

#45

Post by lmm »

ergo14 wrote: post #44
lmm wrote: post #27

Earlier quoted context omitted.

> It can be easy implemented in other lang/frameworks as well. No it can't, it relies on the runtime being capable of fairly strong isolation between parts of the same project, something that is a famous strength of Erlang. If you try to do the same thing in a language like Python or Ruby with monkeypatching and surprise globals, you'll get into a lot of trouble.

Weird, we do it with Python all the time. Just don't use globals/threadlocals everywhere and you will be good.

As long as you're not using any libraries/frameworks that use them.

Re: Monolith First (2015)

#46

Post by hayst4ck »

tappio wrote: post #37
hayst4ck wrote: post #32

If you imagine a monolith as a service that: takes a request -> deserializes it/unpacks it to a function call -> sets up the context of the function call (is the user logged in etc) -> calls the business logic function with the appropriate context and request parameters -> eventually sends requests to downstream servers/data stores to manipulate state -> handles errors/success -> formats a response and returns it The…

I guess it all boils down to building software with modular structure rather than mixing business logic all around. I personally think that it is easier to isolate business logic with microservice structure, but you can also make a huge mess. You can also make really good modular monolith, where business logic and state is where it belongs and not spread everywhere.

It is easier to isolate business logic with a microservice architecture, but as the microservice graph gets more complicated so too does administering it.

How do you make graphs that make sense of your various microservices? How do you make sure code doesn't get stale/all versions are compatible/rolling back code doesn't take out your website? How do you do capacity planning? How are service specific configurations done? How does service discovery work? How do you troubleshoot these systems? How do you document these systems? How do you onboard new people to these systems? What about setting up integration testing? Build systems? Repositories? Oncall? What happens when a single dev spins up a microservice and they quit? What happens when a new dev wants to create a new service in the latest greatest language? What happens when you want to share a piece of business logic of some sort? What about creating canaries for all these services? What about artifact management/versioning?

What about when your microservice becomes monolithic?

Complexity is complexity no matter where it exists. Microservices are an exchange of one complexity for another. Building modular software is a reduction of complexity. A microservice that has business logic mixed with server logic is still going to suffer from being brittle.

Re: Monolith First (2015)

#47

Post by ThouYS »

This is the never ending cycle of "too much order" - "too much chaos". It takes a lot of experience to be able to judge how much chaos you want. That is all.. experience. I don't think any theoretical theory can tell you how much or how little is right

Re: Monolith First (2015)

#48

Post by Cthulhu_ »

ivanb wrote: post #25

There is no replacement for discipline. If you cannot structure your modules well, what makes you think that your microservice spaghetti would look better?

It's a means to shift the problem to Someone Else; I've got my codebase, it is mine and it is perfect. Integrating with it is someone else's problem.

Re: Monolith First (2015)

#49

Post by im3w1l »

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.

If you don't mind telling this story, why did you end up merging them back in? I would have thought that needlessly making microservices is bad but not bad enough to justify merging back.

Re: Monolith First (2015)

#50

Post by ecmascript »

I worked on a project that was a monolith. A team was placed to rewrite it to microservices and shortly after I quit that job. About a year after that I ate lunch with a ex-colleague that told me they were still working on that rewrite.

Looking at the page now it looks like the monolith is still running as far as I can see, about 5 years later. I guess they gave up. :)

Post reply on HN