Avancier
Copyright Avancier Ltd 2017
Microservices from an EA perspective A talk for the BCS EA specialist group
Monday 20th March 2017
It is illegal to copy, share or show this document
(or other document published at http://avancier.website)
without the written permission of the copyright holder
Avancier What follows: made for you this evening from
► Distilled from a 2014 paper on http://avancier.website ■ http://grahamberrisford.com/AM%202%20Methods%20support/08Microservices-Microapps/Microservices%20-%20Micro%20apps.htm
► Adding a few graphics from a 2016 IBM slide show ■ https://www-304.ibm.com/events/tools/interconnect/2016ems/REST/presentations/PDF/InterConnect2016_1434.pdf
► Adding a few slides from Avancier’s training to
■ BCS professional certificates in Enterprise and Solution Architecture ■ http://avancier.website
► This talk: 90 minutes with interaction? Probably 45 minutes without
■ Time constrained so as to leave time for Q&A afterwards
■ Later: read the paper above and replay these slides at your own pace
Copyright Avancier Ltd 2017
Never previously delivered!
Avancier A classic conflict of ideas
► Hierarchy
■ “Strategy and architecture” direct and govern the development of business
applications that enable and support business processes.
► Anarchy
■ Application development teams are agile and autonomous
● Developers do architecture and analysis
● Developers build it and run it
► EA thinking tends to
■ Constrain silo system proliferation
■ Centralise data management
► Microservices thinking tends to encourage the opposite!
Copyright Avancier Ltd 2017
Avancier
Copyright Avancier Ltd 2017
EA thinking
It is illegal to copy, share or show this document
(or other document published at http://avancier.website)
without the written permission of the copyright holder
Avancier EA thinking
► It appears the NIST EA model of
1989 was the first time the term
“EA” used formally in a publication.
► Business data and processes
► EA takes cross-organisational and
strategic perspective
Copyright Avancier Ltd 2017
Avancier But
► It would be misleading to suggest EA started in any one source or
standard.
► EA thinking was evident long before 1989
Copyright Avancier Ltd 2017
Avancier 10 years earlier: Duane Walker’s BSP
► BSP involved
■ identifying Processes, Data Entities and Applications
■ mapping them each other and other entities in matrices
► Zachman (1982) said BSP was
■ Concerned with “data management problems”
■ Based on an analysis tool: a cross-organisational Process/Data matrix
Copyright Avancier Ltd 2017
Register
customer
Place
order
Complete
sale
Launch
product
Recall
product
Customer x x x
Sale x x x
Sale item x x
Product type x x
Avancier A few more EA sources before the NIST EA model
► Information Engineering (1981…)
■ enterprise-wide data analysis
■ “enterprise engineering”
► Zachman (1982…1987… )
■ Information system architecture framework
■ “enterprise-level architecture”
► The PRISM report (1986)
■ Four architecture domains (Bus, Data, Apps and Infrastructure)
■ Architecture should be done at the highest level for which there is consensus
on principles.
► In all sources, EA was about taking a cross-organisational and strategic
perspective of business systems, their data and processes
Copyright Avancier Ltd 2017
Avancier 10 years after the NIST EA model: FEAF v1.1
► Drew from Zachman, Spewak and the NIST EA standard.
► 1999 version summarised four aims for the “Federal Enterprise” ■ “Organize Enterprise information including common data and business processes…
■ Promote information sharing throughout the Enterprise and within segments
■ Help the Enterprise develop architecture descriptions
■ Help the Enterprise move more quickly toward developing new and improved processes”
Copyright Avancier Ltd 2017
Platform Technologies
Locations
Data entities
Processes
Applications (automated
processes applied to digitised
business data
Avancier EA thinking centered on business data and processes
► The architecture vision
■ The solution architecture vision: to support/enable, speed/scale up,
optimise/extend business roles and processes in a narrow scope.
■ The EA vision is broader: to standardise, integrate and coordinate business
data and processes across an enterprise.
► “Mainstream EA” has included countless authors and publications.
■ 1993 “EA Planning” Spewak
■ 2006 “EA as Strategy” Ross, Weil and Robertson
■ Today: Architecture frameworks like IAF, EAF and TOGAF
Copyright Avancier Ltd 2017
Integrate Coordinated Unified
Diversified Standardised
Standardise
Avancier In short
► EA thinking has always been centered on business data and
processes.
► Themes in EA literature include
■ Digital transformation of roles and processes
■ Increase data and process quality
■ Increase data and process sharing
■ Integrate data and processes
■ Reduce duplication and interoperability issues
■ Centralise data management (to some extent, in some way)
► (Read “50 years of Digital Transformation and EA”)
Copyright Avancier Ltd 2017
Avancier Above, below and beside EA thinking
Copyright Avancier Ltd 2017
► Business planning and organisation design
■ EA attends to human roles that create and use digital data.
■ Changes to an organisation’s management structure or
roles are usually managed by a parallel "business change"
team.
► Technology Architecture
■ EA attends to technologies used to create and use data
■ Looks for opportunities created by new technologies.
■ IT platform technology provision is increasingly outsourced
■ “TCP/IP everywhere” enables integration of cross-platform
(heterogeneous) distributed systems
Avancier
Architecture Vocabulary Hell
Aligning TOGAF® with ArchiMate® It is illegal to copy, share or show this document
(or other document published at http://avancier.website)
without the written permission of the copyright holder
Copyright Avancier Ltd 2017
Avancier A few vocabulary hell examples
► ArchiMate distinguishes
► Service from Interface
► Actor from Role
► Data flow from Trigger
Copyright Avancier Ltd 2017
Service Interface (The same thing in UML) (The same thing in UML) (One often implies the other, sometimes in the opposite direction)
Avancier Systems as defined in TOGAF
► TOGAF
■ “Systems are built up from … building blocks [that] interoperate with
other building blocks”
■ “It is important that the interfaces to a building block are published and
reasonably stable”
► IOW: A system is a collection of
■ interacting building blocks that perform
■ processes in response to requests for
■ services which are grouped for access in
■ interfaces
Copyright Avancier Ltd 2017
Behaviour Structure
External
Internal Building
Block
Service
Process
Interface
Avancier Same ideas in ArchiMate
Behaviour
what the system does
Structure
what the system is made of
External
requirements of
external entities
Internal
the workings of the
system
Copyright Avancier Ltd 2017
This figure from ArchiMate® 3.0 Specification Copyright © 2012-2016 The Open Group
Avancier Same ideas in BCS professional certificates for E&SA
► Adapted from ArchiMate
Copyright Avancier Ltd 2017
External View
Internal View
Behaviour Aspect (actions)
Structure Aspect (actors)
Service
Process
Interface
Actor or Component
Services are presented in Interfaces
Data
Passive Structure (acted on)
Processes are performed by Actors and Components
Avancier TOGAF’s core framework – with ArchiMate symbols
Copyright Avancier Ltd 2017
Physical Structure
activity performer
Business
Technology (Infrastructure)
Information Systems
Required Behaviour
event to result
Logical Structure
activity/entity group
Passive Structure
acted on or in
Realised by Acts
on or in Assigned to
Location
Data Entity
Logical Tech Component
Platform Service
Role Actor
Business Service
Org Unit Function
(Capability?)
Logical App Component
Physical App Comp’t IS Service
Process
Physical Tech Comp’t
Logical Data Component
Physical Data Comp’t
Avancier
Physical Structure
activity performer
Business
Location
Technology (Infrastructure)
Applications (IS)
Required Behaviour
event to result
Logical Structure
activity group
Passive Structure
acted on or in
Data Object
ArchiMate’s core framework – core entities & associations
Copyright Avancier Ltd 2017
Technology Interface
or Function
Technology Service
Device
Business Role
Actor (Human)
Business Service
Actor (Org Unit)
Function
Application Interface
or Function
Application Component
Application Service
Realised by Acts
on or in Assigned to
Business Process
System Software
Business Object
Avancier
Copyright Avancier Ltd 2017
EA vocabulary hell
► BCS E&SA
► TOGAF
► ArchiMate
Building Block
Service Portfolio
Active Structure Element
Interface Technology
Information Systems Applications
Business
Node
System Software
Device
Application Component
Organisation Unit (Actor)
Actor
Data Component
Technology (Infrastructure)
Services
Data Object
Technology Component
Application Component
Function
Platform Services
IS Services
Business Services
Application Services
Business Services
Role
TOGAF terms
ArchiMate terms
Application Component
Could be a Microservice
Component
Interface (Service Portfolio)
Avancier Software vocabulary hell
EA as in
TOGAF and ArchiMate
Fowler’s writings for
programmers
A structural BB that offers
multiple services (a service
portfolio) to its clients
Component
A unit of software that is
independently replaceable and
upgradeable.
A behavior composed of
process steps in a sequence
that leads to a result.
Process An instance of a component
executed on a computer.
A discretely requestable
behaviour that encapsulates
one or more processes.
Service
An out-of-process component,
typically reached by a web
service request or RPC.
Copyright Avancier Ltd 2017
Process
Could be a Microservice
Component
Interface (Service Portfolio)
Avancier
Copyright Avancier Ltd 2017
Microservices
It is illegal to copy, share or show this document
(or other document published at http://avancier.website)
without the written permission of the copyright holder
Several graphics are copied from this IBM slide show
https://www-304.ibm.com/events/tools/interconnect/2016ems/REST/presentations/PDF/InterConnect2016_1434.pdf
Avancier Aims today
► Make sense of the term “microservice”.
► Steer people away from badly-designed, hard-to-maintain and
poorly-performing microservices.
► Propose that enterprise and solution architects are responsible for
governing software architects.
Copyright Avancier Ltd 2017
Avancier Not everything is a microservice
► Microservices are application components,
■ but not every component is a microservice.
► Microservices have APIs,
■ but not every API is a microservice.
Copyright Avancier Ltd 2017
Avancier Micro compared with what?
► A whole/monolithic application
■ a macroservice
► Or what would be a whole application if it was not subdivided
► The granularity of components is important when considering best
practice design principles and guidance
Copyright Avancier Ltd 2017
Avancier A true microservice
► a micro application, encapsulated behind an API.
► a discretely deployable subdivision of what could be a monolithic
application.
► encapsulates one partition of what could be a monolithic data
structure (and so “decentralises data management”).
► Also “isolated” & “autonomous”?
Copyright Avancier Ltd 2017
https://www-304.ibm.com/events/tools/interconnect/2016ems/REST/presentations/PDF/InterConnect2016_1434.pdf
All such blue box graphics are copied from
the IBM paper below
Avancier More vocabulary hell
► Division of the whole application into microservice should not affect
services offered to clients, but it might do
► Some mangling of terms here ■ Microservice component
■ Silo = monolithic rather than micro
■ Exposed services/APIs = N services exposed in each API”
■ Or do clients of the whole application have to know which microservice they need?
Copyright Avancier Ltd 2017
Component
Interface (Service Portfolio)
Micro silo
Macro silo Micro silo
Micro silo
Avancier Do microservices undermine EA?
► Microservices tend to create smaller silo systems
► Might over enthusiastic application of the idea
■ disintegrate data and processes?
■ lead to excessive, wasteful, use of network/middleware technologies?
■ hinder how customers or employees perform business processes?
Copyright Avancier Ltd 2017
Avancier Microservices = SOA?
► Really?
■ Microservices do not have to be distributed
■ SOA does not say how to divide an application into modules
► Microservices might more accurately be seen as a scaling up of
OO design, a response to complaints that the granularity of objects
in OOP is too small.
► Anecdote?
Copyright Avancier Ltd 2017
Object Object Object
Object Object Object
Object Object Object
Object Object Object
Object Object Object
Object Object Object
Application
Avancier Fowler’s first rule of distributed objects
► Don’t distribute your objects!
► However, Fowler’s microservices
characteristics include
decentralisation of data
management and governance.
Copyright Avancier Ltd 2017
Are they isolated or autonomous?
Avancier
Copyright Avancier Ltd 2017
Four motivations
It is illegal to copy, share or show this document
(or other document published at http://avancier.website)
without the written permission of the copyright holder
Avancier
-1- To maintain data stores that are already distributed and separately managed
► This describes the application portfolio
most enterprises already have.
► And integrating discrete applications is a
system integration task as it ever has
been.
Copyright Avancier Ltd 2017
ETL
ESB
REST
ODATA
Application
Application Application
Avancier
Enterprise DB Physical MD Virtual MD / III-RM Enterprise DW
RAR Distributed Transaction
Middle ware
Middle ware
Middle ware
Middle ware
Middle ware
SCI LOP
App Integration Patterns don’t demand Microservices
Data App
ERP Data Store
Data App
Billing Data Store
User App User App
Data App
ERP Data Store
Data App
Billing Data Store
User App User App
Data App
CRM Data Store
Data App
ERP Data Store
Data App
Billing Data Store
User App User App User App
ETL ETL
Data App
CRM Data Store
Data App
ERP Data Store
Data App
Billing Data Store
User App User App User App
Data App
Enterprise Data Store
User App User App User App
Data App
CRM Data Store
Data App
ERP Data Store
Data App
Billing Data Store
User App User App User App
Data App
Customer Data Store
Data App
CRM Data Store
Data App
ERP Data Store
Data App
Billing Data Store
User App User App User App
Broker App
Report
Data Warehouse
Data App
CRM Data Store
Data App
ERP Data Store
Data App
Billing Data Store
User App User App User App
ETL ETL ETL
NN
Data App
ERP Data Store
Data App
Billing Data Store
User App User App
Copyright Avancier Ltd 2017
User App
Could be a Microservice
Avancier -2- To separate what must be coded using different technologies.
► Such application components are naturally discrete.
► And it seems advisable not to mix technologies
unless you need to
■ Node.js
● Server-side java script
■ MongoDB
● A free open-source JSON-like document store
■ IBM® Cloudant®
● “A JSON document-store-as-a-service
● built to ensure that the flow of data between app and database
remains uninterrupted and highly performant.”
Copyright Avancier Ltd 2017
Avancier Use different technologies?
Copyright Avancier Ltd 2017
► Don’t mix technologies just because you fancy trying them out
► Note: IBM’s chalk and cheese example oBCSures the sales pitch…
► Which is more scalable? resilient? agile?
ND: provides near-continuous
availability with advanced performance
and management capabilities for
mission-critical applications
Liberty:
lightweight
Typically performant,
resilient etc.
JSON, HTTP Messaging?
Avancier
-3- To enable very high throughput (by processing transactions in parallel components)
► Surely, few enterprise applications have a throughput high enough
to require this solution?
► Solid state drives and in-memory data stores can handle
remarkably high transaction volumes.
Copyright Avancier Ltd 2017
Who decided this is not
Scalable and Resilient enough?
Application
Avancier -4- To facilitate agile development
► This seems the most common motivation
► The aim is to help one person or a small team develop and deploy
a microservice (separately from others) quickly.
Copyright Avancier Ltd 2017
Application
Avancier
Copyright Avancier Ltd 2017
Principles and trade offs
It is illegal to copy, share or show this document
(or other document published at http://avancier.website)
without the written permission of the copyright holder
Avancier Five modular design principles understood in the 1970s
Design principles Meaning
Cohesion A module encapsulates a cohesive data structure or
algorithm
Loose coupling Modules are encapsulated by and communicate via
interfaces (among other meanings)
Composability Modules can be readily invoked and orchestrated by
higher processes
Reusability Modules are designed for use by different clients
Maintainability Modules can be maintained in several versions to enable
incremental change of module clients
Copyright Avancier Ltd 2017
Avancier Loose coupling?
► Promoted since the 1970s as a good thing
► But not a simple concept, doesn’t address
■ Granularity of components (Fine to Coarse)
■ Stability of components (Craig Larman)
► The discussion ever since the 1970s has been about how best to
■ scope a module
■ separate modules
■ ntegrate modules.
Copyright Avancier Ltd 2017
Avancier Nine microservices principles (Fowler)
► Componentization (discussed here)
► Decentralized data management (discussed here)
► Decentralized governance
► Organisation around “Business Capabilities”
► Smart endpoints and dumb pipes
► Design for failure and "You build, you run it"
Three more from the agile development movement.
► Products not Projects
► Infrastructure Automation
► Evolutionary Design
Copyright Avancier Ltd 2017
Application
Avancier What does decentralising data management mean?
► Encapsulating Code + Data for a “Bounded context” ?
Copyright Avancier Ltd 2017
Wasn’t this a bounded context?
Avancier Berrisford’s universal modularisation trade offs.
Agile developers’ dream Enterprise architects’ nightmare
Smaller, simpler modules Larger, more complex module
dependency & integration
Module isolation/autonomy Duplication between modules
and/or difficulties integrating them
Data store isolation Data disintegrity and difficulties
analysing/reporting data
Copyright Avancier Ltd 2017
Avancier
Copyright Avancier Ltd 2017
Division into microservices
It is illegal to copy, share or show this document
(or other document published at http://avancier.website)
without the written permission of the copyright holder
Avancier Hierarchically layered client-server architecture
Client-side
user interface
Typically HTML pages and javascript running in a browser on
the user's machine
Server-side
application
Controllers: handle requests/commands from the client
Views: populate views/pages sent to the client.
Models: retrieve and update data, applying business rules
Data store
A persistent data structure maintained using a database
management system.
Typically a relational DBMS, but there are many data store
varieties.
Copyright Avancier Ltd 2017
NodeJS? http://www.nodebeginner.org/#javascript-and-nodejs
Avancier
Client-side
user interface Screens / Pages
Server-side
application Some OO domain classes Some OO domain classes
Data store Some data entity types Some data entity types
What does decentralising data management mean?
► “A microservice may consist of multiple processes that will always be
developed and deployed together, such as an application process and a
database.” Fowler
Copyright Avancier Ltd 2017
Avancier How to partition the application and data structures?
► There are two recognised techniques
► Do they correspond?
Copyright Avancier Ltd 2017
Client-side
user interface
Server-side
application
Aggregate entity?
(as in DDD)
Aggregate entity?
(as in DDD)
Data store Hierarchical structure? Hierarchical structure?
Avancier How to partition the network structure of a domain model?
► Note that over time
■ Subtypes tend to become roles
■ Aggregations become associations
■ 1-1 associations become1-N
■ 1 to N become N-to-N w link entities
► The result?
► A network of 1-to-N associations,
as in this Salesforce.com domain
model
Copyright Avancier Ltd 2008-2016
Avancier Salesforce.com domain model redrawn (cf. ZF column 1?)
Copyright Avancier Ltd 2008-2016
Kernel entities
Relationships between them (conceptual model?)
Attributes and characteristic entities (logical model?)
Partitions for implementation (physical model?)
Campaign Opportunity Contact Contract
Account
Kernel
Link
Characteristic
To From
Lead
Lead Status
Quote Opportunity
Status Opportunity Competitor
Asset
Case
Case Status
Approval Contact Status
Partner
Partner Role
Campaign Member
Contact Opportunity
Role
Contact Account
Role
Contact Contract
Role
Reports to
Child of
Partitions
Avancier Fowler’s example of division into microservices
► Some may be happy to decouple and duplicate Customer and
Product data
► Others may see decoupling of Sales from Support as a business
issue that needs to be addressed.
Copyright Avancier Ltd 2017
Avancier
Copyright Avancier Ltd 2017
True microservices
It is illegal to copy, share or show this document
(or other document published at http://avancier.website)
without the written permission of the copyright holder
Avancier Orthogonal modularisation dimensions
► You could code a module for each transaction
► Or code a module for each data entity
► Or both
Copyright Avancier Ltd 2017
Transaction
Register
customer
Place
order
Complete
sale
Launch
product
Recall
product
Data entity
Customer Create Read Read
Sale Create Update Read
Sale item Create Read
Product type Update Create Update
Avancier Procedural microservice = transaction script
► One module for each event/command/transaction script
■ a process that has an access path through the persistent data structure.
► Some transactions will contain duplicate parts
■ same access path and same code.
► Factor out substantial common parts into reusable modules.
Copyright Avancier Ltd 2017
Transaction Register customer Place order Complete sale Launch product Recall product
Data entity
Customer Create Read Read
Sale Create Update Read
Sale item Create Read
Product type Update Create Update
Avancier Entity-oriented modularisation
► Modules that encapsulate more-or-less normalised entities are too
small to be deployed separately as microservices.
► Cf. Fowler’s first rule of distributed objects: “Don’t distribute your
objects!”
► Objects are too small, and coordinating them in higher level
processes is horrendously inefficient.
Copyright Avancier Ltd 2017
Transaction Register customer Place order Complete sale Launch product Recall product
Data entity
Customer Create Read Read
Sale Create Update Read
Sale item Create Read
Product type Update Create Update
Avancier Cluster analysis
► Cannot be done so as to create isolated autonomous components
► A compromise is needed
Copyright Avancier Ltd 2017
Transaction Register customer Place order Complete sale Launch product Recall product
Data entity
Customer Create Read Read
Sale Create Update Read
Sale item Create Read
Product type Update Create Update
Avancier Pseudo microservice – N transaction scripts
► Process all transactions with access paths that start at the same data
entity (or in the same aggregate entity).
► Options include
■ allow pseudo microservices to compete for the same data (limits scalability).
■ duplicate data in several microservices (increases disintegrity and complexity).
Copyright Avancier Ltd 2017
Transaction Register customer Place order Complete sale Launch product Recall product
Data entity
Customer Create Read Read
Sale Create Update Read
Sale item Create Read
Product type Update Create Update
Avancier True microservice
► A true microservice encapsulates a relatively substantial portion of
the persistent data (an aggregate entity or more).
Copyright Avancier Ltd 2017
Transaction Register customer Place order Complete sale Launch product Recall product
Data entity
Customer Create Read Read
Sale Create Update Read
Sale item Create Read
Product type Update Create Update
Avancier Cross-component transactions?
► Microservices coordinated to complete a transaction by
■ Orchestration, or Choreography.
■ Or a mix of both (using the GRASP pattern).
► Or else, you have to duplicate some data between data stores.
■ This leads to the complexity of additional processes to align data stores
after a transaction – asynchronously - as best they can.
Copyright Avancier Ltd 2017
Transaction Register customer Place order Complete sale Launch product Recall product
Data entity
Customer Read Read
Sale Create Read
Sale item Create Read
Product type Update Update
Avancier
Copyright Avancier Ltd 2017
Issues arising
It is illegal to copy, share or show this document
(or other document published at http://avancier.website)
without the written permission of the copyright holder
Avancier Decoupling
► There are dozen or more ways to decouple application components
► Physical decoupling (using network and/or messaging technologies)
is not logical decoupling.
Copyright Avancier Ltd 2017
Feature Tight coupling Decoupling techniques
Naming
Paradigm
Time
Location
Data types
Version
Protocol
Integrity constraints
Often faster and/or simpler
Often more flexible, but more complex
Avancier Component granularity?
► The Bezos mandate to all Amazon dev teams
■ you must communicate only via APIs over the network
► The mandate refers to interfaces between teams
■ does not indicate the size of a team or what it maintains.
■ each team might well maintain a large monolithic system.
■ and divide it into “microservices” – unknown to other teams.
Copyright Avancier Ltd 2017
Avancier
Must microservices be distributed across a network? Even fine-grained components using the same technology?
►Who decides? Programmer or architect?
Copyright Avancier Ltd 2017
?
Avancier Network use?
► The Bezos mandate insists inter-team communication is via APIs
exposed across the network.
► Mandating the same for inter-microservices communication may
hinder performance and increase complexity.
■ What are the implications for network traffic, network costs and network
monitoring?
■ One is forced to use defensive design techniques.
■ An architect told me agile development of distributed microservices in
his enterprise had led to wasteful duplication of data and code.
Copyright Avancier Ltd 2017
Avancier
Must we use messaging between microservices? Even fine-grained components using the same technology?
►Who decides? Programmer or architect?
Copyright Avancier Ltd 2017
?
?
Avancier Middleware use?
► Bezos presumes communication over a (the?) network
► Does not presume middleware use (“Bezos doesn’t care”)
► An architect told me they have a "microservices dependency
nightmare" featuring c200 microservices on c15 app servers.
■ Middleware is logging a ridiculous number of events of no interest to the
business.
■ So, they are looking to strip the middleware out of their primary business
application as far as possible.
Copyright Avancier Ltd 2017
Avancier Things to think about include
► Physical decoupling makes logical coupling more complex
► Naïve architecture guidance
■ can mandate decoupling, asynchronicity and scalability where not needed
► Response time
■ where one transaction requires microservices that communicate via network and/or
messaging
► Availability
■ where synchronous access is needed to partitioned/distributed data stores.
► Scope/complexity creep
■ where microservices are increasingly hooked together.
► Business data and process integrity
■ where BASE replaces ACID.
► Application maintenance
■ where multiple design patterns and technologies are used
Copyright Avancier Ltd 2017
Avancier
Copyright Avancier Ltd 2017
CAP theorem: ACID and BASE
It is illegal to copy, share or show this document
(or other document published at http://avancier.website)
without the written permission of the copyright holder
Avancier CAP theorem: in web apps you can’t have all 3 of
► Consistency (aka integrity)
■ the client perceives a business transaction occurs all at once;
■ there is no moment when the data is inconsistent
► Availability
■ each part transaction will terminate in a meaningful response.
► Partition tolerance
■ each part transaction will complete,
■ even if remote components are unavailable.
■ What about complexity?
Copyright Avancier Ltd 2017
C
A P
Avancier ACID v BASE
► ACID gives you C, reasonable A but not P
► and is simpler ■ Atomic: the whole transaction will complete, or else fail and roll back
■ Consistent: data is in a consistent state before and after the transaction
■ Isolated: no parallel transaction can affect the data this transaction acts on
■ Durable: Upon completion, system will move from one state to the next
► BASE gives you P, partial A, but not C
► and is more complex
■ Basically Available
■ Soft state
■ Eventually consistent
Copyright Avancier Ltd 2017
C
A
A P
Avancier ACID
► Forces consistency (aka integrity) at the end of a transaction
► Limits availability (not partition tolerant)
■ A transaction reading two 99.9% available databases will be only 99.8%
available (43 minutes more downtime per month)
► Greatly simplifies the job of the developer
Copyright Avancier Ltd 2017
Sales partner database Hotel partner database
Room
Hotel
Hotel Chain
Room
Reservation
Facility
Town
Facility
Type
Date start
end
Booking
Room
Reservation
Sales
Agent
Address
Customer
Sales
Partner
ACID Transaction
Avancier BASE
► Permits inconsistency (disintegrity) during the whole transaction
► Increases availability of each partial transaction
► Increases complexity of architecture and development
■ Deeper analysis of operations within a logical transaction
■ Additional compensating transactions to achieve eventual consistency
Copyright Avancier Ltd 2017
Sales partner database Hotel partner database
Room
Hotel
Hotel Chain
Room
Reservation
Facility
Town
Facility
Type
Date start
end
Booking
Room
Reservation
Sales
Agent
Address
Customer
Sales
Partner
BASE Messaging
+ Compensating Transactions
Avancier
Copyright Avancier Ltd 2017
Conclusions and remarks
It is illegal to copy, share or show this document
(or other document published at http://avancier.website)
without the written permission of the copyright holder
Avancier Must microservices have all 9 characteristics?
► “SOA, XP, agile, devops [and Microservices] often come with an “all
or nothing” message, but can you take on the whole package?” IBM
Copyright Avancier Ltd 2017
Avancier The central conflict of ideas
► EA thinking tends to
■ Constrain silo system proliferation
■ Centralise data management
► Microservices thinking tends to do the opposite!
► Business process qualities include speed, accuracy and simplicity.
► Chasing
■ unrealistic scalability goals
■ rapid implementation
► can threaten those business process qualities
Copyright Avancier Ltd 2017
Avancier Particular conclusions and remarks
Be cautious about partitioning what could be one cohesive data structure.
Beware naïve principles, look at realistic requirements and trade offs.
► Flexibility?
■ Beware this usually requires a more complex design.
► Scalability?
■ Be realistic about the need, and assess the cost of allowing and restoring
integrity.
► Decoupling?
■ Beware that decoupling related components physically does not decouple them
logically.
► Reuse?
■ Beware that dividing an application does not usually create components readily
reusable in other contexts.
► Keep it simple?
■ Beware BASE can be considerably more complex than ACID.
Copyright Avancier Ltd 2017
Avancier General conclusions and remarks
► EA needs solution architects to
■ shape and steer programming efforts in an EA-friendly direction.
■ abstract and repeat lessons learned from experience.
► Don’t be over eager to use the latest design pattern/method or
technology.
► Beware that ungoverned agile development can lead to duplication,
disintegrity and complexity.
► Keeping things simple, minimising unnecessary code and use of
middleware, is a reasonable principle.
► This can sometimes mean constraining programmers’ enthusiasm
for “new” ways of doing things.
Copyright Avancier Ltd 2017
Avancier Slide 1 in our enterprise and solution architect training says.
► Think about
■ the business context.
■ the numbers
■ the many ways to design and build something.
► You have to balance trade offs:
■ between qualities (e.g. flexibility or simplicity)
■ between what is best for the local system and what is best for a global
system.
► You are responsible for:
■ knowing there are many possible answers
■ ensuring trade offs are addressed and
■ recommending one or more options.
Copyright Avancier Ltd 2017
Avancier Feedback last week from a professional architect
► From: [Recent course delegate]
Sent: 16 March 2017 09:34
To: Graham
Subject: RE: Microservices for EAs DRAFT SLIDE SHOW FOR COMMENT
► … to let you know I passed the exam, but probably more importantly to say how
much I enjoyed the course last week.
► I was talking to [our leader] and mentioned how the ‘Architectural’ approach to
system change/design has been challenged over the last few years in the rush to
Agile (sometimes misinterpreted as a short-cut that means that you don’t need those
‘old’ roles such as SA’s and BA’s).
► [The course] reminded why we still need Architects and the value of the overall
‘Architectural Approach’ … That’s a really important aspect of the course and on a
personal level I found the whole experience to be very positive.
► Best Regards,
► [Recent course delegate]
Copyright Avancier Ltd 2017
Avancier
Copyright Avancier Ltd 2017
Microservices from an EA perspective A talk for the BCS EA specialist group
THE END
Lots more to read at http://avancier.website