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

111–120 of 176 posts

Re: Monolith First (2015)

#111

Post by Arianna34 »

jon-wood wrote: post #110
Animats wrote: post #95

Earlier quoted context omitted.

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.

My mothers neighbour is working part time and averaging $9000 a month. I'm a single mum and just got my first paycheck for $6546! I still can't believe it. I tried it out cause I got really desperate and now I couldn't be happier. Heres what I do, •••••••••>> http://www.joinmate2.com

Re: Monolith First (2015)

#112

Post by true_religion »

eropple wrote: post #28
sbov wrote: post #23

Earlier quoted context omitted.

So it would probably surprise you to hear that companies I've worked for in the past have built monolithic applications serving pages that were per-user dynamic that can handle upwards of 20,000 requests per second? This is why I hate this subject. People use terms and don't define them. If you think microservices is the only way to scale past 30 requests per second you're extremely wrong.

I need to give you an internet fistbump for this. I mean...you know what you can even do instead of The Holy Microservice? You can take parts of your API, facade them behind a different load balancer, and call into different instances of your monolith that only handle user management or billing or whatever. Un-run code's cost is, in the general case, basically zero--act like it. You don't need to do something like th…

That sounds like it's SoA. It's the forgotten intermediary step between a monolith and a microservice architecture.

Re: Monolith First (2015)

#113

Post by [deleted] »

rdnetto wrote: post #85
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…

A variation on this would be to put the database behind a service that abstracted over the schema, though that only works for basic CRUD queries and not complex aggregations. This service would probably evolve from the monolith.

[deleted]

Re: Monolith First (2015)

#114

Post by true_religion »

bsder wrote: post #107

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 qu…

From reading the wiki article, it says the goal was to replace the payroll system for 89,000 people by 1999. By 1997, it went live in a staged rollout for 10,000 employees. Within the same year, the performance of the software improved 8300%.

Sadly, Chrysler was bought[1] out in 1998 and the project was canceled in the year 2000 for unknown reasons. 1999 when it was intended to be fully deployed, Crystler was in the middle of a reorganization, which would lead to layoffs of more than 21,000 people in the next 3 years.

I'd guess organizational politics had more to do with the cancellation than anything the development team did wrong.

[1] Oh, sure it was labeled "a merger of equals", but consider that the share price fell to 50% within a year afterward and Crystler was eventually split off and sold... it just makes me think of the Time Warner + AOL merger.

Re: Monolith First (2015)

#115

Post by watwut »

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…

Proper collaboration in human organization is best served by clear responsibilities, roles and accountability. The monolith in big organization leads to turf wars, random dudes attempting to micromanage components they know nothing about, committees designing simple dunct I nality etc. So you split that in pieces with clear lines between then and voila, hours long bullshit meetings are no longer necessary.

Re: Monolith First (2015)

#116

Post by BurningFrog »

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 think the "micro" part of the name is really unfortunate for "microservices".

"Micro" means "one millionth", so it's easy to get the impression that you should have at least thousands of "microservices".

In reality, if each of your microservices don't fill up at least dozens of heavily loaded servers, you're better off with a monolith architecture.

Re: Monolith First (2015)

#117

Post by heisenbit »

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…

There is one area where I feel it makes sense to consider going into a micro-services direction from the beginning: User Accounts. It is clearly re-usable, can increase security and while more effort it is not so costly.

Re: Monolith First (2015)

#118

Post by olmo »

Ma8ee wrote: post #43
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…

And one day you realize you have to change your data model, and absolutely all your application are coupled to your whole database. Oups!

There is a solution for this problem: I use a monolith that make 100% of my sql queries using LINQ (including massive updates and so). Since Linq is strongly typed you can rename/remove/split tables and columns, fix compilation issues, create a migration and deploy the new monolith. We create an average of 5 migrations per day in a project with around 300 table for 2 years and no signs of an unmantainable mud so far.

Disclaimer: I'm the main developer behind Signum Framework

Re: Monolith First (2015)

#119

Post by bsder »

true_religion wrote: post #114
bsder wrote: post #107

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 qu…

From reading the wiki article, it says the goal was to replace the payroll system for 89,000 people by 1999. By 1997, it went live in a staged rollout for 10,000 employees. Within the same year, the performance of the software improved 8300%. Sadly, Chrysler was bought[1] out in 1998 and the project was canceled in the year 2000 for unknown reasons. 1999 when it was intended to be fully deployed, Crystler was in the…

Starting here also gives an interesting view of whether of not it was a "success": https://books.google.com/books?id=Nxi7O7FCdIEC&pg=PA43&lpg=P...

To be fair, he has an axe to grind, but C3 was quite far from a success.

To be fair, big projects fail. A lot. For many reasons. So, I'm not going to blame the people involved.

And I find Fowler to actually be probably the most level-headed of the bunch to come out of that project.

However, I WILL apply requisite amounts of skepticism when those same people start peddling their "expert knowledge" about subject matter in which they provably didn't "beat the average".

Re: Monolith First (2015)

#120

Post by garganzol »

Every one who eats the food from a thought leader like Martin Fowler eventually meets a trap. Shiny ideas "that sound interesting" are like a candle light for a moth.

I created a simple rule long time ago: last.

Post reply on HN