The document discusses the relationship between microservices, service-oriented architecture (SOA), and APIs, highlighting the evolving landscape of software architecture for digital transformation. It explains microservices as granular, decoupled components that enable agility and scalability, contrasting them with traditional SOA approaches that often focus on integration challenges. It also explores the complexities, benefits, and challenges of adopting microservices, emphasizing the importance of proper management, automation, and maintaining dependencies in a distributed architecture.

1. Microservices, SOA and APIs:
Friends or Enemies?
Co-author:
Brian Petrini
(petrini@us.ibm.com)
Presenter/Author:
Kim Clark
(kim.clark@uk.ibm.com)

2. Evolving exposure of business function
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://ibm.biz/ApiVsSoa

3. Digital Transformation Creates Multi-Modal IT
Digital
• Timeframe: Days/Weeks
• Scope: Strategic
• Sponsor: CMO
• Budget: $
• Complexity: Low
• Buying behavior: Self service
Enterprise
• Timeframe: Months/Years
• Scope: Strategic
• Sponsor: CIO
• Budget: $$$
• 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

4. 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
3

5. What is microservices architecture
Monolithic
application
Microservices
application
Silo
Microservice
(component)
Microservice
(component)
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

6. Microservice
component
Microservice
component
Microservice
component
Encapsulation is key. Related logic and data should remain together, and
which means drawing strong boundaries between microservices.
Monolithic application
Microservices application
Silo logic
Silo
data

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
6
Microservices application
Microservice
(Node.js)
Microservice
(Java +
MongoDB)
Microservice
(Go +
CloudantDB)

8. Why Microservices?
Small scoped, independent, scalable components
Scaling
Elastic scalability
Workload orchestration
Agility
Faster iteration cycles
Bounded context (code and data)
Resilience
Reduced dependencies
Fail fast
7

9. Microservices: Why now? (technical standpoint)
• Internet/intranet/network maturity
• Lightweight runtimes (node.js, WAS Liberty etc.)
• Methods & tools (Agile, DevOps, TDD, CI, XP, Puppet, Chef…)
• Lightweight protocols (RESTful APIs, lightweight messaging)
• Simplified infrastructure
• OS virtualisation (hypervisors), containerisation (e.g. Docker),
infrastructure as a service (IaaS), workload virtualisation
(Kubernetes, Mesos, Spark…)
• Platform as a service
• Auto-scaling, workload management, SLA management,
messaging, caching, build management.
• Alternative data persistance models (NoSQL, MapReduce, BASE,
CQRS)
• Standardised code management (Github, …)
8

10. Microservice
component
Microservice
component
Microservice
component
WAS
LibertyNode.js
What that might look like in IBM technology?
(simplistic representation – NOT a reference architecture!)
Monolithic application
Microservices application
WAS ND
DB2
Mongo
Db
Cloudant
Cloudant
Node.js
IBM Bluemix
(PaaS)
Message
Hub
(Kafka)
JSON/
HTTP

11. Microservice
MicroserviceMicroservice
Microservice
Microservices inter-communication
Aim is decoupling for robustness
Messaging where possible
• Lightweight messaging
(e.g. AMQP, Kafka)
• Publish/subscribe
• Eventual consistency
Direct calls where necessary
Lightweight protocols
(e.g. JSON/HTTP)
• Load balancing/scaling via service
discovery
• Circuit breaker
• Caching
Microservices application
Microservice
Subscribe
JSON
/HTTP
Microservice
Microservice
Message
Hub
API
Microservice
Publish
API
JSON
/HTTP Publish
Service
Discovery

12. 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
componentMicroservice
componentMicroservice
componentMicroservice
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 architecture11

13. Can everything become a microservice?
What about the things you can’t change?
• You can’t refactor all systems to microservices
• Most 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?
• 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?
12

