Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Transforming Monoliths and the Way We Build Software

Transforming Monoliths and the Way We Build Software

At Pivotal, we help clients transform the way they build software. This doesn't only apply to greenfield applications. Using our platforms, we help customers replatform, modernize or rebuild their monolithic applications using proven methodology and practices. This presentation contains a number of those practices and patterns we continuously apply.

Fbcb461e8c19ccc6727f13dbfcd58362?s=128

Andreas Evers

November 29, 2018
Tweet

More Decks by Andreas Evers

Other Decks in Technology

Transcript

  1. © Copyright 2018 Pivotal Software, Inc. All rights Reserved. Version

    1.0 Andreas Evers (@andreasevers) Senior Solutions Architect aevers@pivotal.io Transforming monoliths and the way we build software
  2. Cover w/ Image Who’s this guy? ▪ Andreas Evers -

    Senior Solutions Architect at Pivotal ▪ Active in Application Transformation (AppTx) EMEA ▪ Used to work at TVH for Ordina ▪ Since then active for Renault, Rabobank, ...
  3. None
  4. vSphere Openstack AWS Google Cloud Azure & Azure Stack Shared

    Services Shared Security Shared Networking Logging & Metrics / Services Brokers / API Management Credhub / UAA / Single Sign On VMware NSX Embedded Operating System (Windows / Linux) Application Code & Frameworks Buildpacks / Spring Boot / Spring Cloud / Steeltoe PAS Pivotal Application Service PKS Pivotal Container Service PFS Pivotal Function Service Pivotal Services Marketplace Pivotal and Partner Products Any App Every Cloud One Platform Concourse PCF 2.0 — for everything that matters
  5. Working Code Slices Practices OKRs Event Storming Slice Analysis Boris

    Snap/SnapE Implementation Patterns rinse & repeat Value Stream
  6. OKRs Snap/SnapE Implementation Patterns rinse & repeat Working Code Slices

    Practices Event Storming Slice Analysis Boris Value Stream
  7. Snap/SnapE Implementation Patterns rinse & repeat OKRs Working Code Slices

    Practices Event Storming Slice Analysis Boris Value Stream
  8. OKRs Objectives Key Results Key Result ABC Key Result GHI

  9. OKRs Could Measure Should Measure Objectives Key Results brainstorm decide

    order brainstorm group define Objective Objective Objective
  10. Cultural Transformation • 1 Week iterations with short feedback cycles

    • > 50% Of time spent on pairing or mobbing • 70% Less time spent on estimations & plannings Decrease Time to Market Cloud-Native Transformation • 75% Decrease in lead time for simple code change • 100% Autonomous team, 0 handoffs to get to prod • < 3 Manual steps in the CI/CD pipeline • > 25 Transformation recipes in a central cookbook • 3 Monoliths modularized and running on PCF • > 15 Spring boot or Spring Cloud templates • < 0.01% Downtime due to failures or restarts • 60% Decrease in MTTP for detected CVEs • 40% Decrease in support incidents Better Stability & Security OKRs
  11. Snap/SnapE Implementation Patterns rinse & repeat OKRs Working Code Slices

    Practices Event Storming Slice Analysis Boris Value Stream
  12. Snap/SnapE Implementation Patterns rinse & repeat OKRs Working Code Slices

    Practices Event Storming Slice Analysis Boris Value Stream
  13. Map the As-Is Process

  14. Map the As-Is Process Wri h Fe t e 10

    mi s P s Dev 20 mi s 1-4 da Tot e As-Is: 3-5 We k Po n h Fe t e IP 5-8 da 2-3 da
  15. None
  16. Map the To-Be Process A. Create the To-Be Process using

    the same technique B. Write down the action items needed to make each change happen C. Review the progress against the flipcharts D. Host a quick retro and a quick celebration! E. Send out pictures of the flipcharts, whiteboards, and action items
  17. None
  18. Snap/SnapE Implementation Patterns rinse & repeat OKRs Working Code Slices

    Practices Event Storming Slice Analysis Boris Value Stream
  19. None
  20. This paper discusses modularization as a mechanism for improving the

    flexibility and comprehensibility of a system while allowing the shortening of its development time. The effectiveness of a “modularization” is dependent upon the criteria used in dividing the system into modules.
  21. The major progress in the area of modular programming has

    been the development of coding techniques and assemblers which (1) allow one module to be written with little knowledge of the code used in another module and, (2) allow modules to be reassembled and replaced without reassembly of the whole system.
  22. We have tried to demonstrate…it is almost always incorrect to

    begin the decomposition of a system into modules on the basis of a flowchart…instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. Since, in most cases, design decisions transcend time of execution, modules will not correspond to steps in the processing…we must abandon the assumption that a module is one or more subroutines, and instead allow subroutines and programs to be assembled collections of code from various modules.
  23. The fundamental ways in which we design modules effectively has

    not changed in the last 50 years. MATT STINE
  24. Snap/SnapE Implementation Patterns rinse & repeat OKRs Working Code Slices

    Practices Slice Analysis Boris Event Storming Value Stream
  25. Simple Tools

  26. Bounded Context Seats Payment Aggregate Aggregate Aggregate Domain Event Domain

    Event Domain Event Domain Event Domain Event Domain Event Domain Event Domain Event Domain Event ! Domain Event Relevant Business Event “Seat Chosen”, “Ticket Purchased” Aggregate Brains Accepts Actions / Generates “Events” Domain Event Domain Event Domain Event Domain Event Domain Event Domain Event Domain Event Domain Event Slice candidate Command Command ?
  27. Why Event Storm Making Sense of a Huge Mess Reveal

    Bounded Contexts Explore Domains Identify Potential “Slices” Expose Core Domains Identify Potential Trouble Spots Enable Cross Perspective Conversation Identify Potential Starting Points
  28. None
  29. Bounded Contexts Boundaries, inside of which a Ubiquitous Language can

    be used freely without ambiguity. Microservices Independently deployable units focused around a specific business capability. Aggregates Aggregates are a logical boundary for things that can change in a business transaction of a given context. Tactical Domain Driven Design Technical Design Strategic Domain Driven Design The Golden Rule 1 1 1 1
  30. Tactical Domain Driven Design Technical Design Strategic Domain Driven Design

    The Golden Rule many 1 1 1 Bounded Contexts Boundaries, inside of which a Ubiquitous Language can be used freely without ambiguity. Microservices Independently deployable units focused around a specific business capability. Aggregates Aggregates are a logical boundary for things that can change in a business transaction of a given context.
  31. Tactical Domain Driven Design Technical Design Strategic Domain Driven Design

    The Golden Rule many 1 many 1 Bounded Contexts Boundaries, inside of which a Ubiquitous Language can be used freely without ambiguity. Microservices Independently deployable units focused around a specific business capability. Aggregates Aggregates are a logical boundary for things that can change in a business transaction of a given context.
  32. Bounded Contexts Microservices Aggregates The Golden Rule * .. 1

    * .. 1
  33. Snap/SnapE Implementation Patterns rinse & repeat OKRs Working Code Slices

    Practices Slice Analysis Boris Event Storming Value Stream
  34. Snap/SnapE Implementation Patterns rinse & repeat OKRs Working Code Slices

    Practices Slice Analysis Event Storming Boris Value Stream
  35. More Tools

  36. Service Service based on Context Payment Service” Queue Message Queue

    “Seat Request” UI External Link to External System Service Service Service Service Service Service Ext Ext Q Q Q UI UI
  37. None
  38. None
  39. Modular Monolith Microservices ▪ High Cohesion ▪ Low Coupling ▪

    Business Capability Focus ▪ Bounded Contexts / Aggregates ▪ Data Encapsulation ▪ Substitutable ▪ Composable ▪ Individually Deployable ▪ Individually Upgradeable ▪ Individually Replaceable ▪ Individually Scalable ▪ Heterogeneous Tech Stacks
  40. Snap/SnapE Implementation Patterns rinse & repeat OKRs Working Code Slices

    Practices Slice Analysis Event Storming Boris Value Stream
  41. Snap/SnapE Implementation Patterns rinse & repeat OKRs Working Code Slices

    Practices Event Storming Slice Analysis Boris Value Stream
  42. Map technology stack with C4 diagrams Explore the ideal end

    state Affinity Mapping, Dot Voting The Right Vertical Slice Big Picture Event Storming Process Modelling Identify & Prioritize Bottlenecks Progressively drill from abstract >> specific
  43. Implementation Patterns rinse & repeat OKRs Snap/SnapE Working Code Slices

    Practices Event Storming Slice Analysis Boris Value Stream
  44. SNAP

  45. None
  46. None
  47. None
  48. None
  49. Think to the Future: Choose the Right Tool for the

    Job Container Orchestrator Container Scheduling Primitives for Network, Routing, Logs & Metrics CONTAINER Developer Provides Tool Provides Application Platform APPLICATION Container Orchestrator Serverless Functions FUNCTION Application Platform IaaS Container Image & build L7 Network & Routing Logs, Metrics, Monitoring Services Marketplace Team, Quotas & Usage Function scheduling Function exec services
  50. SnapE API Data Source / Storage UI Risks Stories Rabbit

    MQ REST / JSON CICS GW Other Purchase History AdminUI Dependent On... GET /purchases GET /purchases GET /purchases
  51. Implementation Patterns rinse & repeat OKRs Snap/SnapE Working Code Slices

    Practices Event Storming Slice Analysis Boris Value Stream
  52. rinse & repeat OKRs Snap/SnapE Implementation Patterns Working Code Slices

    Practices Event Storming Slice Analysis Boris Value Stream
  53. Class Decorators, AOP, AspectJ, Javaagents Feature Flags, Dynamic Routing, Dark

    Launching API Gateway, Edge Server, B4FF Inverse Conway Event Shunting ACL, Context Mapping, Strangler Bridge, Router, Proxy, Facade Eventual Consistency, Sagas, microservices instead of ESB
  54. rinse & repeat OKRs Snap/SnapE Implementation Patterns Working Code Slices

    Practices Event Storming Slice Analysis Boris Value Stream
  55. OKRs Snap/SnapE Implementation Patterns Working Code Slices Practices Event Storming

    Slice Analysis Boris Value Stream rinse & repeat
  56. None
  57. Pair Programming

  58. None
  59. None
  60. Mob Programming

  61. None
  62. None
  63. Test Driven Development

  64. None
  65. None
  66. None
  67. OKRs Snap/SnapE Implementation Patterns rinse & repeat Working Code Slices

    Practices Event Storming Slice Analysis Boris Value Stream
  68. OKRs Snap/SnapE Implementation Patterns rinse & repeat Working Code Slices

    Practices Event Storming Slice Analysis Boris Value Stream
  69. Transforming How The World Builds Software Andreas Evers (@andreasevers) Senior

    Solution Architect aevers@pivotal.io https://evers.tech © Copyright 2018 Pivotal Software, Inc. All rights Reserved. Accreditation: Image created by Rawpixel.com - Freepik.com Seahorse by Les vieux garçons from the Noun Project Tool Case by icons producer is licensed under CC 3.0 Steel-bars-of-a-building-under-construction Designed by Freestockcenter