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

391–400 of 671 posts

Re: Modules, not microservices

#391

Post by jcadam »

switch007 wrote: post #365
jcadam wrote: post #332

As a senior software engineer, the most tiresome type of software dev to deal with is not the junior developer, it's the highly opinionated intermediate-level dev. They say things like "we'll obviously build the system using modern microservices architecture using node.js" before they even know the requirements.

They’re likely just trying to pad their resume for the next gig.

Reminds me of the time at a previous job where a poorly supervised engineer developed a complex application using LabVIEW (an utterly inappropriate use of the technology) and then took a new job with National Instruments, leaving a shop full of C and Ada programmers to maintain it.

Re: Modules, not microservices

#392

Post by tofuahdude »

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…

"Unexpected consequences" for a core piece of the technical approach suggests there are architects that are in the wrong role.

Re: Modules, not microservices

#393

Post by Pamar »

ReflectedImage wrote: post #320
Pamar wrote: post #143

Earlier quoted context omitted.

I agree, and yet most microservice zealots seem to have a different opinion on this. e.g.: https://www.baeldung.com/cs/microservices-db-design "2.1. Fundamentals By definition, microservices should be loosely coupled, scalable, and independent in terms of development and deployment. Therefore, the database per service is a preferred approach as it perfectly meets those requirements. Let’s see how it looks:" Please un…

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 it, and so on... try to imagine this like a mix between hotel management and flight company management) Inventory management (i.e. Reservation).

You mention "bookings" like a microservice. This could work for ferry line, where you are basically selling a ticket for a single trip, most of the time with no personal accommodation (except maybe for the car).

A Cruise booking usually comes with a ton of ancillary services (e.g. I live in Berlin and I want to take a cruise in the Caribbeans... therefore I need a flight to get there and back. This could be provided by a charter flight or a normal airline ... in either cases the ticket will be part of the booking itself) - take in account that cruise customers are mostly middle-aged or older and relatively affluent, therefore the last thing they would like to do is to create their own itinerary by booking services on 4-5 different websites.

(But I suppose it is better to stop there, we are really OT now)

Re: Modules, not microservices

#394

Post by nottorp »

riknox wrote: post #197
xnorswap wrote: post #168

Earlier quoted context omitted.

Broadly my heuristic for this is, "Would it make sense to run these functions in the other other?". If you split up MegaFunction(){} to Func1(){} Func2(){}, etc, but it never makes sense to call Func2 except after Func1, then you haven't actually created two functions, you've just created one function in two places. Refactoring should be about logical separation not about just dicing a steak because it's prettier tha…

I think that's a reasonable heuristic, but I'd also say you have to take into account the human readability aspect of it. It sometimes does make sense IMO to split solely for that, if it allows you to "reduce" a complicated/confusing operation to a string name, leading to it being easier to understand at a glance.

Shouldn't split MegaFunction into Func1 and Func2, you should:

  MegaFunction()
  {
  Func1();
  Func2();
  ...
  FuncN();
  }
People will call MegaFunction() but it will be logically split internally.

Re: Modules, not microservices

#395

Post by brhsagain »

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…

I don't understand the argument around microservices purporting to fix scalability. Say your system has modules A, B and C in one app, and that A requires more resources while B and C are relatively unused. Won't B and C just run less and thereby use appropriately fewer resources from within the same system as A? Are microservices just an aesthetic separation (it feels nice to know you're "only" scaling up A)?

Re: Modules, not microservices

#396

Post by boricj »

college_physics wrote: post #345

After scanning 300+ comments my conclusion is that not only there is no conclusion in this debate, there is no discernible framework that would help generate a conclusion Most likely the question is not well defined in the first place.

Maybe that's because AFAIK the various frameworks out there for building applications are strongly opiniated on a given paradigm. We have libraries, but we don't really have composable components that can be assembled into arbitrary architectures.

It's like we're stuck assembling applications by stacking pre-existing Lego sets together with home-made, purpose-built, humongously-sized Lego bricks made of cardboard acting as glue.

I've ranted a bit about that here: https://news.ycombinator.com/item?id=34234840

Re: Modules, not microservices

#397

Post by Zvez »

I didn't get this article. It seems like it contains two things: 1. It was already invented before 2. All the wrong reasons why people decide to use microservices.

But author clearly avoided the real reasons why you actually need to split stuff into separate services: 1. Some processes shouldn't be mixed in the same runtime. Simple example batch/streaming vs 'realtime'. Or important and not important. 2. Some things need different stack, runtimes, frameworks. And is much easier to separate them instead of trying to make them coexist.

And regarding 'it was already in Simpsons' argument, I don't think it should even be considered as argument. If you are old enough to remember EJB, you don't need to be explained why it was a bad idea from the start. Why services built on EJB were never scalable or maintainable. So even if EJB claimed to cover the same features as microservices right now, I'm pretty sure EJB won't be a framework of choice for anybody now.

Obviously considering microservices as the only _right_ solution is stupid. But same goes for pretty much any technology out there.

Re: Modules, not microservices

#398

Post by Sohcahtoa82 »

ivanhoe wrote: post #102
AnIdiotOnTheNet wrote: post #18

Earlier quoted context omitted.

You say that like real-time multiplayer gaming doesn't exist or something. Both of them have worked on those.... I think Carmack invented a lot of the techniques we use for those. Yeah sure, the scale is smaller, but you can't get away with making the user wait 10 seconds to render text and images to a screen either. I think the software world might be a lot better place if more developers thought like game developer…

Let's not turn it into penis measuring contents, please. Code organization and requirements differ significantly between different programming niches, and the today's accepted practices are not some randomly invented caprices, but the result of the slow (and painful) evolution we've been fighting through past decades. Each niche has optimized over time for its own needs and requirements. My web apis have hundreds of…

> My web apis have hundreds of controllers

That you probably don't even need, but there's a paradigm of "every function should be it's own class" that some devs seem to follow that I will never understand.

Re: Modules, not microservices

#399

Post by n1c00o »

lucasyvas wrote: post #227

The biggest draw of microservices to those just adopting them is not scalability or separation of concerns, but independent deployability (move fast and deploy new features in a particular area unencumbered). Good LUCK getting that property with a monolithic or modular system. QE can never be certain (and let's be honest, they should be skeptical) that something modified in the same codebase as something else does no…

This sounds like Bell Labs' Plan9

Re: Modules, not microservices

#400

Post by goodpoint »

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…

> Microservices are less efficient, but are still more scalable.

Not at all. You can run your monolith on multiple nodes just as you can do with microservices. If anything, it scales much better as you reduce network interactions.

Post reply on HN