Mini-course at VFU - Architecting modern digital systems - 4

Architecting
digital
systems
Module 4
Microservices
Alexander Samarin

• Typical concerns
– Time-to-market for new solutions and new versions of existing
solutions (IT agility)
– Ownership of governance and management of applications
– Healthy eco-system of partners and providers
– Transparent cost structure and other good business practices
– Legacy applications
• How to address these concerns
– Develop solutions as a suite of independently deployable, small,
modular services known as microservices (like a football team)
– Refactor, modernise and decompose existing monoliths into
microservices
– Start new solutions with microservices
– Better manage changes in software application
© A. Samarin 2018 Architecting digital systems - Module 4 2
Better application architecture

• I like microservices
• How to define granularity of microservices?
• Let us buy an API gateway tool
• We must have an APaaS
• Let us decompose our in-house monolith ERP into
microservices
• Where can I deploy my microservices?
• I can keep some local data in my microservices, but how
to use some existing corporate data?
• We need DevOps, CI, etc.
• What is our target application architecture?
Typical reaction from IT

• digital computing process
computing process, <digital systems>
act of execution of software by a digital computer
– Note: Many digital computing processes can run concurrently on
the same digital computer
• inter-computing-process communication
inter-process communication, <digital systems>
mechanism enabling different digital computing processes
to exchange data
– Note: Those digital computing processes can be within the same
digital computer or spread over networked digital computers.
AppArch key concepts (1)

• unit-of-functionality, <digital systems>
software capable of accomplishing a certain system
capability
– Examples: function, method, package
• unit-of-deployment, <digital systems>
group of one or more units-of-functionality which,
individually and independently of any other such group, can
be deployed intact to a digital computer or a digital system
– Note: unit-of-deployment may be a composition of
units-of-functionality (i.e. monolith)
– Note: unit-of-deployment may be an aggregation of
other units-of-deployment (i.e. assembly)

• unit-of-execution, <digital systems>
group of one or more units-of-deployment which can be
executed within a digital computing process
– Note 1: The same unit-of-execution can be executed concurrently
within several digital computing processes.
– Note 2: The same unit-of-deployment can be included in more
than one unit-of-execution.
• interface, <digital systems>
shared boundary between two units-of-functionality,
defined by functional characteristics, signal
characteristics, or other characteristics as appropriate

• service, <digital systems>
unit-of-functionality which is available from a separate
computing process via an explicitly-defined interface and
provides some added-value being consumed
– Note: Interface to software services is called Application
Programmer Interface (API)
• service agreement , <digital systems>
agreement between the service consumer and
the service provider on performance, measurement
and conditions of service delivery
Service consumer
Service provider

• microservice, <digital systems>
digital service with a single unit-of-functionality packaged
exclusively in a single unit-of-deployment to form a single
unit-of-execution
– Note: In other words, for a microservice its unit-of-functionality, its
unit-of-deployment and its unit-of-execution have the same
boundaries.
• Microservices are dependent at the design-time
– because they are for Service Oriented Development
• Microservices are independent at the deployment-time
– because they are autonomous (at some extent)
• Microservices are interdependent at the run-time
– because they invoke each others

• Assembly of microservices may be a microservice as well
• Solutions which are assembled from microservices may have
many microservice-to-microservice dynamic connections
N * (N-1) / 2

• API gateway is a proxy between a service consumer and
a service provider
• API gateways are necessary to improve various “abilities”
(flexibility, measurability, availability, etc.) of those
dynamic connections because service providers and
services consumers may be spread over network nodes,
computing environments and clouds
API gateway

• Functional integration
• Platform-based architecture
Application 1
ERP ECM

