Microservices and SOA: Better Together

integration is essential.

no single enterprise can have just one technology or just one system to cater all their computing needs. enterprises need to be composed of multiple programming languages, multiple vendor applications, multiple partner systems, legacy applications, etc.

one architecture style simply cannot fulfill it needs since we typically deal with discrete technologies from many generations, heterogeneous technologies, different vendor systems, and much more. on top of that, each system possesses different architectural abilities.

when a new project comes on board, most solution implementations typically involve leveraging existing investments in systems, catalogs of services, and staff with existing skill sets and experiences. designing solutions using existing systems is only possible with application integration.

application integration, in mule’s words, is:

“the sharing of processes and data among different applications in an enterprise. for both small and large organizations alike, it has become a mission-critical priority to connect disparate applications and leverage application collaboration across the enterprise in order to improve overall business efficiency, enhance scalability, and reduce it costs.”

application integration can happen at three levels:

1. user interface integration (portals) , though some may say that this is a dated integration style and should be deferred due to its tradeoffs

2. system or services integration

3. data integration

software architectures

experts admit that no single architecture is the architecture for all enterprise it needs. it all depends on what system you are designing and where it is used.

some of the well-known architecture styles are:

• layered architecture

• event-driven architecture

• service-oriented architecture

• microservices architecture

• service-based architecture

• microkernel architecture

microservices and soa

while all architecture patterns are important to know, microservices architecture is catching up all the trends in today’s industry for distributed applications.

microservices is indeed a very well-thought-out architecture pattern for applications development, and further services are exposed via restful interfaces.

figure 1: microservices architecture diagram

some characteristics of microservices are that they share nothing, have bounded context, use a restful service interface, involve direct invocation and api layers, favor rewrites over maintenance, and are separately deployed.

some of these characteristics translate to atomic services, no distributed transactions, statelessness (since they were exposed via rest), whether or not something is the right size for microservices, and idempotence.

soa is not just esb or a full-blown product. soa is an architecture style at the enterprise level that brings visibility of all types of services and systems like rest services, soap services, and legacy apps via service layer.

figure 2: service oriented architecture diagram

some traits of soa are that it involves the interoperability of systems, offers native support to integrate, compliments with microservices and the cloud, promotes the reuse of it assets, and involves service taxonomy.

soa doesn’t prescribe how to implement a service. this is left to the individual service designer. since soa primarily solves the application integration problem, it works for most integration needs such as file-based integration, data-based integration, and ws-based integration. these are all possible in soa through jca, adapters, etc.

following are some intrinsic characteristics of services involving soa from lucas jellema in his soa handbook:

• service should support atomic operations whenever possible.

• service should be stateless to keep the footprint small.

• service should be idempotent to allow retries without side effects.

• service should be of the right size .

now, if you scroll back a bit, you can find that microservices characteristics perfectly match the service definition of a service per soa.

service in soa architecture under any taxonomy can be materialized by microservices. maybe that’s the reason why everyone's said, “microservices are soa done right!” those who do budgeting and project costs, don’t you agree that any service is reusable at the enterprise level?

in conclusion, microservices don't replace soa, but they complement very well with soa for large enterprises.