Think2018 2314-Microservices and BPM-can they coexist?

Session : 2314
Microservices and BPM -
Can they coexist?
Claudio Tag
Cloud Solution Architect
Brian M. Petrini
Technical Offering Manager – IBM BPM
Kim Clark
Integration Portfolio Architect
This presentation can be found on SlideShare:
http://www.slideshare.net/brianmpetrini/

Legal Disclaimer
• © IBM Corporation 2018. All Rights Reserved.
• The information contained in this publication is provided for informational purposes only. While efforts were made to verify the completeness and
accuracy of the information contained in this publication, it is provided AS IS without warranty of any kind, express or implied. In addition, this
information is based on IBM’s current product plans and strategy, which are subject to change by IBM without notice. IBM shall not be responsible for
any damages arising out of the use of, or otherwise related to, this publication or any other materials. Nothing contained in this publication is intended
to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of
the applicable license agreement governing the use of IBM software.
• References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates.
Product release dates and/or capabilities referenced in this presentation may change at any time at IBM’s sole discretion based on market
opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. Nothing contained in these
materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue
growth or other results.
• Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or
performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multiprogramming
in the user's job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an
individual user will achieve results similar to those stated here.
• All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have
achieved. Actual environmental costs and performance characteristics may vary by customer.
• All references to fictitious companies are used for illustration purposes only.
© 2018 IBM Corporation
2

3© 2018 IBM Corporation
Silo logic
Silo
data
Microservice comp Microservice comp
Microservice
component
Microservices ApplicationMonolithic Application A set of principles to break
down of large components
into smaller, self-contained
ones enabling greater
agility, more elastic
scalability and and more
differential resilience.
Fundamental principles
include maximizing
isolation and decoupling
between components
(including their data).
Supporting requirements
include automated DevOps
pipelines, good automated
test coverage, and,
fundamentally, leveraging
cloud-native
infrastructure and
platforms.
What is Microservice Architecture?

Why Microservices?
Agility
Faster iteration cycles
Bounded context
Scalability
Elastic scalability
Workload orchestration
Resilience
Reduced dependencies
Fail fast
4
Maturity
§ Are you ready for a radical change in methods, skillsets,
infrastructure, operations.
§ Are you sufficiently automated (infrastructure, test, dev pipeline,
deployment etc.)
Maintenance
§ Will you be able to sustain the skillsets needed to maintain the
microservices architecture in the future?
Latency & Serialization
§ A request/response chained down a set of microservices must
incur extra latency from network hops and serialization
§ Serialization has advanced massively in recent years, but
inevitably has some contribution to CPU usage
Data sharing
§ Not all data can be split into neat independent functions. Some
things are shared, and this needs careful design
Real-time dependencies and their combined availability
§ Microservices calling other microservices synchronously need
careful consideration
§ Tends to creep, as one service builds on top of another
§ Need to move to more complex message based techniques
and/or introduce availability patterns such as circuit breaker
Manageability
§ How do you manage and monitor a vast network of microservices
§ How do you diagnose problems across a heavily distributed
landscape
How does persistence work?
§ Pessimistic versus Optimistic
§ How to handle shared objects
§ Relational / NoSQL
§ ACID / BASE / CQRS / Event Sourcing?
What are the challenges?
https://www.slideshare.net/kimjclark/microservices-where-do-
they-fit-within-a-rapidly-evolving-integration-architecture

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 vs SOA - short blog and video (10 mins)
http://ibm.biz/MicroservicesVsSoaBlog, http://ibm.biz/MicroservicesVsSoaVideoShort
Original PoV paper on microservices and in integration (~ 15 pages) http://ibm.biz/MicroservicesVsSoa
Webinar based on above paper (55 mins) http://ibm.biz/MicroservicesVsSoaFullWebinar
5

What makes a business process suitable for BPM?
• Performing the process provides value to the business
• The process contains individually business relevant steps
• Business relevant data flows through the process
• The process follows a relatively structured path
• The steps within the process are performed by multiple roles/teams
• The process changes over time as a result of changes in the business
Create
Account
Capture
Details
Send
Documents
Sign
Documents
Activate
Account
Customer
Call centre
Back office
Notify
Customer
Existing customer
New customer

