Tags
API, enterprise, ESB, Microservices, MSA, SOA, SOI
Moving my recent blogs on Microservices (Microservices & UI, Microservices) forward a bit further as a result of discussing the ins and outs of using the paradigm. Microservices as the very name suggests is the polar opposite of most COTs and particularly ERP solutions which are pretty much modularised monoliths.
It raises the question of can Microservice Architecture (MSA) deliver any benefit in this situation where buy dominates over build. I believe the answer is to an extend yes. Many consider MSA to be SOA++ although I’m not sold on this MSA does exhibit what has been referred to as Service Oriented Integration (SOI) characteristics. That is the key is not the pure service ideas that you would get if you applied the recommendations of Thomas Erl.
The difference between SOI and SOA is that SOI focuses on things like interface contracts and pulling components together (regardless of whether they embody SOA ideals). Where as SOA focuses more on the business process and capability composition. How components are pulled together is an area where MSA has a strong position.
Where SOA and to an extent SOI would need an ESB (or ESB like) platform to perform the business rules and decisioning we should be keeping the intelligence out of the ESB. You will probably still want an ESB or event registration framework so that all services can register to receive events and react as necessary – I.e. Pure pub-sub model.
One of the SOA patterns for dealing with monoliths was to promote the idea of wrapping such services with a SOA abstraction tier so that you can replace the ERP, build out custom capabilities etc. does this hold true friends a MSA approach. I would suggest yes, but rather than the purity of SOA the abstraction should be aiming for the goals of SOI and simplification both in the ERP interaction, but also moving orchestration intelligence out of an ESB into the services. You can seen a Genesis of this potential with Oracle’s Cloud Adapters whose base framework aims to simplify the integration.
So what might be he benefit of building the Microservice layer? We know MSA exchanges code complexity in the service for agility in service delivery. But when there is a monolith behind the services do you gain anything? The answer is potentially, but will be very dependent on the monolith and ESB. For example if you can actually patch your monolith quickly and easily I.e it doesn’t have huge dependency chains and deployment capabilities such as Oracle EBZ 12.2 includes improved deployment framework that reduces or removes downtime. Like wise if the middleware is exploiting the best of SCA (as offered by Oracle SOA Suite) and or an OSGi container such as Apache Karaf then the benefits start to become more marginal. It becomes more a devil you know style of debate.