Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monoliths Are the Future

changelog.com

Post reply on HN
Print view View original

151–160 of 567 posts

Re: Monoliths Are the Future

#151

Post by ptero »

closeparen wrote: post #57

My employer adopted microservices for a very specific reason: it became nearly impossible to deploy the monolith. With hundreds of commits trying to go out every day, probability that at least one would break something approached 1. Then everything had to be rolled back. Getting unrelated concerns into separate deployable artifacts rescued our velocity. It came with many of its own challenges, too! A great deal of in…

If you have the problem for which microservices are the better solution (as you describe in your example), great!

But I have seen people try to build a solution using microservices "because this is the way to go". But this often trades the problems of commits and unit verification for problems of architecture. It can take a lot of work and skill to design a robust architecture using microservices and architectural bugs and failures can be a lot harder to debug, understand and resolve. Pick your poison.

Re: Monoliths Are the Future

#152

Post by yibg »

BrentOzar wrote: post #8

I'm a database guy, so the question I get from clients is, "We're thinking about breaking up our monolith into a bunch of microservices, and we want to use best-of-breed persistence layers for each microservice. Some data belongs in Postgres, some in DynamoDB, some in JSON files. Now, how do we do reporting?" Analysts expect to be able to connect to one system, see their data, and write queries for it. They were neve…

This isn’t a new problem to microservices though, although maybe it’s amplified. Reporting was challenging before microservices became popular too with data from different sources. Different products, offline data sources etc that all had to be put together. The whole ETL, data warehousing stuff.

In the end everything involves tradeoffs. If you need to partition your data to scale, or for some other reason need to break up the data, then reporting potentially becomes a secondary concern. In this case maybe delayed reporting or a more complex reporting workflow is worth the trade off.

Re: Monoliths Are the Future

#153

Post by jaxn »

jsjohnst wrote: post #101
BrentOzar wrote: post #8

I'm a database guy, so the question I get from clients is, "We're thinking about breaking up our monolith into a bunch of microservices, and we want to use best-of-breed persistence layers for each microservice. Some data belongs in Postgres, some in DynamoDB, some in JSON files. Now, how do we do reporting?" Analysts expect to be able to connect to one system, see their data, and write queries for it. They were neve…

But I’d argue Monoliths don’t have anything inherent to them which makes reporting easier. A proper BI setup requires a lot of hard work no matter how the backend services are built.

Monoliths have an advantage up until the point where you have to shard the database in some way.

Re: Monoliths Are the Future

#154

Post by FlorianRappl »

Glyptodon wrote: post #78
dcwca wrote: post #10

The author does not seem to understand when to correctly apply microservices. There are two basic use cases: 1) Different parts of your solution have different load patterns and it is economically beneficial to scale them at different rates and 2) Different teams need to be able to work & ship autonomously. It's not at all about technical merits or architectural beauty. It's about people and costs.

I kind of think the items (1) and (2) you list don't automatically mean micro-services, so much as they mean separation of concerns can be beneficial. Isn't there room for a middle ground with modularity that can live in between a full blown monolith or a full blown microservices pattern, particularly for operations that are more medium scale?

Of course there is, was, and will be!

I think people sometimes forget that a healthy level of pragmatism is what keeps shipping. Just because someone said "microservices is the new all" you don't need to do it. Just because some said "monoliths are the future" it does not have to be true for you.

Take all these as case studies and solutions that apparently worked under specific conditions.

Re: Monoliths Are the Future

#155

Post by topkai22 »

eej71 wrote: post #80
tudelo wrote: post #12

I have never worked on a real 'production' monolith. I wonder what i'm missing out on :)

For me a single monolithic stack is far more debugable.

Depends on how big that monolith gets. Microservices can definitely be overkill, but at some point its a real liability to not have well isolated abstractions. Yes, you can do that within a monolith, but the temptation to break isolation is just greater when its all in the same folder/repo.

Re: Monoliths Are the Future

#156

Post by y-c-o-m-b »

fmakunbound wrote: post #134

I knew I could ride the micro-services fad out. It was only ever useful for massive deployments that only massive systems like facebook and others needed. However their engineering teams dominated the discourse and others followed, pretending if they too had the same requirements even though their engineering teams were small and their systems far simpler.

> pretending if they too had the same requirements even though their engineering teams were small and their systems far simpler

Cue Hadoop, AI/ML, block-chains

Re: Monoliths Are the Future

#157

Post by 0x445442 »

wobblegong wrote: post #149
closeparen wrote: post #57

My employer adopted microservices for a very specific reason: it became nearly impossible to deploy the monolith. With hundreds of commits trying to go out every day, probability that at least one would break something approached 1. Then everything had to be rolled back. Getting unrelated concerns into separate deployable artifacts rescued our velocity. It came with many of its own challenges, too! A great deal of in…

Our company migrated for very similar reasons - I'm surprised that people aren't mentioning this pain point more. Maybe the overall execution of microservices is poor, so people generally would rather go back to the old thing.

I've found it to be much harder to manage and deploy multiple projects that it was to deploy a war. It's also been a huge PITA to test the newer architecture because all these serverless artifacts need to be deployed together. What we have now is a distributed monolith, just like the article refers to.

Re: Monoliths Are the Future

#158

Post by cobookman »

yibg wrote: post #152
BrentOzar wrote: post #8

I'm a database guy, so the question I get from clients is, "We're thinking about breaking up our monolith into a bunch of microservices, and we want to use best-of-breed persistence layers for each microservice. Some data belongs in Postgres, some in DynamoDB, some in JSON files. Now, how do we do reporting?" Analysts expect to be able to connect to one system, see their data, and write queries for it. They were neve…

This isn’t a new problem to microservices though, although maybe it’s amplified. Reporting was challenging before microservices became popular too with data from different sources. Different products, offline data sources etc that all had to be put together. The whole ETL, data warehousing stuff. In the end everything involves tradeoffs. If you need to partition your data to scale, or for some other reason need to br…

+1, Informatica was founded in 1993. Teradata in 1979. These are not new problems.

DataWarehousing has drastically improved recently with the separation of Storage & Compute. A single analyst's query impacting the entire Data Warehouse is a problem that will in the next few years be something of the past.

Re: Monoliths Are the Future

#160

Post by unlinked_dll »

Glyptodon wrote: post #78
dcwca wrote: post #10

The author does not seem to understand when to correctly apply microservices. There are two basic use cases: 1) Different parts of your solution have different load patterns and it is economically beneficial to scale them at different rates and 2) Different teams need to be able to work & ship autonomously. It's not at all about technical merits or architectural beauty. It's about people and costs.

I kind of think the items (1) and (2) you list don't automatically mean micro-services, so much as they mean separation of concerns can be beneficial. Isn't there room for a middle ground with modularity that can live in between a full blown monolith or a full blown microservices pattern, particularly for operations that are more medium scale?

Yea just take the ideas that apply to your problem domain and implement them in a way that's sane. Design/architecture patterns are much more useful as templates to be specialized for your problem.

I really don't like the dogmatic view of architectures. Leaves no room for craftsmanship, and it's only really useful for creating code monkeys that have to follow a spec and need to be interchangeable cogs in the machine.

Post reply on HN