surviving as a monolith in a microservices world - by blair olynyk, hyperwallet

SURVIVING AS A MONOLITH IN A MICROSERVICES WORLD

• WORKED IN…• Government• Telecommunications• Financial Technology• Consulting

• CURRENT…• Software Architect w/ Hyperwallet

• ROLE…• Steward of the code base• Champion the needs of technology to

the business• And, vice-versa

Background:

WHO AM I?Blair Olynyk

EMAIL: [email protected]

• COMPANY• Financial Technology• Dominates Payments Distribution

• SECTORS• Digital Marketplaces (think Amazon)• Sharing Economy (think Lyft)

• SPECIALIZE• High volume payments, distributed

globally• Payments to

• Bank Accounts• Prepaid/Credit Cards• Etc…

Background:

WHO IS HYPERWALLET?A Payment Distribution Platform

CONTENTS1. WHEN TO ADOPT MICROSERVICES?

• A checklist on when to adopt microservices

• How to make an argument to the business for adoption

2. HOW TO SUCCEED WITHOUT MICROSERVICES?

CONTENTS1. WHEN TO ADOPT MICROSERVICES?

2. HOW TO SUCCEED WITHOUT MICROSERVICES?

• How Hyperwallet is succeeding without microservices

• While moving in the direction of microservices adoption

“WHEN TO ADOPT MICROSERVICES?”

40%Percentage of people that saw an improvement in their development of software after moving to microservices

via ZeroTurnaround

Microservices are HARD

compared to monoliths

MICROSERVICES ARE HARDWhen compared to monoliths

public interface User {

//Call this method //to create a User. void create(...);

...}

• Create a new User in a single JVM instance• It’s dead simple in single thread

• Instantiate the User object• Call the create method• Non-functional overhead of monolith

application• Unit and integration tests• In process scaling through

messaging (if needed)• Automated load testing

Simple use case… Monolith…

When compared to monolithsMICROSERVICES ARE HARD

USER CONTEXT

USER SERVICE

RESTAdapter

DBAdapter

AMQPAdapter

INPUT OUTPUT

Simple use case… Microservice…• Look at communication overhead, hold all other

microservice concerns static• REST and External Messaging

• Endpoint code• Adapter code• Anti-corruption layer

• DB instance per service• Adapter code

• Have to build in resiliency, backpressure or throttling due to the realities of functioning over a network

• Dev-Ops, networks, certificates, etc…


USER CONTEXT

USER SERVICE

RESTAdapter

DBAdapter

AMQPAdapter

INPUT OUTPUT

Simple use case… Microservices• The point is that with all other things being equal, a single

microservices implementation is more complicated, and thus more costly then implementing the same functionality as a monolith


Microservice application• And you have to repeat this work for

every microservice instance in your application• xN instances• (cost / N – i) x N for all N

• I’ll say it again, microservices cost more then monolith applications to produce and maintain

1. RESILIENCY TO FAILURE• Bulkheading, isolating failure to

one service

2. SCALABILITY• Horizontal, x-axis, a.k.a. adding

more cores

3. DEPLOYMENT INDEPENDENCE• Low risk single instance

deployments

4. TECHNOLOGY INDEPENDENCE• Each service chooses it’s

technology stack

WHY ADOPT MICROSERVICES?The benefits are numerous…

5. COMPOSABILITY / REUSABILITY• The realization of SOA

6. REPLACABILITY• Isolated and micro, means

designed for replacability

7. ORGANIZATIONAL ALIGNMENT• Conway’s law, services align with

structures of the organization

1. S.O.L.I.D. PRINCIPLES• Object oriented design and

programming

2. DOMAIN DRIVEN DESIGN• Object oriented done right

3. DEPENDENCY MANAGEMENT• Architecture of application seams

YOU SHOULD NOT ADOPT MICROSERIVCES…If you cannot maintain good software design and architecture principles

• Non-uniform scalability

• Throughput requirements are

characterized by peaks and

valleys

• Deployment independence

• Near daily changes to your

functionality to meet client

requirements

• Technology independence

• Re-inventing the wheel

YOU SHOULD ADOPT MICROSERVICES…If your non functional business requirements warrant it

NON-UNIFORM SCALABILITY REQUIREMENTMaking a business case for microservices

Simplified Payments Application Example

• Focus on the non-functional payments throughput requirements

• Business SLA 50,000 max payments per minute

• Daily cost of the microservice application is $1,000 per service (or $3,000 total)

• Daily cost per instance of monolithic application is $3,000

NON-UNIFORM SCALABILITY REQUIREMENTMaking a business case for microservices

6000

4000

2000

1st 15th 30th

5 Payment Micro or App Instances

1 Payment Micro or App Instance

Request/Minute by Calendar Date

Simplified Payments Application Example

Cost to meet requirements:Microservice: $1,239,000Monolith: $1,527,000

You’ve now started your non-functional business case for microservice

Good software design at the class, package and module levels

Cost of microservices overhead < Revenue or cost savings of adopting microservices

But…

YOU SHOULD ADOPT MICROSERIVCES…If your non functional business requirements warrant it

