3 ms·

> ... the fundamental problem was centered around a shared architecture of destinations and shared code. From an architectural perspective, there is absolutely

> ... the fundamental problem was centered around a shared architecture of destinations and shared code. From an architectural perspective, there is absolutely no difference between a micro service and a library. The only real difference is in the dispatch mechanism. The problems around configuration management are the same problems we've had as programmers for decades. It's just that the people who are keen on micro services are usually not old enough to have experienced the pain in a different context. Should shared libraries be in different repos, or should you put everything in a single repo? How do you deal with versioning? What happens if one app wants version 1 of the library and another app wants version 2? How do you deal with backwards compatibility of the API? Do you make a whole new library when you decide the old API is incompatible with the new vision? Blah, blah, blah, blah. None of this is a new problem. I can't remember which version of Windows it was (maybe 7?) where they were seriously delayed mainly because they had so many programs using different versions of libraries. Integrating it at the end was apparently complete hell. Since they wanted to have separation of responsibility in their groups, each group was just pounding away implementing the features that they needed, but not integrating as they went -- because that would mean lots of cross team communication. The exact same thing is likely in a large organisation with a ton of micro services. There isn't just one way to solve the problem. Mono repos and monoliths help in certain ways and cause problems in other ways. There are other techniques as well (should we implement ld.so for micro services? :-) ) But as you mention, the real answer is that the solution requires humans, not technology.

robotresearcher 8y ago
> From an architectural perspective, there is absolutely no difference between a micro service and a library. I’ll stick to linking glibc, friend architect. Performance is also architecture.
weberc2 8y ago
Microservices do have various organizational tradeoffs. Individual teams can now own deployment, operation, language, and tooling choices for better or worse. This is probably advantageous for large companies where the number of teams scales beyond what a hierarchical control structure can support. In other words, a single devops team can't make good decisions and prescriptions about languages, tooling, deployment, etc nor effectively react to feedback from the dev teams. Control (power and responsibility) becomes distributed instead of centralized, with all the tradeoffs that entails.
maxxxxx 8y ago
"From an architectural perspective, there is absolutely no difference between a micro service and a library. The only real difference is in the dispatch mechanism." I always tell people if you can't write and maintain a library then don't do microservices.
- scruffyherder 8y ago
  Yes the kids have just rediscovered the move from COM to DCOM. It's so silly that we are wasting so much time rebuilding existing things, poorly.
  - User23 8y ago
    COM wasn't a picnic to work with back when it was the new thing. The toolchain sucked. I'll never write another line of MIDL in my life.
    - maxxxxx 8y ago
      Agreed. Although with tools like Visual Basic it was quite nice to use. Now, DCOM was another story. Pretty much everybody I knew who used it started to become suicidal after a while...
      - voltagex_ 8y ago
        I still maintain a (third party) app that requires DCOM.
    - pjmlp 8y ago
      MDIL has been rejuvenated for C++/WinRT, the new C++17 based projection for UWP.
ronjouch 8y ago
> "should we implement ld.so for micro services? :-)" Working exactly along those lines this week on multiple services exposed over REST APIs, I was wondering if tools exist to check compatibility between them. Said differently, - I have a `swagger.yaml` for my service A managing chipmunks and it says endpoint `/chipmunks` supports an 'color' query parameter. - In service B, I have a `handleToServiceA` that encapsulates calling A. Then say I write `const chipmunks = handleToServiceA.getChipmunks({'colour': 'blue'})`. Are there (whatever the ecosystem) tools that would read serviceA's swagger.yaml, detect my error in serviceB (color -> colour) and report the issue at compile time rather than run time?
- aeonsky 8y ago
  I think this is one of the standard options: https://docs.pact.io https://docs.pact.io
- noahsark769 8y ago
  At work, to alleviate this issue, we use a client library for service A (i.e., one that provides service.getChipmunks(color='blue')). This gives you the compile time check, assuming the client library is a compiled language. One step better is autogenerated client libraries where a new version is created every time a new version of swagger.yaml is deployed. However, I don't know an open source project that does this.
