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 176 posts

Re: Monolith First (2015)

#161

Post by upbeta »

srtjstjsj wrote: post #65
morphemass wrote: post #52

Just about every one I've interviewed with recently has been breaking their monolith up into micro-services for some reason. When I've done this in the past I had a key goal: reliability. The cost was about 10x the development effort of the monolith in order to add an extra 9 to the reliability. The monolith was wonderful for getting up and running quickly as a business solution but it actually crippled the business…

Reliability is not important to a startup. http://www.whatisfailwhale.info/

not until one realize it is..

Re: Monolith First (2015)

#162

Post by khana »

srtjstjsj wrote: post #65
morphemass wrote: post #52

Just about every one I've interviewed with recently has been breaking their monolith up into micro-services for some reason. When I've done this in the past I had a key goal: reliability. The cost was about 10x the development effort of the monolith in order to add an extra 9 to the reliability. The monolith was wonderful for getting up and running quickly as a business solution but it actually crippled the business…

Reliability is not important to a startup. http://www.whatisfailwhale.info/

Don't agree. Get it right the first time.

Re: Monolith First (2015)

#163

Post by jakozaur »

Rule of thumb: Number of full-time backend engineers divideed by 5 and rounded up is number of microservices you can afford.

E.g. if you have 500 employees having 100 microservices is fine. If you have 3 engineers and try to have 20 microservices you are wasting tons of time, you should do monolith.

Re: Monolith First (2015)

#164

Post by Daishiman »

sanderjd wrote: post #76
taurath wrote: post #3

If you don't have a product yet or the parameters could change quickly with new business insight, you need to be able to change it fast. With microservices you will be spending half your time figuring out orchestration, building data flows that people can understand, and doing ops. Last startup I was in delayed their launch date for >6 months because of their architecture. Way too many people think they need it, but…

I've experienced the opposite: you get traction with a monolith, and when its time to expand and scale, you find yourself with a massive kludge that makes it hard and slow to make progress. Which is not at all to say that you're wrong - a long delay in the capability to release something can definitely be an earlier and more severe death knell than friction when trying to grow. For me personally, I like to see all of…

> I've experienced the opposite: you get traction with a monolith, and when its time to expand and scale, you find yourself with a massive kludge that makes it hard and slow to make progress.

If you have a team that can't make a monolith scale because of kludges, that says more about the team than the monoliths.

Re: Monolith First (2015)

#165

Post by erikpukinskis »

Animats wrote: post #36
eropple wrote: post #10

Earlier quoted context omitted.

I do devops. I consult for startups. And while it would make me a lot more money in the short term to fuel their microservice-first, sparkly-architecture aspirations, this is exactly the approach I take when I pour some water on that. Your Big Ugly Monolith will get you where you're trying to go if anything will. You don't need services, you don't need microservices, you don't need some bloggable-as-heck Kubernetes s…

Rule of thumb: if you have two "service" talking to the same set of data in the same general-purpose datastore (i.e., not pub-sub, not opposite ends of a job queue), they're the same service. Why? The whole point of a general-purpose database is to allow multiple applications to use the same data. Consider an online ordering system for merchandise. There's an service for checking product availability. There's a servi…

You presumed before you even started design that there would be such a thing as an order, which would be implicated in shopping, payment, and tracking.

There could also be separate order, invoice, and delivery.

Essentially your question is: what if my models are highly overloaded? Won't they need to be used in multiple places?

And of course the answer is yes. But if you are using the same model in dramatically different contexts you probably have a problem of another sort. This is the dreaded "One Object To Rule Them All" OO anti-pattern.

Re: Monolith First (2015)

#166

Post by tomerbd »

eternalban wrote: post #90
sbov wrote: post #42

Earlier quoted context omitted.

A huge point of microservices is to create code that is independent of eachother. Your database backend is tightly coupling what should be completely independent services. Microservices were designed to scale your engineering departments just as much (if not more than) your performance. You are throwing away the major point of why microservices were created in the first place when you do what you're doing: so teams i…

> You are throwing away the major point of why microservices were created in the first place when you do what you're doing: so teams in large organizations can do independent releases. Let's ammend this: so teams in large organizations +{that lack both a coherent architecture and the ability to devise one} can do independent releases +{by adoptiong the no-architecture architecture}.

can you describe a coherent architecture that will turn microservices uneeded?

Re: Monolith First (2015)

#168

Post by sanderjd »

Daishiman wrote: post #164
sanderjd wrote: post #76

Earlier quoted context omitted.

I've experienced the opposite: you get traction with a monolith, and when its time to expand and scale, you find yourself with a massive kludge that makes it hard and slow to make progress. Which is not at all to say that you're wrong - a long delay in the capability to release something can definitely be an earlier and more severe death knell than friction when trying to grow. For me personally, I like to see all of…

> I've experienced the opposite: you get traction with a monolith, and when its time to expand and scale, you find yourself with a massive kludge that makes it hard and slow to make progress. If you have a team that can't make a monolith scale because of kludges, that says more about the team than the monoliths.

sigh this cliche adds little to the discussion. You could say the same from the other side: "if you have a team that can't make microservices work because of tangled service dependencies, that says more about the team than the microservices". That also adds little to the discussion.

Different architectural choices lead to different challenges. Different teams in different organizations will rise to those challenges with different degrees of success. But it's still worth thinking about the trade offs of the different architectures from the perspective of what they make easier and harder.

Re: Monolith First (2015)

#169

Post by quickben »

beat wrote: post #98
quickben wrote: post #87

Earlier quoted context omitted.

If you avoid what you listed in actual software, you'll be left with a mess they will take years and tons of money to fix.

Yes, but if you don't avoid it, you might never get off the ground to the point where you have years of time and tons of money in the first place.

I guess it depends on the viewpoint. Yours sounds valid. Mine comes from the occasional fixing people's messes. But I agree with you, some product is better than no product in most cases.

Re: Monolith First (2015)

#170

Post by navalsaini »

ChristianGeek wrote: post #147
navalsaini wrote: post #96

I agree, monolith first and have proposed a talks to few JS conferences on this topic. I however have not worked in a company that uses microservices architecture at a big scale (like uber, instagram, etc). I am keen to understand - (1) what does it mean to run a microservices architecture from an org. point of view? (2) How are principles like 3 depths deep enforced? (3) How does a developer decide to create a new m…

What is "3 depths deep?" Google doesn't turn up anything.

Services call other services in a microservice architecture. Three depths deep would mean that, there are only three network hops and no more (its strangely similar to inceptions 3 dreams deep adventure). Each network hop adds latency and a threat of failure from network layers. So usually a 3 levels deep rule is followed to keep the failure levels low, making debugging easier, time to find the culprit low, etc in a microservices architecture.
Post reply on HN