2016-09-09

Beauty of #microservices: part 9 explicit coordination as a microservice

1 Introduction


This blogpost is inspired by several blogposts about microservices and it is based on the blogpost [REF1] “Architecting #cloud-friendly application architecture #apparch (inspired by #microservices)” http://improving-bpm-systems.blogspot.ch/2015/04/architecting-cloud-friendly-application.html

See also the previous blogposts of “Beauty of #microservices” series

2 Things work better when they work together, on purpose (from www.tetradian.com )


To be efficient, their work must be explicitly coordinated. Certainly, this is strongly applied to all the microservices comprise an application. Of course, it is considered that an application is a several very loosely-coupled clusters of microservices to be coordinated (for example, each such a cluster is responsible for the lifecycle of a particular business entity).

Although there is an opinion that “Service is not comprised of other services due to the independence requirement” (see https://www2.opengroup.org/ogsys/catalog/W169), it is considered that some (with bigger responsibility) microservices can be assembled from other (with smaller responsivity) microservices.

There are several techniques to implement coordination.

Orchestration

  • nature: centralised at design-time and centralised at run-time thus may be explicit
  • specific: there is a misconception that it uses only synchronous communication (à la RPC) although it may use also asynchronous communication (à la message-passing)

Choreography

  • nature: decentralised at design-time and decentralised at run-time thus implicit
  • specific: uses only asynchronous communication (à la message-passing)

Reactive streams and runnable graphs

  • nature: decentralised at design-time and centralised at run-time thus implicit
  • specific: optimised for high volume event processing

Business-process-based

  • nature: centralised at design time and decentralised at run-time thus explicit
  • specific: each case is a completely separate instance with its own lifecycle; and the process may be another microservice

3 Implementation of business-process-based coordination


Of course, it should be a DSL to define an explicit coordination (e.g. BPEL, BPMN, etc.). Using the terminology from the section 7 of [REF1], a DSL-processor may act as a specialised container for DSL-scripts. Also, some microservices which are coordinated by a DSL-script may use some specialised containers. For example, a specialised container for human-operations, a specialised container for business rules, a few specialised containers for automated-operations.

4 Conclusion


Some advantages of the business-process-based technique:
  • Assembled microservices have no routing logic (thus they follow SRP). 
  • All the necessary microservices (assembled and dependent) can be instance-bound (help to predictive analytics).
  • All the necessary microservices (assembled and dependent) can be instantiated on demand (this minimises DEVOPS).
  • A particular instance may be stopped for the error-recovery without influencing other instances (operational isolation).
  • A few versions of the same coordination (i.e. business process) may co-exist (versioning is easy).
  • Different instances of the same process and their may be executed on different nodes (linear scaling out).
  • Easy to visualise for the business people.



Thanks,
AS
Posted by Alex at 14:07
Labels: , , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)