Services, APIs and Microservices – Part 3

In the first part of this series we introduced a baseline taxonomy for Services, APIs and Microservices where:

• Microservices are merely integration points into Systems of Record, focused on CRUD
• Services manage outcomes given an intent, focused on consistency
• APIs  are simple adapters which map (application) activities to intents

Before pundits start calling that taxonomy, sacrilege, I’d like to offer a simple test to check your architecture, a simple application activity that anyone can relate to: “change of Address”.

In any given IT organization, that activity can appear in many applications, for different products, different user roles and different types of address:

• Product – brokerage
• Product – IRA
• Product – 401k
• Product – banking
  • Application – web
    • Role – customer
      • Type – mailing
      • Type – home
    • Role – beneficiary
      • Type – mailing
      • Type –home
  • Application – mobile
  • …
• …

Why not ask yourself, how would I implement that kind of outcome (changing an address across my entire information system) given my current architecture?

Of course, in a monolith, a simple stored proc would do, and the schema would generally be normalized, or close enough.

In a microservices architecture, each leaf of that tree will end-up being a microservice (remember microservices are autonomous). Some people would suggest it’s safe to wire directly application activities to their corresponding microservice, which, in this case, would directly update its system of record.

The general thinking in the industry is to build microservices along “business capability” lines with some random integration point between them:

Image may be NSFW.
Clik here to view.

That kind of topology is well known to the average IT professional… we have been practising it for at least three decades, when we broke down … the mainframe into “agile” client-server systems.

That architecture, also know as, the “Smart Endpoint and Dumb Pipes” Architecture is a dead-end because neither the Applications, nor the Services can be autonomous, by definition, only the Systems of Record and their integration points (aka microservices) can be, and should be.

That dumb pipe architecture (that we have desperately tried to run away from) entails that, for every activity we duplicate some logic either in the client or the microservice:

1. the logic that validates the address (such as calling an API to fetch a postal address, given a user address)
2. any consistency logic that ensures that the new address is properly replicated in all systems of record, and perhaps a paper or email notification is sent to user

Martin Fowler has made lots of money shorting complexity and buying tiny concepts from user stories to microservices, but he seems to have missed that the underlying concept that structures information systems is “outcome”.  User stories should be written in terms of “outcomes” (and not actions), and a proper “Service Oriented Architecture” should be made of Services that manage outcomes and intents, not data or actions. This has nothing to do with ESB or whatever, this is simple common sense.

Why is it common sense? you should just ask yourself the simple question, how do I add a new product application to my existing landscape? (and how would I wire its change of address activity)

Assuming this application has its own system of record, it will add new outcomes you can reach (and their intentional interface), and of course new APIs that consume existing services in a slightly varying way. When you use Service, API and Microservice Architecture, you can onboard a new system of record behind the service layer and quickly reach consistency for your entire information system without disrupting other apps (arrows in red) or costly denormalization or integration by reusing existing APIs and Services.

That architecture is the key to innovate quickly and cost effectively. That is how you break the monolith, and rapidly stand up (or decommission) applications. Microservices alone will not break much, other than your bottom line (literally).

Image may be NSFW.
Clik here to view.

In the small, we can safely avoid making a distinction between Services, APIs and Microservices, in the large, when we have hundreds, if not thousands, of “intents” and corresponding outcomes, this problem will quickly get out of hand.

In the last part of this series, we’ll focus on how the information model relates to the API and Service interfaces.