Microservices Characteristics


Definition 1
Microservices is an application architectural approach where a large application is 1) composed of several independent, deployable service units. 2) Each unit provides a unique service. 3) The service, in turn, encapsulates and implements a well-defined process. 4) The life cycle of each deployable service unit is managed independently by different functional teams.

Characteristics of microservices
  1. Encapsulate a customer or business scenario. 
  2. Developed by a small engineering team. 
  3. Written in any programming language and use any framework. 
  4. Consist of code and (optionally) state, both of which are independently versioned, deployed and scaled. 
  5. Interact with other microservices over well-defined interfaces and protocols. Have unique names (URLs) used to resolve their location? 
  6. Remain consistent and available in the presence of failures.
https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-overview-microservices

Microservices Orchestration Vs Choreography

Service orchestration works through the exchange of messages in the domain layer of enterprise applications. Since individual services are not programmed to communicate with other services, messages must be exchanged according to a predetermined business logic and execution order so that the composite service or application can run as it is demanded by the end-user. This is usually accomplished through enterprise application integration (EAI), which enables data integration, and the use of a central messaging engine such as an enterprise service bus (ESB), which routes, transforms and enriches messages.

Service choreography is also related to service orchestration, as both are employed to create composite services and applications in service-oriented architectures; however, it is still worth pointing out the differences. A service choreography model works without a central messaging engine or orchestrator while a service orchestration model relies on a central controller to couple services. In the former, the participating services each know the business logic and sequence and timing of message exchanges. In the latter, the participating services don’t know that they are being orchestrated as part of a higher-level service; only the central controller knows the business logic and messaging sequence.