• Instead of creating the right architecture from the start
when building a system, you can create an Evolutionary
Architecture that is constructed for adaptability and can
be changed to become the right one at a particular point
in time. For Tilkov, the approach in such an architecture
includes:
– Separation of large domain into what he calls "islands of change"
– Design for replacement, not for reuse
– Minimizing of shared dependencies, with a focus on autonomy and
redundancy instead of on reuse
• One advantage is that it enables experimentation, for
instance using A/B testing.
AppArch modern tendencies
https://www.infoq.com/news/2018/03/microservices-anti-patterns

• Implement RequestLoan microservice with the following
activities:
– ReviewRequest
– CheckClient or
– CheckHistory
– ApproveLoan or
– RejectLoan
– PrepareContract if approved
Assembling microservices:
use case

choreography
Key
Synchronous
Asynchronous
Prepare
Contract
Approve Loan
Check History
Review
request
Check Client
Reject Loan

orchestration
Request Loan
Key
Synchronous
Asynchronous
Check Client
Check History
Approve Loan
Prepare
Contract
Rview
Request
Reject Loan

Request Loan
Check
Requestor
Check History
Prepare
Contract
reactive streams and runnable graphs
Key
Synchronous
Asynchronous
Approve Loan
Reject Loan

based on business processes
Key
Synchronous
Asynchronous
Prepare
Contract
Approve
Loan
Check
History
Check
Client
Review
Loan
Reject
Loan

Various development lifecycles
monolith
applications
process-based
solutions
microservice
assembles
Existing application Change something New applicationTest everything
Easy Difficult
Existing assembly Change something New assemblyTest relationships
Average
(granularity?)
Average
(too many links!)
Easy and safe
(lesser links)
Existing process
Easy
(granularity comes
from business)
New process
Dev
Dev
Biz
Ops
Ops
Biz
Biz
Dev Ops
Change something Test relationships

• Scale easily and in a highly efficient way
• Have no single point of failure
• Be retired, refactored, or re-written without compromising
the integrity of the entire application
• Be written in many languages and frameworks to suit the
requirement of each service
• Be simple and discrete
• Easily meet requirements for modern PaaS and SaaS
environments
Advantages from technical side

Modern applications are assembled from
existing autonomous components
https://go.ifrc.org/

Typology of applications:
event-driven
Event
processing AC
API
Simple
operation AC
API
Resource
(data) AC
AC – Autonomous
Component
Event
dispatching AC
Utility AC
Simple
operation AC

Utility AC
Data-centric
mini-portal AC
Resource
(data) AC
API
Simple
operation AC
API
API
data-centric
AC – Autonomous
Component

Resource
(documents) AC
Document-
centric mini-
portal AC
Short-running
operation AC
API
Utility AC
Resource
(data) AC
API
API API
document-centric
AC – Autonomous
Component

Resource
(documents) AC
Utility AC
Resource
(data) AC
Operation-centric mini-portal AC
• static list of operations
Short-running
operation AC
Short-running
operation AC
API API
API API
API
API
API
short-running operation-centric
AC – Autonomous
Component

Resource
(documents) AC
Utility AC
Resource
(data) AC
Short-running
operation ACLong-running operation AC
operation definition, states, etc.
Operation-centric mini-portal AC
• static list of operations
• dynamic list of operations
API
API
API
API
API
long-running operation-centric
AC – Autonomous
Component

a. The functional-role-based-portal AC offers to a user some
functions to initiate (as a static list)
b. All explicit-coordination-operation ACs are implemented as
DSL-script
c. A user executes a function which is implemented as a DSL-
script
d. The first of two operations is the automated-operation AC
which uses several other ACs
e. The second of two operations is the human-operation AC
f. The human operation AC must be completed by a user
g. The explicit-coordination-operation AC terminates
Complex application

