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

381–390 of 671 posts

Re: Modules, not microservices

#381

Post by cogman10 »

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 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 monolith into the x/y/z, and x and z got the "load the world" endpoints, that starts the fires of "x is constantly killing things and it's only doing this one thing. How do we do that better?"

That allows you to better prioritize fixing those scaling problems.

Re: Modules, not microservices

#383

Post by kerblang »

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…

Mostly valid, but...

On the RAM front, I am now approaching terabyte levels of services for what would be gigabyte levels of monolith. The reason is that I have to deal with mostly duplicate RAM - the same 200+ MB of framework crud replicated in every process. In fact a lot of microservice advocates insist "RAM is cheap!" until reality hits, especially forgetting the cost is replicated in every development/testing environment.

As for slow startup, a server reboot can be quite excruciating when all these processes are competing to grind & slog through their own copy of that 200+ MB and get situated. In my case, each new & improved microservice alone boots slower than the original legacy monolith, which is just plain dumb, but it's the tech stack I'm stuck with.

Re: Modules, not microservices

#384

Post by Sohcahtoa82 »

surprisetalk wrote: post #328
mr90210 wrote: post #299

Earlier quoted context omitted.

I felt suspicious as soon as I saw Jon Carmack’s website being mentioned in a conversation about Microservices.

I hope this quote from the Carmack essay shows that his argument isn't necessarily restricted to game development: ---------- style C: void MajorFunction( void ) { // MinorFunction1 // MinorFunction2 // MinorFunction3 } > I have historically used "style A" to allow for not prototyping in all cases, although some people prefer "style B". The difference between the two isn't of any consequence. Michael Abrash used to w…

I used to be a fan of style C, but these days, I prefer either A or B, with the condition that no MinorFunction should be less than 5 lines of code. If a function is that small, and it's called from only one place, then it doesn't need to be a function.

Using A or B results in self-documenting code and I think DOES (or at least, CAN) improve readability. It also can help reduce excessive nesting of code.

Re: Modules, not microservices

#385

Post by catlifeonmars »

strictfp wrote: post #154
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…

This has been my major criticism of them; you cement the design of the app by creating an organizational structure around your software components. What happens if you need to redesign the architecture to meet new needs? That's right; it's not going to happen, because people will fight it tooth and nail. You also cannot produce any meaningful end-user value without involving several teams. Microservices is just "back…

> My take: do Microservices all you want, but don't organize teams around the services!

Exactly. In order to reap the benefits of modular/Microservices architecture, you need teams to be organized around product/feature verticals.

IMO it’s not about the internals of a product/service architecture, but about encapsulating, isolating, and formalizing inter-organizational dependencies.

Re: Modules, not microservices

#386

Post by hinkley »

AcerbicZero wrote: post #335

Wear shoes that fit; not shoes you think you'll grow into.

Shoes you’ll grow into is advice for children.

Mastery is substantially about figuring out what rules of thumb and aphorisms are in place to keep beginners and idiots from hurting themselves or each other, and which ones are universal (including some about not hurting yourself, eg gun safety, sharps safety, nuclear safety).

Re: Modules, not microservices

#387

Post by Zvez »

highspeedbus wrote: post #331
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…

>they force alignment on one language or at least runtime A sane thing to do. >they force alignment of dependencies and their versions A sane thing to do. Better yet to do it in a global fashion, along with integration tests. >they can require lots of RAM if you have many modules with many classes You can't make the same set of features build in a distributed manner comsume _less_ RAM than the monolith counterpart. G…

> a sane thing to do

imaging your application contains of two pieces - somewhat simple crud, that requires to respond _fast_ and huge batch processing infrastructure, that needs to work as efficient as possible, but doesn't care about single element processing time. And suddenly 'the sane thing to do' is not the best thing anymore. You need different technologies, different runtime settings and sometimes different runtimes. But most importantly they don't need constraints imposed by unrelated (other) part of the system.

Re: Modules, not microservices

#388

Post by hinkley »

nicoburns wrote: post #59
wodenokoto wrote: post #23

I’m surprised none of the big 3 cloud providers have come out with a cloud native language where modules or even classes gets deployed as micro services that scales horizontally. Then you can have a mono repo that deploys to multiple micro services / cloud functions / lambdas as needed depending on code changes and programmers don’t have to worry about RPC or json when communicating between modules and can just call…

If you want to scale horizontally then why just run multiple copies of your monolith? That will work just fine unless you're really big, in which case you'll probably be wanted to write your own solution rather than depending on a cloud provider anyway.

Multiple copies but with traffic shaping is one of the simplest things that could work.

Re: Modules, not microservices

#389

Post by tail_exchange »

charcircuit wrote: post #294
hgsgm wrote: post #15

How do I horizontally scale my modules across multiple machines? How do I release a new version of my module without waiting for hundreds of other teams to all fix their bugs? .99^100^365 is a very small number.

There will always be bugs in production. Achieving perfection is not something you should require.

Not every company can afford to run crappy code in production. PayPal and banks, for example. Being able to quickly roll back changes while still keeping developer velocity and moving forward is important, and it is very difficult when thousands of changes are going out every day in the same monolith.

Re: Modules, not microservices

#390

Post by randomdata »

Guid_NewGuid wrote: post #378
randomdata wrote: post #272

Earlier quoted context omitted.

Microservices has little to do with tech. It is a way of organizing teams of people , funnelling all communication between teams through well defined specifications instead of ad-hoc meetings. It is not clear where static typing, or lack thereof, comes into play here. TDD is a method of documenting your application in a way that happens to be self-verifying. You could use a Word document instead, but lose the ability…

# Microservices I think at the root this idea that Microservices provide this technical solution to a social issue, coordinating teams at scale, hides the driving motivation. Why can't the teams work on the same codebase and the same database? (again note my edited in disclaimer in the GP post that maybe at certain rare scales it's necessary). What is a well defined specification and why is it only a REST/proto/whate…

> Why can't the teams work on the same codebase and the same database?

The same database is tricky because one team might want to change the schema, breaking another team's work. You then need to have meetings to discuss the changes that will work for all parties and you've broken "communicate only by contract", and therefore no longer doing microservices. If you can ensure that there is no way for teams to trample over each other then you could use the same database.

The same codebase is more feasible as long as the team boundary separation is clear. You are likely already doing microservices with other teams when you import third-party libraries. In practice, though, much like the database problem maintaining boundary separation is difficult if you can easily reach into other team's code, so often each team's work will be parted into distinct codebases using IPC between them to ensure that the separation is unbreakable. This certainly isn't a requirement, though, just one way to keep people in line.

> Testing is certainly a way to provide a self-verifying application. TDD is a toxic, hype-driven, mess

Testing is a development tool to help test the functionality of a feature. If you are faced with a dynamic language you very well might write tests to ensure that types are handled correctly. Static types can, indeed, relieve the need for some tests.

TDD, on the other hand, is a documentation tool to relay to other developers what functionality is intended to provide and how it is meant to be used. It is strange to think that documentation is toxic. Before TDD we wrote "Word documents" containing the same information, but often found that the code didn't do what the documentation said it did. What TDD realized is if the documentation is also executable then you can have the machine prove that the application behaves according to spec. It's not exactly magic.

Post reply on HN