You do NOT need microservices

Assumptions:

1. You have a monolithic application

2. You have a layered architecture

3. You’ve lost control of your

dependency management

ARCHITECTUREIf you are considering microservices

1. WHO IS RESPONSIBLE FOR HOW CODE IN THE APPLICATION IS SEPERATED?• Or, lack thereof

2. ARCHITECURES RESPONSIBILITY• Ends at the Layered / Services

3. DEVELOPERS RESPONSIBILITY• Package / Class

HOW DID IT COME TO THIS?Architecture vs. Code

• The result of this battle is an application with dependency cycles, tangled code, and no encapsulation.

• Kirk Knoernschild:• “Software architects ivory

tower…”• Martin Fowler:

• “Architectus Reloadus…”

• And what you have now is…

You’ve now got a big ball of mud!

“HOW TO SUCCEED WITHOUT MICROSERVICES?”

34%Increase in productivity after Hyperwallet re-imagined how it implements and delivers software

Just like microservices, we touched

on both implementation and runtime

concerns:

• Organizational structure

• Application architecture

• Deployment Concerns

HOW TO SUCCEED WITHOUT MICROSERVICESOur solution

Organizational StructureIf you aren’t oriented towards your goal, then you’ve failed before you’ve even started

“Organizations which design systems ... are constrained to

produce designs which are copies of the communication structures of

these organizations”

- Melvin Conway, 1968

Fine for microservices…

Organizational StructureIf you aren’t oriented towards your goal, then you’ve failed before you’ve even started

Not fine for monoliths…

“The department responsible for developing software systems will have a communication structure that aligns with its architecture.”

- James Chang, 2015

So let’s look at an example…

ORGANIZATIONAL STRUCTUREIf you aren’t oriented towards your goal, then you’ve failed before you’ve even started


• Your software application or system is going to contain functionality that pertains to the requirements of these departments

• According to Melvin Conway you should then have systems that reflect this departmental structure


• Problem is your software is characterized as a monolith


• Chang’s Law constantly overrides Conway’s Law

• This presents a problem when trying to garner the benefits of microservices• Lack of product

responsibility• Poor communication

along lines of business and software development

• Nil passion for the product

Align your development teams around the domains of your organization

Domain Driven DesignORGANIZATIONAL STRUCTURE

Upstream

Downstream

U

D

USER CONTEXT

TAX CONTEXTBANK-ACCOUNT

CONTEXT

COMPLIANCE CONTEXT

PAYMENT CONTEXT

CONTEXT MAP• Strategic design

• Design your domain

• Maintain it’s integrity

• Context map (artifact)

• Alignment of application

with organization at the data

level

ORGANIZATIONAL STRUCTUREFrom Chang’s Law to Conway's Law

Recall assumptions:• Chang’s law, software

departments will align with their architecture

• Monolithic application• Layered architecture

Our goal:• Transform the department

from one that aligns with Chang’s Law to one that aligns with Conway’s Law

From Chang’s Law to Conway's LawORGANIZATIONAL STRUCTURE

UI Team

Service Team

Data Team

CURRENT DEVELOPMENT TEAM STRUCTURE


USER CONTEXT

TAX CONTEXTBANK-ACCOUNT

CONTEXT

COMPLIANCE CONTEXT

PAYMENT CONTEXT

UI Team

Service Team

Data Team

+

CURRENT DEVELOPMENT TEAM STRUCTURE

CONTEXT MAP


=

User Team

Bank Account Team

Compliance Team

Tax Team

Payment Team

NEW TEAM STRUCTURE


User Team

Bank Account Team

Compliance Team

Tax Team

Payment Team

+Business Analyst Team

Quality Assurance

New Team Other SDLC Team Members


=

User Team

Bank Account Team

Compliance Team

Tax Team

Payment Team

NEW DEVELOPMENT TEAM STRUCTURE


User Team

Bank Account Team

Compliance Team

Tax Team

Payment Team

NEW TEAM STRUCTUREBENEFITS• Greater degree of autonomy than in larger

teams• Deliver changes to production more quickly• Product is consistently “owned” and thus

maintained

“The problem is not in the UI layer it’s in the services layer” is replaced by a natural competition to produce the highest quality product.• This is what really matters to the business.• Every one likes cool technology, but the best

product succeeds in the real world.

APPLICATION ARCHITECTUREDependencies are not aligned with organization

1. Development team aligned with organization

2. Code aligned with organization


• Microservices benefits that can be gained from strong cohesion and loose coupling• Organizational

Alignment• Composability of

Services• Increased Resiliency• Improved Deployability• Ease of Replacability


Two paths forward:1. If your code is in

relatively good shape, then refactor it

2. Otherwise, call it a big ball of mud and apply the Strangler Pattern

REVIEW1. Ensure that you can make a solid business case for

adopting microservices as they will cost more to develop and maintain

2. Do not attempt this if you do not have stringent architecture rules around modularity

3. Always align your development teams as well as your software modules with your organizations communication structure (Conway’s Law)


THANK YOU
