BT

Microservices and Integration from an Enterprise Perspective

| by Jan Stenberg Follow 34 Followers on Nov 30, 2015. Estimated reading time: 2 minutes |

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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

large enterprise landscapes are horrible by Jean-Jacques Dubray

This is a great presentation, but could someone explain to me how Microservices are going to deal with that issue?

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.


IMHO, you cannot understand modern IT architectures if you do not reason in terms of Intent and Outcomes. Systems of Engagements are all about expressing a clear intent (including whether you are authorized to do so) while services are about realizing that intent, i.e. governing the outcome(s).

Yes, there are interfaces at every level (client/SOE, SOE/Services and Service/Microservices not to mention Microservices/SOR), but these interfaces are widely different in nature.

What is key to understand here is that "services" have in effect two sides, the consumer interface and the SOR interface. Services are not "autonomous", never have been, never will be.

A Service Oriented Architecture is healthy if you can "onboard" systems of record easily at the "back" of your services. Outcomes don't change as new SoR get added. Therefore, Microservices are a very positive evolution because they make it easier to onboard the SoR they expose. They may also help normalize the information system, but that require a level of maturity that I am not sure a lot of organizations are ready for because it would fracture the relationship between IT assets and Business Ownership.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT