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

591–600 of 671 posts

Re: Modules, not microservices

#591

Post by rlt »

dahfizz wrote: post #366
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.…

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…

You can horizontally scale a monolith without going full microservices.

Re: Modules, not microservices

#592

Post by rightbyte »

koliber wrote: post #30
pshirshov wrote: post #22

Earlier quoted context omitted.

And of course it's lot easier to read 200k+ LoC shattered around twenty repos.

The problem arises when you need to read the code of other modules or services. If you can rely on them working as they should, and interact with them using their well-defined and correctly-behaving interfaces, you won't need to read the code. I'm a proponent of keeping things in a monolith as long as possible. Break code into files. Organize files into modules. A time may come when you need to separate out services.…

> The problem arises when you need to read the code of other modules or services. If you can rely on them working as they should, and interact with them using their well-defined and correctly-behaving interfaces, you won't need to read the code.

You can say the exact same thing about C-headers though.

Re: Modules, not microservices

#593

Post by mk89 »

jmchuster wrote: post #585
mk89 wrote: post #418

Earlier quoted context omitted.

> A better rule is for one service to own writes for a table, and other services can only read that table, Been there: how do you handle schema changes? One of the advantages that having a separate schema per service provides is that services can communicate only via APIs, which decouples them allowing you to deploy them independently, which is at the heart of microservices (and continuous delivery). The way I see it…

For us, we started off with a world where each service communicates to each other only via RabbitMQ, so all fully async. So theoretically each service should be able to be down for however it likes with no impact to anyone else, then it comes back up and starts processing messages off its queue and no one is the wiser. Our data is mostly append-only, or if it's being changed, there is a theoretical final "correct" ve…

> So then back to your original question, the way that this contract can break is via schema changes. So for us, since we use postgres, we created database views that we expose for reading. And postgres view updates are constrained that they must always be backwards compatible from a schema perspective. So then now our migration path is: > - service A has some table of data that you like to share > > - write a migration to expose a view for service A > > - write an update for service B to depend upon that view > > - service B now needs some more data in that view > > - write a db migration for service A that adds that missing data, but keeping the view fully backwards compatible

I don't think I understand. You need to update (and deploy) service B every time you perform a view update (from service A), although it's backward compatible?

Re: Modules, not microservices

#594

Post by esailija »

dkarl wrote: post #285
regularfry wrote: post #201

Earlier quoted context omitted.

You can deploy modules independently, but the technical and organisational measures you need in place to do it safely are an extra step you need to take whereas with microservices they're built in. Modules live in the same execution context, so you need a good shared ownership model for that context itself. The point is that Parnas never conceived of doing it because he was writing about a world where the interfaces…

> the technical and organisational measures you need in place to do it safely are an extra step you need to take whereas with microservices they're built in They aren't built in, it's just that the need for them is impossible to ignore. Developers (and management) can't help but recognize and respect modularity in microservices because the separation of services and the APIs between them make the modularity obvious.…

Module is not just code in a separate file. Litmus test: if you cannot have two modules be written in separate languages - you don't have modules. M

If all modules have to be deployed using the same build even though different build of the modules would have been API compatible - you don't have modules.

Re: Modules, not microservices

#595

Post by rusebor »

mk89 wrote: post #418
barrkel wrote: post #72

Microservices, while often sold as solving a technical problem, usually actually solve for a human problem in scaling up an organization. There's two technical problems that microservices purport to solve: modularization (separation of concerns, hiding implementation, document interface and all that good stuff) and scalability (being able to increase the amount of compute, memory and IO to the specific modules that n…

> A better rule is for one service to own writes for a table, and other services can only read that table, Been there: how do you handle schema changes? One of the advantages that having a separate schema per service provides is that services can communicate only via APIs, which decouples them allowing you to deploy them independently, which is at the heart of microservices (and continuous delivery). The way I see it…

what if we put the table behind a view? would it be count as a communication via API?

Re: Modules, not microservices