Utility AC
Human
operation AC
Resource access
AC (documents)
Persistence backing
AC (state)
Functional-role-based-mini-portal AC
• static list of functions (operations)
• dynamic list of activities (operations)
API
Automated
operation AC
Explicit coordination
operation AC as DSL
script AC
Persistence backing
AC (configuration)
Resource access
AC (data)
Resource assembly
access AC
DSL manager
AC
DSL
processor AC
DSL script
AC
some data flows realised via API
AC
Cloud-friendly: stateless, multiple-place-
independent, individual-instantiation.
Security techniques: embedded.
AC
Cloud-friendly: stateless, place-independent,
availability-based-instantiation.
Security techniques: RBAC.
instantiation
Legacy
pseudo AC
Click to continue
Stage A
Stage B
Stage C
Stage D
Stage E
Stage F
Stage G

a. The functional-role-based-portal AC offers to a user some
functions to initiate (as a static list)
b. All explicit-coordination-operation ACs are implemented as
DSL-script
c. A user executes a function which is implemented as a DSL-
script
d. The first of two operations is the automated-operation AC
which uses several other ACs
e. The second of two operations is the human-operation AC
f. The human operation AC must be completed by a user
g. The explicit-coordination-operation AC terminates
Complex application

Event
in
Human
activity
Document
Event
out
External
automated
activity
Data Business
rule
Built-in
automated
activity
Granularity of microservices (1)
External
automated
activity PRE External
automated
activity
POST
External
automated
activity
Built-in
automated
activity
Data

• Data life cycle (minimally CRUD)
• Documents life cycle
• Events life cycle
• Business rules life cycle
• Audit trails life cycle
• KPIs life cycle
• Human activities life cycle
• Automation scripts life cycle
• Assembles (e.g. process templates) life cycle
Granularity of microservices (2)

“Process-
µservice”
“Activity-
µservices”
“Business
µservices”
“Asset
µservices”
(atomic)
R1 Repository Repository
X
Composite
µservices
Composite
µservices
Composite
µservices
Atomic
µservices
X
Everything is a µservice
OTS
OTS
OTS
OTS
R2
“Asset
µservices”
(composite)
Composite
µservices

• WHY?
– Use of distributed architecture for scalability and fault-tolerance
– Use of clouds (where any service may be disconnected or failed &
VM reloaded)
– HOW?
– Error recovery loop for the invocation of each service or
microservice
– Idempotency in the design of processes, services and
microservices
Easy recovering from errors

• Imagine a process fragment with 3 automation activities
(A, B, and C) to be executed as a transaction; each of
those activities is an invocation of an external services
(not in the run-time as the coordination service); normal
execution sequence is E1-A-B-C-E2
• Because those services may fail this fragment contains
intermediate exception event E3 and an activity for Error
Recovery Procedure (ERP); the latter may be a human
activity
Idempotency explained (1)
A B
x
ERP
C
E3
E1 E2

• First pass with the failure of activity B
– E1-A(done)-B(failed)-E3-ERP ( ERP == Error-Recovery-Procedure)
• Second pass with failure of activity C
– E1-A(already done)-B(done)-C(failed)-E3-ERP
A B
x
ERP
C
E3
E1 E2❶ ❷
❺
❸ ❹
❻
A B
x
ERP
C
E3
E1 E2❶ ❷
❺
❸
❹

• Third pass with no failures
– E1-A(already done)-B(already done)-C(done)-E2
• Activity A was executed 3 times, but it did the real work
only at the first time – two other times were ignored
because of idempotency
• Example of idempotent service: upload a document; if
document’s place, metadata and content are the same
then next upload is ignored
A B
x
ERP
C
E3
E1 E2❶ ❷ ❺❸
❹

Template 1st pass (failure at B)
2nd pass (failure at C)3rd pass (OK)
A B
x
ERP
C
E3
E1 E2 A B
x
ERP
C
E3
E1 E2❶ ❷
❺
❸
❹
A B
x
ERP
C
E3
E1 E2❶ ❷
❺
❸ ❹
❻
A B
x
ERP
C
E3
E1 E2❶ ❷ ❺❸
❹

