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

151–160 of 176 posts

Re: Monolith First (2015)

#151

Post by Turbots »

eropple wrote: post #10
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 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…

Exactly.

Make a monolith first, but do it with clean code and with twelve factor apps in mind. That's why I love using Spring Boot.

Re: Monolith First (2015)

#152

Post by ris »

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…

> Having distinct silos of activity/responsibility, separate teams and communications channels; all can make a large project more manageable than the monolith by allowing the lower level problems to be abstracted away (from a management perspective).

It also has the effect of making small projects large even if they never needed to be in the first place (which of course looks great on a resume)

Re: Monolith First (2015)

#153

Post by rhizome »

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.

It sounds like you're describing ORM-as-API. Which, if you find you need it, great, but I wouldn't try to fool myself that introducing a mediating process like that is all that different from what the language/framework likely already provides (contemporary development frameworks are common). It's just ("just") abstracted to operate on network basis. Actually, what you describe sounds like a reduction in functionality from a non-API model.

Hopefully that parses as English, it's still morning for me.

Re: Monolith First (2015)

#154

Post by brightball »

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…

That's actually one of the biggest perks of Elixir IMO. You can a monolith that's basically already separated into microservices.

Re: Monolith First (2015)

#155

Post by acdha »

bsder wrote: post #119
true_religion wrote: post #114

Earlier quoted context omitted.

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…

That reads like a lot of accusation without much evidence, and the author's credibility was immediately called into question for me when they dismissed Y2k as a non-issue because it didn't produce widespread problems, ignoring all of the problems which had been fixed in the previous decade. (This is like the people saying closures after a snow storm weren't necessary because there was no traffic, ignoring the reason why)

The only real lesson I feel comfortable drawing from that is that we need more diverse case-studies than C3 because very few other projects are going to have the same environment with a huge company, multi-divisional politics and then a merger happening shortly into the project, one of the best defined problems, etc.

Re: Monolith First (2015)

#156

Post by [deleted] »

catern wrote: post #51
tunesmith wrote: post #47

Earlier quoted context omitted.

If that needs to be scaled out to many services, then you also want to scale out the data model. Meaning, events in a commit log, and services that subscribe to that commit log to create their own schemas that are tuned for their own needs. The more I think about commit logs, the more I think giant monolithic database schemas are just kind of weird - a strange compromise between history and state.

That's an interesting idea. If I understand correctly, you're suggesting that services simply broadcast the data mutations they are going to perform. Then, any other services that wish to use that data can filter those broadcasted mutations down to what is relevant to the other services, and store the data in a way that is efficient for what the other services want to do. Are there any examples of things architected…

[deleted]

Re: Monolith First (2015)

#157

Post by olingern »

alexandros wrote: post #145

We started resin.io with a microservices architecture from day one, and we are still happy with the result. It was very painful to get it up and running, but once that was over, we were good to go. The boundaries we defined early on are still solid, and the result works well. One critical detail however, is that all our persistent state lives in one place, minus specific well-understood exceptions. Arguably, starting…

Any advice you would give to a team going this route?

And, I've found that integration tests help keep my sanity if a refactor occurs anywhere. Any learning(s) for adapting to refactors across services?

Re: Monolith First (2015)

#158

Post by alexandros »

olingern wrote: post #157
alexandros wrote: post #145

We started resin.io with a microservices architecture from day one, and we are still happy with the result. It was very painful to get it up and running, but once that was over, we were good to go. The boundaries we defined early on are still solid, and the result works well. One critical detail however, is that all our persistent state lives in one place, minus specific well-understood exceptions. Arguably, starting…

Any advice you would give to a team going this route? And, I've found that integration tests help keep my sanity if a refactor occurs anywhere. Any learning(s) for adapting to refactors across services?

I think keeping all the data in one place has been one of the smartest things we did. If we'd been crazy enough to give each microservice its own persistence, we'd be neck deep in chaos by now. It only happened for one service due to reasons that we should have ignored at the time, and it keeps biting us in the rear to this day. Thankfully we're getting closer to reversing that mistake, oh happy day.

Re: Monolith First (2015)

#159

Post by pgwhalen »

maxxxxx wrote: post #21
a_imho wrote: post #6

Might be OT, but what is the opinion on Martin Fowler in general?

I think he often states the obvious but gives it a nice new name.

That's a good way of putting it, and I think he would actually agree with you on that. I was at his "Event driven architecture" talk at Goto Chicago where he talked about four patterns that can show up in something you might call event driven. He didn't presume to be inventing anything, just categorizing some patterns that have been recognized before, with the intent of clearing up some of the haziness/hype that occurs when someone says they have an event driven architecture.

Re: Monolith First (2015)

#160

Post by hderms »

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.

law of demeter?
Post reply on HN