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.

How to Overcome Data Challenges When Refactoring Monoliths to Microservices

1,188 views

Published on

When taking existing monoliths and decomposing their components into new microservices, the most critical concerns have much less to do with the application code and more to do with handling data.

In this webinar, Kenny Bastani from Pivotal and Jason Mimick from MongoDB will focus on various methods of strangling a monolith’s ownership of domain data by transitioning the system of record over time. The new system of record, MongoDB, will fuel rapidly built and deployed microservices which companies can leverage for new revenue streams.

They will use practices from Martin Fowler’s Strangler Application to slowly strangle domain data away from a legacy system into cloud-native MongoDB clusters using microservices built with Spring Boot and Spring Cloud.

Speakers:
Kenny Bastani is a Spring developer advocate at Pivotal. As a passionate blogger and open source contributor, Kenny engages a community of passionate developers on topics ranging from graph databases to microservices. Kenny is a co-author of Cloud Native Java: Designing Resilient Systems with Spring Boot, Spring Cloud, and Cloud Foundry from O’Reilly.

Jason Mimick is the Technical Director for Partners at MongoDB developing new product and technical innovations with a number of companies. He's been at MongoDB nearly 4 years and previously spent the last 20-odd years in various engineering positions at Intersystems, Microsoft, and other companies.

Published in: Technology
  • Be the first to comment

