So you think you can scale

21
SO YOU THINK YOU CAN S C A L E @lmacvittie @F5Networks

Transcript of So you think you can scale

Page 1: So you think you can scale

SO YOU THINK YOU CAN

S C A L E @lmacvittie @F5Networks

Page 2: So you think you can scale

Why do we scale?

Page 3: So you think you can scale

100 Milliseconds Slower

-1% SALES -0.2% SEARCHES -2% CONVERSION

$660M $45M $244M

H/T James Urquhart, SOASTA Data: Gartner, Walmart

Page 4: So you think you can scale

1 Minute of Downtime

Data: Emerson Power

Costs an average of $7300

Average total cost of downtime per year across industries

PRODUCTIVITY IT PRODUCTIVITY LOST REVENUE

$53,608$140,543 $183,724

Page 5: So you think you can scale

=

Page 6: So you think you can scale

UP OUT

How do we scale today?

Page 7: So you think you can scale

POLB(Plain Old Load Balancing)

We throw POLB in front of everything

Page 8: So you think you can scale

But architectures and apps are changing

THENMONOLITHIC MICROSERVICES & APIs

NOW

Page 9: So you think you can scale

And so are “users”

THENHumans

NOWHumans, Systems, Things

Page 10: So you think you can scale

L7 LBLayer 7 Load Balancing

Modern Apps Need Modern Scale

Page 11: So you think you can scale

Scaling Modern Apps

THEN

CHOOSING AN ALGORITHM

NOW

• Round Robin• Least Connections• Fastest Response

CHOOSING AN ARCHITECTURE

• Horizontal• Functional• Partitioning

Page 12: So you think you can scale

Growth and Innovation

Architectural Debt

Software has technical Debt. Networks have architectural debt.

Page 13: So you think you can scale

L7 LBScalability architectures based on Scale Cube

Horizontal Duplication Functional Decomposition

Data Partitioning (Sharding)

X-AXIS Y-AXIS Z-AXIS

Page 14: So you think you can scale

• Like clustering• Leverages cloning (horizontal duplication) • Typically operates at layer 4 (TCP) • This is POLB

X-AXIS

Page 15: So you think you can scale

Y-AXIS

• Like routing / URL dispatch• Uses identifiable variables (usually from HTTP headers) • Operates at layer 7 (HTTP)

/login/

/checkout/

/search/

Page 16: So you think you can scale

Z-AXIS

/car/[A-M]/

/car/[N-U]/

/car/[V-Z]/

• Like sharding • Uses one or more identifiable variables (usually from HTTP headers) • Operates at layer 7 (HTTP)

Page 17: So you think you can scale

API

API

API

API

qAPI Dispatch

qPOLB

API Façade

Page 18: So you think you can scale

L7

qDevice Driven

(Dispatch)L7

L7

L7

API

API

API

API

API

API

API

Purpose Driven(functional decomposition)

q

/status

/update

/status

/update

/billing

/profile

/update

q

Capacity Driven(POLB)

Variations on a Theme

Page 19: So you think you can scale

• Data Partitioning (Sharding) Architectures• URL/HTTP dispatch• Dynamic routing based on backend

data• Scaling by Functional Decomposition • API metering • App versioning / migration • API deprecation

L7 LBArchitecting

Scalability

Page 20: So you think you can scale

Things to Consider Sooner Rather than Later

Is your API design well-suited to scaling in any way other than POLB?

How do you identify people, systems, and things?

How do you distinguish between API versions?

Multi-tenant or single tenant microservices?

The answers to these questions will impact your scaling architectural options*.

Emacs or vi? *Maybe not that last one.

How are you monitoring (and what are you measuring with it)?

Page 21: So you think you can scale

THANK YOU!@lmacvittie @F5Networks

[email protected]