codesuki 8y ago
> Should shared libraries be in different repos, or should you put everything in a single repo? How do you deal with versioning? What happens if one app wants version 1 of the library and another app wants version 2? How do you deal with backwards compatibility of the API? Do you make a whole new library when you decide the old API is incompatible with the new vision? Could you share methods that worked well for you? Asking because those question come up a lot and there never seems to be any conclusion.
parasubvert 8y ago
You’re oversimplifying. Architecturally speaking, there are some similarities between micro services and libraries because they’re both forms of modularization and usually have an API, but there are some stark differences beyond the “dispatch mechanism”. The main difference is that a service’s deployment lifecycle is completely up to the service admin. Microservices are like websites - they can continuously evolve (within their API’s contract) without asking permission from consumers. This is their main superpower and why they’re a way of scaling a development organization without slowing it down too much. In the case of a shared library, it’s completely up to the host admin as to when to upgrade. In the case of a static library, it’s up to the consuming software to determine when to upgrade. A service can upgrade when it feels like it. Issues of API backwards compatibility, forwards compatibility, extensibility, self descriptiveness, versioning, etc. are old issues but usually have different answers when upgrades are truly happening all the time and not just in theory. It tends towards much fewer hard versions and more evolutionary backwards compatibility. IOW, microservices aren’t a cure all, but they do encourage a set of behaviors. Many articles detracting from them seem to have not wanted those behaviors in their org in the first place.
- blub 8y ago
  You are assuming that microservices must be deployed on the internet, however they can be deployed on another type of network or on a single OS installation, which would prevent them from being completely transparently updated. Shared libraries can be an implementation of micro services. On a platform (e.g. Android) it can be that a shared library is updated and then all consumers are forced to update.
  - parasubvert 8y ago
    No, I’m assuming they must be deployed on an IP network of some sort, not necessarily the Internet. A microservice by definition is a networked service. The whole REASON the term was coined was to differentiate from services which often were developed and deployed monolithically, as opposed to truly autonomous runtime processes (aka. bounded contexts). Services, whether SOA, web services, messaging services, or network services etc, as in SOA, describe a client/server architecture with an API. Usually these APIs are designed by the principles of Domain Driven Design, where different teams map to bounded contexts that have their own published API. Microservices are a form of SOA where each API also runs in its own process and thus has independent deployment lifecycle. Many in the SOA world advocated for this 10-15 years ago (and often ignored), and now the industry has gone back and coined a term for this practice. In an organization that does microservices properly at scale, like Amazon, you have teams that build and run and upgrade their service autonomously from others. Read the Steve Yegge rant about Amazon and Platforms to understand this. It allows tremendous parallelisation of effort and allows for thousands of deploys to production daily without breakage. This is hard to pull off though, and a new initiative doesn’t generally won’t more than a small handful of services. If it’s a shared library, then call it a shared library. It has a completely different lifecycle from a microservice. In your Android example, shared libraries by definition are controlled by whomever can dictate OS updates, not the app developer.

robotresearcher 8y ago

> From an architectural perspective, there is absolutely no difference between a micro service and a library. I’ll stick to linking glibc, friend architect. Performance is also architecture.

weberc2 8y ago

Microservices do have various organizational tradeoffs. Individual teams can now own deployment, operation, language, and tooling choices for better or worse. This is probably advantageous for large companies where the number of teams scales beyond what a hierarchical control structure can support. In other words, a single devops team can't make good decisions and prescriptions about languages, tooling, deployment, etc nor effectively react to feedback from the dev teams. Control (power and responsibility) becomes distributed instead of centralized, with all the tradeoffs that entails.

maxxxxx 8y ago

"From an architectural perspective, there is absolutely no difference between a micro service and a library. The only real difference is in the dispatch mechanism." I always tell people if you can't write and maintain a library then don't do microservices.

scruffyherder 8y ago
Yes the kids have just rediscovered the move from COM to DCOM. It's so silly that we are wasting so much time rebuilding existing things, poorly.
- User23 8y ago
  COM wasn't a picnic to work with back when it was the new thing. The toolchain sucked. I'll never write another line of MIDL in my life.
  - maxxxxx 8y ago
    Agreed. Although with tools like Visual Basic it was quite nice to use. Now, DCOM was another story. Pretty much everybody I knew who used it started to become suicidal after a while...
    - voltagex_ 8y ago
      I still maintain a (third party) app that requires DCOM.
  - pjmlp 8y ago
    MDIL has been rejuvenated for C++/WinRT, the new C++17 based projection for UWP.

