Microservices: Where do they fit within a rapidly evolving integration architecture?

© 2015 IBM Corporation

Microservices: Where do they fit within a rapidly evolving integration architecture?

Kim Clark ([email protected]) Integration and BPM Specialist Version: 1.0 Date: 1st October 2015

Agenda

Defining microservices architecture Is this different from Service Oriented Architecture (SOA)? How is integration architecture changing? Where do microservices fit in across the future landscape? How to start an argument about microservices

1

What is a microservices architecture

Monolithic application

Microservices application

Silo

Microservice (component)



A microservice is a granular decoupled component within a broader application

Agility Scalability Resilience

Simplistically, microservices architecture is about breaking down large silo applications into more manageable fully decoupled pieces

2

Microservices: Why now? (technical standpoint)

•  Internet/intranet/network maturity •  Lightweight runtimes (node.js, WAS Liberty etc.)

•  Methods (Agile, DevOps, TDD, CI, XP etc.)

•  RESTful API conventions (perceived simplicity…)

•  Simplified infrastructure •  Virtualisation (hypervisors), containerisation (Docker),

infrastructure as a service (cloud infrastructure)

•  Platform as a service •  Auto-scaling, SLA management, messaging, caching, build

management.

•  Alternative data access models (NoSQL, MapReduce, BASE, …)

•  Standardised code management (Github, …) 3

Microservice component



Encapsulation is key. Related logic and data should remain together, and which means drawing strong boundaries between microservices.



Silo logic

Silo data

Example operating system boundaries 4




WAS Liberty Node.js

What that might look like in IBM technology? (simplistic representation – NOT a reference architecture!)



WAS ND

DB2

MongoDb

MongoDb

Cloudant

Node.js

IBM Bluemix (PaaS)

MQ Light

5


Microservices inter-communication




Lightweight protocols •  REST (JSON/HTTP) •  Messaging (e.g. AMQP) Aim is complete decoupling, achieved by: •  Messaging wherever possible •  Service registry/discovery •  Load balancing •  Circuit breaker patterns

6


Misconceptions caused by the term “microservice”

Monolithic application Microservices application

Exposed services/APIs



Exposed services/APIs

Silo

Microservices are fine grained SOA services

APIs are microservices

The “service” in “microservice” refers to the granularity of the components, not the exposed interfaces

An application split into microservices may well expose the same APIs as its monolithic equivalent 7

Heterogeneous on the inside, homogeneous on the outside

Freedom to choose runtimes, languages, datastores etc. •  Wise to encourage preferred

technologies. •  Convergence often happens

naturally. Commonality is in the framework in terms of: •  Interconnectivity •  Scalability •  Resilience

8


Microservice (Node.js)

Microservice (Java +

MongoDB)

Microservice (Go +

CloudantDB)

Application frameworks at the network level

Microservices simplify the creation and maintenance of applications by inheriting key non-functional characteristics from their environment. Sounds familiar? Similar in principle to application container frameworks from the past (e.g. JEE), but: Different because •  Framework is agnostic to the

runtime/language used by each microservice

•  Microservices, and framework components sit on the network, rather than within an application server Microservices application



Microservice component Microservice

component Microservice component Microservice

component

Framework provides •  Scaling •  Availability •  Caching •  Messaging •  Connectivity •  …and more

Note that from this perspective there is greater parity between microservices architecture and application servers than there is with service oriented architecture 9

Can everything become a microservice? What about the things you can’t change?

•  You can’t refactor all systems to microservices •  Many applications have an “if it ain’t broke, don’t fix it” policy •  Old systems may be unrealistic to re-engineer

•  What if you can’t change the datastore? •  Are you doing microservices if your data remains in a silo? •  Can you manage without transactionality to the database? •  Will techniques like BASE, CQRS work for your application?

•  How do existing systems fit into a microservices architecture? •  How do you isolate yourself from their availability issues? •  What if they don’t scale as well as your microservices do?

10

Challenges with microservices

•  Maintenance •  Given the aim of freedom of language and runtime, will you have the breadth of

skillsets to maintain the microservices in the future. •  Serialisation – data has to get over the wire

•  Serialisation has advanced massively in recent years. •  Latency

•  A request/response chained down a set of microservices must incur some extra latency from network hops and serialisation.

•  Data sharing •  Not all data can be split into a grid, some things are shared.

•  Real-time dependencies and their combined availability •  Microservices calling other microservices synchronously need careful

consideration. •  Tends to creep, as one service built on top of another.

•  Managability •  How do you manage and monitor a vast network of microservices

•  How does persistence work? Your choices affect how your microservices scale. •  Pessimistic vs. Optimistic •  How handle shared objects •  Relational/NoSQL •  ACID/BASE/CQRS/Event Sourcing?

11

Handling distributed objects

•  First law of distributed objects: Don’t distribute your objects •  http://martinfowler.com/bliki/FirstLaw.html

