Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

28 views

Published on

A small source for IT students at the VFU, Varna.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

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

  1. 1. Architecting digital systems Module 4 Microservices Alexander Samarin
  2. 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 – 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
  3. 3. • 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? © A. Samarin 2018 Architecting digital systems - Module 4 3 Typical reaction from IT
  4. 4. • 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. © A. Samarin 2018 Architecting digital systems - Module 4 4 AppArch key concepts (1)
  5. 5. • 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) © A. Samarin 2018 Architecting digital systems - Module 4 5 AppArch key concepts (2)
  6. 6. • 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 © A. Samarin 2018 Architecting digital systems - Module 4 6 AppArch key concepts (3)
  7. 7. • 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 © A. Samarin 2018 Architecting digital systems - Module 4 7 AppArch key concepts (4) Service consumer Service provider
  8. 8. • 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 © A. Samarin 2018 Architecting digital systems - Module 4 8 AppArch key concepts (4)
  9. 9. • 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 © A. Samarin 2018 Architecting digital systems - Module 4 9 AppArch key concepts (5)
  10. 10. • 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 © A. Samarin 2018 Architecting digital systems - Module 4 10 AppArch key concepts (6) API gateway
  11. 11. • Functional integration • Platform-based architecture © A. Samarin 2018 Architecting digital systems - Module 4 11 AppArch key concepts (7) Application 1 ERP ECM
  12. 12. • 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. © A. Samarin 2018 Architecting digital systems - Module 4 12 AppArch modern tendencies https://www.infoq.com/news/2018/03/microservices-anti-patterns
  13. 13. • Implement RequestLoan microservice with the following activities: – ReviewRequest – CheckClient or – CheckHistory – ApproveLoan or – RejectLoan – PrepareContract if approved © A. Samarin 2018 Architecting digital systems - Module 4 13 Assembling microservices: use case
  14. 14. © A. Samarin 2018 Architecting digital systems - Module 4 14 Assembling microservices: choreography Key Synchronous Asynchronous Prepare Contract Approve Loan Check History Review request Check Client Reject Loan
  15. 15. © A. Samarin 2018 Architecting digital systems - Module 4 15 Assembling microservices: orchestration Request Loan Key Synchronous Asynchronous Check Client Check History Approve Loan Prepare Contract Rview Request Reject Loan
  16. 16. Request Loan Check Requestor Check History Prepare Contract © A. Samarin 2018 Architecting digital systems - Module 4 16 Assembling microservices: reactive streams and runnable graphs Key Synchronous Asynchronous Approve Loan Reject Loan
  17. 17. © A. Samarin 2018 Architecting digital systems - Module 4 17 Assembling microservices: based on business processes Key Synchronous Asynchronous Prepare Contract Approve Loan Check History Check Client Review Loan Reject Loan
  18. 18. © A. Samarin 2018 Architecting digital systems - Module 4 18 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
  19. 19. • 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 © A. Samarin 2018 Architecting digital systems - Module 4 19 Advantages from technical side
  20. 20. © A. Samarin 2018 Architecting digital systems - Module 4 20 Modern applications are assembled from existing autonomous components https://go.ifrc.org/
  21. 21. © A. Samarin 2018 Architecting digital systems - Module 4 21 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
  22. 22. Utility AC Data-centric mini-portal AC Resource (data) AC API Simple operation AC API API Typology of applications: data-centric AC – Autonomous Component © A. Samarin 2018 Architecting digital systems - Module 4 22
  23. 23. Resource (documents) AC Document- centric mini- portal AC Short-running operation AC API Utility AC Resource (data) AC API API API Typology of applications: document-centric AC – Autonomous Component © A. Samarin 2018 Architecting digital systems - Module 4 23
  24. 24. 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 Typology of applications: short-running operation-centric © A. Samarin 2018 Architecting digital systems - Module 4 24 AC – Autonomous Component
  25. 25. 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 Typology of applications: long-running operation-centric © A. Samarin 2018 Architecting digital systems - Module 4 25 AC – Autonomous Component
  26. 26. 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 © A. Samarin 2018 Architecting digital systems - Module 4 26 Complex application
  27. 27. 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. Samarin 2018 Architecting digital systems - Module 4 27
  28. 28. 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 © A. Samarin 2018 Architecting digital systems - Module 4 28 Complex application
  29. 29. Event in Human activity Document Event out External automated activity Data Business rule Built-in automated activity Granularity of microservices (1) © A. Samarin 2018 Architecting digital systems - Module 4 29 External automated activity PRE External automated activity POST External automated activity Built-in automated activity Data
  30. 30. • 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 © A. Samarin 2018 Architecting digital systems - Module 4 30 Granularity of microservices (2)
  31. 31. “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 © A. Samarin 2018 Architecting digital systems - Module 4 31 R2 “Asset µservices” (composite) Composite µservices
  32. 32. • 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 © A. Samarin 2018 Architecting digital systems - Module 4 32 Easy recovering from errors
  33. 33. • 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 © A. Samarin 2018 Architecting digital systems - Module 4 33 Idempotency explained (1) A B x ERP C E3 E1 E2
  34. 34. • 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. Samarin 2018 Architecting digital systems - Module 4 34 Idempotency explained (2) A B x ERP C E3 E1 E2❶ ❷ ❺ ❸ ❹ ❻ A B x ERP C E3 E1 E2❶ ❷ ❺ ❸ ❹
  35. 35. • 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. Samarin 2018 Architecting digital systems - Module 4 35 Idempotency explained (2) A B x ERP C E3 E1 E2❶ ❷ ❺❸ ❹
  36. 36. Template 1st pass (failure at B) 2nd pass (failure at C)3rd pass (OK) Idempotency explained (4) © A. Samarin 2018 Architecting digital systems - Module 4 36 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❶ ❷ ❺❸ ❹
  37. 37. 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 © A. Samarin 2018 Architecting digital systems - Module 4 37
  38. 38. Interpretive language for microservices (2) Ax ERP1 E3 E1 E2 … … ERP2 E4 Bx ERP1 E3 E1 E2 … … ERP2 E4 © A. Samarin 2018 Architecting digital systems - Module 4 38
  39. 39. © A. Samarin 2018 Architecting digital systems - Module 4 39 Containers (1)
  40. 40. • New problem – management of containers (also called orchestration) – consider Kubernetes ( see https://www.infoq.com/articles/kubernetes-effect ) © A. Samarin 2018 Architecting digital systems - Module 4 40 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.
  41. 41. © A. Samarin 2018 Architecting digital systems - Module 4 41 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.
  42. 42. Containers (4) © A. Samarin 2018 Architecting digital systems - Module 4 42 standard container language- specific container specialized container microservice
  43. 43. © A. Samarin 2018 Architecting digital systems - Module 4 43 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
  44. 44. • 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 © A. Samarin 2018 Architecting digital systems - Module 4 44 Security
  45. 45. © A. Samarin 2018 Architecting digital systems - Module 4 45 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
  46. 46. © A. Samarin 2018 Architecting digital systems - Module 4 46 Decomposing monolith (2) 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
  47. 47. 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 © A. Samarin 2018 Architecting digital systems - Module 4 47 Decomposing monolith (3)
  48. 48. 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 © A. Samarin 2018 Architecting digital systems - Module 4 48 Decomposing monolith (4)
  49. 49. Application D Application C Application B Application A Application E α Batch (non-interactive) program ε β ζ γ η θ κ λ δ α © A. Samarin 2018 Architecting digital systems - Module 4 49 Decomposing monolith (5)
  50. 50. As is 1st iteration 2nd iteration 3rd iteration To be Application D Application CApplication Aβ λ Application D Application CApplication Aβ λ Application D Application CApplication Aβ λ Application D Application CApplication Aβ λ Application D Application CApplication Aβ λ © A. Samarin 2018 Architecting digital systems - Module 4 50 Decomposing monolith (6)
  51. 51. • 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 © A. Samarin 2018 Architecting digital systems - Module 4 52 Persistence data management: conventions
  52. 52. © A. Samarin 2018 Architecting digital systems - Module 4 53 Persistence data management: typical point-to-point
  53. 53. © A. Samarin 2018 Architecting digital systems - Module 4 54 Persistent data management: initial
  54. 54. © A. Samarin 2018 Architecting digital systems - Module 4 55 Persistent data management: extension
  55. 55. © A. Samarin 2018 Architecting digital systems - Module 4 56 Persistent data management: updates
  56. 56. © A. Samarin 2018 Architecting digital systems - Module 4 57 Persistent data management: functional
  57. 57. © A. Samarin 2018 Architecting digital systems - Module 4 58 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
  58. 58. © A. Samarin 2018 Architecting digital systems - Module 4 59 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
  59. 59. © A. Samarin 2018 Architecting digital systems - Module 4 60 Tools and experience https://www.youtube.com/watch?v=OuzjaYlxX1A
  60. 60. Typical technical view © A. Samarin 2018 Architecting digital systems - Module 4 61
  61. 61. • API gateway • Event bus (queue, dispatcher) • Service discovery • integration Platform as a Services (iPaaS) • Containers, Orchestration, Infrastructure as Code (IaC) © A. Samarin 2018 Architecting digital systems - Module 4 62 5 major tools
  62. 62. © A. Samarin 2018 Architecting digital systems - Module 4 63 Business goals achieved with microservices • Solutions which are “Best for fit” • Time-to-market • Low cost of operations
  63. 63. • Moving fast • Focus on frontends • Cloud-native and serverless • Ambient сomputing • Information security © A. Samarin 2018 Architecting digital systems - Module 4 64 Tendencies https://www.infoq.com/news/2018/03/microservices-future-it-changes
  64. 64. © A. Samarin 2018 Architecting digital systems - Module 4 65 Example of transformation
  65. 65. Legacy application or COTS Atomic service Application flow of controlflow of data implicit mixed flowexplicit mixed flow In-house
  66. 66. Legacy application or COTS App Internet In-house SaaS in Cloud API Atomic service Application flow of controlflow of data implicit mixed flowexplicit mixed flow
  67. 67. Legacy application or COTS App SOA+ESB+API APIAPI Container Container Internet In-house SaaS in Cloud API Atomic service Application flow of controlflow of data implicit mixed flowexplicit mixed flow
  68. 68. 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 flow of controlflow of data implicit mixed flowexplicit mixed flow
  69. 69. 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 flow of controlflow of data implicit mixed flowexplicit mixed flow Click for animation
  70. 70. Legacy application or COTS App SOA+ESB+API APIAPIAPIAPIAPI Container ContainerBPMS containerBPMS containerBPMS container Internet In-house Process-centric solution (internal, B2C, B2B) 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 flow of controlflow of data implicit mixed flowexplicit mixed flow
  71. 71. Legacy application or COTS App SOA+ESB+API APIAPIAPIAPIAPI Container ContainerBPMS containerBPMS containerBPMS container Internet In-house Process-centric solution (internal, B2C, B2B) 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 flow of controlflow of data implicit mixed flowexplicit mixed flow
  72. 72. 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 flow of controlflow of data implicit mixed flowexplicit mixed flow 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 Process-centric solution (internal, B2C, B2B)
  73. 73. 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 flow of controlflow of data implicit mixed flowexplicit mixed flow 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 Process-centric solution (internal, B2C, B2B) App
  74. 74. 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 flow of controlflow of data implicit mixed flowexplicit mixed flow 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 Process-centric solution (internal, B2C, B2B) App
  75. 75. SOA+ESB+API SOA+ESB+API Legacy application or COTS App API API Container Container Internet In-house SaaS in Cloud API Atomic service flow of controlflow of data implicit mixed flowexplicit mixed flow 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 Process-centric solution (internal, B2C, B2B) App
  76. 76. SOA+ESB+API App API Container Internet In-house SaaS in Cloud API Atomic service flow of controlflow of data implicit mixed flowexplicit mixed flow 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 Process-centric solution (internal, B2C, B2B) App Service API Container Another PaaS in Cloud Service API Container SaaS in Cloud COTS API
  77. 77. © A. Samarin 2018 Architecting digital systems - Module 4 79 Questions?
  78. 78. • 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 © A. Samarin 2018 Architecting digital systems - Module 4 80 Application building blocks which BPM-suite tool as APaaS can manage
  79. 79. • 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 © A. Samarin 2018 Architecting digital systems - Module 4 81 BPM-suite tool helps to determine “right” granularity for microservices

×