You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Although it has been clear that what loose coupling meant, the section describes the loose coupling between microservices in the context of containers and benefits of microservices, which should be corrected.
First of all, loose coupling is an architecture pattern (https://en.wikipedia.org/wiki/Loose_coupling), where microservices entirely communicate via APIs (or standard format), hiding the implementation details within each microservice. Moreover, if you see, loose coupling is the design goal in SOA (and not Microservices architectures). There are advantages of systems when components loosely coupled.
Moreover, when the loose coupling implemented, there is no need for a separate database for communication between microservices, which brings another set of challenges into the picture.
The paragraph, which states that one microservice per container is an ideal state, shouldn't part of the loose coupling section. Designing microservices and bundling them for deployment should be indifferent section altogether, and we need to highlight loose coupling more elaboratively in the article. The same goes for runtime discussion in the next para.
The text was updated successfully, but these errors were encountered:
Although it has been clear that what loose coupling meant, the section describes the loose coupling between microservices in the context of containers and benefits of microservices, which should be corrected.
First of all, loose coupling is an architecture pattern (https://en.wikipedia.org/wiki/Loose_coupling), where microservices entirely communicate via APIs (or standard format), hiding the implementation details within each microservice. Moreover, if you see, loose coupling is the design goal in SOA (and not Microservices architectures). There are advantages of systems when components loosely coupled.
Moreover, when the loose coupling implemented, there is no need for a separate database for communication between microservices, which brings another set of challenges into the picture.
The paragraph, which states that one microservice per container is an ideal state, shouldn't part of the loose coupling section. Designing microservices and bundling them for deployment should be indifferent section altogether, and we need to highlight loose coupling more elaboratively in the article. The same goes for runtime discussion in the next para.
The text was updated successfully, but these errors were encountered: