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

21–30 of 356 posts

Re: Monolith First (2015)

#21

Post by jtcto »

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 really like how you've worded this and agree.

Some of this is driven by well documented cognitive biases, such as the availabily heuristic which you've identified, but there are so many.

This is a good video on it https://birgitta.info/redefining-confidence/

Re: Monolith First (2015)

#23

Post by domano »

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…

I don't see a lot of cost associated with the duck typing-ish approach go takes with interfaces. Instead of passing an implementation directly (or even having it in the first place) you can develop with an interface from the get go. Makes for easier tests too.

In my experience the cost is lower if you write code the way you described (and you don't need to plan ahead as much)

Re: Monolith First (2015)

#24

Post by spectramax »

xxs wrote: post #19
spectramax wrote: post #8

Earlier quoted context omitted.

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…

You're actually right. Just don't call the portions of the app and you can horizontally scale too.

Re: Monolith First (2015)

#25

Post by ivanb »

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

Re: Monolith First (2015)

#26

Post by andy_ppp »

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! Service boundaries are vital and almost intractable to design up front as you won’t be sure of your systems’ use cases. I’ve worked on numerous micro services systems and all of them were designed in such a way that data loss and unknown error states were mandatory. Micro services seem simpler, but are actually harder than my methodology “as few services as necessary” + bounded contexts within them. Using network partitions to stop spaghetti code just leads to spaghetti network partitions. The discipline to keep this simple and self contained is the important part.

Re: Monolith First (2015)

#27

Post by lmm »

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…

> 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.

Re: Monolith First (2015)

#29

Post by tutfbhuf »

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…

> 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?

Well sometimes there are very complex subsystems in the monolith and it's easier to create a completely new microservices out of that instead of trying to rewrite the existing code in the monolith.

We had done so successfully by creating a new payment microservices with stripe integration and then just route every payment that way. Doing the same in a huge pile of perl mess has been assessed as (nearly) impossible by the core developer team without any doubts.

But I have to admit that the full monolith code base is in a maintenance mode beyond repair, only bug & security fixes are accepted at this point in time. Feature development is not longer a viable option for this codebase.

Re: Monolith First (2015)

#30

Post by forgingahead »

Your first and biggest problem when you start a technology startup is lack of customers and revenue. Do everything that gets you to the first customers and first revenue, and do everything that helps you find a repeatable & mechanical distribution strategy to reach more customers and more revenue.

Then and only then should you even consider paying back your technical debt. Monolith first always until you have the cash to do otherwise, and even then only if your app desperately needs it.

Post reply on HN