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

261–270 of 567 posts

Re: Monoliths Are the Future

#261

Post by hopia »

geggam wrote: post #253
MadWombat wrote: post #231

Earlier quoted context omitted.

Microservices provide an abstraction. That is kind of the point. If you feel like the data yours service operates on would be better off stored in a redis database instead of an RDBMS, you can rewrite your persistence layer, test and roll out the new version of the service. As long as your APIs do not change, nobody cares how you produce responses to requests. In a monolith, this would be a nightmare. You don't have…

Seems to me you are talking about a database access layer instead of microservices. My understanding of microservices is a bunch of loosely connected services that can be changed with minimal impact to the others Problem with the ideal is in reality this never works as complexity grows the spaghetti code moves to spaghetti infrastructure ( Done a network map of a large k8s / istio deployment lately ? )

The impact would be minimal only if the API of the microservice didn't change. But in the same codebase too, if you have a module whose API doesn't change the changes from refactoring it would likewise be minimal.

Re: Monoliths Are the Future

#262

Post by btilly »

baq wrote: post #223
btilly wrote: post #144

Earlier quoted context omitted.

I've seen some great criticisms of microservices, some of which made me pause. Now, however, I think there's a reasonable way through the obstacles. It doesn't have to be a mess. Nothing is a magic bullet, but about anything will work if your game is good enough. You don't buy a bright and shiny to make your game better. Doesn't work like that. With all due respect, the argument that microservices can work is not an…

I work on a project where dev teams (plural) occupy time zones spanning 16h. Having a very hard boundary between service concerns helps immensely with remaining sane even if the project could be rolled into a monolith from the perspective of code or data complexity.

There are ways to get such boundaries without having separate microservices.

Also having dev teams across time zones is itself a challenge. The devs are cheaper, but integration is worse. In Steve McConnell's book Software Estimation the industry average seems to be that development is over 40% longer, and defect rates also go up.

That, however, is a debate for another day.

Re: Monoliths Are the Future

#263

Post by cryptozeus »

This is like saying microservices are the future. Both are incorrect, of course this is case by case bases and one should keep an open mind and should know the pros and cons of both. Apply either one when needed.

Re: Monoliths Are the Future

#264

Post by pjmlp »

echelon wrote: post #140
MadWombat wrote: post #131

Earlier quoted context omitted.

> Some data belongs in Postgres, some in DynamoDB, some in JSON files. Now, how do we do reporting? One of the key concepts in microservice architecture is data sovereignity. It doesn't matter how/where the data is stored. The only thing that cares about the details of the data storage is the service itself. If you need some data the service operates on for reporting purposes, make an API that gets you this data and…

> But you do not simply go and poke your reporting fingers into individual service databases. This is why I distrust all of the monolith folks. Yes, it's easier to get your data, but in the long run you create unmaintainable spaghetti that can't ever change without breaking things you can't easily surface. Monoliths are undisciplined and encourage unhealthy and unsustainable engineering. Microservices enforce separat…

Only when done by folks that never learned how to write modular code and package libraries.

The same folks aren't going to magically learn how to do distributed computing properly, rather they will implement unmaintainable spaghetti network calls with all the distributed computing issues on top.

Re: Monoliths Are the Future

#265

Post by chillacy »

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…

Feature toggles are a solution this. That lets you do feature releases independent of code deployment. Doesn’t work 100% of the time but I can’t imagine doing a large monolith without feature toggles.

Re: Monoliths Are the Future

#266

Post by cc81 »

rjkennedy98 wrote: post #24
reading-at-work wrote: post #6

I think the underlying point, as expressed by the author, is that trendy new architecture patterns will never be a panacea for bad engineering, though that's often how they're implicitly sold as ideas.

It is actually sold as a way to fix bad engineering? I've literally never heard that before. I think almost everyone knows that microservices are hard. On the other hand they are often sold as a way to increase developer velocity. And I do sometimes wonder if that is the case (based on personal experience).

Yes, it is a pretty common saying that it forces separation of concerns and avoids the spaghetti that monoliths end up like.

People are selling it as easy. You can deploy them independently, each service is small with low complexity.

That it is not that easy in reality and that the total complexity increase is so big is not told as often. There is a team at my work with 6 developers developing something that processes a couple of gigs of data each day and has a front end serving maybe a hundred users total, I would guess 20 would be logged in at the same time.

Kubernetes, 10 microservices, 2 different types of databases.

Re: Monoliths Are the Future

#268

Post by jayd16 »

StavrosK wrote: post #193
echelon wrote: post #140

Earlier quoted context omitted.

> But you do not simply go and poke your reporting fingers into individual service databases. This is why I distrust all of the monolith folks. Yes, it's easier to get your data, but in the long run you create unmaintainable spaghetti that can't ever change without breaking things you can't easily surface. Monoliths are undisciplined and encourage unhealthy and unsustainable engineering. Microservices enforce separat…

You're saying "monoliths encourage unhealthy engineering" and then in the next sentence say "when executed correctly" for microservices. That sounds like a having/eating cake type situation.

Not exactly. It's hard to tell from the outside if a monolith was architecture well or is about the fall over.

In a microservice architecture it's harder to pretend you're doing it right.

Re: Monoliths Are the Future

#269

Post by cc81 »

davnicwil wrote: post #216
eightysixfour wrote: post #113

Monoliths and Microservices are technical expressions of organizational structure. Talking about them in only a technical sense misses the forest for the trees, IMO.

Completely agree and actually think this is the root of the problem. People look at what really big successful companies are doing and draw inspiration from that. Problems come when they mix up cause and effect, and then view things through the wrong lens. As you say, microservices are a mostly organisational, partly technical, effect of having to scale a huge techincal org. But then when taking this end state and vi…

Yes, I had a discussion about a very senior (but not developer) why we he thought we must enforce microservices in our applications from a technical perspective. He thought it was incredibly important to be able to scale parts of it independently and it is a normal CRUD internal application with a couple of thousand users.

Of course he looks at Netflix and Google as best practices but that discussion probably spent more money in salary than our server costs.

Re: Monoliths Are the Future

#270

Post by celticmusic »

karmakaze wrote: post #53
andrew_n wrote: post #42

Spot on. The metaphor I typically use here is cleaning up a mess vs spreading it around. If you have a really big mess and spend a year or two rearranging it into dozens or hundreds of smaller messes, yes the big obvious mess is gone, but the overall amount of mess has likely gone up and by segregating everything you’ve probably made it much harder to someday get to a clean state. If you’re moving to microservices be…

Complexity (as in unintended/unexpected behaviour) varies with N^p where p > 1.0 so having N messages of 1/N size is a definite advantage and does make it easier to clean up the little messes.

that's assuming the complexity never crosses boundaries, which is why the whole mess analogy falls down.
Post reply on HN