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

641–650 of 671 posts

Re: Modules, not microservices

#641

Post by ElectricalUnion »

KronisLV wrote: post #631
JAlexoid wrote: post #621

Earlier quoted context omitted.

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

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

> Maybe "the real world" isn't the best wording, though, and choosing "enterprise settings" or anything along those lines would be more suitable.

This is the point - for-profit corporations, by definition, don't want to waste money, and if "high reliability" isn't required (or they don't know about it), they don't waste money. Most of the time, they don't waste the money.

However, if "being cheap" would means billions in lost income (and they know about it), they really want to have reliable, redundant infrastructure and systems around.

Re: Modules, not microservices

#642

Post by greenhatman »

SgtBastard wrote: post #519
greenhatman wrote: post #500

Earlier quoted context omitted.

You can have more than one server per monolith. I don't think you actually understand what microservices are. You don't put a load balancer to load balance between different services. A load balancer balances trafic between servers of the same service or monolith. Microservices mean the servers of different services run different code. A load balancer only works together with servers running the same code.

>A load balancer only works together with servers running the same code. Uh - what? >A load balancer balances traffic between servers Correct. > of the same service or mononlith Incorrect. Load balancers used to work solely at Layer 4, in which case you’d be correct that any 80/443 traffic would be farmed across servers that would necessarily need to run the same code base. But modern load balancers (NGINX et al) esp…

I don't really think of route based "load balancing" as load balancing. That's routing, or a reverse proxy. Not load balancing. Load balancing is a very specific type of reverse proxy.

The point is, if a client makes a request to a server, the response should always be the same, no matter where the load balancer sends the request to. Which means it should run the same code.

Nginx doesn't even mention route based or endpoint based load balancing in their docs. Maybe they don't consider it load balancing either.

https://www.nginx.com/resources/glossary/load-balancing/

Re: Modules, not microservices

#643

Post by rusebor »

mk89 wrote: post #630
rusebor wrote: post #595

Earlier quoted context omitted.

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

No, because that's not the service API. That's just a view over a table - an internal data structure used to represent some business domain model which should be properly exposed through some implementation-agnostic API. Service B should not care how service A implements it. And the fact you must keep backward compatibility ( see the OP answer above) at the implementation level shows how fragile this approach is - yo…

a view would allow you to change a field's type.

something like this

CREATE VIEW table_read_api AS SELECT TO_CHAR(now_int) as was_char FROM the_table;

not sure that the view is an internal structure because it will be exposed via API as it is.

SQL allows to swap the database at least if no specific SQL features are used.

Re: Modules, not microservices

#644

Post by Dudeman112 »

geodel wrote: post #215
mbork_pl wrote: post #13

Earlier quoted context omitted.

> It's okay to have files with 10,000 lines. Ever since my time as a mathematician (I worked at a university) and using LaTeX extensively, I never understood the "divide your documents/code into many small files" mantra. With tools like grep (and its editor equivalents), jumping to definition, ripgrep et al., I have little problem working with files spanning thousands of lines. And yet I keep hearing that I should di…

It is a kind of cult really. Along with the rise of modern editors which somehow craps out at relatively large files. So small files are sold as well organized , modular , logically arranged codebase. You see these lot of adjectives to support short files. None of them seem to be obviously true to me.

Generally speaking those 10k lines files are shit code, regardless of context

Generally speaking it's only Enterprise(tm) code that has miniscule (not small, miniscule) files with shit code

As long as it's good code, no one cares. If you aren't working on Enterprise(tm) code odds are every bad code you'll look at has way too many lines in the abstraction unit that is being used

Re: Modules, not microservices

#645

Post by JAlexoid »

thayne wrote: post #627
JAlexoid wrote: post #620

Earlier quoted context omitted.

Giving me an example that is created to work explicitly at system/container level isn't the "gotcha" you think it is.(IAM profiles have their own limitations) Separate process vaults, HSMs and other techniques of offloading security credentials - are the same for microservice architecture, as "monolith". The implication that anything other than a microservice architecture must be exclusively an uber executable doing…

> Separate process vaults, HSMs and other techniques of offloading security credentials How do give one module access to the vault/HSM without also giving any other code in the same process access? Even in the event of a security compromise. And that still doesn't address the problem of a vulnerability anywhere in the monolith potentially exposing any sensitive data in processes memory (such as user data including pa…

> I'm comparing specifically against a monolith where you have an "uber executable doing literally everything".

I doubt that anyone here is advocating for a system that it literally everything in one OS process. I bet even you would say that a process with a RDMBS connection is a monolith, even though it doesn't fit your definition.

As for modules - they can run as a separate process on the same machine, to isolate security critical elements.

Conversely, I doubt that any reasonable microservices architecture has every instance of a microservice in its own subnet with a firewall and strict network access permissions... including one off generated API keys.

Most, at best, use a static API key per microsoervice inside one large "secure" network... which leads me back to my point - they're not exactly easier to secure. Methods may differ a little bit, but the techniques are the same.

Then your example of a buffer overflow is going to be as bad for microservices, as for monolith.

Unless you're going to invest in a variety of systems, programming languages and OSes in your stack - your one buffer overflow, turns into buffer overflow on every other microservice... making your claim of "easier to isolate" a little bit delusional. (Classic example of Log4J bug, where monolith or microservices - once you're breached "game over")