How can microservices principles be applied to a BPM?
Granularity
• Splitting into separate runtime components by activity?
• Splitting into separate runtime components by process?
Architecture
• Re-architecting the BPM runtime into decoupled components?
• Breaking out the integration layer into decoupled components?
Scope
• BPM runtime to coordinate microservices (e.g. BPM UIs)?

Granularity
Architecture
Scope

Splitting into separate runtime components by activity
Queued events
Chained interactions (a.k.a. Saga pattern, Choreography)
Pros
• Higher performance due to simplistic persistence
• Loose-coupling of activities
Cons
• Largely a custom solution
• No notion of “process”, only the individual steps
• Process “model” not visible in implementation
• Custom work for effective monitoring/reporting
• Exception paths harder to understand
• Custom work to migrate to new processes
• Custom work to introduce human interaction
• No time-sensitive data consistency
Splitting a process up in this way entails:
a) not having a business friendly representation
b) no longer having a first class notion of process
c) It is now harder to manage processes
In short, in losing all the core benefits of BPM© 2018 IBM Corporation
9
Queued events
Process Runtime
Process A
Process state
Orchestrated interactions (BPM)
Pros
• Mature products available (e.g. BPM)
• First class notion of “process”
• Innate centralized governance
• Modelled process visible in implementation
• Monitoring/reporting at process level
• Process version migration support
• Clearer modelling of exception paths
• Easier to introduce human interaction
Cons
• Higher CPU/network usage due to persistence
• Potential tight-coupling of activities

Granularity
Architecture
Scope

What drives co-location of processes?
Process Runtime
Process Runtime
Process Model A
Process Model B
Process Model C
Process Model C
Process Model C
• Time-span
• Granularity
• Human interaction
• Principal objects
• Application integration
• Complexity
• Monitoring
• Flow ownership
• Dynamicity
• Transactionality
• Performance
• Volumes
• Business value
• State management
• Security
• Infrastructure
11

Process Runtime
Process Runtime
Process RuntimeProcess Runtime
Splitting into separate runtime components by process
• Split by Process Model
• Provides runtime isolation
(security, privacy, resilience)
• Tune for different workloads
(e.g. throughput vs. response
time)
• Provide different levels of
service (different HA/DR
requirements)
Note: A runtime topology per
process might be too granular.
12
However
This may be decoupled/isolated, independently scalable, etc., but it is not microservices architecture
Process Model A
Process Model B
Process Model C
Process Model A
Process Model B
Process Model C

Granularity
Architecture
Scope

14This graphic is illustrative only and is not meant to represent the current or future architecture of the IBM products
Runtime
Data store
Artefacts
repository
Running process
state
Task state Analytics
Task UIPortal Framework Admin UIDesigner UI
Task/Page
Navigator
Process
Orchestrator /
Case Manager
Process/Case
template
Manager
Reporting
Content
Manager
Content
BPM componentry in a single runtime

Runtime
Runtime
Runtime
Runtime
Re-architecting the BPM runtime into separate decoupled components
15
Running
process/case state
Analytics
RuntimeRuntime
Process
Orchestrator /
Case Manager
Task UI
Reporting
Portal Framework Admin UIDesigner UI
This graphic is illustrative only and is not meant to represent the current or future architecture of the IBM products
Data store Data store
Note: The BPM solution will look largely the same on the outside, so may be better to leave this to the vendor!
Runtime
Task state
Task/Page
Navigator
Data store
Runtime
Artefacts repository
Process/Case
Template
Manager
Data store
Runtime
Content
Content
Manager
Data store

IBM BPM and microservices
• IBM development is exploring how to better support cloud native
architectures based on microservices principles for IBM BPM.
• Our interest is supporting more flexible and faster deployment patterns
and scalability patterns.

Granularity
Architecture
Scope

Integrated
workflow
Stateful
integration
Aggregation
Enriched
update
Composition
Exceptions
only
Process
Stateless* engine Stateful* engine
* This refers to persistence of orchestration state
Real time retrieval
of data from
multiple systems
Single update,
preceded by
multiple
preparatory reads
Multiple critical
updates across
systems that can’t be
combined
transactionally
People based
exception handling
Processes
integrating
people and
systems
18
read read update
80%
20%
Different patterns of orchestration

