5 ms·

Because there is state?

anyfoo 5y ago
I think the question was meant to be along the lines of: Why have that unit as a separate service then, instead of just locally as, e.g., a shared library, running in the same process? Unless you have the specific need of that piece of code not being in the same process/container/computer/network. Unless your linking time is prohibitively high (but even very large software takes minutes, not hours), the benefit to compile time should be the same. But maybe "redeploying" is more disruptive (I don't know, I haven't done web development for something approaching 10 years now), and depending on the language, problems in one part can crash the whole process. (But depending on the actual process model used, shouldn't it just restart? Unless the language is not sufficiently memory safe, e.g. it's C, and you get way worse problems with memory smashers.)
- gravypod 5y ago
  Think of a situation where you have, for example, a database like Redis. If you need to run two systems that need to access that data there will need to be some process that maintains that data and allows other people to access it. You would have a hard time to make a resource efficient distributed in-process key-value store. You could have an in-process library but this would cause your two programs to have either: 1. Store different data 2. All writes would need to be distributed to all processes (looping back to needing a network connection).
  - anyfoo 5y ago
    Yeah, that makes sense for the data store, but don't microservices split up much more? Of course this could quickly devolve into a conversation about "at what point is it microservices".
    - gravypod 5y ago
      > Of course this could quickly devolve into a conversation about "at what point is it microservices". Yep, exactly. I've built more than one microservice in my time that loads up a few GB of data into RAM and efficiently queries it for a lot of services. At that point the line between DB and service gets blurry. But, essentially, the TCP connection between your services isn't necessarily a big issue. If there is some logic/operation/access that is complex it makes sense to chuck a language-independent interface in front of it for most use cases. There are some where performance trumps maintenance but where it doesn't I think this abstraction is helpful.
- jmchuster 5y ago
  Service A calls to Service B and interacts with state, then Service B has a background process to do some post-processing on its state, then Service C calls to service B and interacts with state, then you interact with Service B's web interface to interact with state. How is the shared library managing and persisting the state between all these interactions?
  - anyfoo 5y ago
    The suggestion was to not split up the application into (many) services in the first place. Modularity and modular interfaces can exist without that.
    - jmchuster 5y ago
      Generally when I think about a shared library, i think about a interface that manipulates state in memory to return some result. I think i'd be quite surprised if it had some built-in persistence, if it launched its own background processes, and had a web interface included. I would expect libraries to almost intentionally not cross these types of boundaries.
      - anyfoo 5y ago
        Sigh. We can continue playing that game, or acknowledge that the question was between microservices vs. more monolithic approaches, obviously in situations where both is equally viable. If your boundaries between services (or whatever) are only what you just mentioned, then either it is a small application, or the services are not very “micro”. Again, my, and likely OPs point, was that distinct, modular development (and for example the mentioned low compile times) is not contingent on separate services and IPC or even RPC, which come with a whole other can of worms. (BTW your scope of shared library is also pretty narrow. For persistence for example, SQLite is essentially a persistence layer that is a shared library. And some libraries do certainly spawn threads for their work. But that’s not really the point.)
        jmchuster 5y ago

I think the question was meant to be along the lines of: Why have that unit as a separate service then, instead of just locally as, e.g., a shared library, running in the same process? Unless you have the specific need of that piece of code not being in the same process/container/computer/network. Unless your linking time is prohibitively high (but even very large software takes minutes, not hours), the benefit to compile time should be the same. But maybe "redeploying" is more disruptive (I don't know, I haven't done web development for something approaching 10 years now), and depending on the language, problems in one part can crash the whole process. (But depending on the actual process model used, shouldn't it just restart? Unless the language is not sufficiently memory safe, e.g. it's C, and you get way worse problems with memory smashers.)

gravypod 5y ago
Think of a situation where you have, for example, a database like Redis. If you need to run two systems that need to access that data there will need to be some process that maintains that data and allows other people to access it. You would have a hard time to make a resource efficient distributed in-process key-value store. You could have an in-process library but this would cause your two programs to have either: 1. Store different data 2. All writes would need to be distributed to all processes (looping back to needing a network connection).
- anyfoo 5y ago
  Yeah, that makes sense for the data store, but don't microservices split up much more? Of course this could quickly devolve into a conversation about "at what point is it microservices".
  - gravypod 5y ago
    > Of course this could quickly devolve into a conversation about "at what point is it microservices". Yep, exactly. I've built more than one microservice in my time that loads up a few GB of data into RAM and efficiently queries it for a lot of services. At that point the line between DB and service gets blurry. But, essentially, the TCP connection between your services isn't necessarily a big issue. If there is some logic/operation/access that is complex it makes sense to chuck a language-independent interface in front of it for most use cases. There are some where performance trumps maintenance but where it doesn't I think this abstraction is helpful.
jmchuster 5y ago
Service A calls to Service B and interacts with state, then Service B has a background process to do some post-processing on its state, then Service C calls to service B and interacts with state, then you interact with Service B's web interface to interact with state. How is the shared library managing and persisting the state between all these interactions?
- anyfoo 5y ago
  The suggestion was to not split up the application into (many) services in the first place. Modularity and modular interfaces can exist without that.
  - jmchuster 5y ago
    Generally when I think about a shared library, i think about a interface that manipulates state in memory to return some result. I think i'd be quite surprised if it had some built-in persistence, if it launched its own background processes, and had a web interface included. I would expect libraries to almost intentionally not cross these types of boundaries.
    - anyfoo 5y ago
      Sigh. We can continue playing that game, or acknowledge that the question was between microservices vs. more monolithic approaches, obviously in situations where both is equally viable. If your boundaries between services (or whatever) are only what you just mentioned, then either it is a small application, or the services are not very “micro”. Again, my, and likely OPs point, was that distinct, modular development (and for example the mentioned low compile times) is not contingent on separate services and IPC or even RPC, which come with a whole other can of worms. (BTW your scope of shared library is also pretty narrow. For persistence for example, SQLite is essentially a persistence layer that is a shared library. And some libraries do certainly spawn threads for their work. But that’s not really the point.)
      - jmchuster 5y ago