the leading api for financial services search, acquisition ... · microservices application ......

+

The Leading API for Financial Services Search, Acquisition and Monetization

Macroservices: A Pragmatic Solution Architecture

October 9, 2019

© 2019 - CONFIDENTIAL

2

Agenda

1 - Introduction

2 - Premature Microservices

3 - Aging Monolith

4 - Macroservice Approach

Select Services

Iterate On Architecture

Spin Up Microservices

Break Up Macroservices


3

01 Introduction


4

Even Overview

● Mission: To provide the definitive search, comparison and recommendation engine for financial services

● Founded 2015, lots of growth since: ○ $1B in funded loans ○ raised lots of money ○ nearly 100 employees


5

Even Eng Overview

● Service-oriented and API-first ● Built on AWS ● Scala services with Postgres DBs ● Deployed using Docker on ECS ● Lots of serverless ● Spark and Redshift


6

Early Stage

● Maximize focus on shipping features to: ○ Verify business model ○ Drive growth

● For anything outside of features, ask yourself what

you can: ○ Get for free? ○ Get away with doing naively? ○ Get away with not doing?

● Areas include:

○ Internal business tools ○ Tech tools ○ Dev ops ○ Monitoring ○ ETL and analytics


7

Monolith

● Application implemented by: ○ Single code repository ○ Single application cluster ○ Single DB

● Good for early stage because it requires

minimal architectural investment


8

Growth Stage

● Continued focus on feature development to drive growth

● But now there are more constraints: ○ Increased traffic ○ Reliability expectations ○ Hiring ○ Increasingly complex communication patterns ○ More code ○ More deploys


9

Microservices

● Application implemented by: ○ One or more repositories ○ Many service clusters ○ Many DBs ○ New features are implemented using a new service ○ Services communicate with each other over the

network

● Good for growth stage because small services can: ○ Match communication patterns in the org ○ Scale resources independently ○ Support multiple languages ○ Strictly enforce decoupled modules


10

● Starting with a monolith and transitioning to microservices can be tricky

● But starting with microservices can cause problems also

● At Even, we started with a hybrid approach that we called macroservices: a few, big, loosely coupled services

● The results were: ○ extended how long we can reap the benefits of a

monolith ○ eased the transition to microservices

Macroservices


11

02 Premature Microservices


12

Features vs. Architecture

Microservices

● Early on, too much investment, not

enough return

● Solve problems that you don’t yet have

● Require decisions that you don’t have

enough information to make

● Takes focus away from shipping

features

Monolith

● Minimally viable architecture

● Allows you to focus on features


13

Microservice Challenge: Adding Functionality

MONOLITH MICROSERVICE

Make a PR Make a New Service


14

Microservice Challenge: Calling Code


Call a Method Make a Network Call


15

Microservice Challenge: Joining Data


Join Query Join in the Application or Eventual

Consistency


16

Microservice Challenge: Sharing Code


Add a Namespace Make a Library


17

Microservice Challenge: Local Development


Start One Service Start a Lot of Services


18

Microservice Challenge: Unit Testing


Connect to DB Mock Service Calls


19

Microservice Challenge: Breaking Changes


Change a Method Carefully Roll Out an Endpoint


20

Microservice Challenge: Debugging


Check Metrics in One Service Trace Requests Across Services


21

Microservice Challenge: Analytics


Use a Replica Build an ETL Pipeline


22

03 Aging Monolith


23

Growth Stage

State of the Org

● The business model has gained

traction

● Application traffic is increasing rapidly

● Lots of hiring and changes to the org

chart

● Building more and more features to

support growth

State of the Monolith

● These emerging forces strain the

monoliths ability to scale along with

the org


24

Putting Pressure on the Monolith

Code 2 People

● As you hire, communication

patterns become

exponentially more complex

● Scaling the organization

requires autonomous teams

● More people means more

code, which means more

features and more deploys

● More code in a single VM

introduces the potential for

reduced modularity

Traffic

