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

131–140 of 671 posts

Re: Modules, not microservices

#131

Post by Pamar »

0xblinq wrote: post #78
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…

> However one of the unexpected consequences How the hell... like... who decided to do Microservices in the first place if they didn't know this? This is such a rookie mistake. It's like somebody right out of high school just read on a blog the new way is "microservices" and then went ahead with it.

well, this is a surprisingly common case in my experience, except that the people were not "right out of high school" but "right out of a company funded seminar on microservices".

Re: Modules, not microservices

#132

Post by anthonypasq »

Pamar wrote: post #120
ReflectedImage wrote: post #101

Earlier quoted context omitted.

The distinct elements are they compile separately and have versioning on their API calls. No, you don't use separate microservices for writing out that text message. The idea is pretty simple instead of writing one big program, you write many smaller programs. It's useful around the 3 to 4 separate developers mark. It avoids you having to recompile for any minor change, allows you run the tests for just the part you…

No, you don't use separate microservices for writing out that text message. But in order to find out that Genua is the name of the port from where the cruise is departing, the appropriate time (converted to the timezone of the port, or the timezone of the client who will see this message, depending on what business rule you want to apply) and that Genua is in IT=Italy... how many microservices do I have to query, con…

ive never seen that in practice. you dont have a database for each individual lambda. thats insanity. you can have multiple microservices point to a shared datasource, its not illegal.

Re: Modules, not microservices

#133

Post by Pamar »

wruza wrote: post #122
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…

Would be interesting to learn how your (or any other) team defines borders of a microservice. Iow, how “micro” they are and in which aspect. I guess without these details it will be hard to reason about it. At my last job we created a whole fleet of microservices instead of a single modular project/repo. Some of them required non-trivial dependencies. Some executed pretty long-running tasks or jobs for which network…

Did you have a common, centralized data store or did each and every microservice manage their own instance?

(Because this is at the same time one of the defining elements of this architecture... and the first one to be opted out when you actually start using it "for real").

Re: Modules, not microservices

#134

Post by BackBlast »

leidenfrost wrote: post #123

I think most criticisms around microservices are about good practices and skills beating microservices in theory. And the virtue of microservices is that they create hard boundaries no matter your skill and seniority level. Any unsupervised junior will probably dissolve the module boundaries. But they can't simply dissolve the hard boundary of having a service in another location.

Those boundaries also increase the cost of development. If you are institutionally incapable of enforcing coding standards such that you can't prevent juniors from coupling your modules, perhaps it's worth it. But there are more efficient ways to build and run an engineering organization.

The best place for such boundaries is at the team/division/org level, not team-internal or single dev-internal like microservices implies with its name. Embrace Conway's law in your architecture, and don't subdivide within a service.

Re: Modules, not microservices

#135

Post by jhoelzel »

ah come on, there is a reason why we start most estimates with "it depends".

It's on the same page as "yes, we could have written this in assembler better" or "this could simply be a daemon, why is it a container?"

As if an agile, gitops based, rootlessly built, microservice oriented, worldwide clustered app will magially solve all your problems :D

If i learned anything it's to expect problems and build a stack that is dynamic enough to react. And that any modern stack includes the people managing it just as much as the code.

But yes, back when ASP.NET MVC came out i too wanted to rebuild the world using c# modules.

Re: Modules, not microservices

#136

Post by revskill »

In theory microservice is cool. In practice, it's not.

Microservice and modularity is orthogonal, it's not the same.

Modularity is related to business concept, microservice is related to infrastructure concept.

For example, i could have a module A which is deployed into microservide A1 and A2. In this case, A is almost abstract concept.

And of course, i could deploy all modules A, B, C using 1 big service (monothlic).

Moreover, i could share one microservice X for all modules.

All confusion from microservice, is made from the misconception that microservice = module.

Worse, most of "expert advice" which i've learnt actually relate Domain Driven Design to Microservice. They're not related, again.

Microservice to me, is to scale. Scale the infrastructure. Scale the team (management concept).

Re: Modules, not microservices

#137

Post by mcculley »

beagle3 wrote: post #85
mcculley wrote: post #34

You don’t have to necessarily decide one way or the other. I have systems where the decision to put the module in the same process or to call it via RPC is done at runtime. Java’s dynamic proxies help with this, but it can be done in any language. The only downside is that one has to think about the size of messages crossing the API and that they need to be immutable values, not references to something in the process…

There is another downside, much more problematic in my experience - the failure modes of a distributed system (even over multiple processes in the same machine) are very different. The other process might be killed by OOM manager, user initiated kill signal, or a bug. All of a sudden, asking an object for its string identifier xyz.Name() becomes a possibly failing operation even though it succeeded a microsecond ago.

Yes, there are downsides to distributed systems. In some cases, they are still necessary. This approach allows us to make the decision to be distributed at runtime instead of at design time.

For our services, there is never a single point of failure. We use Resilience4j for retries, caching inside the dynamic proxy handler (using annotations to describe what is cacheable), and annotations to describe what can be done asynchronously.

In the cases where we use these, the caller is aware (via the interface documentation) that this is a distributed system where sometimes invocations happen really fast and reliably.

Re: Modules, not microservices

#138

Post by regularfry »

karamanolev wrote: post #24
SomeoneOnTheWeb wrote: post #14

Earlier quoted context omitted.

I strongly disagree on this one. 10+K lines files are absolutely unreadable most of the time. Separating business logic than other parts of the application helps maintaining it and making everything evolve in parallel, without mixing things up. It also helps to clearly see where business logic happens.

I'm inbetween. 10K line files are usually extremely messy, but they can be written not to - a large number of well-organized, well-capsulated Same for business logic - very clear separation can be cumbersome sometimes, but otherwise it becomes messy if you're not careful. And careful people just tend to separate it.

What muddies the waters here is languages like Java, where "10k lines" means "you've got a 10kLOC class there", and ecosystems like PHP's where while there's nothing in the language to require it, people and teams will insist on one class per file because hard rules are easier to understand and enforce than "let's let this area evolve as we increase our understanding".

As long as what's there is comprehensible, being able to evolve it over time is a very useful lever.

Re: Modules, not microservices

#140

Post by [deleted] »

kubb wrote: post #40
surprisetalk wrote: post #2

I suspect that most people would be better off favoring inlined code over modules and microservices. It's okay to not organize your code. It's okay to have files with 10,000 lines. It's okay not to put "business logic" in a special place. It's okay to make merge conflicts. The overhead devs spend worrying about code organization may vastly exceed the amount of time floundering with messy programs. Microservices aren'…

Respectfully, rants by niche celebrities are not something we should base our opinions on. If you're a single dev making a game, by all means, do what you want. If you work with me in a team, I expect a certain level of quality in the code you write that will get shipped as a part of the project I'm responsible for. It should be structured, tested, malleable, navigable and understandable.

[deleted]
Post reply on HN