Common misconceptions both in integration groups and around the business in large enterprises that Kim Clark meets are that microservices are fine grained WSDL operations or that APIs are microservices. A reason for this is that they are confusing interface granularity with component granularity, Clark claimed in his presentation at this year’s Microservices Conference in London discussing the microservices movement and the similarities and differences compared with integration architecture. This confusion about microservices and their relation to integration make him wonder if microservices architecture really should have been called micro-component architecture.
Clark, working for IBM with a focus on integration, claims that SOA was really about trying to refactor the IT landscape into components better aligned with the business needs and exposing the services needed. Breaking something up into smaller components is also a microservices style architecture and microservices then start to look like doing SOA right. Because of this he thinks that maybe SOA principles will get a second chance to actually work. One massive problem though with SOA that he describes was funding. No project wanted to take on the initial cost since it didn’t bring any benefit for the business. He believes this has changed today when we can expose APIs outside of an enterprise and potentially find funding models with real money coming into the organisation.
Clark emphasises that large enterprise landscapes are horrible, among other things due to mergers and acquisitions which may have resulted in more than one system for the same type of data. Entities or data with extremely long lifecycles, e.g. mortgages or pensions with an increasing complexity in models and business rules also adds to that picture.
When looking forward Clark’s hope is that in the future all applications within an enterprise are neatly bounded with standardized interfaces, and most importantly with those interfaces exposed and administered by the teams writing the application, not by a completely separate integration team with their own tools which is very common today. Effectively this means federating out and decentralising the whole integration problem over to the teams. In reality Clark believes this will be a long haul for many organisations, it will be an evolution with some backend systems modernized, possibly broken up into microservices application, but also plenty of applications not changed at all lacking any reason for it.
Clark ends by describing some of the confusing comparisons that he has come across during his talks with customers, talks that often start off with bit of a terminology struggle:
- Microservices vs. SOA. This is comparing components with an architecture. The intention is probably to compare SOA with a microservices architecture.
- Microservices vs. APIs. This is comparing interfaces, a mechanism for exposing business functionality, with components implementing those functions which make no sense.
- Microservice vs. Service. Service is a very abstract concept and must be qualified for a meaningful comparision.
Next year’s Microservices Conference in London is scheduled for November 7-8 2016.
