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
- “Beauty of #microservices: part 1 #entarch #apparch” http://improving-bpm-systems.blogspot.ch/2015/05/beauty-of-microservices-part-1-entarch.html
- “Beauty of #microservices: part 2 architecting for change” http://improving-bpm-systems.blogspot.ch/2015/05/beauty-of-microservices-part-2.html
- “Beauty of #microservices: part 3 employ #BPM to tame the service granularly beast” http://improving-bpm-systems.blogspot.ch/2016/08/beauty-of-microservices-part-3-employ.html
- “Beauty of #microservices: part 4 from agile development to agility of enterprise systems” http://improving-bpm-systems.blogspot.ch/2016/08/beauty-of-microservices-part-4-from.html
- “Beauty of #microservices: part 5 defragmentation of enterprise data model” http://improving-bpm-systems.blogspot.ch/2016/09/beauty-of-microservices-part-5.html
- “Beauty of #microservices: part 6 managing state is a teamwork http://improving-bpm-systems.blogspot.ch/2016/09/beauty-of-microservices-part-6-managing.html
- “Beauty of #microservices: part 6 managing breaking the monolith” http://improving-bpm-systems.blogspot.ch/2016/09/beauty-of-microservices-part-7-breaking.html
- “Beauty of #microservices: part 8 dump-pipes & smart-containers & minimalistic-microservices” http://improving-bpm-systems.blogspot.ch/2016/09/beauty-of-microservices-part-8-dump.html
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.
- 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)
- 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
- 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.
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.