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

Modules, not microservices

blogs.newardassociates.com

Post reply on HN
Print view View original

601–610 of 671 posts

Re: Modules, not microservices

#601

Post by LeZuse »

There are so many misconceptions about what microservices are or what problems they are trying to solve. Most people don't even experience the problems (yet or ever) they are meant to solve and they go straight to micro. 5 person teams making 5 services to power their product :faceplam:. A relatively simple b2b web application without any serious traffic also does not need microservices to handle its load.

People just read up on whatever seems to be the newest, coolest thing. The issue is that MS articles are usually coming from FAANG/ex-FANNG. These companies are solving problems that 99% of others do not.

As engineers we should be looking for the most effective solutions to a given business problem. Sadly, I see engineers with senior/staff titles just throwing cool tech terms/libs around. Boring tech club ftw

Re: Modules, not microservices

#602

Post by jbergens »

lamontcg wrote: post #411
eklitzke wrote: post #356

Earlier quoted context omitted.

I just want to point out that for the second problem (scalability of CPU/memory/io), microservices almost always make things worse. Making an RPC necessarily implies serialization and deserialization of data, and nearly always also means sending data over a socket. Plus the fact that most services have some constant overhead of the footprint to run the RPC code and other things (healthchecking, stats collection, etc.…

I was working at Amazon when they started transitioning from monolith to microservices, and the big win there was locality of data and caching. All of the catalog data was moved to a service which only served catalog data so its cache was optimized for catalog data and the load balancers in front of it could optimize across that cache with consistent hashing. This was different from the front end web tier which used…

I think Amazon (and Google and other FAANG entities) work at another scale than 99.9% of the rest of the world. The problems they face are different, including the impact of data locality.

I've seen many systems where there are a few hundred to a few thousand users, not hundred of millions or billions of users. There can also be teams of 5-10 developers who manages +20 microservices. I still don't think those projects have the same needs and could have done something else.

Re: Modules, not microservices

#603

Post by jbergens »

thayne wrote: post #476
cogman10 wrote: post #381

Earlier quoted context omitted.

You know, I don't really think microservices are fundamentally more scalable. Rather, they expose scaling issues more readily. When you have a giant monolith with the "load the world" endpoint, it can be tricky to pinpoint the the "load the world" endpoint (or, as is often the case, endpoint*s*) is what's causing issues. Instead, everyone just tends to think of it as "the x app having problems." When you bust the mon…

> I don't really think microservices are fundamentally more scalable It depends on what you are scaling. I think microservices are fundamentally more scalable for deployment, since changes can be rolled out only to the services that changed, rather than everywhere. Unless your language and runtime support hot-loading individual modules at runtime.

If you have many app servers and they all run copies of the same app you can roll out new versions to a few servers at a time. You just have to handle the db update first but you need to do that with microservices anyway (they might use smaller databases and therefore making it somewhat easier).

Re: Modules, not microservices

#604

Post by ReflectedImage »

Pamar wrote: post #393
ReflectedImage wrote: post #320

Earlier quoted context omitted.

Whilst I don't know much about cruises. Let me make up an example for you. Let's suppose we are Acme Cruise Lines running a Cruiseliner: Microservice - National Coastguard Ship Arrival System Feed Handler Database - Logs incoming messages on the feed Microservice - Asian and Australian Joint Ship Monitoring System Database - Logs incoming messages on the feed Microservice - Cruiser Arrival and Departure Times Databas…

You are absolutely right: you do not know much about cruises. The things you listed are ... 4-5 different applications , mostly running directly on the ship(s) and what is conspicuously missing are the parts that are managed shoreside, like: Itinerary planning (your product is one or more cruises: therefore you need to preplan the itineraries, which ships to use, when you will enter each port and when you will leave…

"4-5 different websites" No, no, no. Those are internal APIs. You still only present one website to the end user.

Re: Modules, not microservices

#605

Post by danielheath »

TickleSteve wrote: post #600
Karrot_Kream wrote: post #583

Earlier quoted context omitted.

If your monolithic service OOMs, hits a large GC pause causing dependent requests to time out, locks a shared file descriptor, or a bunch of other things then the monolithic service as a whole can hit a fault or stall even if other threads/tasks are still executing. While classes of errors like OOMs go away when multiple processes are executing.

"Classes of errors such as OOMs go away when multiple processes are executing" You're going to have to explain what you mean by that a bit more... You surely cant mean it as it is written.

I don't think it was well expressed, but to reuse my last example: OOM-killer ending the recommendations process mid-request is less of a big deal if the main store server can keep running and serving traffic.

If the recommendations team write code that causes the OOM-killer to end their process, making them run it on separate infrastructure insulates your "main store team" from the bugs they write.

Re: Modules, not microservices

#606

Post by oflor »

brundolf wrote: post #510
oflor wrote: post #506

Earlier quoted context omitted.

Tech zoo sometimes considered to be an anti-pattern in microservices. By introducing a different language into your organization, you decrease the mobility of developers between code bases and dilute technical knowledge.

Everybody shouldn't pull in their favorite stack just for fun, but it seems valuable to have the option of trying out new things that could turn out to be a better way forward for the org

Rewriting a module from one tech stack to another is not much harder when that module was a part of a monolith and not a separate service, except that you haven't paid the upfront cost of bootstrapping a new service, putting in RPC calls, etc. And in any case, starting a project as microservices is already a bad practice due to a number of reasons, the most important for me is that it's hard to change module boundaries, which you will most likely get wrong in a new project.

Re: Modules, not microservices

#607

Post by funnymony »

throwaway894345 wrote: post #432
dahfizz wrote: post #366

Earlier quoted context omitted.

Microservices are less efficient , but are still more scalable . Servers can only get so big. If your monolith needs more resources than a single server can provide, then you can chop it up into microservices and each microservice can get its own beefy server. Then you can put a load balancer in front of a microservice and run it on N beefy servers. But this only matters at Facebook scale. I think most devs would be…

Yeah, it's bin packing, not straight efficiency. Also, people seem to exaggerate latency for RPC calls. I often get the feeling that people who make these latency criticisms have been burned by some nominal "microservices" architecture in which an API call is made in a hot loop or something. Network latency is real, and some systems really do run on a tight latency budget, but most sane architectures will just do a c…

Couple of calls is normal. But if you make everything a microservice. And there are dependencies between them, then by design its destined that some hotter loop eventually will contain rpc.

Re: Modules, not microservices

#608

Post by nova22033 »

c-fe wrote: post #73

I am working on a project that uses a microservice architecture to make the individual components scalable and separate the concerns. However one of the unexpected consequences is that we are now doing a lot of network calls between these microservices, and this has actually become the main speed bottleneck for our program, especially since some of these services are not even in the same data center. We are now attem…

especially since some of these services are not even in the same data center.

Why is the other service in another data center? Does it need to be in another data center? If it does, how will a monolith help?

Re: Modules, not microservices

#609

Post by vinay_ys »

This article builds up a bunch of straw man arguments based on what other people claimed in blog posts and then attacks them. In real world where micro services really made a difference, they enabled being more tolerant to a mix of different quality/maturity/velocity in different parts of the overall system and still keeping things as healthy as possible. If you have a monolithic execution binary that hosted all the logic code, then they all have to be of high quality or the entire thing can be taken down with one bad quality stuff. Having a mix of different quality/maturity/velocity in different parts of your systems is a business reality if your system is modeling a complex multi-pronged business that's evolving and growing and maturing in different prongs with different timelines. If this core value prop isn't needed, then probably you can solve your problems without micro services just as good or even better.

Re: Modules, not microservices

#610

Post by vinay_ys »

mixermachine wrote: post #524
gadflyinyoureye wrote: post #517

Earlier quoted context omitted.

Sometimes. If the services are all interrelated, you’re as dead on the water with Microservices was you would be in a monolith.

Sure depends on the architecture. When the auth service is down, everything else should be down. But when the "optional feature" service is down, a core component should be unaffected by that. Split up services where it makes sense and don't over do it. That's how I design my projects.

When the auth service is down, only new authentications should fail. Existing auth sessions should continue to function just fine. This exact failure mode occured at Google in early 2021 which caused a fairly big outage but not as big as it could have been because of this design choice.
Post reply on HN