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

471–480 of 567 posts

Re: Monoliths Are the Future

#471

Post by kortex »

abraxas wrote: post #437
simonh wrote: post #322

Earlier quoted context omitted.

The service will need to read all its data and put it into objects, then extract the data from the objects to report it, then garbage collect all of that. For every single record in its entire data set. You could say but oh, why not just return the underlying data without making objects? Well now you are exposing the underlying data format, which is what we’re trying to avoid by giving this job to the service.

And thus such patterns lead to the absurdity where 90% of enterprise apps do little actual computations beside serializing and deserializing JSON (or XML if a "legacy" app).

It's remarkable what you can do with just functions and nested data structures. Used to be big on the whole OOP thing, data roles, so much effort for so little.

Now I try to think about problems as "I have input data of shape X, I need shape Y" and fractally break it down into smaller shape-changes. I am kinda starting to get what those functional programmers are yammering on about.

Re: Monoliths Are the Future

#472

Post by artellectual »

I think most people who flock to Micro Services are looking for a better design / architecture choice for software. The thing that Micro Service can teach you is Single Responsibility Principle and learning to segregate responsibility. You need to define a clear scope of the 'modules' in your system.

At the end of the day if you don't architect your system correctly Monolith / Micro Services won't help you.

For me and my team now I have 1 ideaology regarding this topic. I don't care whether it's monolith or micro service. As long as I can have clear segregation of responsibility between the different modules. Our company now has a monolith (core banking app) that has modules that handle their own responsibility and communicate whether its over http or internal communication bus we developed it doesn't matter. We can easily move modules out into a separate service if we need.

What determines the factor of whether we move things into it's own service? A few things. If we need to deploy / scale something independently we will decide to take on the overhead and move things out into their own external service. Or if something has a specific security requirement that will increase the complexity of the overall system we will isolate that and deploy it separately. Otherwise we keep things as a monolith. For example in Banking there are many things like the ledger / transaction data that are highly sensitve that require certain security requirements like being hosted on a cloud that has certain standards. We will deploy this part on GCP. But

People seem to love to stereotype and find a one solution fits all. There is no such thing. Everything in engineering requires a deep level of understanding of the problem and making choices and the problems present itself.

I believe most apps can start their life out as a monolith, and can grow and divide as needed. There just isn't a one size fits all for anything in tech. That's what I've learned.

Re: Monoliths Are the Future

#473

Post by zomglings »

rjkennedy98 wrote: post #19
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 is what Kafka is for. You put Kafka on top of your database to expose data and events. Now BI can take the events put them into their system as they want.

> You put Kafka on top of your database

Your casual tone is at odds with what I've seen when teams run Kafka clusters in production. Not a decision I would take so lightly.

Re: Monoliths Are the Future

#474

Post by jackcosgrove »

artellectual wrote: post #472

I think most people who flock to Micro Services are looking for a better design / architecture choice for software. The thing that Micro Service can teach you is Single Responsibility Principle and learning to segregate responsibility. You need to define a clear scope of the 'modules' in your system. At the end of the day if you don't architect your system correctly Monolith / Micro Services won't help you. For me an…

I think the monolith vs microservice question is more about organizational needs than anything else. Technically neither is superior, and the debate pales compared to the need to only hire quality developers. Good developers can make either pattern work, and bad developers can break either pattern.

Re: Monoliths Are the Future

#475

Post by JamesBarney »

tristador wrote: post #416
JamesBarney wrote: post #401

Earlier quoted context omitted.

You're right that micro-services avoid a lot of the pain of micro-services if they have one consolidated "Data service" that sits on top of their data repositories. But a micro-services architecture with a consolidated data service is similar to an airplane on the ground, it's true it can't fall out of the sky, but it's as useful as a car with awful gas mileage. Once you add in this consolidated data service, every o…

I'm not following. How do things work better for the non-microservice approach? Re. teams: For any project above a certain size, you'll have teams. If that's a network boundary, a process boundary, or a library boundary doesn't change that you'll have multiple teams for a large project. I'm not sure I get the resiliency point. I worked on a project where the dependent data service was offline painfully frequently. We…

> Re. teams: For any project above a certain size, you'll have teams. If that's a network boundary, a process boundary, or a library boundary doesn't change that you'll have multiple teams for a large project.

For sure, and one of the big selling points for micro-services is you can split those teams by micro service, with each team having an independent service they are responsible for. But when a big chunk of everyone's development is done on one giant service everyone shares you don't get the same benefits you would if the services were independent. Or put another way, splitting micro-services vertically can yield a bunch of benefits, but splitting them horizontally introduces a lot of pain with few benefits.

