Live data from Hacker News

You Don't Need Microservices

medium.com

81–90 of 169 posts

Re: You Don't Need Microservices

#81
Some people will make an incoherent mess out of anything.

A garbled knot of interdependent microservices with timing issues, bad extensibility, and unpredictable flow.

An ornate matroyshka set of wrapper functions calling each other spreading over multiple directories making any modification a large error prone effort.

Event systems, probably multiple, without any real difference between just a function call other than your debugger getting very confused by it.

Database schemas with table names that exude the narcissism of small differences with nitpicky rules that make it explode if any flexibility is demanded

Aws bill that's 10x more than any reasonable expectation given the problem set.

An object oriented design that looks like some kind of fetishized exercise of every feature possible, where defects cascade to action at a distance and unintended consequences with tight coupling that can't be extricated leading to a rewrite, just like it did last time

They are the people who create the waterfall of dozens of levels of div tags for no functional reason other than to accommodate their incompetency

They are the ones that want to pollute your entire day with needless meetings over irrelevant things that will not be acted upon.

Of course there's no useful comments or tests or documentation. The git comment messages are single words like "fix" and "rewrite". There's no versions in the deploy or a reasonable approach to logging that allows a successful audit and the thing is too state dependent to reproduce bugs.

Then there's dependencies, loads of them just picked seemingly at random, written by people who think like them with the same disregard for documentation, compatibility or testing. But they have very pretty websites which says they're painless, simple and easy, so I guess it's all ok right?

The problem with microservices is the same problem with anything else and changing paradigms won't fix it. The approach needs to change, not the technique. It's a different kind of budo.

Re: You Don't Need Microservices

#82

Earlier quoted context omitted.

Just 'services' will do. A couple of them tied together with a single front is >> a monolith.

I find it pretty entertaining how the word "microservices" got to mean what we used to mean by "services" or "web services." It has not referred to size in the npm "left-pad" sense at all for a long time now. I feel that the battle is lost at this point, kind of like the battle for the meaning of "hacker."

I think there's a lot of historical accident involved. Personally, my experience of the two terms was that I heard about "services" aka "SOA" first, and it meant a top-down global architecture where the pieces were composed in elaborate, cumbersome ways: service buses, orchestrators, complicated XML-based technologies, service discovery, remote transactions, all that fancy stuff that many people tried and few people ever got working correctly. People were talking about integrating a new service to your architecture by dragging and dropping widgets in an orchestration dashboard generated from XML descriptors published by the services, and it was the kind of thing that blew your mind for a few seconds until you realized it was obviously never going to work.

Then I heard about "microservices," and the people using that term were talking about JSON and HTTP and DNS, stuff you could actually imagine working, and then you tried it and you actually could get it working with almost no effort, which was mind-blowing in a different and better way.

That difference was a historical accident based on where those terms were in the hype cycle. Now a lot of definitions of "microservices" describe architectures that are almost as elaborate as the old SOA ideas I was exposed to, and people have the same reaction I did to "services" back then. And now it's the supposed microservices experts who will tell you that if you did anything simple enough that you actually got it working in less than six months with less than fifty people, then you did it wrong and doomed your company. The hype cycle has made a complete turn.

Re: You Don't Need Microservices

#83
post #18

One of the benefits of being in this industry for a while is that you learn to spot and avoid fads. You even learn classes of fads. Microservices instantly looked like a fad. Two classes of fad apply. One is a "move stuff around and complexity will magically go away" fallacy fad. The other is a "way to promote vendor lock-in or higher cost" fad. Other major classes of fads are: consultant self promotion fads, re-inve…

> actually practical and useful provably-safe language (Rust).

You can have spatial and temporal memory safety by writing single threaded code in any GC language.

Re: You Don't Need Microservices

#84
post #49

Earlier quoted context omitted.

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

Correct, no API gateway.

> Not sure how useful this is since that is the entry point for all the lambda functions.