Interpretive language for microservices (1)
Ax
ERP1 E3
E1 E2
… …
ERP2
E4
Universal microservice
– robot – it gets and
executes a script
• Apache Groovy, a dynamic
programming and scripting language
• JRuby, an implementation of Ruby
• Jython, an implementation of Python

Interpretive language for microservices (2)
Ax
ERP1 E3
E1 E2
… …
ERP2
E4
Bx
ERP1 E3
E1 E2
… …
ERP2
E4

Containers (1)

• New problem – management of containers (also called
orchestration) – consider Kubernetes ( see
https://www.infoq.com/articles/kubernetes-effect )
Containers (2)
• Pod : the deployment unit for a related
collection of containers.
• Service : service discovery and load balancing
primitive.
• Job: an atomic unit of work scheduled
asynchronously.
• CronJob: an atomic unit of work scheduled at a
specific time in the future or periodically.
• ConfigMap: a mechanism for distributing
configuration data across service instances.
• Secret : a mechanism for management of
sensitive configuration data.
• Deployment: a declarative application release
mechanism.
• Namespace :a control unit for isolating
resource pools.

Containers (3)
• Node: A single virtual or physical machine in a
Kubernetes cluster.
• Cluster: A group of nodes firewalled from the
internet, that are the primary compute resources
managed by Kubernetes.
• Edge router: A router that enforces the firewall
policy for your cluster. This could be a gateway
managed by a cloud provider or a physical piece
of hardware.
• Cluster network: A set of links, logical or physical,
that facilitate communication within a cluster
according to the Kubernetes networking model.
Examples of a Cluster network include Overlays
such as flannel or SDNs such as OVS.
• Service: A Kubernetes Service that identifies a set
of pods using label selectors. Unless mentioned
otherwise, Services are assumed to have virtual
IPs only routable within the cluster network.
• Ingress: An Ingress is a collection of rules that
allow inbound connections to reach the cluster
services.

Containers (4)
standard
container language-
specific
container
specialized
container
microservice

Versioning
template v2 availability span
template v1 availability span
Time
instance v1,a execution span
instance v1,b execution span
process instance v1,c execution span
process instance v2,d
execution span
process instance v2,e
execution span
Process template v1
Process template v2

• Don’t write your own crypto code
• Align with the “Principle of Least Access”
• Policies at API gateway
• JSON Web Tokens (JWT)
• Login from Google
• Tie into the existing SSO and authorization schemes to
generate a JWT model
• Security of containers
Security

Decomposing monolith (1)
Monolithic application
GUI screen 2
GUI screen 1
GUI screen 3
Business logic
Business object
“Partner”
persistence
Business object
“Competition”
persistence
Business object
“Event”
persistence
BPM/SOA modular solution
Business logic
service
Interactive
service 1
Interactive
service 2
Interactive
service 3
Coordination service
Business object
“Partner” persistence
service
Business object
“Competition”
persistence service
Business object
“Event” persistence
service

Legacy ERP functionality
DM service B
DM service A
DM service C
Industrial DMSIndustrial ERP
HR
Fin
Procurement
Business logic
suite (BRM)
Coordination
suite (BPM)
Specific
service 1
Specific
service 2
Specific
service 3
In-house
development
10-15 % 10-15 %20-40 %10-20 %
Industrial generic suites Industrial specific
tools
Event
management
…
20-30 %
Note: Specified values are just estimations

M
O
N
O
L
I
T
H
B
P
M
S
AS-IS 1st step 2nd step TO-BE
OtherBE func-APIThisBE stor-APIThisBE stor-API ThisBE stor-API
Implicit
ThisBE
process
ThisBE
rules
ThisBE
events
ThisBEThisBE ThisBE ThisBE
ThisBE
rules
ThisBE
events
ThisBE
events
Explicit
Master
Slave
Copy
ThisBE
rules
ThisBE
process
ThisBE events
ThisBE
ThisBE rules
ThisBE
process
ThisBE events
ThisBE
ThisBE rules
ThisBE
process
ThisBE
ThisBE rules

Application D Application C
Application B
Application A
Application E
α
Batch (non-interactive)
program
ε
β
ζ γ
η
θ
κ
λ
δ
α

As is
1st iteration
2nd iteration
3rd iteration
To be
Application D Application CApplication Aβ λ

• BE – Business Entity
• stor-API – interface for a particular data storage
repository
• stor-API (R) – read only API
• stor-API (RW) – read and write API
• func-API – functional interface
Persistence data management:
conventions

Persistence data management:
typical point-to-point

Persistent data management:
initial

extension

updates

functional

Microservices first (1)
Types of building
block
Prototyping Implementation Production
Human activities High Medium Low
Data structures Low Medium Low
Documents Low Low Low
Roles Low Low Low
Business rules Medium Medium Low
Automated activities Low High Medium*)
Reports Low Medium Low
Records Low Low Low
Dashboards Low Medium Low
Portal Low Medium Low
Explicit-assembles Medium Low Low
*) It is mandatory to be ready for quick changes in automated activities for error recovery of instances

