Here is the link.
Even though there isn’t a formal definition of microservices architectural style, there are some common characteristics that all applications adhering to this architecture should exhibit to make them scalable. These characteristics are smart endpoints & dumb pipes, decentralized governance, infrastructure automation, and failure isolation. Let’s discuss about each characteristic in the following sections.
1. Integration pattern: smart endpoints and dumb pipes
As a microservices application split up its structure into loosely coupled multiple components, natural questions to ask seem to be: In which protocols are pairwise components communication conducted? Given the protocols, in what patterns should the data be routed throughout the application?
a. Communication Protocols
When building communication structures between different processes, there’re many products and approaches that stress putting significant effort into the communication mechanism itself. A good example of this is the Enterprise Service Bus (ESB), where ESP products often include sophisticated facilities for message routing, choreography, transformation, and applying business rules. (ESB is also the fundamental difference between Microservices and Service-oriented Architecture (SOA). Further comparison between the two can be found at [2]).
Microservices, instead, favors an alternative approach: “smart endpoints and dumb pipes”. Microservices applications aim to be as decoupled and as cohesive as possible — they own their own domain logic an act more as filters in the classical Unix sense- receiving a request, applying logic as appropriate and producing a response, which is choreographed using mostly two commonly form of communications: Request-Response and Observer.
No comments:
Post a Comment