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

31–40 of 567 posts

Re: Monoliths Are the Future

#31

Post by DanielBMarkham »

With respect to the author, who probably is a much smarter person than I am, this is yet another in a long, long series of HN articles that should be grouped under "I don't know what the hell X is, but I was an expert in it, and I can tell you it sucks"

I've seen X be a dozen things: UML, databases, User Stories, Functional Programming, Testing... It's too much to list.

Yes. If you do it that way it will hurt, and you should stop. I don't know this author, but I suspect that many people who jump into microservices are not getting the foundations they need to successful. The idea that microservices are just broken-up monoliths is a big clue. They're spot on about marketing and spend, though. In this community we're quick to hype and sell things to one another whether it's a good idea or not.

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.

Re: Monoliths Are the Future

#33

Post by keithb- »

andy_ppp wrote: post #17
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…

> Reporting on a bunch of different databases is a hard nut to crack. It's not necessarily a bad idea though :-/

I thought that's what solutions like Calcite[1] were for: running queries across disparate data sources. Yes, you still need to have adapters for each source to normalize access semantics. No, not all sources will have the same schema. But if you're trying to combine Postgres and DynamoDB into a single query, you would narrow your view to something that exists in both places, e.g. customer keys, meta data, etc.

Maybe I'm wrong.

[1] https://calcite.apache.org/

Re: Monoliths Are the Future

#34

Post by trey-jones »

So many problems arise from the idea that "we are going to do this thing to the maximum extreme and exclusion of other possibilities."

Just look at the US legislature right now. Anyway, it doesn't have to be Monoliths vs. Microservices. It can be a compromise. Perhaps the microservices are a bit less segmented than we have been imagining. It might be OK for a microservice to do more than one job. As the highlight shows, the fundamental ingredient is Engineering Discipline. If we strive for that it might work out in a Monolith, Microservice, or somewhere in between.

Re: Monoliths Are the Future

#35

Post by eternalny1 »

What is old is new again.

I've been a software engineer for over 30 years and have dealt with companies always trying to jump on the next bandwagon. One company I worked with tried to move our entire monolith application, which was well architected and worked fine, over to a microservices-based architecture and the result was an unstable, complex mess.

Sometimes, if it's not broke, don't try to "fix" it.

I can say the same regarding a lot of what is going on in the JavaScript ecosystem, where people are trying to replicate stuff that works fine in other languages in JavaScript. Mostly because they are only familiar with JavaScript and don't realize this stuff already exists and doesn't need to be in JavaScript.

Re: Monoliths Are the Future

#36

Post by one2know »

Pretty much microservices happened because of managers. Managers are promoted to high level jobs such as Director or VP based on number of direct reports. This won't happen with a small team of devs. So they need an infrastructure team, a devops team, a SRE team, a QA team, a microservices core team, an access management team, network engineering team, AWS integration team, and the list goes on. What was once a four person team is now a 50 person team costing 10 million per year, but, hey, the guy/girl gets his VP promotion for setting all this up.

Re: Monoliths Are the Future

#37

Post by staticassertion »

holoduke wrote: post #3

Designing an application from scratch where pure microservices is implemented is in my opinion the same as over engineering possible future performance issues. Splitting up your application in many services requires a lot of thinking and designing. Challenges with syncing, communication etc are not always easy to deal with. That's why I agree to start as a monolith but with architectural principles to still have mult…

I did this. I built a big service microservice first, with the single caveat that I wrote a local Python version that did everything with fake data in memory first, just to test it out.

I'm very happy with this approach.

> Splitting up your application in many services requires a lot of thinking and designing.

In my experience, you spend a bit of time asking "What does my project do, and how do I decompose it?" and that's about it. The same thing you'd do with a single binary that you decompose into modules.

> Challenges with syncing, communication etc are not always easy to deal with.

Depends on what you're doing certainly. For me, I'm basically doing an ETL and analytics pipeline, so I have no issues there.

I have found it much easier to reason about code and boundaries. I did a ton of experimentation with code and services (I didn't know how to build it when I started, so there was tons of iterationt) and the ability to just rewrite any service fairly trivially helped a ton.

I haven't had to do any "splitting". Merging services is trivial, splitting is not. I'd much rather say "Ah, the synchronization here is too hard, I'll shove it into one process" than "How the hell am I going to scale these two modules separately with all of this shared memory between them?".

I've gone through a "We have to start splitting things for reliability/performance/conway's law" and it's years of very difficult, dangerous work.

It's really a "to each their own" but I don't think I overengineered things at all. Microservices just make sense for my use case.

Re: Monoliths Are the Future

#38

Post by 1MoreThing »

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…

Isn't this the whole point of a data lake?

Re: Monoliths Are the Future

#39

Post by sytse »

At GitLab a couple of years ago we had to fight the temptation to split the application up in hundreds of micro-services.

I'm glad we did and today GitLab has a big monolith but also a ton of services working together https://docs.gitlab.com/ee/development/architecture.html#com...

I did an interview about this yesterday https://www.youtube.com/watch?v=WDqGaPGBZ9Y

Re: Monoliths Are the Future

#40

Post by eof »

As someone in the middle of destroying a monolith I hope the title is not true. Of course distributed-yet-still-deeply-coupled systems are possible they are at least harder to create.

For me though the most important thing is grokability. Our monolith is to a point literally no one on earth can understand the whole thing.

Even if the system is complex, the individual deployables being fully understood by some number of engineers is extremely valuable and drastically reduces search space for the cases where things don’t go as planned

Post reply on HN