“Meaningful architecture is a living, vibrant process of deliberation, design, & decision, not just documentation.” Grady Booch
As a passionate software engineering company, we have always had our eye on developments in software architecture. Even with that experience though we have to admit that sometimes it seems that the more things change the more they remain the same. The subtle but important shift from Service Oriented Architecture to Microservices and what has been called Micro-SOA seems to be a case in point.
Here’s a definition from Wikipedia, “….. is an architectural pattern in computer software design in which application components provide services to other components via a communications protocol, typically over a network. The principles of ..… are independent of any vendor, product or technology.” It’s not hard to imagine “SOA” filling those blanks but just as easily you could be talking about “Microservices”. There seems to be general agreement that Microservices is an evolution of SOA and to that extent the overlap in the definitions is understandable but clearly deeper examination is called for to separate the two and define when one approach scores over the other.
The focus in SOA was on the business services – making them reusable and building them on top of large, what has been called “monolithic” applications that were structured and secure. The intent behind separating the enterprise-wide IT into business services was to become more scalable, agile and flexible. Potentially since the focus is on business services this approach could deal with systems across applications, systems and functional groups. For example a loan sanctioning “service” may be called upon to get data about the customer, their past history, credit rating and risk profile from several different systems and may then have to “consult” with business specific applications before giving a go-ahead for disbursement to a separate business functional area responsible for making payments. Even relatively simple business processes could call for many such client programs, each making their own connections. Without getting into too many gory details let us just say that the XML data formats that SOA is based on, WSDL, uses an enterprise-shared data model. This introduces some complexity when something has to be changed – say for example the way the risk profile of the customer is tagged. Despite not really having anything to do with each business area chances are this change will impact each individual business process. You’re probably beginning to understand where the “monolithic” description is coming from.
It seems clear that there is need to introduce more flexibility into this approach. This is where Microservices come in. Chris Haddad, formerly of Gartner explains just how, “Microservices is about taking the organization’s services portfolio and decomposing them based on business domain function.” The approach calls for breaking up each service into individual applications, process elements and smaller, more specific services that allow those processes to function as designed. The individual applications tend to be smaller, easier to manage and control. This is where the Micro-SOA becomes important – clearly just breaking up the “monolithic” service into processes is easier said than done. There is an enterprise infrastructure and a functional eco-system that will be impacted. The Architecture, actually the Micro-SOA, will thus have to go far deeper than just parcelling out the business service into constituent elements.
This is also where some of the major challenges lie in moving to a Microservices way of thinking. Developers are more attuned to considering applications as a single, self-contained unit with all the constituent elements within easy reach, so to say. The Micro-SOA approach forces them to radically rethink how they look at such applications – not always the easiest thing to do.
We agree that at face value the concepts seem to overlap. At such times, it’s good to recall what author Neal Stephenson said, “Intelligent people can handle subtlety. They are not baffled by ambiguous or even contradictory situations – in fact, they expect them and are apt to become suspicious when things seem overly straightforward.” Since software architects are all intelligent people clearly we expect they will all be up for the SOA to Micro-SOA shift.