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

61–70 of 567 posts

Re: Monoliths Are the Future

#61

Post by kizer »

erikpukinskis wrote: post #55
eternalny1 wrote: post #35

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

Agree with your last point. And as someone who really liked old school callback/prototype/closure based JavaScript, I can say not only would these people have been better off using a better language, they also ruined JavaScript for the things it was great at.

You can still do all that in JS, novel syntactic sugar aside.

Re: Monoliths Are the Future

#62

Post by wvenable »

DanielBMarkham wrote: post #31

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

Yes, the problem is that all these things are sold as magic bullets -- or worse -- that you current solution is sold as obsolete garbage. The word "monolith" has a negative connotation so obviously you can't have that and so you need something else.

When microservices started to catch on, it was just a name given to a really good solution to a specific problem. And there are plenty of problems for which creating an independent service is a great way to manage both technological and organizational issues. But it doesn't just magically solve those issues -- you can't apply that model to everything just because -- it has to fit the problem space.

I had a conversation on Reddit with a developer whose application had over 3,000 independent micro-services. He was very proud of this solution. But I can't imagine that could be anything but a monolith with function calls replaced with network I/O.

Re: Monoliths Are the Future

#63

Post by DanielBMarkham »

davidy123 wrote: post #54
DanielBMarkham wrote: post #31

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

Kelsey Hightower is a rather pivotal person in the Kubernetes world. It's unusual that he's basically cautioning people not to use the system he's so involved in. His point is that many people are doing microservices wrong

Kubernetes is a deployment strategy. It should be orthogonal to microservices.

I'll delete the comment if I was unnecessarily cruel or missed the sarcasm. It was not intentional. But it is important to understand that you want to think of persistence and deployment coupling as independently of your microservices strategy as possible. The vast majority of problems we see with people implementing microservices is people carrying baggage over from some previous project or pet technology. K8S's great. It's just not relevant here.

Re: Monoliths Are the Future

#64

Post by andrew_n »

DanielBMarkham wrote: post #31

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

A typical UML-bashing article/comment doesn’t suggest some potentially superior alternative, but takes the “everything is awful” stance.

The text of the article reads in that same vein, but given that the title is “Monoliths are the Future” I think the author’s original intent was to describe the advantages of monoliths and point out that microservices have advantages only in relatively rare cases. Too bad they made the article about microservices instead of monoliths.

Sounds to me like a good opportunity for the author to write a followup post.

Re: Monoliths Are the Future

#65

Post by MockObject »

eternalny1 wrote: post #35

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

It used to be that people wrote Fortran in any language. Now they're rewriting Java in every language.

Re: Monoliths Are the Future

#67

Post by bdcravens »

davidy123 wrote: post #54
DanielBMarkham wrote: post #31

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

Kelsey Hightower is a rather pivotal person in the Kubernetes world. It's unusual that he's basically cautioning people not to use the system he's so involved in. His point is that many people are doing microservices wrong

I think Kubernetes can be used well with monoliths that are actually more monorepos. You keep the code and dependencies in one place, and then use the service definitions within your cluster to define your boundaries. (Imagine an application where your front end, back end, and background workers all share some objects, but not all of them)

Re: Monoliths Are the Future

#69

Post by ChrisMarshallNY »

I think it depends on the application.

Some are best served with aggregates; some with monoliths.

For myself, I have always developed in a "layered," and "modular" manner, with discrete subprojects; each, given its own configuration management and lifecycle. The resultant applications tend to be "monolithic," but some are parts of a larger, loosely-connected architecture.

Works for me, but YMMV.

Re: Monoliths Are the Future

#70

Post by DanielBMarkham »

wvenable wrote: post #62
DanielBMarkham wrote: post #31

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

Yes, the problem is that all these things are sold as magic bullets -- or worse -- that you current solution is sold as obsolete garbage. The word "monolith" has a negative connotation so obviously you can't have that and so you need something else. When microservices started to catch on, it was just a name given to a really good solution to a specific problem. And there are plenty of problems for which creating an i…

Yes. It wouldn't surprise me if it's reached the point where 90%+ of people saying they're doing microservices are making disasters. There's just so much stuff you have to un-learn, and that's uncomfortable.

I consulted with a team last year that was moving to microserivces. They bought BigToolX and had already created a disaster ... and they weren't even through their design. Most all of what they were doing was just best practices in some other paradigm. It was painful.

Whenever I fall in love too much with a technology, I get paranoid. There's usually something I'm missing.

Post reply on HN