•  Microservices and the First Law of Distributed Objects •  http://martinfowler.com/articles/distributed-objects-

microservices.html

•  Don’t go too granular, as harder to gather up than to break out.

12

Agenda


13

Application

SOA relates to enterprise service exposure

Application Application Application

Service oriented architecture (SOA) and microservices architecture relate to different scopes

Microservice application

µService

µService µService

µService

Microservices relate to application architecture

However, even this simple distinction can be contentious depending on your definition of SOA

14

What was SOA really about? Integration or Components? “SOA is about how to achieve integration often to aging complex back end systems in order to expose services” In this case SOA is primarily a connectivity p rob lem w i th l i t t l e re la t i onsh ip to microservices architecture and certainly at a different scope.

“SOA is about re-factoring your IT landscape into components that better align with the business needs and expose the services that it needs” Here the connectivity problem is pushed down to the applications and the focus of SOA is on realignment of to the business needs. The service components look more like applications, and we might consider microservices as “more granular SOA”, or even “SOA done right”.

System of Record

Integration Hub

Adapter Adapter

Exposure Gateway

Exposed Services/APIs

System of Record

System of Record

Adapter


System of Record

Adapter

Service Component

Service Component

Service Component

Exposure Gateway

However, SOA, despite it’s broader intent, resulted mostly in interface related technology (e.g. WS-*, ESBs). Microservices architecture is more specific on how components should be implemented, and benefits from more real examples of frameworks, and platforms in this area than SOA did at an equivalent time in it’s history. 15

For large, long established enterprises, integration maturity has been a long journey

Service Exposure (enterprise)

Low Level APIs (platform/package)

Application Integration (application)

Service/API Exposure (external known

consumers)

External API Exposure (public)

Future?

Differentiating between web APIs, SOA, and integration http://www.slideshare.net/kimjclark/ino-2739-impact2014integrationsoaapiv15 Related article on developerWorks http://www.ibm.com/developerworks/websphere/library/techarticles/1503_clark/1305_clark.html 16

What does a large scale integration landscape look like

Systems of engagement •  Modern languages/runtimes •  Agile •  Simple modern connectivity

Systems of record •  Older technology •  Harder to change •  Harder to integrate with

Integration Hub

Integration Hub Adapter Adapter

“Systems of Engagement” Applications

Exposure Gateway (internal)

“Systems of Record”

Applications

Mature large enterprise (simplified)

Exposure Gateway (external)

Adapter Adapter

“Hub and Spoke” integration

“Enterprise Service Bus”

“Web API Gateway”

17

Digital Transformation Creates Multi-Speed IT

Digital •  Timeframe: Days/Weeks •  Scope: Strategic •  Sponsor: CMO •  Budget: Thousands $ •  Complexity: Low •  Buying behavior: Self service

Enterprise •  Timeframe: Months/Years •  Scope: Strategic •  Sponsor: CIO •  Budget: Millions •  Complexity: High •  Buying behavior: Human engagement

Enterprise

IT

Digital Teams

Explore, adopt, adapt with rapid, iterative prototypes

Always on, always available Security, control, and governance

18

Where are microservices most commonly used an established complex integration landscape?

19

Syst

ems

of R

ecor