14. Challenges with microservices
Automation
Automation is key to retaining agility: Test automation. Continuous integration and deployment
and more…
Managing and monitoring
How do you manage and monitor a vast network of 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 more often (however, 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
What is the combined availability of all dependencies
Microservices calling other microservices synchronously need careful consideration.
Tends to creep, as one service built on top of another.
How does persistence work?
Pessimistic vs. Optimistic
How handle shared objects
Relational/NoSQL
ACID/BASE/CQRS/Event Sourcing?
13

15. 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 too soon.
It is harder to gather up than to break out.
14

16. Are we really doing microservices?
Martin Fowler/James Lewis
1. Componentization
2. Organized around Business
Capabilities
3. Products not Projects
4. Smart endpoints and dumb pipes
5. Decentralized Governance
6. Decentralized Data Management
7. Infrastructure Automation
8. Design for failure
9. Evolutionary Design
http://martinfowler.com/articles/microser
vices.html
15
12 factor apps
I. Codebase
II. Dependencies
III. Config
IV. Backing Services
V. Build, release, run
VI. Processes
VII. Port binding
VIII. Concurrency
IX. Disposability
X. Dev/prod parity
XI. Logs
XII. Admin processes
http://12factor.net
Are we really doing microservices or just aligning with some of the
microservices principles?
Consider the adoption paths of SOA, XP, agile, devops etc. These often come
with an “all or nothing” message, but can you take on the whole package?

17. 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
16

18. Microservice
component
Common misconception resulting from the term “microservice”
Monolithic application Microservices application
Exposed services/APIs
Microservice
component
Microservice
component
Exposed services/APIs
Silo
component
Microservices are just more fine grained web services
APIs are microservices
“micro” refers to the granularity of the components,
not the granularity of the exposed interfaces
x 1 x 3
x 4x 4
Is “microservices architecture” is really
“micro-component architecture”?

19. Application
SOA relates to enterprise service exposure *
Application ApplicationApplication
Service oriented architecture (SOA)
and microservices architecture relate to different scopes
Microservice
application
µService
µServiceµService
µService
Microservices relate to
application architecture
* this simple distinction can be contentious depending on your definition of SOA
“Microservices, SOA, and APIs: Friends or enemies?”
http://ibm.biz/MicroservicesVsSoa

20. What was SOA really about?
Integration or Components?
Opinion 1: “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
problem with little relationship to
microservices architecture and certainly at a
different scope.
Opinion 2: “SOA is about re-factoring your IT
landscape into components that better align with
the business needs and expose the services that it
requires”
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
Exposed Services/APIs
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. 19

21. 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”

22. Why such split opinions on microservices vs SOA?
21
Integration Hub
Integration Hub
Adapter Adapter
Engagement
Applications
SaaS
Application
BusinessPartner
Systemsof
Record
Business
Partner
Exposure Gateway (external)
Mature large enterprise
Microservices are just one style of application
Exposing services is an integration and data challenge
Green field online start-up
Much of landscape could be microservice based
The landscape is as (micro)service oriented architecture
Exposure Gateway (external)
Microservice
application
µService
µServiceµService
µService
Exposure Gateway (internal)
µService
µService
µService
µService
µService
µService
µService
µService
µService
µService
µService
EnterpriseBoundary
EnterpriseBoundary
Adapter Adapter

23. Where do we typically see microservices in large organisations today?
22
Systems
ofRecord
Integration Hub
Integration Hub
Adapter Adapter
Engagement
Applications
Microservice
applications
SaaSApplications
(external)
Adapter
Externally Exposed Services/APIs
Exposure Gateway (internal)
Exposure Gateway (external)
BusinessPartners

24. Mapping to example IBM products
23
SystemsofRecord
(Internalcoreapplications)
Integration Hub
Integration Hub
Adapter Adapter
Engagement
Applications
Microservice
applications
SaaSApplications
(external)
Adapter
Externally Exposed Services/APIs
Exposure Gateway (internal)
Exposure Gateway (external)
BusinessPartners
WebSphere
Application
Server (WAS)
IBM API Connect or
IBM Integration Bus
IBM Integration Bus
IBM Integration Bus
WAS Liberty,
Node.js, MongoDb,
Cloudant etc.
on IBM Bluemix
IBM API Connect +
IBM DataPower
Gateway
IBM API Connect
IBM MQ feeding
events IBM
Message Hub in
Bluemix, or IIB
talking directly to
Kafka APIs

25. Where might we see microservice principles in use going forward?
24
Systems
ofRecord
Integration Hub
Integration Hub
Adapter Adapter
Engagement
Applications
Microservice
applications
SaaSApplications
(external)
Adapter
Externally Exposed Services/APIs
Exposure Gateway (internal)
Exposure Gateway (external)
BusinessPartners

26. 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
25

27. Integration Domain
Enterprise Ownership Boundary
The Integration Domain of the Hybrid Enterprise
Dedicated CloudPublic CloudSaaS
Customers Business Partners
Appl. Appl.Appl.Appl.Appl.Appl.
Appl. Appl. Appl. Appl.
On-Premise
Appl.Appl. Appl.Appl. Appl.
Local Cloud
Appl. Appl.

28. ApplicationApplication
Decentralising synchronous integration
Engagement
Applications
System
of
Record
Integration
Public API
Enterprise API
API Gateway
System
of RecordSystem
of
Record
Integration
EnterpriseBoundary
Exposure Gateway (external)
SaaS
Application
Business
Partner
In a perfect world…
• Application teams self-
administer exposure of their
own APIs
• Application teams handle their
own integration needs
• Access to external APIs is
governed using the same
mechanisms used to govern
access to internal APIs.
• Application logic is firmly seated
with the application teams
• API monitoring/diagnostics
would be gathered consistently
across the organisation
• Security models would be
implemented more consistently
ApplicationApplication
So where is the ESB now?
Where might we find microservices here?
What about event driven integration?

29. What is an application boundary
in an microservices world?
Similar to application boundaries
today because
• Group related functionality
• Enable more coarse grained
ownership and responsibility (in
addition to full ownership at the
microservice level)
Different because
• Application sub-components
(microservices) are truly
independent.
• Application boundaries can be
easily changed – it’s primarily
about the right ownership
• Application boundaries can spread
across network boundaries (e.g.
between clouds)…but should they!
28
µService
µService
µService
µService
µService
µService
µService
µService
µService
µService
µService

30. Microservice
component
Inter-microservice vs. inter-application communication
Microservices
application
Microservice
component
Microservice
component
Inter-microservice communication
• Lightweight protocols: HTTP,
application messaging
• Runtime component registry
• Client-side load balancing and circuit
breaker patterns
Microservices
application
Exposure Gateway
Inter-application communication
• Enterprise protocols: Managed API
gateways, enterprise messaging
• Design time developer portals
• Gateway load balancing and throttling
JSON/HTTP RESTful communication styles may
be present in both types of communication, but
their implementation may be radically different.
JSON/HTTP

31. 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
30

32. 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.
31

33. Questions?
32
http://www.slideshare.net/kimjclark/presentations
https://www.linkedin.com/in/kimjulianclark

34. Thank You