the leading api for financial services search, acquisition ... · microservices application ......
TRANSCRIPT
+
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 [email protected] // twitter.com/khyland // linkedin.com/in/kevin-hyland-799466182