Preparing for Growth—
Capacity Planning and Scaling
Dean Bryen
Principal Cloud Advocate

Resources
Session Resources Hub
aka.ms/OPS50
Session Code on GitHub
aka.ms/OPS50repo
All Event Session Resources
aka.ms/mymsignitethetour

Here’s our map
The Dickerson
Hierarchy of Reliability

OPS50
OPS40
OPS30
OPS20
OPS10Monitoring
Incident response
Post-incident review
Testing/release
Capacity/scale
DEV
UX
Welcome to the
OPS learning path

OPS50Capacity/scale
Our session today

New product line launching soon!
The revolutionary electric Hammer!

THE ELECTRIC HAMMER!

iOS and Android
client applications
Rewards app
Azure Kubernetes Service
Stock
Profile
Products
My coupons
Cart
Popular
products
Website
Mobile for
frontend
Backend for
frontend
Single points of failure

iOS and Android
client applications
Rewards app
Azure Kubernetes Service
Stock
Profile
Products
My coupons
Cart
Popular
products
Website
Mobile for
frontend
Backend for
frontend
Pre-provisioned capacity

iOS and Android
client applications
Rewards app
Azure Kubernetes Service
Stock
Profile
Products
My coupons
Cart
Popular
products
Website
Mobile for
frontend
Backend for
frontend
Unknown costs

iOS and Android
client applications
Rewards app
Azure Kubernetes Service
Stock
Profile
Products
My coupons
Cart
Popular
products
Website
Mobile for
frontend
Backend for
frontend
Tailwind Traders architecture

When may we need to scale?
Sometimes we
can plan for scale
Sometimes we’re
hit by surprise
Hopefully, the system
just takes care of it

A quick primer

Some pre-requisites
Scaling up Scaling out
Manually scaling Auto-scaling
DIY scale Inherent scale
https://aka.ms/OPS50architecture

Scalability ❤️ Reliability
Most of the time….

Planning for
scale and growth

Do I need to do capacity
planning in the cloud?

iOS and Android
client applications
Rewards app
Azure Kubernetes Service
Stock
Profile
Products
My coupons
Cart
Popular
products
Mobile for
frontend
Backend for
frontend
Website

Understanding how Azure
CosmosDB measures capacity

Request units (RU/s)

Retrieving capacity metrics

Azure Cosmos DB capacity planning—organic growth
2530
5100
7435
10081
0
2000
4000
6000
8000
10000
12000
July August September October
Users
Example Tailwind Traders usage
Users

Azure Cosmos DB capacity planning—organic growth
151 198 254 300
5000 5000 5000 5000
0
1000
2000
3000
4000
5000
6000
July August September October
Storage Capacity
Example Tailwind Traders usage
Storage

Azure Cosmos DB capacity planning—organic growth
0
100
200
300
1000 1000 1000 1000
0
200
400
600
800
1000
1200
July August September October
RU/s Usage Provisioned RU/s
Example Tailwind Traders usage
Throughput

Azure Cosmos DB capacity planning—organic growth
0
100
200
300
400
500
600
700
800
900
1000
1100
1000 1000 1000 1000 1000 1000 1000 1000 1000 1000
1000
1000
0
200
400
600
800
1000
1200
RU/s Usage Provisioned RU/s
Example Tailwind Traders usage
Throughput

But what about
in-organic growth?
It’s a cross team effort

In-organic planning
Example known event!
What we know
What we can expect

Azure Cosmos DB capacity planning—organic growth
151 198 254 300 400
5000 5000 5000 5000 5000
0
1000
2000
3000
4000
5000
6000
July August September October November
Storage Capacity
After marketing event
Storage
Example Tailwind Traders usage

Azure Cosmos DB capacity planning—organic growth
0
100
200
300
500
1000 1000 1000 1000 1000
0
200
400
600
800
1000
1200
July August September October November
RU/s usage Provisioned RU/s
Example Tailwind Traders usage
Throughput
After marketing event
Sufficient capacity

In-organic planning—cost
75
59.52
134.52
100
59.52
159.52
0
20
40
60
80
100
120
140
160
180
Storage Throughput Total
Before Event (USD) After Event (USD)
Example Tailwind Traders usage

