Microservices Architectures 30.09.2019
Total Page:16
File Type:pdf, Size:1020Kb
pictures: sxc.hu Philippe Collet, with a set of slides assembled by Sébastien Mosser Microservices Architectures 30.09.2019 pictures: sxc.hu @MELANIECEBULA / SEPT 2017 / FUTURESTACK From Monolith to Microservices: How to Scale Your Architecture Developing applications A pattern language for with a microservice microservices architecture Chris Richardson Founder of Eventuate.io Chris Richardson Founder of the original CloudFoundry.com Author of POJOs in Action Author of POJOs in Action @crichardson Founder of the original CloudFoundry.com [email protected] http://microservices.io @crichardson http://eventuate.io [email protected] http://plainoldobjects.com http://plainoldobjects.com @crichardson @crichardson MetaMagic USA Global MetaMagic NJ, Inc., Co ARAF HAMID KARSH - Founder Founder CTO / @arafkarsh arafkarsh ARAF KARSH HAMID Microservices Co-Founder / CTO MetaMagic Global Inc., NJ, USA Architecture @arafkarsh World Agile Testing & Automation arafkarsh Novotel Techpark, Bangalore, June 22, 2018 https://1point21gws.com/testingsummit/bangalore/ � 3 �(�) = ����3�2� 3D �=1 Driven Design Driven Domain Micro Services Architecture Part 1 : Infrastructure Comparison & Design Styles (DDD, Event Sourcing / CQRS, Functional Reactive Programming) Araf Karsh Hamid – Co Founder / CTO, MetaMagic Global Inc., NJ, USA A Micro Service will have its own Code Pipeline for build and deployment functionalities and it’s scope will be defined by the Bounded Context focusing on the Business Capabilities and the interoperability between Micro Services will be achieved using message based communication. The AirBnB Case Study “Monorail” OUR MONOLITHIC RUBY ON RAILS APPLICATION 1 GitHub repo 1 SRE Sysops 4000000 3000000 When it starts to become a problem 2000000 MONORAIL LOC 1000000 0 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 Democratic deploys All developers are expected to “own” their features from implementation to production. Each developer is expected to: • deploy their changes • monitor their changes • roll back, abort, or revert if necessary Scaling Deploy Process • builds, tests, and deploys must be fast and reliable • ping authors when they need to take action • automatic (and fast) reverts • merge queue • automatic rollbacks for new exceptions Why Not Microservices? Why Microservices? • Distributed systems • Independent are hard! deployment • Naming things is • Modular structure / hard! Ownership • Having to support • Secure / Performant different languages / • Upgrading frameworks dependencies Why Microservices? SCALING CONTINUOUS DELIVERY Why Microservices? Deploys per week (all apps, all environments) Why Microservices? 75,000 production deploys per year Services 900 300 4k developers services deploys per week Splitting the Monolith UI Layer API Layer Monorail P1 P2 P3 P4 Vertical concerns Horizontal concerns Splitting the Monolith UI Layer API Layer Vertical concerns Horizontal concerns 1. Monolith first 2. Devops culture 3. Configuration as code 4. Monitoring and Alerting The important part 5. Continuous delivery 10 TAKEAWAYS 6. Automate what you can 7. Your first service is going to be bad 8. Services own their own data 9. Break apart the Monolith 10. Standardize service creation Elements of Domain-driven design 2 Understanding Requirement Analysis using DDD Bounded Context Areas of the domain treated independently Discovered as you assess requirements and build language 15 April 2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 19 2 DDD : Understanding Bounded Context 20 • DDD deals with large models By dividing them into different Bounded Contexts and being explicit about their interrelationships. • Bounded Contexts have both unrelated concepts • Such as a support ticket only existing in a customer support context • But also share concepts such as products and customers. • Different contexts may have completely different models of common concepts with mechanisms to map between these polysemic Source: BoundedContext By Martin Fowler : concepts for integration. http://martinfowler.com/Bliki/BoundedContext.html 15 April 2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 2 DDD: Bounded Context – Strategic Design Semi Cooked An App User’s Journey can run across Recipes Frozen multiple Bounded Context / Micro Chef Steward Raw Services. uses Materials Tables Dinning User Journey X Order Appetizer Veg Main Course Reservation uses Veg Menu Appetizer Non Bounded Bounded Bounded Veg Context Context Context Main Course Soft Drinks Hot Drinks Desserts Non Veg Dinning Semi Cooked Kitchen Recipes Frozen Context Areas of the domain treated Context Chef independently Steward Raw uses Materials Tables Dinning Order Appetizer Veg Main Course Discovered as you assess Reservation uses Veg requirements and build language Menu Appetizer Non Veg Main Course Soft Drinks Hot Drinks Desserts Non Veg Source: Domain-Driven Design App (DDD) of a Restaurant Bounded Context Understanding 8/10/2018 Reference by Eric Evans Menu Context 13 2 DDD: Ubiquitous Language: Strategic Design Ubiquitous Vocabulary shared by Used in all forms of spoken / Language all involved parties written communication Restaurant Context – Food Item : Role-Feature-Reason Matrix Analyst Developers Eg. Food Item (Navrathnakurma) As an Restaurant Owner Domain I want to know who my Customers are can have different meaning or Expert properties depends on the So that I can serve them better context. BDD Construct • In the Menu Context it’s a Ubiquitous QA Veg Dish. Language Given Customer John Doe exists • In the Kitchen Context it’s is recipe. When Customer orders food • And in the Dining Context it will have more info Assign customer preferences Design Test Cases Then related to user feed back Docs as Veg or Non Veg customer etc. Code BDD – Behavior Driven Development 10 August 2018 14 2 125 Understanding Aggregate Root Domain Driven • An aggregate will have one of its component Design objects be the aggregate root. Any references Aggregate Root Customer from outside the aggregate should only go to the aggregate root. The root can thus ensure the integrity of the aggregate as a whole. Order * Line Item Line Item • Aggregates are the basic element of transfer of Line Item data storage - you request to load or save whole aggregates. Transactions should not cross Shipping aggregate boundaries. Address Payment • Aggregates are sometimes confused with Strategy collection classes (lists, maps, etc.). Bank Transfer • Aggregates are domain concepts (order, clinic visit, playlist), while collections are generic. An aggregate will often contain multiple collections, Cash together with simple fields. Credit Card Source: Martin Fowler : Aggregate Root (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 17 2 Designing and Fine Tuning Aggregate Root Aggregate Root - #1 Aggregate Root - #2 10 August August 2018 10 Super Dense Single Aggregate Root Super Dense Aggregate Root is split into 4 Results in Transaction concurrency issues. different smaller Aggregate Root in the 2nd Iteration. Working on different design models helps the developers to come up with best possible design. Source : Effective Aggregate Design Part 1/2/3 : Vaughn Vernon http://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_1.pdf (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 18 2 Anemic Domain Model : Anti Pattern 25 • There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have. • The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters. • The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented design; which is to combine data and process together. • The anemic domain model is really just a procedural style design, exactly the kind of thing that object bigots like me (and Eric) have been fighting since our • lockUser() early days in Smalltalk. • unlockUser() • addAddress(String address) • removeAddress(String address) Source: Anemic Domain Model By Martin Fowler : http://martinfowler.com/bliki/AnemicDomainModel.html 2 Event Sourcing & CQRS (Command and Query Responsibility Segregation) • In traditional data management systems, both commands (updates to the data) and queries (requests for data) are executed against the same set of entities in a single data repository. • CQRS is a pattern that segregates the operations that read data (Queries) from the operations that update data (Commands) by using separate interfaces. • CQRS should only be used on specific portions of a system in Bounded Context (in DDD). (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA JERSEY, NEW INC., GLOBALMETAMAGIC COPYRIGHT(C) • CQRS should be used along with Event Sourcing. Java Axon Framework Resource : http://www.axonframework.org Axon CQS : Greg MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx | Framework Bertrand Meyer Young Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html For Java 6/24/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 29 2 Source: https://docs.microsoFt.com/en-us/azure/architecture/patterns/cqrs CRUD and CQRS https://blogs.msdn.microsoFt.com/maarten_mullender/2004/07/23/crud-only-when-you-can-aFFord-it-revisite Traditional CRUD Architecture CRUD Disadvantages Presentation • A mismatch between the read and write representations of the data. Services • It risks