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

101–110 of 176 posts

Re: Monolith First (2015)

#101

Post by defined »

y2hhcmxlcw wrote: post #18

At what point will corporations that still design massive systems as an unmaintanable monolith figure out they can architect things better and save a ton of developer dollars? At what point do they start taking good points from articles like this and either break those up into microservices or some other solution?

I suspect that it will be in a very long time.

For one thing, I've seen each generation of new managers forget or ignore the knowledge hard-won by their predecessors or the software body of knowledge. Oh, and ignore their current experts, too. I think it's a bug in the human wetware because it happens so often.

For another, it was explained to me when consulting at $giantcorp that sometimes - for example, regulatory compliance or competitive edge - it's more important to get a shitty monolith out there, bugs and all, by a drop-dead date than to save in the long run by doing a good job.

And as long as there are people out there willing to work for low wages fixing or rewriting the pile of crap, and it's profitable for $company, the practice will continue.

Or until someone can prove, with cost measurements on multiple large-scale projects implementing the same requirements, that the ROI - in bottom line $ terms - on a well-engineered system is much greater than the crappy equivalent.

I can't see that happening because of all the variables involved (team, skill, chance, cost, variance in interpretation of requirements, and so on), plus, who would pay for that?

EDIT - typo.

Re: Monolith First (2015)

#103

Post by losteric »

y2hhcmxlcw wrote: post #39
losteric wrote: post #26

Earlier quoted context omitted.

When they realize business managers don't know jack about computers, and delegate more authority to engineers and/or hire product/technical managers. Development processes and software architecture follow from business process and architecture... it's hard to be agile and develop services with clean separation of responsibilities when business insists on monolithic hairball project reqs with fixed deadlines. (aka Con…

I wonder at what point the financial pressure to stop designing bad software becomes so high that it overrides the political pressures that created the bad designs and practices? To a community like HN it's just normal every day thinking to design even at least a decent web application, but at some companies that's seen as either visionary and impossible or even immature. But at some point it seems there would be so…

Well, Conway's Law states that code reflects the organization's bureaucracy... bad software means bad leadership and decision making, likely spread throughout the company. Companies will root out those inefficiencies if and only if they are doing poorly. Deep cultural changes are hard to drive if the company is doing relatively well, no one wants to take the "risk" of trying to improve.

Re: Monolith First (2015)

#104

Post by lisa_henderson »

Last year I worked at an electronic publishing firm which had wasted $3 million and 5 years on a Ruby On Rails application which was universally hated by the staff, and which we replaced with 6 clean, separate services. The problem with the Ruby On Rails app is that it was trying to be everything to everyone, which is a common problem for monoliths in corporate environments. But the needs of the marketing department were very different from the needs of the publishing department. A request for a new feature would come in from the blogging/content division which would be added to the Ruby On Rails app, even though it slowed the app down for everyone else.

Six separate services allowed multiple benefits:

1.) each service was smaller and faster

2.) each service was focused on the real needs of its users

3.) each service was free to evolve without harming the people who did not use the service

There was some duplication of code, which suggests a process that is the exact opposite of "Monolith First":

Start with separate services for each group of users, then later look to combine redundant code into some shared libraries.

Re: Monolith First (2015)

#106

Post by ris »

dasil003 wrote: post #77
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…

In this case I think it's proper to consider the database as a service in its own right. This is the way it always used to be done, and there are significant advantages, such as being able to focus on safeguarding the data, and leveraging ACID and constraints/stored procs to make the application code less error-prone. The downside is you have a potentially hard scalability ceiling, and you have coupling of every down…

> The downside is you have a potentially hard scalability ceiling

Which 99.9% of projects will never ever hit, and those that do will by that point have become such an extreme scale that significant reengineering should be something that's happening anyway.

I couldn't agree more with your last paragraph.

Re: Monolith First (2015)

#107

Post by bsder »

Fowler failed miserably when building a monolith. See: https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...

Why should we believe his statements about microservices?

Personally, my experience in microservices vs monolith has been as follows:

If your system needs fast update with quick rollout of new features, monolith is probably superior. Being able to touch everything quickly and redeploy is generally quicker in a monolith.

If your system needs to be able to survive component latency/failure, microservices are probably superior. You will have hard separation that enables testability from the beginning.

Overall, I find the monolith vs microservices debate insipid. We have LOTS of counterexamples. Practically everybody writing Erlang laughs at people building a monolith.

Re: Monolith First (2015)

#108

Post by vog »

ris wrote: post #106
dasil003 wrote: post #77

Earlier quoted context omitted.

In this case I think it's proper to consider the database as a service in its own right. This is the way it always used to be done, and there are significant advantages, such as being able to focus on safeguarding the data, and leveraging ACID and constraints/stored procs to make the application code less error-prone. The downside is you have a potentially hard scalability ceiling, and you have coupling of every down…

> The downside is you have a potentially hard scalability ceiling Which 99.9% of projects will never ever hit, and those that do will by that point have become such an extreme scale that significant reengineering should be something that's happening anyway. I couldn't agree more with your last paragraph.

This can't be said often enough: Scaling is a luxury problem!

It is far more likely that a company gets a "small", stable user base that provides enough income, than it is to become the next Google.

It doesn't make sense to apply all the complexity for large-scale problems when your user base isn't even small-scale. And if your monolith is structured in a remotely sane way, you can introduce microservices (or whatever will be best practice) later on.

On the other hand, it doesn't hurd to write your code with performance and scalability in mind. Neglecting this too hard may result in bad performance even for the first 10 users. But that's more in the sense of "keep it simple enough so it can be easily restructured later on". And in the sense of "measure performance to know your hot spots" ... and concentrate you efforts there.

Re: Monolith First (2015)

#109

Post by raarts »

taurath wrote: post #58
tomnipotent wrote: post #53

Earlier quoted context omitted.

Event Sourcing [0] & CQRS [1] come to mind. I'm also a fan of Bottled Water [2] that turns Postgres ops into a stream of events that you can then push to other services. [0] https://martinfowler.com/eaaDev/EventSourcing.html [1] https://martinfowler.com/bliki/CQRS.html [2] https://github.com/confluentinc/bottledwater-pg

It's hilarious to me that that came up, because that was a big part of the 6 month delay.

Any particular one or all three of them?

Re: Monolith First (2015)

#110

Post by jon-wood »

Animats wrote: post #95
dasil003 wrote: post #77

Earlier quoted context omitted.

In this case I think it's proper to consider the database as a service in its own right. This is the way it always used to be done, and there are significant advantages, such as being able to focus on safeguarding the data, and leveraging ACID and constraints/stored procs to make the application code less error-prone. The downside is you have a potentially hard scalability ceiling, and you have coupling of every down…

As I point out occasionally, Wikipedia is MariaDB front-ended by various caching systems. There's some auxiliary stuff for logging and searching, but its synchronization is not mission critical. Wikipedia is the ninth most popular site on the web. You're probably not going to be bigger than that.

Wikipedia is also massively cacheable, much more so than almost any other application.
Post reply on HN