DEVNET-1142 Decomposing Monolithic Applications to Microservices
1 like1,245 views
The document discusses the transition from monolithic applications to microservices, emphasizing benefits such as agility, scalability, and fault isolation. It outlines key considerations and eight strategies for decomposing a monolith, including leveraging new features, understanding user roles, and recognizing data models. Additionally, the document highlights the importance of operational tools and distributed programming skills for successful implementation.
DEVNET-1142 Decomposing Monolithic Applications to Microservices
- 2. Decomposing Monoliths to Microservices Jim Bugwadia, Nirmata DEVNET-1142
- 3. About me • Founder and CEO at Nirmata • Developer (C++, Java, JS, Go) • Large-scale distributed systems
- 4. • Microservices • Why? • Definition • Pros & Cons • Monolith Microservices • Before you start • 8 tips to decompose a Monolith • Summary Agenda
- 5. Businesses are adopting Microservices for agility at scale 20% of enterprises will adopt Microservices by 2016” -- Gartner
- 7. 1. Elastic: scales up or down independently of other services 2. Resilient: services provide fault isolation boundaries 3. Composable: uniform APIs for each service 4. Minimal: highly cohesive set of entities 5. Complete: loosely coupled with other services A Microservices style application is composed of several cooperating services, and each Service is:
- 8. Microservices ++ Microservices -- • Agility • Small code sets are easier to learn and manage • Small autonomous teams with end-to- end ownership • Enables continuous delivery • Scalability • Resiliency • Resource usage efficiencies • Can choose, evolve, and experiment with, best technologies for each service • Distributed systems are hard • Increased intra-system communication • Increased operational complexity
- 9. Before you start… • Microservices will not fix existing design issues • Apply SOLID OO principles (or similar) for modular design • Microservices require distributed system expertise • Learn distributed programming Microservices patterns • Microservices require operational tooling • Adopt Infrastructure as a Service • Containerize your monolith • Automate application deployment and lifecycle management • Select the right Microservices operations & management solution
- 10. 8 ways to decompose the monolith 1. New features 2. Conway’s Law 3. Application Data Model 4. Application Modules 5. Users 6. Resiliency 7. Scalability 8. Stability
- 11. 1. New Features • Package new feature “as a Service” • Use a Proxy / Adapter design pattern for existing modules to communicate with the new Service • Shield users from the change Pets Customers Reports Proxy Reports Service API Users
- 12. 2. Conway’s Law Organizations Systems organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations -- Melvin Conway, 1968
- 13. 3. Data Model • Look for groupings in data model • Consider data sizing and access, in addition to relations
- 14. 4. Modules • Modular design High Cohesion and Low Coupling • Entities in a module should be highly cohesive i.e. focused on solving the same problem • Modules should be loosely coupled with each other • A modular design can be converted to a Microservices architecture, where each module is a candidate for a service Pets Users Ratings Reviews Payments Orders
- 15. 5. Users and roles • Identify different sets of users • Internal vs. External • Microservices as business functions
- 16. 6. Resiliency • Can the application still function when a module fails? • Which modules can operate independently? • Which modules can exchange data using stable interfaces? Pets Users Ratings Reviews Payments Orders X See also: Bounded Context in Domain Driven Design Domain-Driven Design: Tackling Complexity in the Heart of Software – Eric Evans
- 17. 7. Scalability • Which module gets utilized the most? • What are the I/O, memory, and CPU patterns for each module? • Separate modules with very different characteristics
- 18. 8. Stability • How often do modules change? • Separate stable modules from fast changing ones • System dependencies should point towards stability 0 2 4 6 8 10 12 14 Jan Feb Mar Apr May Jun Orders Bookings Catalog
- 19. Summary • Microservices enable agility at scale • Microservices require operations tooling and distributed programming skills • 8 ways to evolve a Monolith to Microservices 1. New features 2. Conway’s Law 3. Application Data Model 4. Application Modules 5. Users and roles 6. Resiliency 7. Scalability 8. Stability
- 20. Related Sessions Come try Nirmata with UCS and Intercloud @ DevNet Cloud POD #3 DEVNET-1184 – Microservices Patterns Monday, June 8, 10:30 AM – 11:00 AM, DevNet Theater DEVNET-2013 - DevOps In Depth - Adrian Cockcroft on Fast Delivery Tuesday, Jun 9, 1:45 PM - 2:30 PM, DevNet Theater DEVNET-1170 - Intercloud Microservices with Docker and Nirmata Thursday, Jun 11, 11:00 AM - 11:30 AM, DevNet Theater DEVNET-1137 - Application Centric Microservices Wednesday, Jun 10, 3:00 PM - 4:00 PM. DevNet Theater BRKDEV-1002 - What's Hot in Containers Thursday, Jun 11, 1:00 PM - 2:30 PM, 30B Upper Level
- 21. Thank you