ronjouch 8y ago

> "should we implement ld.so for micro services? :-)" Working exactly along those lines this week on multiple services exposed over REST APIs, I was wondering if tools exist to check compatibility between them. Said differently, - I have a `swagger.yaml` for my service A managing chipmunks and it says endpoint `/chipmunks` supports an 'color' query parameter. - In service B, I have a `handleToServiceA` that encapsulates calling A. Then say I write `const chipmunks = handleToServiceA.getChipmunks({'colour': 'blue'})`. Are there (whatever the ecosystem) tools that would read serviceA's swagger.yaml, detect my error in serviceB (color -> colour) and report the issue at compile time rather than run time?

aeonsky 8y ago
I think this is one of the standard options: https://docs.pact.io https://docs.pact.io
noahsark769 8y ago
At work, to alleviate this issue, we use a client library for service A (i.e., one that provides service.getChipmunks(color='blue')). This gives you the compile time check, assuming the client library is a compiled language. One step better is autogenerated client libraries where a new version is created every time a new version of swagger.yaml is deployed. However, I don't know an open source project that does this.

codesuki 8y ago

> Should shared libraries be in different repos, or should you put everything in a single repo? How do you deal with versioning? What happens if one app wants version 1 of the library and another app wants version 2? How do you deal with backwards compatibility of the API? Do you make a whole new library when you decide the old API is incompatible with the new vision? Could you share methods that worked well for you? Asking because those question come up a lot and there never seems to be any conclusion.

parasubvert 8y ago

You’re oversimplifying. Architecturally speaking, there are some similarities between micro services and libraries because they’re both forms of modularization and usually have an API, but there are some stark differences beyond the “dispatch mechanism”. The main difference is that a service’s deployment lifecycle is completely up to the service admin. Microservices are like websites - they can continuously evolve (within their API’s contract) without asking permission from consumers. This is their main superpower and why they’re a way of scaling a development organization without slowing it down too much. In the case of a shared library, it’s completely up to the host admin as to when to upgrade. In the case of a static library, it’s up to the consuming software to determine when to upgrade. A service can upgrade when it feels like it. Issues of API backwards compatibility, forwards compatibility, extensibility, self descriptiveness, versioning, etc. are old issues but usually have different answers when upgrades are truly happening all the time and not just in theory. It tends towards much fewer hard versions and more evolutionary backwards compatibility. IOW, microservices aren’t a cure all, but they do encourage a set of behaviors. Many articles detracting from them seem to have not wanted those behaviors in their org in the first place.

blub 8y ago
You are assuming that microservices must be deployed on the internet, however they can be deployed on another type of network or on a single OS installation, which would prevent them from being completely transparently updated. Shared libraries can be an implementation of micro services. On a platform (e.g. Android) it can be that a shared library is updated and then all consumers are forced to update.
- parasubvert 8y ago
  No, I’m assuming they must be deployed on an IP network of some sort, not necessarily the Internet. A microservice by definition is a networked service. The whole REASON the term was coined was to differentiate from services which often were developed and deployed monolithically, as opposed to truly autonomous runtime processes (aka. bounded contexts). Services, whether SOA, web services, messaging services, or network services etc, as in SOA, describe a client/server architecture with an API. Usually these APIs are designed by the principles of Domain Driven Design, where different teams map to bounded contexts that have their own published API. Microservices are a form of SOA where each API also runs in its own process and thus has independent deployment lifecycle. Many in the SOA world advocated for this 10-15 years ago (and often ignored), and now the industry has gone back and coined a term for this practice. In an organization that does microservices properly at scale, like Amazon, you have teams that build and run and upgrade their service autonomously from others. Read the Steve Yegge rant about Amazon and Platforms to understand this. It allows tremendous parallelisation of effort and allows for thousands of deploys to production daily without breakage. This is hard to pull off though, and a new initiative doesn’t generally won’t more than a small handful of services. If it’s a shared library, then call it a shared library. It has a completely different lifecycle from a microservice. In your Android example, shared libraries by definition are controlled by whomever can dictate OS updates, not the app developer.