Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You Don't Need Microservices

medium.com

Post reply on HN
Print view View original

41–50 of 169 posts

Re: You Don't Need Microservices

#41

Post by jacquesm »

foobarian wrote: post #32
jacquesm wrote: post #29

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

When I see a service around every single table in a database with an absolutely ridiculous spaghetti of inter-process communication to tie it all together it usually is because someone took the 'services' pattern a bit too far and in that case 'microservices' is a proper moniker. And for Erlang based systems it usually is also appropriate. If there are fewer than 10 or so services usually they are not 'microservices' but just services.

Re: You Don't Need Microservices

#43

Post by kkapelon »

tlonny wrote: post #16
goncalo-r wrote: post #3

Aren't microservices nice because they allow you to have different teams own different parts of the code and minimize the communication overhead?

This can be accomplished using a modular monorepo. Different teams simply manage different directories or modules of the same repo. Breaking up an app into microservices is total overkill in this instance...

This doesn't cover independent deployments.

Microservices allow team A to deploy their component, while team B are just writing code. Then team B deploys their own component and while team A is at the bar.

Re: You Don't Need Microservices

#44

Post by honkycat »

DoneWithAllThat wrote: post #34

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.

There are a lot of small shops who aren't dealing with scale, and assume that what works for them works for everyone.

Personally, I think micro-services should be approached very carefully but I understand the idea of them.

Re: You Don't Need Microservices

#45

Post by akoumjian »

Self-promoting a little utility I wrote that helps guide teams on whether your service boundary is a good idea: https://mulch.dev/service-scorecard/

The service scorecard asks a bunch of reflective questions about the ramifications of making some set of functions a unique service and points its benefits or lack thereof on a scale.

Re: You Don't Need Microservices

#46

Post by tomtheelder »

revskill wrote: post #17

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 microservices than to a decently organized monolith.

I would only seriously consider a move to microservices for deployment/perf reasons.

Re: You Don't Need Microservices

#47

Post by EGreg »

As someone who has built a monolith, full-stack (literally everything from MySQL to PHP+Node.js to the Web to Cordova) platform at https://qbix.com/platform I can still tell you, that microservices are great. But the average person isn't going to fine-tune all those microservices. They need to install something that just works out of the box. An expert can be hired to fine-tune some parts of the stack (e.g. add a CDN or varnish cache) and not others. The layers (e.g. database, file system) already are separated and cloud services like Amazon can even scale them automatically (e.g. Aurora or Lambda).

The main problem isn't microservices, it's control and interoperability. Facebook decides it wants to turn into TikTok? Too bad for all its users, it'll happen. "Relax, breathe, we hear you" is what Zuck said to all his outraged users after the first big rollout of newsfeed. Then a lot of scandals later (beacon, etc.) they are still at it. Google sunset Reader just like that. People are HOPING that Elon Musk adds a feature to Twitter. This is crazy.

Host stuff yourself, and not in the cloud. And for that, we need people to be able to "just install" something, like a Wordpress 5 min install on a hosting company.

I don't want to make this comment long, so anyone who wants to read the full thesis can see it here: https://qbix.com/blog/2021/01/15/open-source-communities/

Re: You Don't Need Microservices

#48

Post by DJBunnies »

DoneWithAllThat wrote: post #34

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 think that all the time.

Or more specifically, "I wish these services were a monolith so we could have better type checks/easier logging/debugging."

Re: You Don't Need Microservices

#49

Post by aarondf »

upupandup wrote: post #38
aarondf wrote: post #9

I wrote a library [1] for Laravel that lets you put a kind of "microservice" inside of your monolith. It lets you develop, deploy, and execute AWS Lambda functions from your Laravel application. The theory here is that sometimes you need some other language/infrastructure beyond what you're comfortable devops-ing yourself, and Lambda is actually quite good at providing you with an entire stack of stuff you don't have…

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 Sidecar admin keys, it configures all the permissions, roles, etc, and then self-destructs the admin keys. So you don't have to muck around with anything at all.

> also curious how yours also differ from the paid Laravel solution that lets you deploy your stack serverless.

Sidecar deploys and executes _non-PHP_ functions from your Laravel app. So it's completely different. Vapor deploys your whole app and runs it on Lambda, I just deploy single functions at a time.

Post reply on HN