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

61–70 of 176 posts

Re: Monolith First (2015)

#61

Post by acdha »

tunesmith wrote: post #48
sbov wrote: post #17

Earlier quoted context omitted.

> significant load Please define significant load.

Sometimes it's not about load, but speed of innovation. A huge complex monolithic codebase might not have a lot of load, but it can still limit a team's ability to experiment with new features due to big ball of mud. Decomposing areas into service might enable faster innovation better than refactoring the whole monolith.

That seems orthogonal to me: is adding a network boundary really the only way to enforce basic software engineering practices? It seems just as likely that the same organizational issues would lead to e.g. learning that your data model is wrong and part of the app now needs to dispatch thousands of queries, and fixing this is harder than refactoring a couple parts of the same codebase.

(Note: I'm not saying microservices are bad – I just think that the process which lead to that ball of mud will unfold similarly with a different methodology)

Re: Monolith First (2015)

#62

Post by srtjstjsj »

karmajunkie wrote: post #49
Animats wrote: post #36

Earlier quoted context omitted.

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…

Whether they can be worked on independently is not the criteria that matters (and in point of fact, its a false assertion in this case if they're using the same database, as neither can iterate on the schema of the data completely independently of the other). What matters is, can I take this service completely offline and have the other still function? If the share a datastore, then the answer is no.

All services depend on a router, so you can't take any one service _completely_ offline, so they are all part of one service.

Re: Monolith First (2015)

#63

Post by srtjstjsj »

taurath wrote: post #13
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…

Couldn't agree more - inheritance chains and heavily stateful instruction environments are the number one blocker to eventually decoupling a monolith. The "enterprise" code style is absolutely what you need to avoid in a startup.

what is "enterprise" code style?

Re: Monolith First (2015)

#64

Post by srtjstjsj »

to3m wrote: post #57
eropple wrote: post #29

Earlier quoted context omitted.

> Also you certainly can't port a complex monolith to microservices Upvoted you, but I disagree with a little. "Microservices" tend to pathological cases, but you 100% can segment a monolithic apps into services . Each module in your application has an interface. Behind that interface, replace it with network calls that fulfill the interface's contracts. (If your monolith doesn't have sections that encapsulate work--…

> Behind that interface, replace it with network calls that fulfill the interface's contracts Just like that?! You can encapsulate work fine, without making microservices at all easy to retrofit. There's a big difference between calling a function that does something and returns a result, and calling a function that does nothing until you've gone back to the main loop to handle network input. (You can confront many o…

> There's a big difference between calling a function that does something and returns a result, and calling a function that does nothing until you've gone back to the main loop to handle network input.

the difference is latency, so of course you put extreme low-latency operations inside the same service.

Re: Monolith First (2015)

#65

Post by srtjstjsj »

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/

Re: Monolith First (2015)

#66

Post by srtjstjsj »

maxxxxx wrote: post #20
gluczywo wrote: post #4

even experienced architects working in familiar domains have great difficulty getting boundaries right at the beginning. By building a monolith first, you can figure out what the right boundaries are This line of thought reaches two decades ago and was expressed in a wonderful essay "Big Ball of Mud" http://www.laputan.org/mud/ EDIT: updated with the quote

A lot of people don't have the discipline to write decent libraries so they need the overhead of microservices to force them to structure their code reasonably. It seems to me you can have exactly the same boundaries between components that you get through microservices by just having a good compenent separation.

if you have component separation, you have microservices

Re: Monolith First (2015)

#67

Post by lucisferre »

phamilton wrote: post #60

I all comes back to Conway's Law (Your software will look like your organization). Microservices allow and require low coupling in the organization. If you want to reduce coupling in your org, you'll be well served by microservices. If you want tight collaboration in your org, you'll be well served by a monolith. As orgs grow into multiple independently executing units, a monolith starts to limit the ability to indep…

Modularly designed software, with appropriate boundaries can accomplish the same thing without the overhead of microservice deployments.

During the early stages where there is maybe 1-2 people coding, microservices add a lot of unneeded overhead and orchestration.

Re: Monolith First (2015)

#68

Post by mixedCase »

phamilton wrote: post #60

I all comes back to Conway's Law (Your software will look like your organization). Microservices allow and require low coupling in the organization. If you want to reduce coupling in your org, you'll be well served by microservices. If you want tight collaboration in your org, you'll be well served by a monolith. As orgs grow into multiple independently executing units, a monolith starts to limit the ability to indep…

I believe a simpler explanation is that it's easier for some devs to cleanly separate concerns when they're forced to do so by the constraint of process separation, rather than language modules/packages, where it's too easy for a junior dev to break the architecture with a single import.

Keeping a monolith's concerns cleanly segregated does require a small amount of discipline.

Re: Monolith First (2015)

#69

Post by transitorykris »

phamilton wrote: post #60

I all comes back to Conway's Law (Your software will look like your organization). Microservices allow and require low coupling in the organization. If you want to reduce coupling in your org, you'll be well served by microservices. If you want tight collaboration in your org, you'll be well served by a monolith. As orgs grow into multiple independently executing units, a monolith starts to limit the ability to indep…

"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."

This is a statement about an existing organization and the system they design. It doesn't say you can design a system and then the organization of your choice forms around it.

Bezos had to start with a management edict about how the organization is structured (by threat of firing) to get the SOA system he desired at Amazon. https://plus.google.com/+RipRowan/posts/eVeouesvaVX

Post reply on HN