Core types of Orchestration: Process vs. Composition
Process
• Makes calls to mature high level services
• Often triggered (i.e. one way call) rather than invoked as a two way call
• Where it is invoked as a two way interaction, the caller is typically asynchronous (i.e.
not a user) and therefore the service level agreement is throughput based rather than
response time based
• Stateful persistence of the steps in the process
• Events can correlate with the running process
• Often involves human interaction to perform some tasks within the process
Composition
• Grouping of relatively fine grained interactions
• Typically called in real-time in a request/response (two way) interaction style
• Response time is the primary driver for the service level agreement
• Common for aggregation functions
• Some or all the granular interactions may not themselves be exposed as re-usable
services
• Generally state free
• Never involves human interaction during the composition
By definition, BPM
is well suited to
implementing
“process”
requirements
Integration
components are
better suited to
implementing
“composition”
requirements
19

Operational Systems
(Applications and Data)
Composition
Business
Process
Aggregation
Enriched update
Stateful integration
Integrated workflow
20

A shift to Lightweight Integration
Part 2: Moving to lightweight integration
http://ibm.biz/LightweightIntegrationPaper
Containerization
Centralized
ESB
Fine-grained
Integration
Application autonomy Polyglot runtimes
Decentralized
Integration
Integration as a
microservice runtime
Part 1: The fate of the ESB
http://ibm.biz/FateOfTheESBPaper
More material
http://ibm.biz/LightweightIntegrationLinks

FAST LIGHT
DEPLOYMENT
VIRTUAL-
IZATION
SUPPORT
STATELESS
ENGINE
DISTRIBUTED
DEPLOY
READY
DEVOPS
TOOLING
SUPPORT
CLOUD
FIRST
JSON /
REST
SUPPORT
CONNEC-
TIVITY
Lightweight integration runtime - App Connect Enterprise

23
• 5-10 SaaS apps a day is now common
• How many of those were you using 5 years
ago? 1 year ago?
• How many contain duplicate information?
• If you could join them together meaningfully,
could you be more efficient/effective?
• What about if you could link them to your
company’s internal systems?
Integration Platform as a Service - App Connect Enterprise
Developer
Integrator
Automator

Granularity
Architecture
Scope

Presentation
Business Process
& Composition
Microservice-based
applications
Business Process coordinating Microservices

Across application coordination or within application coordination
Microservice
Application Y
Microservice
Application X
Business Process
& Composition
Microservice-based
applications
Microservice Application Z
Composition across
microservice applications
Composition within
a microservice application

Granularity
• Splitting into separate runtime components by activity: Choreography?
• Splitting into separate runtime components by process: Orchestration?
Architecture
Scope
• BPM runtime for microservices coordination?

Operational Systems
Composition
Business
Process
Aggregation
Enriched update
Stateful integration
Integrated workflow Integrated workflow
28

Operational Systems
Composition
Business
Process
By activity By process
Granularity: separate application runtime components
29

Operational Systems
Composition
Business
Process
Process
runtime
Integration
runtime
30
Architecture: separate platform runtime components

Operational Systems
Composition
Business
Process
Business
Process
Microservices
Coordination
31
Scope: Business Process vs. Microservices Coordination

Silo logic
Silo
data
Microservice comp Microservice comp
Microservice
component
Microservices ApplicationMonolithic Application A set of principles to break
down of large components
into smaller, self-contained
ones enabling greater
agility, more elastic
scalability and and more
differential resilience.
Fundamental principles
include maximizing
isolation and decoupling
between components
(including their data).
Supporting requirements
include automated DevOps
pipelines, good automated
test coverage, and,
fundamentally, leveraging
cloud-native
infrastructure and
platforms.
What is Microservice Architecture?

Artefacts
Resources
Security
Operations
Routing
Deployment
Delivery
33
Artefacts
Resources
Security
Operations
Routing
Deployment
Delivery
Traditional infrastructure
(Pets)
Cloud Native infrastructure
(Cattle)
Runtime specific
Provided by platform
Microservice Architecture on Cloud Native platforms

34
A Cloud Native platform with Enterprise-grade content
IBM Cloud Private
Leverage existing
investments
Open by design,
preventing vendor
lock-in
Enterprise grade
operations, across your
Hybrid IT environment
Enterprise grade
services for
Middleware, Data,
Analytics, DevOps
IBM Middleware, Data, Analytics and Developer Services
Cloud enabled middleware, messaging, databases, analytics, and cognitive services
to optimize current investments while rapidly innovating
Core Operational Services
Simplify Operations Management, Security, and Hybrid integration
Provision infrastructure and apps across Multi-Cloud environments
Kubernetes-based
Container Platform
Industry leading container
orchestration platform across private,
dedicated & public clouds
Cloud Foundry
For prescribed app
development &
deployment
Runs on existing IaaS: System Z IBM
Spectrum
Third Party alliances: Dell Cisco NetApp Lenovo Canonical …
CMSBluemix Local System

