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

The costs of microservices (2020)

robertovitillo.com

Post reply on HN
Print view View original

241–250 of 410 posts

Re: The costs of microservices (2020)

#241

Post by john-tells-all »

Monoliths are so much easier to test and deploy!

Even if one service needs to be developed separately, it can still live in the monolith. For dev, it's easier to test. For production, deploy the same monolith but have it only handle a single service, depending on how it's deployed. You get all the benefits of a monolith while a little benefit of separate services.

Microservices are okay, but "kick up" a lot of issues that can be slow/awkward to solve. Testing being the big one. If the business decides it's worth the exponential complexity then that's fine.

Re: The costs of microservices (2020)

#242

Post by TeMPOraL »

arzke wrote: post #14
nevinera wrote: post #3

The right time to extract something into a separate service is when there's a problem that you can't tractably solve without doing so. Increasing architectural complexity to enforce boundaries is never a solution to a lack of organizational discipline, but midsize tech companies _incessantly_ treat it like one. If you're having trouble because your domains lack good boundaries, then extracting services _is not going…

"The last responsible moment (LRM) is the strategy of delaying a decision until the moment when the cost of not making the decision is greater than the cost of making it." Quoted from: https://www.oreilly.com/library/view/software-architects-han...

Still trying to unlearn that one. Turns out, most decisions are cheap to revert or backtrack on, while delaying them until Last Responsible Moment often ends in shooting past that moment.

Re: The costs of microservices (2020)

#243

Post by Gluber »

Every company i have advised jumped on the microservice bandwagon some time ago.... Here is what I tell them:

1. Microservices are a great tool... IF you have a genuine need for them 2. Decoupling in and on itself with services it not a goal 3. Developers who are bad at writing proper modular code in a monolithic setting will not magically write better code in a Microservice environment.. Rather it will get even worse since APIS ( be it GRPC, Restful or whatever ) are even harder to design 4. Most developers have NO clue about consistency or how to achieve certrain gurantees in a microservice setting ( Fun fact: My first question to developers in that area is: Define your notion of consistency, before be get to the fun stuff like RAFT or PAXOS) 5. You don't have the problems where microservices shine ( e.g banks with a few thounsands RPS ) 6. Your communication overhead will dramatically increase 7. Application A that does not genuinly need microservices will be much cheaper as a monolith with proper code seperation

Right now we have generation of developers and managers who don'T know any better, and just do what everybody else seems to be doing: Microservices and Scrum ... and then wonder why their costs explode.

Re: The costs of microservices (2020)

#244

Post by stavros »

ph4evers wrote: post #227

I still don’t fully understand what makes something a monolith. For example, I have a big app which is serving 90% of the API traffic. I also have three separate services, one for a camera, one to run ML inference, and one to drive a laser welding process. They are split up because they all need specific hardware and preferably a separate process (one per gpu for example). Is this a monolothic app or a micro service…

> Is this a monolothic app or a micro service architecture?

Yes.

To be less facetious, the continuum goes from "all the code in a single process" to "every line of code is a separate service". It's not either-or.

Re: The costs of microservices (2020)

#245

Post by SanderNL »

ph4evers wrote: post #227

I still don’t fully understand what makes something a monolith. For example, I have a big app which is serving 90% of the API traffic. I also have three separate services, one for a camera, one to run ML inference, and one to drive a laser welding process. They are split up because they all need specific hardware and preferably a separate process (one per gpu for example). Is this a monolothic app or a micro service…

I tend to call these things “distributed monoliths” assuming the camera, ML and laser driver are integral to the functionality of the system.

There is no hard rule that I know of but my heuristic is something like “can I bring instances up and down randomly without affecting operations (too much)”. If so, I’d call that a microservice(ish) architecture.

The waters have been muddied though. Microservices were IMO once associated with Netflix-like scalability, bringing up and down bunches up “instances” without trouble. But nowadays what used to be good old service-oriented architecture (SOA) tend to be also called microservices.

SOA can also be about scalability, but it tended to focus more on how to partition the system on (business) boundaries. I guess like you did.

It’s all a bit muddy in my experience.

Re: The costs of microservices (2020)

#246

Post by wnolens »

