2018 Pivotal DevOps Day_마이크로서비스 전환 방법론과 사례
3 likes•791 views
The document outlines strategies and methodologies for transitioning to microservices, including the use of cloud-native applications, domain-driven design, and the Apptx methodology. It emphasizes the importance of evaluating application portfolios, implementing iterative processes, and applying technical assessments to identify suitable candidates for migration. The case study of Liberty Mutual highlights practical experiences in overcoming challenges associated with monolithic architectures and moving towards a more agile, microservices-based framework.
2018 Pivotal DevOps Day_마이크로서비스 전환 방법론과 사례
- 2. 마이크로서비스 전환 방법론과 사례 김영태
- 3. • Cloud Native Applications Journey • Domain Driven Design • AppTx Methodology • Liberty Mutual Case Agenda
- 4. Part 1 Cloud Native Applications Journey © Copyright 2017 Pivotal Software, Inc. All rights Reserved.
- 5. Technical Filter Type (ex. COTS, ISV), Suitability Factors, etc. Application Portfolio Business Filter Criticality, Risk Tolerance, Change Frequency, etc. Prioritized Backlog App Tx Iterative Process App Patterns PCF App Measurement & Learning Select top app in migration backlog Continued iteration Create / update patterns, provide feedback to enhance filtering and backlog velocity Application Transformation Funnel Use of tooling and templates to quickly make effective candidate selection, constantly prioritize work and continuously share feedback to accelerate future efforts
- 6. Technical Triage: App Foundry Automated suitability assessment and decisioning framework. Currently a closed beta, targeting GA this fall. Upload binary or map to source control Parsers for most common languages (Java, .NET, PHP, Ruby, etc.) Extensible rules (100s available currently) UI dashboard to help triage decisioning
- 7. Understanding Your Application Portfolio TECHNICALCONDITION BUSINESS VALUEWORSE BETTER WORSEBETTER Tolerate Invest MigrateEliminate Focus here and start with the most impactful custom apps built 0 to 7 years ago with supported tech Understand: ● Technical condition (Y-Axis), e.g. ○ Scalability ○ Performance ● Business value, (X-Axis)e.g. ○ Criticality ○ Competitive advantage ● Operational cost (Size), e.g. ○ License ○ Hardware ● Risk (Color), e.g. ○ Compliance ○ Skill set
- 8. Methodology and Techniques • Portfolio level goals definition • Cloud suitability assessment and education • Define OKRs • Discuss timeline, staffing, risk, dependencies, etc. • One-week iterations • Hands-on code within 2-3 days • 1s to 10s of apps moved in 1s of weeks • Working code used to inform a cookbook of patterns Product Backlog (Pivotal Tracker) Boris Event Storming OKRs Slice Analysis Snap / SnapE Patterns ScopingDiscovery Ongoing Delivery Cycle Value Stream Fixed Timeline Engagement Supported by a Paired Team
- 9. Part 2 Domain Driven Design © Copyright 2017 Pivotal Software, Inc. All rights Reserved.
- 10. “...the real breakthrough of object design comes when the code expresses the concepts of a model.” “Anyone responsible for changing code must learn to express a model through the code. Every developer must be involved in some level of discussion about the model and have contact with domain experts.” - Eric Evans, Domain-Driven Design Domain-Driven Design
- 11. “In the end the code is the model and the model is the code.” - Vaughn Vernon, Domain-Driven Design Distilled As opposed to: 1. Business Overview 1.1 Requirement This interface is used to send Sched CGO messages from SHIP-PRO to ODS. SHIP-PRO will send the SyncSCHD_CGO BO to MBS and MBS will push the data to ODS as SCHD_CGO_WRAPPER BO. This interface will also be added to the AMS view for monitoring. Domain Driven Design
- 12. Aggregates AGGREGATES mark off the scope within which invariants have to be maintained at every stage of the lifecycle ● Transactional Boundary ● Public access only via the Aggregate Root
- 13. “Generally speaking, there is a correspondence of one team per BOUNDED CONTEXT. One team can maintain multiple BOUNDED CONTEXTS, but it is hard … for multiple teams to work on one together.” - Evans Bounded Context
- 14. Vaughn Vernon, Domain-Driven Design Distilled Event Driven Architecture
- 15. Part 3 AppTx Methodology © Copyright 2017 Pivotal Software, Inc. All rights Reserved.
- 17. OKRs
- 18. Ambitious Where to? Objectives Key Results + -increase decrease% # Are we going the right way? AppTx 70 - 80%
- 19. Config Customer Test Environment Quicker Incrementally Handle PROD traffic Create Guidance for App Transformation 1 Process state migrated to PCF 1 State transition from PCF to legacy env. Reduce manual steps by 25% Setup & complete < 2 day Reduce # of tools used by 1/3 1 Central cookbook of transformation recipes 5 Testing guidelines 10 Spring Boot templates Mission: Reduce time to onboard new customers
- 20. Could Measure Should Measure Objectives Key Results brainstorm brainstorm decide order define Objective Objective Objective
- 21. Monitor by Status and Confidence
- 23. Simple Tools
- 24. Discount Bounded Context Show Payment Payment Movie Venue Movie Chosen Date Chosen Venue Chosen Seat Chosen Payment Started Discount Code Entered Card Payment Chosen Payment Complet ed Ticket Purchas ed ! Domain Event Relevant Business Event “Seat Chosen”, “Ticket Purchased” Aggregate Brains Accepts Actions / Generates “Events” Partner Venue Chosen 3rd Party Coupon Entered Mobile Payment Chosen 3rd Party Payment Chosen Slice candidate ?
- 27. More Tools
- 28. 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
- 30. Inform Architecture Event Flow Contexts to µService API Discovery Scenario Modeling Orchestration to Choreography Validate Slice Candidate Fill the Backlog
- 32. SnapE API Data Source / Storage UI Risks Stories Rabbit MQ REST / JSON CICS GW Other Purchase History AdminUI Dependent On... GET /purchasesGET /purchasesGET /purchases
- 35. Pivotal Tracker © Copyright 2018 Pivotal Software, Inc. All rights reserved. Requirements from Snap-E are managed in Pivotal Tracker Everyone on the team has access to the tool and can at any time see what the team is working on. We break work down into small, granular user stories that have user value. We stack rank the stories so that the highest priority and highest value things are at the top. We release frequently to keep feedback loops short in order to learn if our product is on the right track.
- 36. Commit Code Change Automate Build, Test, Deploy Store Binaries & Build Artifacts Deploy, UAT, Stage App Zero Downtime Upgrade to Production SampleTool Chain Gitlab ArtifactoryConcourse Pivotal HA Services (API Driven) Build pipeline that automates smoke, acceptance, unit and integration tests as feasible SDLC space promotion driven by automated process Patching and upgrades fulfilled on a rolling basis with zero downtime </> Clean up SCC, dependency and config mgmt, tweak code and address other 12-factor concerns as needed Automate the Release Pipeline
- 37. Various Patterns for Microservices API Gateway, Edge Server, B4FFInverse Conway Event Shunting ACL, Context Mapping, Strangler Bridge, Router, Proxy, Facade Eventual Consistency, Sagas, ESB >> microservices Tool Case by icons producer is licensed under CC 3.0
- 38. Cookbooks Reusable patterns are documented as cookbooks to be reused by other developers Learn techniques for identifying problem areas, decomposing monolithic apps, and organizing code for continuous delivery. Introduce technologies that help you build more maintainable, adaptable systems. Get access to playbooks and blueprints used by dozens of enterprises to build a long-lasting practice around app transformation.
- 39. Working Code Slices Patterns OKRs Event Storming Boris SnapE Implementation rinse&repeat Direction / Stay on Track Business Flow / Potential Slices Event Flow/ Inform Architecture Size / Risk Repeatable Recipes
- 40. Part 4 Liberty Mutual Case © Copyright 2017 Pivotal Software, Inc. All rights Reserved.
- 41. Liberty Mutual’s Experiences with... • Conway’s Law • Entropy • Breaking Down Monoliths for real • MSA w/DDD to API-First
- 42. Conway’s law holds true Source: https://martinfowler.com/articles/microservices.html#CharacteristicsOfAMicroserviceArchitecture “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.” - Conway’s Law Source: http://melconway.com/Home/Conways_Law.html
- 43. Entropy always tends to increase within monoliths Source: http://facstaff.gpc.edu/~mkim/C1211&1212Lec/C1212_Lecture.htm
- 44. Logical Separation Physical Separation
- 45. Decoupled UI
- 47. Before After * * one aggregate Deconstructing monolithic databases
- 48. API-First
- 49. Thank you.