Re: Modules, not microservices

#646

Post by JAlexoid »

KronisLV wrote: post #631
JAlexoid wrote: post #621

Earlier quoted context omitted.

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

I could probably design and deploy an HA system for way less. Maybe less than $200/month. It wouldn't be the most performant, but would be HA in three regions.

But it leads me back to my original statement - extreme requirements for uptime don't come out of nothing.

If you're in a location where IT related labor is extremely cheap - you're just going to have people keep one server up.

I know I used to do exactly that, because the server was more than my annual income. But that didn't last long. After the first 20 minute downtime, the budget for HA solution was allocated. But before a certain point downtime wasn't expensive.

Non-profits would probably be the only reasonable exception, where HA and low budgets could coincide. Otherwise - nah...

Re: Modules, not microservices

#647

Post by SgtBastard »

greenhatman wrote: post #642
SgtBastard wrote: post #519

Earlier quoted context omitted.

>A load balancer only works together with servers running the same code. Uh - what? >A load balancer balances traffic between servers Correct. > of the same service or mononlith Incorrect. Load balancers used to work solely at Layer 4, in which case you’d be correct that any 80/443 traffic would be farmed across servers that would necessarily need to run the same code base. But modern load balancers (NGINX et al) esp…

I don't really think of route based "load balancing" as load balancing. That's routing, or a reverse proxy. Not load balancing. Load balancing is a very specific type of reverse proxy. The point is, if a client makes a request to a server, the response should always be the same, no matter where the load balancer sends the request to. Which means it should run the same code. Nginx doesn't even mention route based or e…

https://www.nginx.com/blog/nginx-plus-ingress-controller-kub...

Describes exactly what I’m talking about.

Re: Modules, not microservices

#648

Post by SgtBastard »

closeparen wrote: post #568
SgtBastard wrote: post #519

Earlier quoted context omitted.

>A load balancer only works together with servers running the same code. Uh - what? >A load balancer balances traffic between servers Correct. > of the same service or mononlith Incorrect. Load balancers used to work solely at Layer 4, in which case you’d be correct that any 80/443 traffic would be farmed across servers that would necessarily need to run the same code base. But modern load balancers (NGINX et al) esp…

Each set of upstream hosts in nginx is a single instance of load balancing. You aren't load balancing across services, you're splitting traffic by service and then load balancing across instances of that service. The split is inessential. You can just as easily have homogeneous backends & one big load balancing pool. Instances within that pool can even have affinity for or ownership of particular records! The ability…

> The ability to load balance across nodes is not, as you claimed, a particular advantage of microservices.

Are you replying to the right comment? I made no such claim.

Re: Modules, not microservices

#649

Post by KronisLV »

JAlexoid wrote: post #646
KronisLV wrote: post #631

Earlier quoted context omitted.

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

I could probably design and deploy an HA system for way less. Maybe less than $200/month. It wouldn't be the most performant, but would be HA in three regions. But it leads me back to my original statement - extreme requirements for uptime don't come out of nothing. If you're in a location where IT related labor is extremely cheap - you're just going to have people keep one server up. I know I used to do exactly that…

Those are all fair points, perhaps even more so given the trend of compute and other resources generally becoming more cheap with time (things like Wirth's law and limited IPv6 support aside), thanks for expanding on your arguments!

Re: Modules, not microservices

#650

Post by int_19h »

esailija wrote: post #594
dkarl wrote: post #285

Earlier quoted context omitted.

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

That sounds way too strict to me. A C++ app might use the C++ ABI to communicate with its modules, which would preclude writing them in any other language without jumping through too many hoops. But that's an ABI constraint and says nothing about the actual modularity of the application.

IMO a module is defined as something that has a self-contained API, and versioning rules for that API if the module is evolving.

Post reply on HN