Hello All,
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.
Hello All,
Paul
My Experience with SOA is almost 2 decades. I was part of the product development team with Sun SeeBeyond, later Glassfish ESB and then Oracle OSB and saw that moving to Cloud as SOACS and OIC; Currently, I am architecting solutions on Mule on Cloud, Hybrid, On-Premises on different kinds of flavours like CloudHub, RTF and Naked Mule. Apart from that, I used Spring Integration and other open-source workflow engines like Aciviti/Flowable etc.
Service-Oriented Development was more or less synonymous with Integration for a long time with the intent of making disparate systems work together seamlessly.; The principles since are generic percolated into application development. There are different kinds of solutions based on Traditional SOA, ESB which are heavy/monolithic but proven w.r.t. transaction management/coherent closed integrations which work; -- Oracle SOA/OSB or IBM, TIBCO etc.
The monolithic solutions are evolving into Microservices for agility, distribution, management and for more freedom to the individual business units to explore and innovate as the time to market is the most important factor in the modern world.
Though it might seem all good Microservices also have a price to pay in terms of:
1. As the number of Microservices surges you need management and control of several applications in terms of
-- security of endpoints and infrastructure,
-- monitoring,
-- versioning,
-- talking to each other -- might need a mesh increasing complexity
2. If you have already an existing infrastructure -- Database etc.. you need business continuity
-- Use strangler to identify services that can be isolated
-- shared database instead of domain-driven model -- compromising the principle of database/service
3. Since these are distributed according to principles to maintain integrity and transactionality you might need to implement (This might be an issue if the developers fail to understand the complexity and empathize importance)
-- CQRS pattern
-- SEDA approach
Hence for me, the solution is a fine line of the delicate balance between Organizational needs and Organizational ability;
I would answer the question (Does the use case really require "Micro"services or Services enough) before I choose how to architect the solution. The considerations are:
1. What's the TCO? And whether the organization can afford the same?
2. What are the "necessary" characteristics of the solutions?
-- Scalability -- container based
-- High Availability
-- Failover
-- XA Transactions? -- can the the data source / resource manager be same?
-- Security
-- Regulations like Gov/HIPAA/SOC etc..
3. Agility: How frequently the components would change -- because this would determine isolation of services without affecting the other parts/components of the solution
4. How can I minimize the compartments so that each one can function independently or what are the services that can be co-located or part of the same deployable
5. How far my resource landscape both infra as well as people can cope with a multitude of changes and requirements.
6. Whether I am going with Cloud or On-premises since this would affect the deployment options as well as the TCO
As the need for agility and dynamism increases you tend towards judicious use of "Micro" services.