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

121–130 of 176 posts

Re: Monolith First (2015)

#121

Post by collyw »

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.

You mean like an API?

Re: Monolith First (2015)

#122

Post by NathanKP »

dasil003 wrote: post #78
sanderjd wrote: post #76

Earlier quoted context omitted.

I've experienced the opposite: you get traction with a monolith, and when its time to expand and scale, you find yourself with a massive kludge that makes it hard and slow to make progress. Which is not at all to say that you're wrong - a long delay in the capability to release something can definitely be an earlier and more severe death knell than friction when trying to grow. For me personally, I like to see all of…

Sure, but if you build microservices from the start, you die before you get traction because refactoring takes too long while you are finding product-market fit. The right way to do it is to write a modular monolith and maintain a loose plan on how to break it up later. Admittedly this is difficult in SV's youth-obsessed culture where "senior" devs have 5 years experience, and staying at a company long enough to unde…

> because refactoring takes too long

In my experience refactoring microservices only takes a long time if the microservices are badly done, just like refactoring a monolith only takes a long time if the monolith is a horrible piece of spaghetti code.

If refactoring requires modifying multiple microservices then the microservice boundaries and contracts were badly designed at the start. When you have practice drawing boundaries well then refactoring with microservices becomes very fast, as you only have to modify the code of one service and redeploy it.

I think too many microservice enthusiasts have a tendency to claim monoliths always turn into spaghetti code, and monolith enthusiasts claim microservices are always slower and hard to refactor. This is just a sign that neither group of architecture fans knows how to do the other architecture properly, because its possible to build microservices fast and refactor them quickly just like its possible to build a monolith that is clean and scalable.

Re: Monolith First (2015)

#123

Post by tajen »

marcuslager wrote: post #97
eternalban wrote: post #90

Earlier quoted context omitted.

> You are throwing away the major point of why microservices were created in the first place when you do what you're doing: so teams in large organizations can do independent releases. Let's ammend this: so teams in large organizations +{that lack both a coherent architecture and the ability to devise one} can do independent releases +{by adoptiong the no-architecture architecture}.

"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 be restarted and upgraded independently. As a customer, we didn't notice differences in the UI (e.g. the file storage on AWS).

Epilogue: They had a shared login system, multi tenant and all... which they recently replaced by a third party. Proof that services are replaceable, but also an acknowledgment that simple critical services can be hard at scale.

I personally believe that Atlassian switched to services at the right time, when it's hard to coordinate teams of thousands working on a dozen products, and when the monolithic approach was way past refactoring date ;)

Re: Monolith First (2015)

#124

Post by kid0m4n »

defined wrote: post #101
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…

We took ur jobs????

Re: Monolith First (2015)

#125

Post by tnolet »

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…

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.

Re: Monolith First (2015)

#126

Post by joncrocks »

NathanKP wrote: post #122
dasil003 wrote: post #78

Earlier quoted context omitted.

Sure, but if you build microservices from the start, you die before you get traction because refactoring takes too long while you are finding product-market fit. The right way to do it is to write a modular monolith and maintain a loose plan on how to break it up later. Admittedly this is difficult in SV's youth-obsessed culture where "senior" devs have 5 years experience, and staying at a company long enough to unde…

> because refactoring takes too long In my experience refactoring microservices only takes a long time if the microservices are badly done, just like refactoring a monolith only takes a long time if the monolith is a horrible piece of spaghetti code. If refactoring requires modifying multiple microservices then the microservice boundaries and contracts were badly designed at the start. When you have practice drawing…

I think the parent's comment around refactoring was precisely that you don't know what the contracts and boundaries between your microservices should be before you build them, as you don't know much about the problem space yet.

Re: Monolith First (2015)

#127

Post by pjmlp »

srtjstjsj wrote: post #65
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/

Only because people got to learn software isn't to be trusted.

If companies got heavy fines like in other industries for selling broken products, the scenario would be quite different.

Re: Monolith First (2015)

#128

Post by crdoconnor »

mixedCase wrote: post #68
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.

>it's easier for some devs to cleanly separate concerns when they're forced to do so by the constraint of process separation

This is a dangerous ideology. Process separation doesn't enforce loose coupling, it simply makes the pain of tight coupling between them that much worse.

I worked on a "microservice" system once where I regularly had to debug a problem across four different service boundaries and two different languages. It felt like I was using boxing gloves to perform surgery on a rube goldberg toy.

Re: Monolith First (2015)

#129

Post by Steeeve »

dasil003 wrote: post #78
sanderjd wrote: post #76

Earlier quoted context omitted.

I've experienced the opposite: you get traction with a monolith, and when its time to expand and scale, you find yourself with a massive kludge that makes it hard and slow to make progress. Which is not at all to say that you're wrong - a long delay in the capability to release something can definitely be an earlier and more severe death knell than friction when trying to grow. For me personally, I like to see all of…

Sure, but if you build microservices from the start, you die before you get traction because refactoring takes too long while you are finding product-market fit. The right way to do it is to write a modular monolith and maintain a loose plan on how to break it up later. Admittedly this is difficult in SV's youth-obsessed culture where "senior" devs have 5 years experience, and staying at a company long enough to unde…

> where "senior" devs have 5 years experience, and staying at a company long enough to understand the long-term repercussions of architectural choices is seen as a black mark on your resume

I had to laugh at that...

And then throw up just a little.

Re: Monolith First (2015)

#130

Post by kpil »

vog wrote: post #108
ris wrote: post #106

Earlier quoted context omitted.

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

The main problem is that micro service based architecture is sold as a silver bullet that takes care of all problems.

Knowledgeable and experienced people know that there is no free lunch, but not every opiniated voice isn't necessarily so, and refuting bullshit takes ten times more effort than producing it, so objections might be handwaved away as backwardness if there is a strong force for a modern architecture.

I mean, more of the same old shit isn't exactly an easy sell either, even if every old bad choice could be rationalized at the time...

Post reply on HN