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

© 2019 - CONFIDENTIAL

3

01 Introduction

© 2019 - CONFIDENTIAL

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

© 2019 - CONFIDENTIAL

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

© 2019 - CONFIDENTIAL

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

© 2019 - CONFIDENTIAL

7

Monolith

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

● Good for early stage because it requires

minimal architectural investment

© 2019 - CONFIDENTIAL

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

© 2019 - CONFIDENTIAL

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

© 2019 - CONFIDENTIAL

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

© 2019 - CONFIDENTIAL

11

02 Premature Microservices

© 2019 - CONFIDENTIAL

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

© 2019 - CONFIDENTIAL

13

Microservice Challenge: Adding Functionality

MONOLITH MICROSERVICE

Make a PR Make a New Service

© 2019 - CONFIDENTIAL

14

Microservice Challenge: Calling Code

MONOLITH MICROSERVICE

Call a Method Make a Network Call

© 2019 - CONFIDENTIAL

15

Microservice Challenge: Joining Data

MONOLITH MICROSERVICE

Join Query Join in the Application or Eventual

Consistency

© 2019 - CONFIDENTIAL

16

Microservice Challenge: Sharing Code

MONOLITH MICROSERVICE

Add a Namespace Make a Library

© 2019 - CONFIDENTIAL

17

Microservice Challenge: Local Development

MONOLITH MICROSERVICE

Start One Service Start a Lot of Services

© 2019 - CONFIDENTIAL

18

Microservice Challenge: Unit Testing

MONOLITH MICROSERVICE

Connect to DB Mock Service Calls

© 2019 - CONFIDENTIAL

19

Microservice Challenge: Breaking Changes

MONOLITH MICROSERVICE

Change a Method Carefully Roll Out an Endpoint

© 2019 - CONFIDENTIAL

20

Microservice Challenge: Debugging

MONOLITH MICROSERVICE

Check Metrics in One Service Trace Requests Across Services

© 2019 - CONFIDENTIAL

21

Microservice Challenge: Analytics

MONOLITH MICROSERVICE

Use a Replica Build an ETL Pipeline

© 2019 - CONFIDENTIAL

22

03 Aging Monolith

© 2019 - CONFIDENTIAL

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

© 2019 - CONFIDENTIAL

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

© 2019 - CONFIDENTIAL

25

Monolith Challenge: Modularity

MONOLITH MICROSERVICE

Entangled Decoupled

© 2019 - CONFIDENTIAL

26

Monolith Challenge: Languages

MONOLITH MICROSERVICE

Monolingual Polyglot

© 2019 - CONFIDENTIAL

27

Monolith Challenge: Team Coordination

MONOLITH MICROSERVICE

Mutex Message Passing

© 2019 - CONFIDENTIAL

28

Monolith Challenge: Test Suites

MONOLITH MICROSERVICE

All Encompassing Targeted

© 2019 - CONFIDENTIAL

29

Monolith Challenge: Resources

MONOLITH MICROSERVICE

One Size Fits All Bespoke

© 2019 - CONFIDENTIAL

30

Monolith Challenge: Framework Upgrades

MONOLITH MICROSERVICE

Big Release Small Releases

© 2019 - CONFIDENTIAL

31

Monolith Challenge: DB Upgrades

MONOLITH MICROSERVICE

Big Chunk of Downtime Flexible Downtime

© 2019 - CONFIDENTIAL

32

04 Macroservice Approach

© 2019 - CONFIDENTIAL

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

© 2019 - CONFIDENTIAL

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

© 2019 - CONFIDENTIAL

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

© 2019 - CONFIDENTIAL

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

© 2019 - CONFIDENTIAL

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

© 2019 - CONFIDENTIAL

38

Architecture Choice: Networking

AT FIRST LATER

Manual Service Mesh

© 2019 - CONFIDENTIAL

39

Architecture Choice: Request Format

AT FIRST LATER

JSON over REST Alternatives

© 2019 - CONFIDENTIAL

40

Architecture Choice: Interface Style

AT FIRST LATER

Request / Response Event Queue

© 2019 - CONFIDENTIAL

41

Architecture Choice: ETL

AT FIRST LATER

Polling Streaming

© 2019 - CONFIDENTIAL

42

Architecture Choice: API Specification

AT FIRST LATER

Reference Implementations Agnostic Specs

© 2019 - CONFIDENTIAL

43

Architecture Choice: Service Clients

AT FIRST LATER

Custom Generated

© 2019 - CONFIDENTIAL

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

© 2019 - CONFIDENTIAL

45

Architecture Choice: Service Bootstrapping

AT FIRST LATER

Copy and Paste Templates

© 2019 - CONFIDENTIAL

46

Architecture Choice: Build Process

AT FIRST LATER

Per Service Shared

© 2019 - CONFIDENTIAL

47

Architecture Choice: Infrastructure Provisioning

AT FIRST LATER

Manual Infrastructure as Code

© 2019 - CONFIDENTIAL

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

© 2019 - CONFIDENTIAL

49

Kevin Hyland, CTO kevin@evenfinancial.com // twitter.com/khyland // linkedin.com/in/kevin-hyland-799466182