The cloud
has limits too
The cloud offers a whole new
level of scale. However, there are
some limits to know about.
aka.ms/OPS50limits

Service limits and quotas: portal

List usages—API
124
1000

Keep an eye
on the cost
Adding more servers
makes you more scalable
But it can cost more, too

Cost management

Scaling Tailwind Traders

Perform
regular
architecture
reviews
Keeping on top of things
once deployed, will ensure
you’re always ready for scale
aka.ms/OPS50architecture

Scaling vs.
finding the bugs
Do we always need to scale?
Or is there a bug?

You work closely with developers
to make your systems more scalable

Tailwind Traders architecture
iOS and Android
client applications
Rewards app
Azure Kubernetes Service
Stock
Profile
My coupons
Cart
Popular
products
Website
Mobile for
frontend
Backend for
frontend
Products

Scaling our products service
Azure Region
Availability Zone B

Scaling our products service: scale sets
Azure Region
Availability Zone AAvailability Zone B

Why use scale sets?
Autoscaling
Leverage Availability Zones
Automatically create and integrate with load balancers

Some considerations
Avoid instance stickiness
Remove persistent data
Design for scale-in

Scaling our products service: decoupling
Azure Region
Availability Zone AAvailability Zone B

Scaling with queues

Scaling our products service: caching
Azure Region
Availability Zone AAvailability Zone B
Redis cache

Scaling our products service: database
Redis cache
Azure Region
Availability Zone AAvailability Zone B
Read replica

Read replica
#Master Connection String
ApplicationIntent=ReadWrite
#Read Replica Connection String
ApplicationIntent=ReadOnly
#Full Example
ApplicationInte
nt=ReadOnly

Azure Region
Scaling our products service: DB sharding
Availability Zone AAvailability Zone B
A B C A B C
Read replica

Why we may need to shard
Too much data Too much throughput Physical isolation

What’s next?
Going global?
Do we need to go global?
Can we leverage a CDN?
Would independent
systems be more suitable?
What consistency do
we need for the data?

Tailwind Traders architecture
iOS and Android
client applications
Rewards app
Azure Kubernetes Service
Stock
Profile
Products
My coupons
Cart
Popular
products
Website
Mobile for
frontend
Backend for
frontend

Summary:
planning
for growth
Are you aware of your service limits
Can you plan for scale
using capacity planning?
Can you predict your future cloud spend?

Summary:
scale
Could you leverage an inherently
scalable cloud service instead?
Should we fix the bug?
Or scale our resources?
Are you able to scale horizontally?
Can you decouple your
system using queues?
Will caching help?

Summary:
reliability
Are you leveraging availability
zones for reliability?
Do you really need to go global?

/Docs alert
aka.ms/OPS50architecture

/MS Learn alert
aka.ms/OPS50MSLearnCollection
Complete interactive learning
exercises, watch videos,
and practice and apply
your new skills

/Microsoft Certification alert
Microsoft Certified:
Azure Solutions Architect Expert
Get hired, stay ahead, and receive
the recognition you deserve
#MSIgniteTheTour
aka.ms/SolutionsArchitectCert

Free Certification Exam
on Fundamentals or Role-based Certifications
Find a Learning Partner to help you prepare
aka.ms/LearningPartner
Begin with free online training
Microsoft.com/Learn
Learn more about Microsoft Certifications
Microsoft.com/Certifications
Now is your chance
to stand out among your peers.
Get certified and prove your expertise to
employers and peers and get the recognition
and opportunities you've earned.
Exclusive offer for Microsoft Ignite The Tour attendees
aka.ms/FreeExam_MSIgnite
Limited to one per eligible attendee. Terms and
conditions apply. Please see website for details.

Resources
Session Code on GitHub
Session Resources
aka.ms/mymsignitethetour
All Event Resources
aka.ms/OPS50repo
aka.ms/OPS50
#MSIgniteTheTour
Get Certified
Azure Solutions Architect Expert
aka.ms/SolutionsArchitectCert