Live data from Hacker News

You Don't Need Microservices

medium.com

71–80 of 169 posts

Re: You Don't Need Microservices

#71
post #59
post #37

I’d argue bashing microsevices is more in vogue than microservices themselves. They’ve reached that point on the hype cycle where you can get a whole bunch of likes by saying “microservices bad amirite?!”

That wasn't the argument that was being made. Do you have commentary on the content of the article, or just that you don't like that he had a non-party line opinion?

Nothing in the article is fresh news. Sam Newman made many of these same points himself in his 2015 book on microservices.

The article does _not_ discuss why engineering teams ignore that advice.

Companies see microservices as a silver bullet for solving complexity. Inexperienced engineers attracted to shiny things jump on the bandwagon. Vendors sell tooling to deal with the new complexity. But in that case, if it wasn’t microservices, it would be OOP, FP, SPAs, RPC, RDBMS, NoSQL, etc. The problem is the hype cycle. Over-use of microservices is only a symptom.

Re: You Don't Need Microservices

#72

Microservice is to manage junior level programmers who don't know how to make loosely coupling architecture. That's it. Because your job is to manage low quality code produced by junior devs, you need to use microservice to prevent bad code to break the monothlic. Edit: For more context, this opinion is more about "the art of developer management", not much about infra, security, scalability stuff

Adding in a machine boundary does not guarantee loose coupling. If a dev does not have the skills to make a loosely coupled monolith, how they can they suddenly have the skills to make a collection of loosely coupled services running on more machines? That same low skilled dev is going to have to deal with a lot of other complexities now...

Re: You Don't Need Microservices

#73

Microservice is to manage junior level programmers who don't know how to make loosely coupling architecture. That's it. Because your job is to manage low quality code produced by junior devs, you need to use microservice to prevent bad code to break the monothlic. Edit: For more context, this opinion is more about "the art of developer management", not much about infra, security, scalability stuff

Adding in a machine boundary does not guarantee loose coupling. If a dev does not have the skills to make a loosely coupled monolith, how they can they suddenly have the skills to make a collection of loosely coupled services running on more machines? That same low skilled dev is going to have to deal with a lot of other complexities now...

The point is, to keep the sprint in velocity, let's just keep the bad code (tech debt), but make sure it won't break the quality of original system. By extracting "bad parts" into its own system, you can manage it efficiently.

Re: You Don't Need Microservices

#74
post #37

I’d argue bashing microsevices is more in vogue than microservices themselves. They’ve reached that point on the hype cycle where you can get a whole bunch of likes by saying “microservices bad amirite?!”

Most of the real world "microservices" usage outside of FAANG has been to legitimize polyglot development (a net negative for most organizations) and the to create heretofore unseen levels of Conway's law. A microservice per person? Sure, why not? It's madness. The solution is to avoid the polyglot issue by fiat and to ensure that there is some actual planning and rationale around when it makes sense to add a service…

A crypto exchange has bragged about having 30ish microservices per engineer. It's pretty wild.

Re: You Don't Need Microservices

#75
post #37

I’d argue bashing microsevices is more in vogue than microservices themselves. They’ve reached that point on the hype cycle where you can get a whole bunch of likes by saying “microservices bad amirite?!”

Most of the real world "microservices" usage outside of FAANG has been to legitimize polyglot development (a net negative for most organizations) and the to create heretofore unseen levels of Conway's law. A microservice per person? Sure, why not? It's madness. The solution is to avoid the polyglot issue by fiat and to ensure that there is some actual planning and rationale around when it makes sense to add a service…

I agree. There’s a whole cohort that seems to think you should introduce IO between every function call. But they’re not “managing complexity”, they’re just shifting it into the operational layer, where it’s harder and more expensive to run, debug, secure, etc.

Re: You Don't Need Microservices

#76

Microservice is to manage junior level programmers who don't know how to make loosely coupling architecture. That's it. Because your job is to manage low quality code produced by junior devs, you need to use microservice to prevent bad code to break the monothlic. Edit: For more context, this opinion is more about "the art of developer management", not much about infra, security, scalability stuff

