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

631–640 of 671 posts

Re: Modules, not microservices

#631

Post by KronisLV »

JAlexoid wrote: post #621
KronisLV wrote: post #582

Earlier quoted context omitted.

> That's a budget for a local crafts store website hosting, not "high availability" system I'm not sure about that: you could still put something together within that budget, say, a few different VPSes across Hetzner and Contabo (or different regions within the same provider's offerings), with some circuit breaking and load balancing between those. Probably either a managed database offering, or a cluster of DBs runn…

If you're a amateur something, that just does it for fun - sure Otherwise what you have is a budget that is lower than the possible implications of temporary downtime. That doesn't make sense in the real world.

> If you're a amateur something, that just does it for fun - sure

  sed "s/amateur/comparatively poor, from a third world country, without VC money, or have cheap labor/g"
Not everyone can afford advanced tools or platforms, or even using something like AWS/Azure/GCP. Some of those can indeed be amateur use cases (e.g. side project or bootstrapped SaaS), others simply stretching your money for any number of considerations (e.g. non profit, limited budget etc.), but it's definitely possible. In some countries it probably makes more sense to just build your own solution, as long as you're not doing anything too advanced.

500 USD a month would get you approximately the following resources (taxes vary) on the aforementioned platforms:

  Contabo
  Nodes: 15 to 83 (depending on configuration)
  CPU: 150 to 332 cores
  RAM: 664 to 900 GB
  SSD: 4150 to 6000 GB
  
  Hetzner
  Nodes: 7 to 110 (depending on configuration)
  CPU: 86 to 192 cores
  RAM: 192 to 384 GB
  SSD: 2200 to 4800 GB
  
  (this includes regular VPS packages, not storage optimized ones, or dedicated hosting etc.)
I'm not sure about you, but in my experience that could be enough for some pretty decent systems, albeit some storage heavy workloads would need the storage packages instead of the regular VPS ones. It's mostly a matter of picking a suitable topology and working towards your goals.

> Otherwise what you have is a budget that is lower than the possible implications of temporary downtime. That doesn't make sense in the real world.

This (depending on the circumstances) does sound like a good point! Maybe "the real world" isn't the best wording, though, and choosing "enterprise settings" or anything along those lines would be more suitable.

Re: Modules, not microservices

#632

Post by nottorp »

xnorswap wrote: post #589
nottorp wrote: post #394

Earlier quoted context omitted.

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.

This is how it's taught in school but the argument is that you shouldn't do that, instead just inline Func1 and Func2 and comment it better. By chopping up MegaFunction like this, you've not actually separated Func1 and Func2 if they aren't really independent, they're just MegaFunction in disguise but now split across two places making it more difficult, not easier, to reason about. If you need the state (implied or…

> you shouldn't do that, instead just inline Func1 and Func2 and comment it better.

Frankly It Depends(tm). Sometimes you can do this and not pass too much state, sometimes you can not. Sometimes your state is in a class, or global, and you just pass the class around.

I have somewhere a 3000 line state machine with the app state in a class - i just pulled out logically connected states in auxiliary files when it went over 1k lines. In my case it's easy to comprehend because groups of states are kinda separated logically.

Re: Modules, not microservices

#633

Post by sally_glance »

MuffinFlavored wrote: post #380
__jem wrote: post #354

Earlier quoted context omitted.

In the case of Java, imagine we have a big Maven project that has a bunch of different well factored modules that form the "libraries" of our application. At first, in our Maven project we also have a single module which is the deployable for "the monolith" -- it consumes all the other "lib" modules and gets packaged into a fat jar. We deploy a few instances of the monolith fronted by a load balancer. There's not muc…

so you end up with a monolith that might have a config flag or something to determine its purpose when it comes online, and then it can go down a few different code paths. pretty cool. is this something that is done on the fly and then later you don't let that code pattern stay alive (aka, is it not a smell/bandaid)? my concern would be if you accidentally create bugs by basically creating new mini-monolith flavors a…

I was part of a project that did exactly this - same monolithic code base with config flags that transformed it into web server, worker or scheduler. It allows scaling all parts separately, but I can confirm it's easy to introduce bugs if you're not careful. Since you're sharing the same DB, migrations also need to be backwards-compatible.

A cool side-effect is that you can usually run the whole thing in one app for development by just enabling all profiles - as opposed to some microservice architectures where you need dozens of containers and DBs for replicating inter-service bugs.

Re: Modules, not microservices

#634

Post by speed_spread »

mbork_pl wrote: post #156
speed_spread wrote: post #82

Earlier quoted context omitted.

One big reason is source control. Having many smaller files with well defined purpose reduces the number of edit collisions (merges) when working in teams. Also, filenames and directories tree act as metadata to help create a mental map of the application. The filesystem is generally well represented in exploratory tools like file browser and IDE. While the same information can be encoded within the structure of a si…

Well, Git is pretty good at merging when the changes are in different places of the same file. Though your second point is a very good one. FWIW, sometimes when I worked on a really large file, I put some ^L's ("new page" characters) between logical sections, so that I could utilize Emacs' page movement commands.

It's not just git, it's pull requests and code reviews that block on concurrent file updates. The workflow friction multiplies with the number of devs sharing the same code area. Small files minimize this by making more granular work units.

Re: Modules, not microservices

#635

Post by dilyevsky »

ergo14 wrote: post #599
dilyevsky wrote: post #288

Earlier quoted context omitted.

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?

If you distribute the state over ALL your services and need 100% data consistency you’re holding it wrong

Re: Modules, not microservices

#636

Post by lamontcg »

jbergens wrote: post #602
lamontcg wrote: post #411

Earlier quoted context omitted.

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 project…

I started at Amazon in 2001 when we had around 400 servers running the website, it was large, but it was around the scale that most Fortune 500 companies operate at.

I'll agree that a team of developers with 20 microservices sounds obviously wrong (which is really my point that the site should be divided around data and the orgs should probably reflect the needs of the data--not the other way around). And Amazon back then didn't have that problem.

Re: Modules, not microservices

#637

Post by Karrot_Kream »

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.

It was about the OOM killer as the sibling comment says, yeah. I'm surprised you're so incredulous. OOM Killer and GC stalls are some things I've run up against in my career frequently. I'm sorry my comment didn't live up to your expectations, it was hastily typed on mobile.

Re: Modules, not microservices

#638

Post by Karrot_Kream »

thrwawai39f3 wrote: post #616
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.

A monolith can also scale vertically with mechanisms to redeploy on fatal errors. If all starts failing, you may have a problem. But you can get the same problems with a microservices that is in the critical path Networks could have unexpected delays, routing errors and other glitches. At least with a monolith you can often find a stacktrace for debugging. I have seen startups that have limited traceability and loggi…

Right I'm not advocating for one over the other, I was just explaining issues solved by microservices. Now instead of the OOM Killer taking your service down, you have a flaky NIC on another microservice box and now you need to figure out how to gracefully degrade.

I love working with microservices at the scale of $WORK, but we're Big Tech. I can't imagine why a 5 person startup would want k8s and microservices. You don't need that scale until you have more than 2 teams, and you're pushing at the very least 15 engineers at that point and usually the sales and marketing staff to make that investment worth it.

Re: Modules, not microservices

#639

Post by oblio »

Karrot_Kream wrote: post #637
TickleSteve wrote: post #600

Earlier quoted context omitted.

"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.

It was about the OOM killer as the sibling comment says, yeah. I'm surprised you're so incredulous. OOM Killer and GC stalls are some things I've run up against in my career frequently. I'm sorry my comment didn't live up to your expectations, it was hastily typed on mobile.

His point was that the comment was unclear if you'd also read it hastily :-)

I imagine his logic was something like: "How can OOMs happen less often if you run more processes (possibly on the same machine)?", while your comment actually wants to say: "if a specific service is affected by an OOM, with microservices only that specific microservice goes down, since it's probably running on its own hardware".

Re: Modules, not microservices

#640

Post by oblio »

davej wrote: post #103
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…

Twitter has a similar issue according to Musk https://twitter.com/elonmusk/status/1592176202873085952

Musk last wrote code in 1995, most likely.
Post reply on HN