Live data from Hacker News

You want microservices, but do you need them?

docker.com

91–100 of 151 posts

Re: You want microservices, but do you need them?

#91

I don't want or need microservices. What I want is for people to stop putting TCP roundtrips in between what would otherwise be simple function calls in a sane universe. I don't want to have to take a graduate-level course on the CAP theorem to clock in and work on whatever "Uber for dogs" nonsense is paying my rent. You almost certainly don't have a scaling problem that necessitates a distributed system, I guarantee…

> I don't want to have to take a graduate-level course on the CAP theorem

It would be a blessing if people actually did that, because then they'd avoid useless distributed systems.

> using gRPC to poorly and unnecessarily communicate

At least you've had the blessing of it being gRPC and not having to manually write JSON de/serializers by hand.

> Kubernetes isn't doing anything your operating system can't do

Kubernetes is good if you need to orchestrate across multiple machines. This of course requires an actual need for multiple machines. If you're doing so with underpowered cloud VMs (of which you waste a third of the RAM on K8s itself), just get a single bigger VM and skip K8s.

Re: You want microservices, but do you need them?

#92
post #84

It is not so black and white. The BEAM ecosystem (Erlang, Elixir, Gleam, etc) can do distributed microservices within a monolith. A single monolith can be deployed in different ways to handle different scalability requirements. For example, a distinct set of pods responding to endpoints for reports, another set for just websocket connections, and the remaining ones for the rest of the endpoints. Those can be independ…

> The BEAM ecosystem (Erlang, Elixir, Gleam, etc) can do distributed microservices within a monolith. This ain't new. Any language supporting loading modules can give you the organization benefit of microservices (if you consider it a benefit that is - very few orgs actually benefit from the separation) while operating like a monolith. Java could do it 20+ years ago, just upload your .WAR files to an application serv…

> Java could do it 20+ years ago, just upload your .WAR files to an application server.

Erlang could do it almost 40 years ago.

It can be used to upgrade applications at runtime without stopping the service. That works well in Erlang, it’s designed from the ground up for it. I know of a few places that used that feature.

Re: You want microservices, but do you need them?

#93

Earlier quoted context omitted.

That's the most nonsensical reason to adopt microservices imo. Consider this: every API call (or function call) in your application has different scaling requirements. Every LOC in your application has different scaling requirements. What difference does it make whether you scale it all "together" as a monolith or separately? One step further, I'd argue it's better to scale everything together because the total breat…

At this point, I'm convinced that too many people simply haven't built software in a way that isn't super Kubernetes-ified, so they don't know that it's possible. This is the field where developers think 32 GB of RAM isn't enough in their laptop, when we went to the moon with like... 4K. There is no historical or cultural memory in software anymore, so people graduate not understanding that you can actually handle 10…

Many developers started their career during the ZIRP era where none of the typical constraints of "engineering" (cost control, etc) actually applied and complexity & high cloud bills were seen as a good thing, so no wonder.

Re: You want microservices, but do you need them?

#94
post #84

It is not so black and white. The BEAM ecosystem (Erlang, Elixir, Gleam, etc) can do distributed microservices within a monolith. A single monolith can be deployed in different ways to handle different scalability requirements. For example, a distinct set of pods responding to endpoints for reports, another set for just websocket connections, and the remaining ones for the rest of the endpoints. Those can be independ…

> The BEAM ecosystem (Erlang, Elixir, Gleam, etc) can do distributed microservices within a monolith. This ain't new. Any language supporting loading modules can give you the organization benefit of microservices (if you consider it a benefit that is - very few orgs actually benefit from the separation) while operating like a monolith. Java could do it 20+ years ago, just upload your .WAR files to an application serv…

I mean sure but one could also argue that VB6 can do the same analogue of Java so long as ASP is involved... And yes I've seen it done; you have a basic interface similar to an actor, but really more like a 'Take a key-value in for input, do processing on it, return a key-value to go to the next stage' and then the other necessary glue to handle that. The way the glue worked, it was minimal ceremony to get a new module in.

NGL It was clever enough that every few years I think about trying to redo the concept in another language....

Re: You want microservices, but do you need them?

#95
post #36

You need multiple services whenever the scaling requirements of two components of your system are significantly different. That's pretty much it. These are often called micro services, but they don't have to actually be "micro"