Microservices first (2)
Viewpoint: Application as a
set of units-of-deployment
Viewpoint: Application as a
set of units-of-functionality
Starting the development
Completing the development
Unit-of-functionality
Microservice container
Service container
Platform container / Monolith

Tools and experience
https://www.youtube.com/watch?v=OuzjaYlxX1A

Typical technical view

• API gateway
• Event bus (queue, dispatcher)
• Service discovery
• integration Platform as a Services (iPaaS)
• Containers, Orchestration, Infrastructure as Code (IaC)
5 major tools

Business goals achieved with
microservices
• Solutions which are “Best for fit”
• Time-to-market
• Low cost of operations

• Moving fast
• Focus on frontends
• Cloud-native and serverless
• Ambient сomputing
• Information security
Tendencies
https://www.infoq.com/news/2018/03/microservices-future-it-changes

Example of transformation

Legacy application
or COTS
Atomic
service
Application
flow of controlflow of data implicit mixed flowexplicit mixed flow
In-house

Legacy application
or COTS
App
Internet
In-house
SaaS in Cloud
API
Atomic
service
Application

Legacy application
or COTS
App
SOA+ESB+API
APIAPI
Container Container
Internet
In-house
SaaS in Cloud
API
Atomic
service
Application

Legacy application
or COTS
App
SOA+ESB+API
APIAPI
Container Container
Internet
In-house
API
Container
Composite
service
SaaS in Cloud
API
Atomic
service
Application

Legacy application
or COTS
App
SOA+ESB+API
APIAPI
Container Container
Internet
In-house
Process-centric solution
(internal, B2C, B2B)
API
Container
Composite
service
SaaS in Cloud
API
Atomic
service
API
BPMS container
BPMS
management
as COTS
services
API
BPMS container
Process
instance as a
composite
service
API
BPMS container
Human
activity as
an atomic
service
API
BPMS container
Automatic
activity as a
composite
service
Application
Click for animation

Legacy application
or COTS
App
SOA+ESB+API
APIAPIAPIAPIAPI
Container ContainerBPMS containerBPMS containerBPMS container
Internet
In-house
API
Container
Composite
service
SaaS in Cloud
API
Atomic
service
BPMS
management
as COTS
services
Process
instance as a
composite
service
Human
activity as
an atomic
service
API
BPMS container
Automatic
activity as a
composite
service

Legacy application
or COTS
App
SOA+ESB+API
APIAPIAPIAPIAPI
Container ContainerBPMS containerBPMS containerBPMS container
Internet
In-house
SaaS in Cloud
API
Atomic
service
BPMS
management
as COTS
services
Process
instance as a
composite
service
Human
activity as
an atomic
service
API
BPMS container
Automatic
activity as a
composite
service

