Microservices style architectures provide several benefits, such as enabling shorter delivery cycles, improved elasticity and resiliency. However, most existing applications are not developed using a microservices-style architecture. In this session, we describe how you can incrementally transform a traditional 3-tier monolith application, into a microservices style application. Beyond design and development of microservices, the session will also provide best practices and guidelines on the operations and cultural changes required for a successful transformation 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