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

131–140 of 176 posts

Re: Monolith First (2015)

#131

Post by Steeeve »

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…

People spend entirely too much time debating how to avoid a giant ball of unmaintainable junk while driving their projects to inevitably become giant balls of unmaintainable junk.

You can do monoliths bad. You can do microservices bad. You can spend too much time architecting and not enough time understanding where the practical design considerations lie.

My philosophy is to build with the intention of delegating. If you can communicate how your software works well enough that someone can take over maintenance, then you've done your job. Better if you can communicate it well enough that you can delegate it to separate groups with differing responsibilities.

Any system can get complex to the point where it's dangerous to make changes.

Re: Monolith First (2015)

#132

Post by crdoconnor »

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…

>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 independently execute.

Most individual computers combine seamlessly interoperating software that was, ultimately, written by tens if not hundreds of thousands of people, most of whom do not know one another - all the way from the kernel to the highest level scripting languages.

I think you're right microservices are primarily about Conway's law. I just don't think it's about operational effectiveness (it actually makes operational effectiveness harder, IMO).

I think it's primarily successful in large orgs because it minimizes finger pointing by establishing tighter loci of responsibility.

My rule of thumb is "could this service be spun off as a separate business?". E.g. postcode->address service, sure, microservice that. Image manipulation service->maybe yes, maybe no, "user" service-> no, price calculation service->no

Re: Monolith First (2015)

#133

Post by Olivia4654 »

collyw wrote: post #121
rdnetto wrote: post #85

Earlier quoted context omitted.

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.

You mean like an API?

I get paid over $95 per hour working from home with 2 kids at home. I never thought I'd be able to do it but my best friend earns over 10k a month doing this and she convinced me to try. The potential with this is endless. Heres what I've been doing, •••••••••>>http://www.joinmate2.com

Re: Monolith First (2015)

#134

Post by tokenizerrr »

tajen wrote: post #123
marcuslager wrote: post #97

Earlier quoted context omitted.

"teams in large organizations" Could be simplified to just "teams. These days from what I can see teams in organizations with no ability to devise a sane architecture usually take the microservice route. Management loves this new buzzword. To them it means problems go away.

Atlassian started rearchitecturing around services in 2013. They were 1500ppl at the time. Confluence and JIRA were not only monoliths, but non-multitenant, so they had to have one instance per customer (700Mb RAM JIRA, 700Mb Confluence, a dozen gigs on SSD). The worst was restarting upon upgrades: Easily 3-5 minutes per instance, which, at scale, was a huge burden. After rearchitecting around services, pieces could…

On the flip side, cloud hosted jira is soooo slow now.

Re: Monolith First (2015)

#135

Post by noir_lord »

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!

Just inherited exactly that.

The final cherry is that it uses zero joins, it's all done in code.

It's going to be a bastard to unfuck that mess.

Re: Monolith First (2015)

#136

Post by noir_lord »

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!

Just inherited exactly that.

The final cherry is that it uses zero joins, it's all done in code.

It's going to be a bastard to unfuck that mess.

Re: Monolith First (2015)

#137

Post by humanrebar »

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…

> resume-driven development

To be fair, until companies are willing to pay a premium (1) for working on bad-for-resume projects, this is very rational behavior on the part of the technical team.

1) That is, job listings can't have merely "competitive" or "market rate" salary expectations.

Re: Monolith First (2015)

#138

Post by marichards »

Modular monoliths can be a simpler medium. Writing modules of functionality that work on their own (in memory integration test) can easily be tested, separated into microservices or assimilated into a monolith. Be wary of runtime function shared between modules as it will strictly couple the two and risk side effects on each other, tending towards spaghetti. But for monolith quick wins they can help for sharing management dependent resources like database transactions.

Re: Monolith First (2015)

#139

Post by avip »

tnolet wrote: post #125
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…

This is exactly what happened / is happening at my former employer. Already 2 years of work, team of 5 engineers, Kubernetes, dozens of microservices. Lot's of time wasted on CI/CD, orchestration, monitoring, refactoring. Live date? Probably somewhere next year. It was sad to watch. 100% resume-based development.

RDD is 2010. It's called blog-driven development now (BDD)

Re: Monolith First (2015)

#140

Post by ValentineC »

crdoconnor wrote: post #132
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…

>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 independently execute. Most individual computers combine seamlessly interoperating soft…

> My rule of thumb is "could this service be spun off as a separate business?". E.g. postcode->address service, sure, microservice that. Image manipulation service->maybe yes, maybe no, "user" service-> no, price calculation service->no

Curious: why would a "user" service not be viable as a separate business? There's always space for one more authentication option.

Post reply on HN