#596

Post by esailija »

gunnarmorling wrote: post #169

I really like modular designs, but this article is missing some key limitations of monolithic applications, also if they are really well modularized (this is written mostly from the perspective of a Java developer): * they force alignment on one language or at least runtime * they force alignment of dependencies and their versions (yes, you can have different versions e.g. via Java classloaders, but that's getting tr…

Please check your assumptions. Why do you think 2 modules cannot be in different runtimes? How do you think JNI works?

You can absolutely call js running in V8 vm from scala running in jvm. No networking needed, hell not even IPC is needed.

And when you deploy this you don't have to deploy all modules' http servers (for external requests into the system) and queue consumers in the same container, only a single module's. So no busy loops affect other modules, unless as a result of direct api call from module to module. If anything it encourages looser coupling as you are incenticised to use indirect communication through the queue over direct api calls.

Re: Modules, not microservices

#597

Post by ahmetnoid »

LeonM wrote: post #588
ahmetnoid wrote: post #584

Earlier quoted context omitted.

Scalability is not a feature. If you "need" to scale but don't then you're not delivering to your target market, not delivering is not a lack of a feature it's a net loss to the organization. If you're Twitter/Instagram/Uber/whatever you cannot tell your users to not post or like or request a ride because "right now we don't have the scalability feature"

I don't completely agree here. Yes, if you can't scale fast enough as you need to, it can hurt your business. Not being able to keep up with demand is a (luxury) problem that every business faces, not just in tech. They would often be called 'growing pains' in a business, and though they are bad, they rarely contribute to the failure of a company. Starting a startup/service/platform with microservices before you even…

I'm not making a case in favor of starting with microservices for your startup, that'd be insane, to say the least. I'm just disagreeing with "scalability is a feature". A feature is every addition on top of your minimum viable product. If at some point it becomes apparent that the business needs scalability, then scalability becomes your minimum viable product.

Re: Modules, not microservices

#598

Post by code_biologist »

esailija wrote: post #596
gunnarmorling wrote: post #169

I really like modular designs, but this article is missing some key limitations of monolithic applications, also if they are really well modularized (this is written mostly from the perspective of a Java developer): * they force alignment on one language or at least runtime * they force alignment of dependencies and their versions (yes, you can have different versions e.g. via Java classloaders, but that's getting tr…

Please check your assumptions. Why do you think 2 modules cannot be in different runtimes? How do you think JNI works? You can absolutely call js running in V8 vm from scala running in jvm. No networking needed, hell not even IPC is needed. And when you deploy this you don't have to deploy all modules' http servers (for external requests into the system) and queue consumers in the same container, only a single module…

hell not even IPC is needed.

Uh... what's the trick? I don't see how you can have V8 and the JVM communicate without something that's inter-process.

Re: Modules, not microservices

#599

Post by ergo14 »

dilyevsky wrote: post #288
pjmlp wrote: post #241

Earlier quoted context omitted.

So much for the theory, most services I see in the wild are stateful. As for scalability, most orgs aren't Facebook nor Google scale, regardless of how much they want it to be true. All of those issues can be tackled, when proper architecture design is done, instead of coding on the go and then will see attitude.

People keep regurgitating this “you aint going to be google” mantra but I worked there and in reality generic microservice stack is in a totally different league of complexity and sophistication of what google and co have. This argument is basically reductio ad absurdum

So all your microservices implement sagas or other synchronisation patterns that ensure 100% data consistency?

Re: Modules, not microservices

#600

Post by TickleSteve »

Karrot_Kream wrote: post #583
noogle wrote: post #569

Earlier quoted context omitted.

That makes sense. I am still trying to understand why does it differ between a monolith and microservices. The app in the monolith can make the call to non-critical functionalities time-limited and fault-tolerant, just like a network call has a time-out and can return nothing (in a simplified manner, it can wrap that call with a timer and an exception handler). I agree that microservices are suitable for large organi…

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.

Post reply on HN