Monoliths Are the Future • Hacker News Board

Re: Monoliths Are the Future

#81

Post by Ididntdothis » Thu, Jan 30, 2020, 6:47 PM UTC

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…

“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.”

This 100x. If you aren’t able to maintain a monolith you will most likely mess up microservices too. Every approach has its own set of trade offs and problems. if you know what you are doing you can make things work.

Re: Monoliths Are the Future

#82

Post by peteforde » Thu, Jan 30, 2020, 6:47 PM UTC

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.

The author is a Kubernetes expert, so perhaps you are the student and not the master?

https://github.com/kelseyhightower/kubernetes-the-hard-way

Re: Monoliths Are the Future

#83

Post by one2know » Thu, Jan 30, 2020, 6:47 PM UTC

Perhaps the solution is a single server where one can drop a zip file containing their microservice and have it automatically deploy without the hassle of setting up a new pod/server/container. Congratulations you have reinvented java servlets 1.0 circa 1996.

Re: Monoliths Are the Future

#84

Post by baron816 » Thu, Jan 30, 2020, 6:48 PM UTC

baron816 wrote: post #9

Maybe the title should be “Bad Engineering is the Future”.

I think I need to explain this joke. I don’t mean that Monoliths are bad engineering, just that, as the article suggests, microservices don’t prevent bad engineering. And in many regards are inevitable without the right culture.

Re: Monoliths Are the Future

#85

Post by Udik » Thu, Jan 30, 2020, 6:48 PM UTC

one2know wrote: post #36

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…

I don't know why you were downvoted, the importance of projects (and their leaders) is measured on the team sizes and budgets. So increasing costs makes the project and its leaders more important and valued.

Re: Monoliths Are the Future

#86

Post by iamEAP » Thu, Jan 30, 2020, 6:49 PM UTC

BrentOzar wrote: post #47

1MoreThing wrote: post #38

Earlier quoted context omitted.

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

> Isn't this the whole point of a data lake? Yes, but data lakes don't fill themselves. Each team has to be responsible for exporting every transaction to the lake, either in real time or delayed, and then the reporting systems have to be able to combine the different sources/formats. If each microservice team expects to be able to change their formats in the data lake willy-nilly, bam, there breaks the report again.

This problem exists in monolithic data stores and codebases too. It's not as if independent teams have absolute sovereignty over their table schemas.

Schemas evolve as the needs of the product change, and that evolution will always outpace the way the business looks at the data.

The best way I've seen to deal with this is to handle this at report query-time (e.g. pick a platform that can effectively handle the necessary transformations at query-time, rather than at load-time).

Re: Monoliths Are the Future

#87

Post by tylerjwilk00 » Thu, Jan 30, 2020, 6:49 PM UTC

thrower123 wrote: post #58

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…

I can't imagine your level of cynicism. I've only been at this for ten years, and the number of times I've seen the wheel come full circle and old ideas come back into vogue, the problems with them rediscovered, reactions to those problems, and then the thing that preceded them again take precedence is somewhat depressing. At best I feel like we are grinding ahead a few inches each cycle.

It's like the movie Benjamin Button but with a case of amnesia every three years.

Re: Monoliths Are the Future

#88

Post by davidy123 » Thu, Jan 30, 2020, 6:49 PM UTC

DanielBMarkham wrote: post #63

davidy123 wrote: post #54

Earlier quoted context omitted.

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

You're right, though k8s is often associated with microservices you can deploy a monolith with it. But there's a disconnect where as an expert in associated areas he's saying people aren't doing microservices properly, and you're saying just do them properly.

Re: Monoliths Are the Future

#89

Post by rantwasp » Thu, Jan 30, 2020, 6:50 PM UTC

as always the truth is somewhere in the middle. monoliths make a lot of sense when you're starting out and you can see all your code in one place and you can build, test and deploy everything together. as the service grows there are arguments to be made around splitting it (based on usage patterns, loads, etc).

the things that most people don't get is that: microservices are not free (now you're doing all this devops stuff N times and you have to think long and hard about changes that need to happen across api boundaries). The anti-pattern is that you take your monolith and you split it in 10 but apart from actually doing all this work you still treat it as a monolith (ie you still do mono-repo because it's convenient, the deployment still happens at the same time for all services, you centralize everything when it comes to logging and metrics and you even force people to do things in a certain way when it comes to their service). Everything grinds to a halt and now you're more concerned about "growing" the team to fix the issues that popped up and maybe chasing the new shiny thing to keep your resume up-to-date. Even worse people start feeling like they "own" their service and now the decisions that are made are maybe locally optimal but who cares about global optimization.

So my take is: start with a monolith and in 85% of the cases you'll be just fine forever. you don't need all the bells and whistles to get the job done. Introduce new things only so solve actual pain-points and when you do actually thing through what it means to introduce them (so go N->N+1 and never 1->N)

Re: Monoliths Are the Future

#90

Post by speleding » Thu, Jan 30, 2020, 6:50 PM UTC

BrentOzar wrote: post #45

gowld wrote: post #26

Earlier quoted context omitted.

Build a reporting database that maintains a copy of data from other data stores. Simple enough. Surely you wouldn't run analytics directly on your prod serving database, and risk a bad query taking down your whole system?

> Surely you wouldn't run analytics directly on your prod serving database, and risk a bad query taking down your whole system? Uhh, yep, that's exactly how a lot of businesses work. There are defenses at the database layer. For example, in Microsoft SQL Server, we've got Resource Governor which lets you cap how much CPU/memory/etc that any one department or user can get.

That's not a good idea. The usage patterns for a production database and one that runs reporting are very different. Reporting has long running queries with complex joins, production has many parallel short queries. If you start mixing the two, you can no longer reliably tune your database. For example you would want the alert for slow queries set set to a different time out on production and on reporting.

Also, you complicate locking down access to the database. A reporting database can typically contain less sensitive info, reporting would not have password (hashes) for user accounts for example.