DEVNET-1142Decomposing Monolithic Applications to Microservices

Decomposing Monoliths to Microservices

Jim Bugwadia, Nirmata

DEVNET-1142

About me

• Founder and CEO at Nirmata

• Developer (C++, Java, JS, Go)

• Large-scale distributed systems

• Microservices

• Why?

• Definition

• Pros & Cons

• Monolith Microservices

• Before you start

• 8 tips to decompose a Monolith

• Summary

Agenda

Businesses are adopting Microservices for agility at scale

20% of enterprises will adopt Microservices by 2016” -- Gartner

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:

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

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

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

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

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

3. Data Model

• Look for groupings in data model

• Consider data sizing and access, in addition to relations

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

5. Users and roles

• Identify different sets of users

• Internal vs. External

• Microservices as business functions

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

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

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

Summary

• Microservices enable agility at scale

• Microservices require operations tooling and distributed programming skills

• 8 ways to evolve a Monolith to Microservices1. New features

2. Conway’s Law

3. Application Data Model

4. Application Modules

5. Users and roles

6. Resiliency

7. Scalability

8. Stability

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

Thank you