open

Insights

Thoughtful impact

The Agile Architect Part 3: Microservices and SOA

  Home/Media/Insights/Agile/The Agile Architect Part 3: Microservices and SOA
The Agile Architect Part 3: Microservices and SOA
Sonia Vaessler
Principle Enterprise Architecture Consultant, Trainer, DVT

The Agile Architect Part 3: Microservices and SOA

After reading a Blog article by a learned colleague on "making a success of Microservices" I am asking myself whether Microservices and SOA would create a conflict of interest in my software development deliveries.


So please tell me if I understand it correctly.


Microservices must be autonomously deployable whereas SOA services are often implemented in deployment. Microservices adds to the grouping concept, defining a service over all application layers, including the UI. So people already doing SOA may gain technology liberation and an alternative to mature technologies. Because individual services within an application can be progressively swapped out for those based on more modern technologies, without having to replace the entire application.


Microservices is not a substitute to SOA, but rather a way to restore suppleness that may have been lost in SOAs that became too rigid.


The prospect for microservices could be viewed as a way to shift from a top-down to a bottom-up approach to SOA. As an example, where legacy applications must be replaced or reimplemented by a more modern solution a microservices architecture can provide a basis for a holistic SOA approach.


In the end, it all comes down to business value. Many people build “functional services” that create architectural bottlenecks in an SOA. If the platform lacks a feature, you should create a library, not a runtime service. We as developers and architects should be busy building business services that offer specific value to the organisation. Microservices could offer the means to deliver that value.