I came here to say the same. If you’re arguing either for or against microservices you’re probably not thinking about the problem correctly. Running one big service may make sense if your resource needs are pretty uniform. Even if they’re not you need to weight the cost of adding complexity vs the cost of scaling some things prematurely or unnecessarily. Often this is an acceptable precursor to splitting up a process…

You can still horizontally scale a monolith and distribute requests equally or route certain requests to certain instances; the only downside is that those instances would technically waste a few hundred MBs of RAM holding code for endpoints they will never serve; however RAM is cheap compared to the labor cost of a microservices environment.

Re: You want microservices, but do you need them?

#96

I would really like to send this article out to all the developers in my small company (only 120+ people, about 40 dev & test) but the political path has been chosen and the new shiny tech has people entranced. What we do (physics simulation software) doesn’t need all the complexity (in my option as a long time software developer & tester) and software engineering knowledge that splitting stuff into micro services re…

IMO, Engineering mindset is a huge challenge when it comes to 'do you do microservices'

And by that, I mean that I have at times seen and/or perhaps even personally used as a cudgel - "This thing has a specific contract and it is implicitly separate and it forces people to remember that if their change needs to touch other parts well then they have to communicate it". In the real world sometimes you need to partition software enough that engineers don't get too far out of the boundaries one way or another (i.e. changes inadvertently breaking something else because they were not focused enough)

Re: You want microservices, but do you need them?

#97
post #65

On the theme of several other responders: I don't want microservices; I want an executable. Memory is shared directly, and the IDE and compiler know about the whole system by virtue of it being integrated.

Probably works OK for a small project with a close knit team of skilled contributors where there's some well defined structure and everyone has sufficient high level understanding of that structure to know what kinds of dependencies are or are not healthy to have. But, unless you have some way of enforcing that access between different components happens through some kind of well defined interfaces, the codebase may…

> through some kind of well defined interfaces

Every compiled language has the concept of "interfaces", and can load even compiled modules/assemblies if you insist on them being built separately.

The compiler will enforce interface compliance much better than hitting untyped JSON endpoints over a network.

Re: You want microservices, but do you need them?

#98
post #59
post #14

in my opinion "you need microservices" peaked around 2018-2019 ... does nowadays someone think that, apart from when you reach certain limits and specific contexts, they are a good idea?

Half of the jobs I'm applying to have microservices in the description, much more often than, say, REST or Boot, so somebody definitely thinks they're a general solution to something.

Microservices is an excellent generator for developer busywork and increased headcount. Busywork benefits the developers, increased headcount benefits their manager, and so on.

Re: You want microservices, but do you need them?

#99
post #92

Earlier quoted context omitted.

> The BEAM ecosystem (Erlang, Elixir, Gleam, etc) can do distributed microservices within a monolith. This ain't new. Any language supporting loading modules can give you the organization benefit of microservices (if you consider it a benefit that is - very few orgs actually benefit from the separation) while operating like a monolith. Java could do it 20+ years ago, just upload your .WAR files to an application serv…

> Java could do it 20+ years ago, just upload your .WAR files to an application server. Erlang could do it almost 40 years ago. It can be used to upgrade applications at runtime without stopping the service. That works well in Erlang, it’s designed from the ground up for it. I know of a few places that used that feature.

Erlang seems like a joy to use. I feel a slight pang of regret that I haven't (yet) gotten to use it in my career. (I don't quite have the time or energy to play with it during my off hours, but it is on my list for someday.)

Re: You want microservices, but do you need them?

#100

Earlier quoted context omitted.

That's the most nonsensical reason to adopt microservices imo. Consider this: every API call (or function call) in your application has different scaling requirements. Every LOC in your application has different scaling requirements. What difference does it make whether you scale it all "together" as a monolith or separately? One step further, I'd argue it's better to scale everything together because the total breat…

At this point, I'm convinced that too many people simply haven't built software in a way that isn't super Kubernetes-ified, so they don't know that it's possible. This is the field where developers think 32 GB of RAM isn't enough in their laptop, when we went to the moon with like... 4K. There is no historical or cultural memory in software anymore, so people graduate not understanding that you can actually handle 10…

You’re focusing on the theoretical and ignoring cost. That’s incompetent engineering.
Post reply on HN