5 ms·

Because of dependency issues like he mentioned. If I am using Library A which depends on version 1 of Library C and I need to start using Library B which depend

Because of dependency issues like he mentioned. If I am using Library A which depends on version 1 of Library C and I need to start using Library B which depends on version 2 of Library C then I have a clear problem because most popular programming languages don't support referencing multiple different versions of the same library.

furstenheim 3y ago
This node got it just right. You only get this issue for big stateful libraries, like frameworks
rmbyrro 3y ago
Can't we just isolate these two services in containers, using different library versions? They don't need to be microservices in order to isolate dependencies, do they? In Python, for instance, you don't even need containers. Just different virtual environments running on separate processes.
- mjr00 3y ago
  If you have two separate processes running in two separate containers... those are two separate services. You need to solve the same problems that would come with running them on two different EC2 instances: what's the method for communicating with the other container? What happens if the other container I'm calling is down? If the other container is down or slow to respond to my API calls, am I dealing with backpressure gracefully or will the system start to experiencing a cascade of failures?
- jethro_tell 3y ago
  I suppose if you do that, they will communicate over the network likely via api and have the ability to scale independently. You just invented microservices, lol.
foobiekr 3y ago
You’re not wrong here but usually this comes down to having one or a small number of version specific container processors (and I do not mean container in the docker sense) to host those functions. Not microservices. That said, almost always, if you are seriously trying to keep old unsupported dependencies running, you’re violating any reasonable security stance. I’m not saying it never happens, but often the issues that the code is not understood, and no one is capable of supporting it, and so you are deep in the shit already.
slowmovintarget 3y ago
OSGi and Java Modules would like a word. Too few developers use the facilities available for that kind of in-process isolation, even when it is possible. (Don't tell me Java isn't popular... It may be the new COBOL, but it's still mainstream.)
- lemmsjid 3y ago
  Good show for mentioning that. If it becomes commonplace for popular runtimes and languages to be able to load modules and their dependencies at that level, then a lot of arguments for service encapsulation go away. I think in these discussions, a lot of times people are taking past one another. If I start putting a JRE-targeted application together, I know I can eventually reach for isolated modules if I follow good internal practices, whereas if I'm in Python land it's pretty unattainable.
  - smaudet 3y ago
    AWS Lambdas and OSGI invocations are the same thing! (Except one costs you money and one doesn't, guess which one is easier to use).
- lmm 3y ago
  > OSGi and Java Modules would like a word. OSGi is the one that's deprecated and Java Modules is the one that can't actually provide that functionality yet, right? Or is it the other way round? Either way you get the point.
  - pjmlp 3y ago
    Java modules are doing alright since Java 9, are the foundation for Java's linker and code stripping on AOT, while Eclipse keeps using OSGi just fine.
    - slowmovintarget 3y ago
      That's right. OSGi predated the Java Module system, and in many cases, informed its design. I think it's unfortunate that when they were including the Module system into Java, they didn't just import OSGi whole. OSGi has an in-VM service registry which allows late binding of "services" by interface. This means you can do a lot of sophisticated mixing and matching of capabilities with OSGi, including the ability to load and use incompatible versions of the same library (if need be) in different parts of your code. More than a decade ago, I built an app server system that used an OSGi base for server-side products and agent systems. I even had a flavor of JBoss running on OSGi (with dramatically faster start up times) before JBoss went OSGi on its own. But now my teams do their work in Node. Isolation is by process, hopefully, maybe, and we're right smack back in version hell.

furstenheim 3y ago

This node got it just right. You only get this issue for big stateful libraries, like frameworks

rmbyrro 3y ago

Can't we just isolate these two services in containers, using different library versions? They don't need to be microservices in order to isolate dependencies, do they? In Python, for instance, you don't even need containers. Just different virtual environments running on separate processes.

mjr00 3y ago
If you have two separate processes running in two separate containers... those are two separate services. You need to solve the same problems that would come with running them on two different EC2 instances: what's the method for communicating with the other container? What happens if the other container I'm calling is down? If the other container is down or slow to respond to my API calls, am I dealing with backpressure gracefully or will the system start to experiencing a cascade of failures?
jethro_tell 3y ago
I suppose if you do that, they will communicate over the network likely via api and have the ability to scale independently. You just invented microservices, lol.

foobiekr 3y ago

You’re not wrong here but usually this comes down to having one or a small number of version specific container processors (and I do not mean container in the docker sense) to host those functions. Not microservices. That said, almost always, if you are seriously trying to keep old unsupported dependencies running, you’re violating any reasonable security stance. I’m not saying it never happens, but often the issues that the code is not understood, and no one is capable of supporting it, and so you are deep in the shit already.

slowmovintarget 3y ago

OSGi and Java Modules would like a word. Too few developers use the facilities available for that kind of in-process isolation, even when it is possible. (Don't tell me Java isn't popular... It may be the new COBOL, but it's still mainstream.)

lemmsjid 3y ago
Good show for mentioning that. If it becomes commonplace for popular runtimes and languages to be able to load modules and their dependencies at that level, then a lot of arguments for service encapsulation go away. I think in these discussions, a lot of times people are taking past one another. If I start putting a JRE-targeted application together, I know I can eventually reach for isolated modules if I follow good internal practices, whereas if I'm in Python land it's pretty unattainable.
- smaudet 3y ago
  AWS Lambdas and OSGI invocations are the same thing! (Except one costs you money and one doesn't, guess which one is easier to use).
lmm 3y ago
> OSGi and Java Modules would like a word. OSGi is the one that's deprecated and Java Modules is the one that can't actually provide that functionality yet, right? Or is it the other way round? Either way you get the point.
- pjmlp 3y ago
  Java modules are doing alright since Java 9, are the foundation for Java's linker and code stripping on AOT, while Eclipse keeps using OSGi just fine.
  - slowmovintarget 3y ago
    That's right. OSGi predated the Java Module system, and in many cases, informed its design. I think it's unfortunate that when they were including the Module system into Java, they didn't just import OSGi whole. OSGi has an in-VM service registry which allows late binding of "services" by interface. This means you can do a lot of sophisticated mixing and matching of capabilities with OSGi, including the ability to load and use incompatible versions of the same library (if need be) in different parts of your code. More than a decade ago, I built an app server system that used an OSGi base for server-side products and agent systems. I even had a flavor of JBoss running on OSGi (with dramatically faster start up times) before JBoss went OSGi on its own. But now my teams do their work in Node. Isolation is by process, hopefully, maybe, and we're right smack back in version hell.