> I'm not sure I get the resiliency point. I worked on a project where the dependent data service was offline painfully frequently. We used async tasks and caching to keep things running and were able to let the users do many tasks. For us our tool was still fairly useful when dependencies went down. If we used monolith then everything would be down, right? That doesn't sound better.

I'm not saying to never spin off services. If you have a piece of functionality that you just can't get stable for the life of you, splitting it off into it's own service, and coding everything up to be resilient to it's failure makes a lot of sense. (I am very curious what the cause of the data service crashing was that you couldn't fix.)

But micro-services aren't a free lunch for resiliency. You're increasing the numbers of systems, servers, configurations, and connections which by default will decrease up-time until you do a ton of work. Not to mention tracking and debugging cross service failures is much more difficult than a single server.

Re: Monoliths Are the Future

#476

Post by Aperocky »

smoyer wrote: post #406
rubyn00bie wrote: post #347

I couldn't agree more with an article. Most people think a micro-service architecture is a panacea because "look at how simple X is," but it's not that simple. It's now a distributed system, and very likely, it's a the worst-of-the-worst a distributed monolith. Distributed system are hard, I know, I do it. Three signs you have a distributed monolith: 1. You're duplicating the tables (information), without transformin…

We've moved a lot of services into Kubernetes and broken things up into smaller and smaller micro-services. It definitely eliminates a lot of the complexity for developers ... but you trade it for operational complexity (e.g. routing, security, mis-matched client/server versions, resiliency when dependency isn't responding). I still believe that overall software quality is higher with micro-services (our Swagger docu…

You’ll have endless race conditions to deal with, even when storage is central and unique.

We learned and is continuing learning that.

Re: Monoliths Are the Future

#477

Post by tomerbd »

smoyer wrote: post #406
rubyn00bie wrote: post #347

I couldn't agree more with an article. Most people think a micro-service architecture is a panacea because "look at how simple X is," but it's not that simple. It's now a distributed system, and very likely, it's a the worst-of-the-worst a distributed monolith. Distributed system are hard, I know, I do it. Three signs you have a distributed monolith: 1. You're duplicating the tables (information), without transformin…

We've moved a lot of services into Kubernetes and broken things up into smaller and smaller micro-services. It definitely eliminates a lot of the complexity for developers ... but you trade it for operational complexity (e.g. routing, security, mis-matched client/server versions, resiliency when dependency isn't responding). I still believe that overall software quality is higher with micro-services (our Swagger docu…

And also trading off with how easy it is to understand the system. If you have one monolith in most cases it's a single code base you can navigate through and understand exactly who calls who and why.

Re: Monoliths Are the Future

#478

Post by _jal »

empthought wrote: post #399
HeroOfAges wrote: post #328

Earlier quoted context omitted.

Wait, I would assume that the people in need of reporting would have a pretty good idea of what those reports should look like. That means you know exactly what data needs to be read from a data store optimized for reporting. Each micro-service contributes their share of data to a data store optimized for reading. This is a text-book use case for a non-relational document store. I'm really not seeing what's so diffic…

Reporting and non-relational are like oil and water, coming from experience working with people who make reports. It’s not like they come up with every report they think they might need while the micro service is being architected. They come up with a new report long after engineers have moved on. If it’s a SQL database, no problem. If it’s some silly resumeware data store, then what?

Yeah, this.

If you can't ask questions you didn't think of in advance, you didn't collect data.

Re: Monoliths Are the Future

#479

Post by idiocratic »

Aperocky wrote: post #476
smoyer wrote: post #406

Earlier quoted context omitted.

We've moved a lot of services into Kubernetes and broken things up into smaller and smaller micro-services. It definitely eliminates a lot of the complexity for developers ... but you trade it for operational complexity (e.g. routing, security, mis-matched client/server versions, resiliency when dependency isn't responding). I still believe that overall software quality is higher with micro-services (our Swagger docu…

You’ll have endless race conditions to deal with, even when storage is central and unique. We learned and is continuing learning that.

Unique storage for multiple services sounds like a recipe for disaster. The purpose of splitting services, at least one of, is to decouple parts of the code at a fundamental level, including storage and overall ownership thereof. You're probably better served with a modular monolith if you really can't break storage up.

Re: Monoliths Are the Future

#480

Post by Aperocky »

idiocratic wrote: post #479
Aperocky wrote: post #476

Earlier quoted context omitted.

You’ll have endless race conditions to deal with, even when storage is central and unique. We learned and is continuing learning that.

Unique storage for multiple services sounds like a recipe for disaster. The purpose of splitting services, at least one of, is to decouple parts of the code at a fundamental level, including storage and overall ownership thereof. You're probably better served with a modular monolith if you really can't break storage up.

No, only one service is reading/writing, everything else just call that. Still, things get quite lost when it involves talking to multiple other teams and needing to keep everything in sync.
Post reply on HN