d (In

tern

al c

o`re

app

licat

ions

)

Integration Hub


Enga

gem

ent

App

licat

ions

Mic

rose

rvic

e ap

plic

atio

ns

SaaS

App

licat

ions

(e

xter

nal)

Adapter

Externally Exposed Services/APIs



Bus

ines

s Pa

rtne

rs

Mapping to example IBM products

20

Syst

ems

of R

ecor

d (In

tern

al c

ore

appl

icat

ions

)

Integration Hub


Enga

gem

ent

App

licat

ions

Mic

rose

rvic

e ap

plic

atio

ns

SaaS

App

licat

ions

(e

xter

nal)

Adapter

Externally Exposed Services/APIs



Bus

ines

s Pa

rtne

rs

WebSphere Application

Server (WAS)

IBM API Management or

IBM Integration Bus

IBM Integration Bus

IBM Integration Bus/ IBM InfoSphere DataStage

WAS Liberty, Node.js, MongoDb,

Cloudant etc. on IBM Bluemix

IBM API Management + IBM DataPower Gateway

Do todays systems of engagement become tomorrows systems of record?

Enga

gem

ent

App

licat

ion

Exposure Gateway

Logic

Sy

stem

s of

R

ecor

d

Presentation

Data

Logic

Presentation

Data

Logic

1

2

3

1 New engagement application •  Provides new, engaging, agile presentation tier •  Cache/subset of data, for temporary and/or low

latency storage •  Integrates with enterprise services/APIs easily.

2 Aging engagement application •  Presentation less attractive and agile •  Data model broadened, with increased integrity

as now used by other applications •  Struggles to integrate with other systems

3 Becomes system of record •  Presentation tier no longer used. Logic/data

now accessed and/or replicated to new systems of engagement.

•  Data model stabilised, and hard to change, with increased integrity as now used by other applications

•  Requires external tools to integrate with other systems.

1.  How long before your microservice application becomes the older system?

2.  How long before you have more than one micoservices platform? 21

The “whole enterprise” view can vary considerably as can the relative impact of microservices

22

Integration Hub


Enga

gem

ent

App

licat

ions

Mic

rose

rvic

e ar

chite

ctur

e Sa

aS

App

licat

ion


Bus

ines

s Pa

rtne

r

Sy

stem

s of

R

ecor

d

Bus

ines

s Pa

rtne

r


Mature large enterprise Microservices just one style of application

Green field online start-up Much of landscape could be microservice based


A green field enterprise needs many of the same functions of a large enterprise, but not to the same depth.

23

Integration Hub


Enga

gem

ent

App

licat

ions

Mic

rose

rvic

e ar

chite

ctur

e

SaaS

A

pplic

atio

n


Bus

ines

s Pa

rtne

r

Sy

stem

s of

R

ecor

d

Bus

ines

s Pa

rtne

r


Mature large enterprise Green field online start-up


Agenda


24

When does integration become application?

25

System of

Record

Integration Hub

Adapter Adapter

Exposure Gateway


System of

Record

System of

Record

Adapter

Exposure Gateway


System of

Record

Integration Hub

System of

Record

System of

Record

Exposure Gateway

Exposure Gateway

API Implementation (application?)

Exposure Gateway

API Implementation (application?)

Exposure Gateway


Early in SOA the focus was on achieving complex connectivity and integration in order to surface services in aged back end systems.

As interface connectivity options on back end systems modernise, the focus moves to the management of service/API exposure.

But if this takes the deeper connectivity issues away, the job of the hub becomes focused primarily on the compositional logic. Is this not really the territory of applications?

Traditional Engagement Application

System of

record

System of

record

SaaS Application

Decentralising service/API exposure

•  Pre-requisites •  Applications make APIs available

–  Requires application level integration tooling

•  Application teams self-administer exposure of their APIs –  Requires API Management

capabilities •  APIs exposed consistently

–  Requires guidelines and governance •  Consistent monitoring

–  Requires API logging and analytics •  Consistent authentication/

authorisation –  Uniform security model/directory

•  Pros •  No additional team required to

enable integration •  Application logic is firmly seated with

the application teams •  Cons

•  What new skills/tools do the application teams need to pick up to enable API exposure

26

Business Partner

Ent

erpr

ise

Bou

ndar

y

Public API

Private API API Gateway

Microservice Engagement Application

Levels of API/service exposure

•  How different is the APIs exposure style at each level?

•  How strong should the application boundaries be?

27


Microservice

Microservice

Within-application

Enterprise-wide

Internet exposed

API/service exposure scope

Agenda


28

Caution with comparisons (or “how to start an argument”!)

Comparisons that make some level of sense

Microservice architecture vs. Service oriented architecture Trying to achieve many of the same things (enable the creation of re-usable business functions as isolated components), but at a very different scale. SOA evolved to become focused on the enterprise scale (though some would say that wasn’t the original intent). Microservices, is primarily at the application scale.

Microservice component vs. Service component Both describe the actual implementation of a business function. They differ primarily in granularity, but also arguably in maintainability, agility etc.

Confusing comparisons

Microservices vs. SOA Microservices are components. SOA is an architecture. What you’re probably trying to compare is Microservices Architecture with SOA (see above).

Microservices vs. APIs APIs are a interface. A mechanism for exposing business function. Microservices are the component architecture used to implement those business functions. It makes no sense to directly compare them.

Microservice vs. Service “Service” means different things to different people. Needs to be qualified. Service Implementation? Service exposure? Service definition? The same could be said for microservice. Need to be specific.

29

Are we really doing microservices?

•  Are we really doing microservices or just aligning with some of the microservices logical principles?

•  Componentization •  Organized around Business Capabilities •  Products not Projects •  Smart endpoints and dumb pipes •  Decentralized Governance •  Decentralized Data Management •  Infrastructure Automation •  Design for failure •  Evolutionary Design Source: http://martinfowler.com/articles/microservices.html

•  Compare to SOA, XP, agile, devops. These often came with an “all or nothing” message, but only a minority ever took them on wholeheartedly.

30

Key points covered •  Defining microservices architecture

•  Microservices overview •  Conditions for true microservices architecture •  Pros and cons

•  Is this different from Service Oriented Architecture (SOA)? •  What was the intent of SOA in comparison to microservices •  Where do microservices fit in the current landscape •  Relationship to APIs

•  How is integration architecture changing? •  Moving away from heavy centralised integration layer •  Lightweight integration capabilities for app teams •  Federation of gateway configuration to application teams

•  Where do microservices fit in across the future landscape? •  When does integration become application build? •  Microservices principles in the integration layer?

31

Questions?

32

Technology

Microservices: Where do they fit within a rapidly evolving integration architecture?