Legacy application
or COTS
App
SOA+ESB+API
APIAPIAPIAPI
Container ContainerBPMS containerBPMS container
Internet
In-house
SaaS in Cloud
API
Atomic
service
BPMS
management
as COTS
services
Process
instance as a
composite
service
API
BPMS container
Automatic
activity as a
composite
service
SOA+ESB+API
APIAPIAPI
BPMS containerBPMS containerBPMS container
BPMS
management
as COTS
services
Process
instance as a
composite
service
Human
activity as
an atomic
service
API
BPMS container
Automatic
activity as a
composite
service
PaaS in Cloud

SOA+ESB+API
API
Container
Atomic
service
SOA+ESB+API
Legacy application
or COTS
App
API
APIAPIAPI
Container
Container
BPMS containerBPMS container
Internet
In-house
SaaS in Cloud
API
Atomic
service
BPMS
management
as COTS
services
Process
instance as a
composite
service
API
BPMS container
Automatic
activity as a
composite
service
APIAPIAPI
BPMS
management
as COTS
services
Process
instance as a
composite
service
Human
activity as
an atomic
service
API
BPMS container
Automatic
activity as a
composite
service
PaaS in Cloud
App

SOA+ESB+API
SOA+ESB+API
Legacy application
or COTS
App
API
APIAPIAPI
Container
Container
BPMS containerBPMS container
Internet
In-house
SaaS in Cloud
API
Atomic
service
BPMS
management
as COTS
services
Process
instance as a
composite
service
API
BPMS container
Automatic
activity as a
composite
service
APIAPIAPI
BPMS
management
as COTS
services
Process
instance as a
composite
service
Human
activity as
an atomic
service
API
BPMS container
Automatic
activity as a
composite
service
PaaS in Cloud
App

SOA+ESB+API
SOA+ESB+API
Legacy application
or COTS
App
API
API
Container
Container
Internet
In-house
SaaS in Cloud
API
Atomic
service
APIAPIAPI
BPMS
management
as COTS
services
Process
instance as a
composite
service
Human
activity as
an atomic
service
API
BPMS container
Automatic
activity as a
composite
service
PaaS in Cloud
App

SOA+ESB+API
App
API
Container
Internet
In-house
SaaS in Cloud
API
Atomic
service
APIAPIAPI
BPMS
management
as COTS
services
Process
instance as a
composite
service
Human
activity as
an atomic
service
API
BPMS container
Automatic
activity as a
composite
service
PaaS in Cloud
App
Service
API
Container
Another PaaS
in Cloud
Service
API
Container
SaaS in Cloud
COTS
API

Questions?

• Single-responsibility building blocks are microservice-ready
– Human activities (as UI)
– Data structures (from various repositories)
– Documents (from various repositories)
– Events
– Business rules
– Roles
– Automated activities
– Explicit-assemblies via DSLs (orchestration and choreography)
– Reports
• Single-responsibility building blocks
– Dashboards
– Portals (as a navigator over some human activities)
– Implicit-aggregators via events and reactive programming
Application building blocks which
BPM-suite tool as APaaS can manage

• Each process, case and activity is a single responsibility
• Human activities are designed for single responsibility
• Data structure design is actually Domain-Driven Design
because a process or a group of related processes define
a domain
• Granularity of business rules is defined by their
consumers (i.e. activities)
• Automated activities primarily augment (enrich) related
human activates thus their granularity
• Roles are related to processes, cases and activities
BPM-suite tool helps to determine
“right” granularity for microservices

Mini-course at VFU - Architecting modern digital systems - 4

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Mini-course at VFU - Architecting modern digital systems - 4

Semelhante a Mini-course at VFU - Architecting modern digital systems - 4 (20)

Mais de Alexander SAMARIN

Mais de Alexander SAMARIN (14)

Último

Último (20)

Mini-course at VFU - Architecting modern digital systems - 4

Notas do Editor