● Growing traffic exposes

differing resource

requirements across

different modules

sara to add graphic

icon - more serious


25

Monolith Challenge: Modularity


Entangled Decoupled


26

Monolith Challenge: Languages


Monolingual Polyglot


27

Monolith Challenge: Team Coordination


Mutex Message Passing


28

Monolith Challenge: Test Suites


All Encompassing Targeted


29

Monolith Challenge: Resources


One Size Fits All Bespoke


30

Monolith Challenge: Framework Upgrades


Big Release Small Releases


31

Monolith Challenge: DB Upgrades


Big Chunk of Downtime Flexible Downtime


32

04 Macroservice Approach


33

Macroservices

Goals

● Extend how long we can leverage the good properties

of monoliths

● Ease transition to microservices

Approach

● Distribute functionality and data across a limited of

services from the outset

● Choose services that will fit within the emerging

constraints of your growing org

Plan

1. Select services

2. Iterate on architecture

3. Spin up microservices

4. Break up macroservices

SCREENSHOT HERE


34

Step 1: Select Services

What will be the next team structure?

You should have one service per team

What languages will you use?

Services are language specific, of course

What will your high-level modules be?

If a team is responsible for multiple modules with well-

defined interfaces, split out services for each

Will any functionality have unique

resource requirements?

For example, image processing probably shouldn’t live with

internal CRUD endpoints

SCREENSHOT HERE


35

Example: Ecommerce

Supply Team

● Catalog service (Java) - owns product

availability, descriptions and specs

● Image service (C++) - serves and

transform product images

● Order service (Java) - processes user

orders and charges CC

Demand Team

● Merchant service (Java) - lets

merchants add new products and

configure display

● Inventory service (Java) - handles

warehousing and vendor invoicing


36

Example: Social Network

Network Team

● Users service (Go) - owns user profiles

and avatars, medium throughput

● Friends service (Ruby) - owns friend

connections between users, low

throughput

Interactions Team

● Likes service (Go) - handles all likes,

very high throughput

● Comments service (Go) - handles all

comments, medium throughput


37

Step 2: Iterate on Architecture

Make Some Decisions

● You have a service-oriented

architecture, so you’ll need to make

some architectural decisions

● But, since you have so few services,

you don’t have to make good decisions

● Cost of experimentation is low,

meaning your architecture will be

informed by real use cases

Localized Monoliths

In the meantime, the macroservices will

continue to scale with your org


38

Architecture Choice: Networking

AT FIRST LATER

Manual Service Mesh


39

Architecture Choice: Request Format

AT FIRST LATER

JSON over REST Alternatives


40

Architecture Choice: Interface Style

AT FIRST LATER

Request / Response Event Queue


41

Architecture Choice: ETL

AT FIRST LATER

Polling Streaming


42

Architecture Choice: API Specification

AT FIRST LATER

Reference Implementations Agnostic Specs


43

Architecture Choice: Service Clients

AT FIRST LATER

Custom Generated


44

Step 3: Spin Up Microservices

Maturing Architecture

● When you feel confident about your

architecture, try spinning up new

services

● This presents the opportunity to make

a few more architecture decisions


45

Architecture Choice: Service Bootstrapping

AT FIRST LATER

Copy and Paste Templates


46

Architecture Choice: Build Process

AT FIRST LATER

Per Service Shared


47

Architecture Choice: Infrastructure Provisioning

AT FIRST LATER

Manual Infrastructure as Code


48

Step 4: Break Up Macroservices

Or Don’t

If the macroservices continue to scale,

there’s no need to break them up

If You Need To

You’ll be in a much better position to

because you’ll have:

● more architecture

● more people

● more knowledge

And, the macroservices are a fraction of the

size that the monolith would’ve been.

Thank You


49

Kevin Hyland, CTO [email protected] // twitter.com/khyland // linkedin.com/in/kevin-hyland-799466182

mailto:[email protected]

the leading api for financial services search, acquisition ... · microservices application ......

Documents