1. The cloud infra sizing dilemma
● How do i decide how big my servers need to
be?
● How do I calculate the processing power /
memory / disk space required ? Is this even
possible to do ?
● How can I scale my infra up (or down) quickly
and seamlessly ?
● What are the things that I need to worry
about when I design my application?

2. Lets look at AWS as an example
● The basic building block is called an EC2 instance
● Instance sizes vary widely and all instance types are
not available in all AWS regions
● Compute power is measured in EC2 units . One EC2
Unit provides the equivalent CPU capacity of a 1.0-1.2
GHz 2007 Opteron or 2007 Xeon processor. This is
also the equivalent to an early-2006 1.7 GHz Xeon
processor.
● Confused enough ? splendid read on it gets better

3. So how do I size my servers ?
● The short sweet answer ? - Dont bother, you are
never going to get it absolutely right
● The good news ... it doesn't matter what size they are
now. It only matters how "elastic" they are.
● Elasticity is the ability to scale up or down based on
certain parameters (utilisation, load etc)
● So the secret is .. to be able to elastically scale
● Scaling can be achieved two ways:
○ Vertical
○ Horizontal

4. ● Vertical : This is when you add more resources to the same
host. Think if it like adding more memory to your laptop. Of
course this has limits .
● Horizontal: This is when you add more hosts to your infra
to distribute the load. Think of it like adding more workers
to finish the job faster. The workers dont need to be
homogenous. One can be stronger than the other.
● Okay so this horizontal scaling thing sounds fine for CPU
and memory. What about storage ? All my app servers need
to have access to the same data.Cloning each server doesnt
seem like a workable idea for storage. EXCELLENT
QUESTION !!! Read on

5. ● For Storage you can either
○ Setup a centralized file store (such as an NFS or
SMB file share)
○ Use object storage (such as Amazon S3 - the simple
storage service)
● If you use a centralized file store
○ You still need to overprovision you storage for
future expansion (at least to an extent) and will end
up paying for unused storage as well
○ run the normal risks of losing data due to
filesystem corruption, etc etc

6. ● If you use S3
○ You pay for only what you use currently (down to the
MB)
○ You get spectacular reliability. (99.999999999%) To
put that in perspective, if you store 10,000 objects
with Amazon S3, you can on average expect to incur a
loss of a single object once every 10,000,000 years
○ You can scale to practically any size of storage
○ Since S3 is a service, it gives your application an API
to get, put, delete etc the objects stored on S3. The
problem of how the 'cloned' servers access your data
is now solved

7. So how do we do this ?

8. What's happening here ?
● Using custom metrics (cpu load, memory, load
average etc.) , more instances of the server are being
brought into play by the ELB (Elastic Load Balancer)
● The Amazon cloudwatch monitoring service is what is
being used to monitor the metrics and trigger the
scaling
● The fully configured App server has been converted to
an AMI (Amazon machine image) and is being used as
the template on which new instances are being spun
up
● S3 is being used to store files as discussed earlier

9. Application design considerations
● You need to keep the following in mind
● Decouple your components: The more modular the
app, the more scalable it is. Use web services/ api's for
integration and interaction between the modules
● Design the application to be stateless: store session
state in a DB. This ensures that load is distributed
evenly. Otherwise, only new sessions will get pushed
to the newly spun up instances
● The choice of DB plays a very important role. Consider
using DB as service such as Amazon RDS

10. Application design considerations
Your Data storage strategy also needs to be scalable. refer
to the brief description of the S3 service earlier in this
presentation
Other considerations
Instance spin up time: This has to be taken into
consideration when designing your auto scaling strategy
Code updates: you will need to make changes to all
running instances of the server. Also the changes need
to be made in the Machine Image used to spin up new
instances. Develop a sound deployment or devops
strategy

11. About Cloud2scale
Cloud2scale offers cloud architecture, design , setup,
maintenance and monitoring services for the cloud.
Cloud2scale works with a number of startups in the area of
social networking , gaming etc.
Like this presentation ? Join our mailing list to stay updated
Contact Details
web:http://www.cloud2scale.com
email:info@cloud2scale.com