How to Overcome Data Challenges When Refactoring Monoliths to Microservices

  1. 1. © Copyright 2018 Pivotal Software, Inc. All rights Reserved. Version 1.0 How to Overcome Data Challenges When Refactoring Monoliths to Microservices Kenny Bastani, Developer Advocate, Pivotal Twitter: @kennybastani Jason Mimick, Technical Director, MongoDB Twitter: @jmimick
  2. 2. Today’s Speakers Kenny Bastani Spring Developer Advocate Jason Mimick Technical Director, Partners
  3. 3. Pivotal Partner Ecosystem
  4. 4. Agenda Overcoming Data Challenges When Refactoring Monoliths to Microservices ● From Monolith to Microservices ● Migration Strategies ○ Splitting the Monolith ○ Strangling the Monolith ● From RDBMS to NoSQL ● Pivotal Cloud Foundry + MongoDB ● Reference Architecture & Open Source Example ● Q/A
  5. 5. Safe Harbor Statement This presentation contains “forward-looking statements” within the meaning of Section 27A of the Securities Act of 1933, as amended, and Section 21E of the Securities Exchange Act of 1934, as amended. Such forward-looking statements are subject to a number of risks, uncertainties, assumptions and other factors that could cause actual results and the timing of certain events to differ materially from future results expressed or implied by the forward-looking statements. Factors that could cause or contribute to such differences include, but are not limited to, those identified our filings with the Securities and Exchange Commission. You should not rely upon forward-looking statements as predictions of future events. Furthermore, such forward-looking statements speak only as of the date of this presentation. In particular, the development, release, and timing of any features or functionality described for MongoDB products remains at MongoDB’s sole discretion. This information is merely intended to outline our general product direction and it should not be relied on in making a purchasing decision nor is this a commitment, promise or legal obligation to deliver any material, code, or functionality. Except as required by law, we undertake no obligation to update any forward-looking statements to reflect events or circumstances after the date of such statements.
  6. 6. Abandoning the Status Quo From Monolith to Microservices
  7. 7. The Monolith
  8. 8. Make JAR not WAR. – Josh Long Monolith – One Release Cycle to Rule Them All ● Slows down velocity of deploying new features ● Takes too long to ramp up new developers ● The code base becomes too large to fully comprehend ● Centralized change management slows progress (DBA, Ops) ● Deployments batch together changes from different teams ● Ops team manages infrastructure ● Ops team drives execution environment and upgrades ● Deploy everything at once or nothing at all
  9. 9. The SOA Independent Release Cycles
  10. 10. Single Responsibility Principle A class should have only one reason to change. – Uncle Bob Distributed Monolith If your [services] must be deployed as a complete set in a specific order, please put them back in a monolith and save yourself some pain. – Matt Stine SOA – The Curious Case of Shared Ownership ● Services typically share one database ● Services typically share ownership of tables ● Services share libraries containing domain objects ● Boundaries of ownership become blurred over time
  11. 11. Single Responsibility Principle A class should have only one reason to change. – Uncle Bob Distributed Monolith If your [services] must be deployed as a complete set in a specific order, please put them back in a monolith and save yourself some pain. – Matt Stine SOA – Coordinated Releases ● Account service makes a change to customer record ○ Can be deployed independently ● Account service makes a change to address record ○ Must deploy all three services together
  12. 12. Microservices ● Independent Release Cycles ● No table sharing ● No library sharing ● Teams do not share ownership
  13. 13. Conway’s Law Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations. – Melvin Conway Microservices – Share-nothing Architecture ● Small teams focusing on business capabilities ● Share-nothing architecture ● Independent release cycles ● Increases number of pathways to production
  14. 14. Microservices - Encapsulation of Data Data Encapsulation For us service orientation means encapsulating the data with the business logic that operates on the data, with the only access through a published service interface. No direct database access is allowed from outside the service, and there’s no data sharing among the services. – Werner Vogels, CTO, Amazon
  15. 15. Microservices - Encapsulation of Data Logical Separation Horizontal Scalability
  16. 16. Replacing the Airplane’s Engine While In-flight Migration Strategies
  17. 17. Splitting the Monolith Monolith Shared Tables
  18. 18. Splitting the Monolith Monolith New Microservice
  19. 19. The monolith grows over time. It acquires new functionality and lines of code at an alarming rate. Before long it becomes a big, scary giant presence in our organization that people are scared to touch or change. But all is not lost! With the right tools at our disposal, we can slay this beast. – Sam Newman Splitting the Monolith – Fracture & Refactor ● Fracture and refactor modules into encapsulated services ● Impractical for most large enterprises ● Foreign-key relationships are not easy to break ● High risk of breaking data warehouse integrations and ETLs
  20. 20. Strangling the Monolith Gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled. – Martin Fowler The strangler vine seeds itself in the upper branches of a fig tree and works its way down to the roots, slowly starving the tree of resources.
  21. 21. Strangling the Monolith Monolith Create an edge around the legacy system and slowly migrate data away
  22. 22. Strangling the Monolith Monolith API Gateway New Microservices Move new feature development to microservices
  23. 23. “Gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled.” – Martin Fowler Strangling the Monolith – Abstract Away & Deprecate ● Minimizes wasted development cycles ● Focuses on new feature development with microservices ● Integrates with legacy system using an API gateway ● Slowly moves data away from large shared database
  24. 24. Strangling the Monolith API Gateway ● API gateway automatically adapts between old and new formats ● Uses cache pattern to migrate system of record to microservices ● Needs to replicate writes back to large shared database ● Legacy system also routes requests through API gateway ● Router can identify system of record for domain data by primary key
  25. 25. The Struggle of Systems of Record From RDBMS to NoSQL
  26. 26. Scalability & Performance Always On, Global Deployments FlexibilityExpressive Query Language & Secondary Indexes Strong Consistency Enterprise Management & Integrations Non relational (NoSQL) and relational/tabular
  27. 27. Scalability & Performance Always On, Global Deployments FlexibilityExpressive Query Language & Secondary Indexes Strong Consistency Enterprise Management & Integrations Modern database requirements
  28. 28. 28 Freedom to run anywhere Database that runs the same everywhere Coverage in any geography Leverage the benefits of a multi-cloud strategy Avoid lock-in Mainframe Database as a service ServerLaptop Self-managed in the cloud Modern database requirements
  29. 29. Database as a service Self-service, elastic, and automated Secure by defaultGlobal and highly available Continuous backups Real-time monitoring and optimization Cloud agnostic
  30. 30. A Cloud-native Platform for Microservices Pivotal Cloud Foundry + MongoDB
  31. 31. MongoDB as a service on Pivotal Cloud Foundry, build faster and deliver faster with reliability BUILD FASTER DELIVER FASTER, RELIABILY DEV • On demand production ready MongoDB • Integrate and bind easily with app and other services OPS • Provisioning and scaling • Management • Continuous backup and recovery • Monitoring • Automate and simplify: • Security and control
  32. 32. How does the integration work
  33. 33. Value Deliver value from day 1. MongoDB Enterprise on Pivotal Cloud Foundry aligns with existing DevOps (CI/CD) workflows and provides on demand production ready MongoDB and application cluster in minutes, enabling you to rapidly build apps and micro-services De‐risk your deployments. Our solution offers enterprise grade with high availability, blue-green deployments, continuous backups and point-in-time recovery to keep your mission critical deployments always-on Drive operational excellence. MongoDB Ops Manager with BOSH automate and simplify managing, patching, configuring, scaling, tuning, and monitoring MongoDB deployments to reduce IT capital and operational expenses
  34. 34. Supporting modern applications New and coming features: • Change Streams • Change Data Capture/Event Sourcing • Schema Validation • Data governance • Transactions - COMING MONGODB 4.0 • Coordinating multi-system & complex data relationships
  35. 35. Change Streams Enabling developers to build reactive, real-time services ChangeStreamsAPI Business Apps User Data Sensors Clickstream Real-Time Event Notifications Message Queue
  36. 36. Schema Validation Enforces strict schema structure over a complete collection for data governance & quality • Builds on document validation introduced by restricting new content that can be added to a document • Enforces presence, type, and values for document content, including nested array • Simplifies application logic Tunable: enforce document structure, log warnings, or allow complete schema flexibility Queryable: identify all existing documents that do not comply
  37. 37. MongoDB Multi-Document Transactions Just like relational transactions ● Multi-statement, familiar relational syntax ● Easy to add to any application ● Multiple documents in 1 or many collections ACID guarantees ● Snapshot isolation, all or nothing execution ● No performance impact for non-transactional operations Schedule ● MongoDB 4.0, Summer ‘18: replica set ● MongoDB 4.2: extended to sharded clusters
  38. 38. Cloud Native Java + PCF + MongoDB Reference Architecture
  39. 39. $ cf dev start Open Source Example
  40. 40. https://github.com/kbastani/cloud-native-microservice-strangler-example http://www.kennybastani.com/2016/08/strangling-legacy-microservices-spring-cloud.html Open Source Example on GitHub
  41. 41. © Copyright 2018 Pivotal Software, Inc. All rights Reserved. Version 1.0 How to Overcome Data Challenges When Refactoring Monoliths to Microservices Kenny Bastani, Developer Advocate, Pivotal Twitter: @kennybastani Jason Mimick, Technical Director, MongoDB Twitter: @jmimick
  42. 42. The First Law of Microservices – “It Depends” Q/A

×