Code quality is only one reason to use microservices; deployment frequency is another (you want people to be able to deploy their service without needing to coordinate with every other service in the system).

Moreover, code quality isn't just encumbered by junior devs--in fact, in my experience it's more often managers pressuring developers to take shortcuts (e.g., taking a dependency on another system's private internals in the name of expedience, while swearing up and down that we will totally clean it up in a future iteration) or other organizational hurdles that make it difficult/impossible to fix it the right way, so shortcuts are taken instead (with microservices, the organization has to confront those issues, they can't be easily papered over by bypassing official interfaces).

Another reason to prefer microservices is security--not putting every secret in a single process's memory space is a great way to minimize blast radius if a service is compromised.

Another reason is reliability--if one system has a catastrophic failure mode, it won't take out all other systems. Of course, if the failing system is a core service, then it may not matter, but at least you're not bringing everything down when some service on the architectural periphery goes haywire.

Re: You Don't Need Microservices

#77

I’ve worked for decades now as both a developer and an SRE and have never once thought either “man I wish these microservices were monolithic” nor “man this monolith is so great I’m glad it’s not a collection of microservices”. These kinds of articles seem to be written for people who work in environments I’ve never even heard of let alone experienced.

I've seen the degenerate states of both extremes: - a monolith with too many engineers contributing: no continuous deployment but rather "release day," which was a shitshow; said day was an extensive process where hundreds of engineers (anybody who was on git blame) had to be online and sitting by for four hours while it rolled; the release team often had to hand-revert bad patches; bullying of engineers who "broke t…

No post body was provided.

Re: You Don't Need Microservices

#78
post #49

Earlier quoted context omitted.

The problem I find with these plugin serverless is that they rarely work well. Even with a framework produced by Chalice, there are issues that are largely so minor in detail but required to work well with AWS. Often they are not even code related but infrastructure. IMHO, AWS Chalice remains the goto method to generate REST API serverless manner but also curious how yours also differ from the paid Laravel solution t…

> IMHO, AWS Chalice remains the goto method to generate REST API serverless manner Sidecar (my library) provides no REST API. You just... call the function from PHP. So you'd call it like 'bar']); And that would run the function _on Lambda._ Whether that function is JS, Ruby, Python, whatever. With Sidecar, you never have to configure anything in the AWS console, besides the initial IAM configuration. You give Sideca…

So it doesn't configure API gateway? Not sure how useful this is since that is the entry point for all the lambda functions.

If I want to create functions easily I would just use pure functions in Chalice

@app.lambda_function(name='MyFunction') def myfunc: return 'OK'

and then I could go into MyFunction and modify the code. I just don't see why I would need to use PHP for this.

Re: You Don't Need Microservices

#79
post #69

Earlier quoted context omitted.

It's not a service for every DB activity; this is a fundamental misunderstanding about what microservices are, how to use them, etc so of course you're going to have a bad time with them. :)

Yes let's make every function call its own service with monitoring, a database, the network stack, management, and so on and then enjoy wonderful performance and easy management

That doesn't seem advisable. Maybe you should try microservices instead?

Re: You Don't Need Microservices

#80
post #37

I’d argue bashing microsevices is more in vogue than microservices themselves. They’ve reached that point on the hype cycle where you can get a whole bunch of likes by saying “microservices bad amirite?!”

That's true for all ideas. A lot of people, especially smart people, like going "everyone says X, I'm going to try to appear smart by arguing not-X". And that's how you end up with people in the west going "Russia is the victim of the war in Ukraine! Nato encroachment!", or "they haven't tested the vaccines!"

I’d argue that’s being contrarian - taking an opposing stance just for attention seeking.

This is more like “the trough of disillusionment” on the hype cycle. You’ve suffered so much at the hands of microservices, you want to convince everyone else not to use them. Lots of others have suffered similarly, so thanks to confirmation bias, your post gets lots of likes based on the sentiment.

Post reply on HN