SOA Governance Forum
Aug 11 2020
One of the objectives of the Service-Oriented development is to bring closer business and development by reducing the gap between their jargon, semantic, and overall the granularity of their concerns.
Let’s take an example: When a developer talks about data mapping as a service, she/he is far below the radar of the business where a service is a coarse grain element (or entity) such as “Calculate a credit risk” or “Find the best haulage contractor for my customer”. By intensively using service orchestration and composition within processes, Service-Orientation development attempts to create coarse grain services and process that matches business concerns.
Microservice orientation chose a few years ago another way by using “micro” services independent and decided to rely on the infrastructure to link these tiny services to create business process implementations.
I never hide reservation about this philosophy for two main reasons. I understand the willpower to develop small (micro) services, as a sign to go out of the business scope (below the radar). Also, I think that pushing aside service orchestration for a technical composition based on the infrastructure, increase the complexity of process developments.
I would like to get feedback from the community and understand if for you, using microservices development impacts your service granularity and how it fits with your business requirements. On the other side, does a decentralised process impact your process development and evolution since the process context is also distributed and travel from service to service without centralisation?
Thank you for your feedback.