35
Microservices and BPM - Can they coexist?

Thank you
36Think 2018 / DOC ID / Month XX, 2018 / © 2018 IBM Corporation
Claudio Tag
Cloud Solution Architect
—
Claudio.tag@uk.ibm.com
https://www.ibm.com/automation/ibm-automation-platform-digital-business
Brian M. Petrini
Technical Offering Manager – IBM BPM
—
petrini@us.ibm.com
https://www.ibm.com/cloud/automation-software/workflow
Kim Clark
Integration Portfolio Architect, Offering Management
—
Kim.clark@uk.ibm.com
https://www.ibm.com/cloud/app-connect/enterprise

Notices and disclaimers
© 2018 International Business Machines Corporation. No part of this
document may be reproduced or transmitted in any form without
written permission from IBM.
U.S. Government Users Restricted Rights — use, duplication or
disclosure restricted by GSA ADP Schedule Contract with IBM.
Information in these presentations (including information relating to
products that have not yet been announced by IBM) has been reviewed
for accuracy as of the date of initial publication and could include
unintentional technical or typographical errors. IBM shall have no
responsibility to update this information. This document is distributed
“as is” without any warranty, either express or implied. In no event,
shall IBM be liable for any damage arising from the use of this
information, including but not limited to, loss of data, business
interruption, loss of profit or loss of opportunity. IBM products and
services are warranted per the terms and conditions of the agreements
under which they are provided.
IBM products are manufactured from new parts or new and used parts.
In some cases, a product may not be new and may have been previously
installed. Regardless, our warranty terms apply.”
Any statements regarding IBM's future direction, intent or product
plans are subject to change or withdrawal without notice.
Performance data contained herein was generally obtained in a
controlled, isolated environments. Customer examples are presented as
illustrations of how those
customers have used IBM products and the results they may have
achieved. Actual performance, cost, savings or other results in other
operating environments may vary.
References in this document to IBM products, programs, or services
does not imply that IBM intends to make such products, programs or
services available in all countries in which IBM operates or does
business.
Workshops, sessions and associated materials may have been prepared
by independent session speakers, and do not necessarily reflect the
views of IBM. All materials and discussions are provided for
informational purposes only, and are neither intended to, nor shall
constitute legal or other guidance or advice to any individual participant
or their specific situation.
It is the customer’s responsibility to insure its own compliance
with legal requirements and to obtain advice of competent legal counsel
as to the identification and interpretation of any relevant laws and
regulatory requirements that may affect the customer’s business and
any actions the customer may need to take to comply with such
laws. IBM does not provide legal advice or represent or warrant that its
services or products will ensure that the customer follows any law.

Notices and disclaimers
continued
Information concerning non-IBM products was obtained from the
suppliers of those products, their published announcements or other
publicly available sources. IBM has not tested those products about this
publication and cannot confirm the accuracy of performance,
compatibility or any other claims related to non-IBM
products. Questions on the capabilities of non-IBM products should be
addressed to the suppliers of those products. IBM does not warrant the
quality of any third-party products, or the ability of any such third-party
products to interoperate with IBM’s products. IBM expressly disclaims
all warranties, expressed or implied, including but not limited to, the
implied warranties of merchantability and fitness for a purpose.
The provision of the information contained herein is not intended to, and
does not, grant any right or license under any IBM patents, copyrights,
trademarks or other intellectual property right.
IBM, the IBM logo, ibm.com and [names of other referenced IBM
products and services used in the presentation] are trademarks of
International Business Machines Corporation, registered in many
jurisdictions worldwide. Other product and service names might
be trademarks of IBM or other companies. A current list of IBM
trademarks is available on the Web at "Copyright and trademark
information" at: www.ibm.com/legal/copytrade.shtml.
.

Think2018 2314-Microservices and BPM-can they coexist?

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Think2018 2314-Microservices and BPM-can they coexist?

Ähnlich wie Think2018 2314-Microservices and BPM-can they coexist? (20)

Mehr von Brian Petrini

Mehr von Brian Petrini (13)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Think2018 2314-Microservices and BPM-can they coexist?