hu3 wrote: post #189
wnolens wrote: post #123

If a monolith is well-factored, what is the difference between it and co-located microservices? Probably just the interface - function calls become RPC. You accept some overhead for some benefits of treating components individually (patching!) What is the difference between distributed microservices v.s. co-located microservices? Deployment is more complex, but you get to intelligently assign processes to more optima…

> Probably just the interface - function calls become RPC. Network calls introduce new failure modes and challenges which require more plumbing. Can I retry this RPC call safely? How about exponential backoff? Is my API load-balancer doing its thing correctly? We'll need to monitor it. How about tracing between microservices? Now we need OpenTelemetry or something like that. How harder is it to debug with breakpoints…

My first Q was re: monolith on one host to many services on one host.

And yes, when going off-host, you'll have these issues. One should not employ network hops unnecessarily. Engineering is hard. Doesn't make it not worth doing.

Re: The costs of microservices (2020)

#247

Post by wnolens »

elevation wrote: post #193
wnolens wrote: post #123

If a monolith is well-factored, what is the difference between it and co-located microservices? Probably just the interface - function calls become RPC. You accept some overhead for some benefits of treating components individually (patching!) What is the difference between distributed microservices v.s. co-located microservices? Deployment is more complex, but you get to intelligently assign processes to more optima…

Monolith->microservice is not a trivial change no matter how well-factored it is to begin with -- though being poorly architected could certainly make the transition more difficult! > Probably just the interface - function calls become RPC. This sounds simple, but once "function calls become RPC" then your client app also needs to handle: * DNS server unreachable * DNS server reachable but RPC hostname won't resolve…

I was offering that simplification to compare monolith single host to multi-service single host. No network hops.

But yes, you proceed to explain (some of) the complexities of RPC over the network. Security concerns make this even worse. I could go on..

Engineering is hard

Re: The costs of microservices (2020)

#248

Post by jocaal »

tsss wrote: post #238
ljm wrote: post #230

Earlier quoted context omitted.

Ideally you would use the same language if it had distributed support. Use Erlang or Elixir for example and you have everything you need for IPC out of the box. Might take a little bit more effort if you're on Kubernetes. One of my problems with microservices isn't really the services themselves, but the insane amount of tooling that creeps in: GRPC, Kafka, custom JSON APIs, protobufs, etc. etc. and a lot of them exi…

If you do so much IPC that you have to design your language around it you're probably doing it wrong. I don't think that moving to a monolith would really cut down that much on other technologies. Maybe you can do without Kafka, but certainly you will need some other kind of persistent message queue. You will still need API docs and E2E integration tests.

> If you do so much IPC that you have to design your language around it you're probably doing it wrong...

I'm gonna have to disagree with this. Often when languages add features to their core, it allows for a very different (and often better) approach to writing code. Think Lisp with first class functions, or Rust with the borrow checker. Why should concurrency be any different? This feels like a Blub moment and I would highly recommend you give erlang or elixir a try, just to see what it is about.

Re: The costs of microservices (2020)

#249

Post by bibabaloo »

bob1029 wrote: post #157

> And think of the sheer number of libraries - one for each language adopted - that need to be supported to provide common functionality that all services need, like logging. This is the #1 reason we quit the microservices game. It is simply a complete waste of mental bandwidth to worry about with the kind of tooling we have in 2023 (pure cloud native / infiniscale FaaS), especially when you have a customer base (e.g…

How many developers do you have working on that monolith though? The size of your binary isn't usually why teams start breaking up a monolith.

Re: The costs of microservices (2020)

#250

Post by economist420 »

PedroBatista wrote: post #202

Similarly with frontend devs thinking a "modern web-app" can only be built with frontend frameworks/libs like React/Vue/Svelte, etc, lately I feel there's an idea floating around that "monolith" equals running that scary big black ball of tar as a single instance and therefore "it doesn't scale", which is insane. Another observation is the overall amount of code is much bigger and most of these services are ~20% busi…

While I agree with you that a lot of websites overuse javascript and frameworks. Can you tell me what else I'm supposed to use if I'm going to build a desktop class web app without it becoming a huge mess or I having to end up up inventing the same concepts already existing in these frameworks?
Post reply on HN