Better application architecture with #microservices and #BPM (as APaaS)
-
Upload
alexander-samarin -
Category
Technology
-
view
835 -
download
0
Transcript of Better application architecture with #microservices and #BPM (as APaaS)
Better application architecture with #microservices and #BPM
Alexander SAMARIN
Better application architecture 2
• 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
• How to address those concerns– Develop solutions as a suite of independently deployable, small,
modular services known as microservices (like a football team is assembled from individual players)
– Refactor, modernise and decompose existing monoliths into microservices
– Start new solutions with microservices– Better manage changes in software application
2016-09-01
Better application architecture
Better application architecture 3
• I like microservices• How to define granularity of microservices?• Let us buy API gateway• 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 corporate data?• We need DevOps, CI, etc.• What is our target application architecture?2016-09-01
Typical IT concerns
Better application architecture 4
• Unit-of-functionality is a computing component implementing a particular capability– examples: function, method, package
• Unit-of-deployment is a computing component which can be individually and independently deployed into a runtime computing environment– 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)
2016-09-01
Application architecture key concepts (1)
Better application architecture 5
• Interface is a shared boundary between two units-of-functionality, defined by functional characteristics, signal characteristics, or other characteristics as appropriate
• Service is a unit-of-functionality which is available from (usually separate from its consumer) unit-of-deployment 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 is an agreement between
the service consumer and the service provider on performance, measurement and conditions of service delivery
2016-09-01
Application architecture key concepts (2)
Service consumer
Service provider
Better application architecture 6
• Microservice is functionally-minimalistic and deployment-independent service– functionally-minimalistic, i.e. follow the Single Responsibility Principle– deployment-independent i.e. unit-of-functionality equals to unit-of-
deployment thus autonomous in some extent• Assembly of microservices may
be a microservice as well
• Solutions which are assembledfrom microservices may havemany microservice-to-microservicedynamic connections N * (N-1) / 2
2016-09-01
Application architecture key concepts (3)
Better application architecture 7
• API gateway is a proxy between a service consumer and a service provider – 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
2016-09-01
Application architecture key concepts (4)
API gateway
Better application architecture 8
• 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
2016-09-01
Microservices in application lifecycle
Better application architecture 92016-09-01
Various development lifecycles
monolith applications
process-basedsolutions
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
CI
CI
SA
Dev Ops
Dev Ops
SA
SA
CI Dev Ops
Change something Test relationships
SA – Solution ArchitectureCI – Continuous Integration
Better application architecture 10
• 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
2016-09-01
Application building blocks which BPM-suite tool as APaaS can manage
Better application architecture 11
• 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
2016-09-01
BPM-suite tool helps to determine “right” granularity for microservices
Better application architecture 122016-09-01
Frequency of changes in various building blocks
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
Better application architecture 132016-09-01
Scenarios for implementation of process-centric solutions
Types of building block
Prototyping Pragmatic combination Extreme microservices (BPM-Suite tool defines API)
Human activities iBPMS iBPMS iBPMS
Data structures New: iBPMS, existing: ext. tools μService from external tools μService from corporate tool
Documents New: iBPMS, existing: ext. tools μService from external tools μService with corporate tool ECM
Roles New: iBPMS, existing: ext. tools New: iBPMS, existing: ext. tool Corporate tool IAM
Business rules New: iBPMS, existing: ext. tools New: iBPMS, existing: μService iBPMS and μService (exposing iBPMS)
Automated activities New: iBPMS, existing: ext. tools Generic: iBPMS, specific: μService Generic: iBPMS, specific: μService
Reports New: iBPMS, existing: corp. tool New: iBPMS, existing: corp. tool μService with corporate tool
Records New: iBPMS, existing: corp. tool New: iBPMS, existing: corp. tool μService with corporate tool
Dashboards New: iBPMS, existing: corp. tool New: iBPMS, existing: corp. tool μService with corporate tool
Portal iBPMS or corporate tool iBPMS or corporate tool Corporate tool role-based portal
Explicit-assembles iBPMS iBPMS iBPMS
Better application architecture 14
• Determine business domains and the kernel• Select a particular domain for be “eclipsed”• Model a group processes (activities, events, roles and
data) for this domain• Separate back office and front office• Find candidates for the kernel• Define data model for this domain• Implement domain and kernel data as services• Implement kernel’s services• Apply eclipse pattern (also known as stranger pattern)• Refactor what matter with processes• Keep the monolith in the box 2016-09-01
Decomposing of monoliths
Better application architecture 15
• The combination of BPM and microservices also naturally incorporate agile development into application architecture
• Agile development is the best way to implement microservices
• Related blogposts– http://improving-bpm-systems.blogspot.ch/search/label/%23microservices
– http://improving-bpm-systems.blogspot.ch/search/label/%23apparch
– http://improving-bpm-systems.blogspot.ch/2014/06/different-coordination-techniques-in.html
– http://improving-bpm-systems.blogspot.ch/2014/04/ideas-for-bpmshift-delenda-est-vendor_27.html
– http://improving-bpm-systems.blogspot.ch/2013/04/enterprise-patterns-strategy.html
2016-09-01
Bonus – agile development
Better application architecture 16
• Personal website: http://www.samarin.biz• Blog http://improving-bpm-systems.blogspot.com• LinkedIn: http://www.linkedin.com/in/alexandersamarin• E-mail: [email protected]• Twitter: @samarin • Mobile: +41 76 573 40 61• Book: www.samarin.biz/book
Thank you
2016-09-01
Better application architecture 172016-09-01
Better application architecture 18
• An enterprise architect– from a programmer to a systems architect (systems of various
sizes: company, corporate, canton, country, continent)– have created production systems which work without me
• Some of my professional roles– “cleaning lady” (usually in an IT department)– “peacemaker” (between the IT and business)– “swiss knife” (for solving any problem)– “patterns detective” (seeing commonalities in “unique” cases)– “assembler” (making unique things from commodities)– “barriers breaker” (there is always a bigger system)– “coordinator” (without any formal authority over components)
About me
2016-09-01