Well that's just not accurate! You can also call them via API. Which is what Sidecar does.

> I just don't see why I would need to use PHP for this.

Because you're already using Laravel! If you're not using Laravel, you wouldn't use this.

If you want to see me doing a live-demo of this at a conference, it might make a bit more sense: https://youtu.be/0Rq-yHAwYjQ?t=11751

Re: You Don't Need Microservices

#85

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

Firmly disagree. Microservices get you very little in terms of code quality enforcement past what you would get with a well modularized monolith, and they introduce a lot of code quality & architectural pitfalls. I think going microservices to enforce boundaries and decoupling is a very bad idea that will create far more trouble than its worth. I'd be a lot more scared of my junior devs committing code to microservic…

You might misunderstand the point here.

It's about how to keep the velocity without firing junior dev, without removing bad code from the production system.

So microservice is a leadership tool to manage it. Keep it in control.

Re: You Don't Need Microservices

#86
post #71
post #59

Earlier quoted context omitted.

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

He didn't label it as "news", it was an opinion. Regardless if it was said before, who cares? He's not allowed to speak on his experiences because it offends your MO?

I think the opinion he had was justified by his own experiences, which mimic my own - and many of those working at smaller agencies/dev shops (you know, the vast majority of the workforce). It was nice to read something not entirely in the perspective of a Silicon Valley developer drunk on his own ignorance of the rest of the world.

Re: You Don't Need Microservices

#87
post #86
post #71

Earlier quoted context omitted.

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

He didn't label it as "news", it was an opinion. Regardless if it was said before, who cares? He's not allowed to speak on his experiences because it offends your MO? I think the opinion he had was justified by his own experiences, which mimic my own - and many of those working at smaller agencies/dev shops (you know, the vast majority of the workforce). It was nice to read something not entirely in the perspective o…

Check out my comment history and you’ll see that I agree with the points too! But the bar for a good Hacker News post is “interesting”. Opinions that are widely agreed with on here, and have been for years, don’t meet that for me personally. That’s my say on the matter, you of course are welcome to yours.

For what it’s worth, I live in the UK, and have never been to the US.

Re: You Don't Need Microservices

#88

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.

Same. I keep hearing that people have had bad experiences with microservices, but I'm not sure what those bad experiences are. I certainly don't relate to them. We had a monolith, and it devolved into a mess--managers would insist on people taking dependencies on stuff they didn't own in the name of expedience ("yeah, we'll totally circle back and do it the right way lol"). Microservices kept things neat by making du…

Microservices suck when you need to make a process faster, so you run a profiler and figure out that 90% of the workload is handling the http requests between the services.

Re: You Don't Need Microservices

#89
post #87
post #86

Earlier quoted context omitted.

He didn't label it as "news", it was an opinion. Regardless if it was said before, who cares? He's not allowed to speak on his experiences because it offends your MO? I think the opinion he had was justified by his own experiences, which mimic my own - and many of those working at smaller agencies/dev shops (you know, the vast majority of the workforce). It was nice to read something not entirely in the perspective o…

Check out my comment history and you’ll see that I agree with the points too! But the bar for a good Hacker News post is “interesting”. Opinions that are widely agreed with on here, and have been for years, don’t meet that for me personally. That’s my say on the matter, you of course are welcome to yours. For what it’s worth, I live in the UK, and have never been to the US.

I implore you to watch the incessant, and regular posts on HN claiming that microservices are the future for everyone and everything, and then be there to tell them you've seen this before. My guess is you won't be as lead-footed in those cases. The idea that if you write an article or an opinion, and have to do an hour of research to see if its been covered before is a high level of micromanagement that you just aren't ever going to see, I'm sorry. It's super unrealistic to expect that.

Re: You Don't Need Microservices

#90

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

I would think that junior level developers are usually walking into an architecture put together by leads/seniors? Juniors should be coming into a well-architected monolith that they can be productive in, if they can’t that’s kinda on the senior staff…
Post reply on HN