O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Better application architecture with #microservices and #BPM (as APaaS)

2.747 visualizações

Publicada em

Better application architecture with #microservices and #BPM (as APaaS)

Publicada em: Tecnologia
  • Seja o primeiro a comentar

Better application architecture with #microservices and #BPM (as APaaS)

  1. 1. Better application architecture with #microservices and #BPM 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 • 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 2 Better application architecture
  3. 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 Better application architecture 3 Typical IT concerns
  4. 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 Better application architecture 4 Application architecture key concepts (1)
  5. 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 Better application architecture 5 Application architecture key concepts (2) Service consumer Service provider
  6. 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 assembled from microservices may have many microservice-to-microservice dynamic connections N * (N-1) / 2 2016-09-01 Better application architecture 6 Application architecture key concepts (3)
  7. 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 Better application architecture 7 Application architecture key concepts (4) API gateway
  8. 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 Better application architecture 8 Microservices in application lifecycle
  9. 9. 2016-09-01 Better application architecture 9 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 CI CI SA Dev Ops Dev Ops SA SA CI Dev Ops Change something Test relationships SA – Solution Architecture CI – Continuous Integration
  10. 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 Better application architecture 10 Application building blocks which BPM-suite tool as APaaS can manage
  11. 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 Better application architecture 11 BPM-suite tool helps to determine “right” granularity for microservices
  12. 12. 2016-09-01 Better application architecture 12 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
  13. 13. 2016-09-01 Better application architecture 13 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
  14. 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 Better application architecture 14 Decomposing of monoliths
  15. 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 Better application architecture 15 Bonus – agile development
  16. 16. • Personal website: http://www.samarin.biz • Blog http://improving-bpm-systems.blogspot.com • LinkedIn: http://www.linkedin.com/in/alexandersamarin • E-mail: alexandre.samarine@gmail.com • Twitter: @samarin • Mobile: +41 76 573 40 61 • Book: www.samarin.biz/book Better application architecture 16 Thank you 2016-09-01
  17. 17. 2016-09-01 Better application architecture 17
  18. 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 Better application architecture 18

×