Understanding Cloud Characteristics - Deploying and Managing a Cloud Infrastructure - page 3

have peak service capacity of 500 users. During the holiday season, there's an influx of 1,000
users, which is double the capacity of what the current deployment can handle. If Amazon
were smart, it would have set up 5 additional (or maybe 10) servers within its data center in
anticipation of the holiday season spike. This would mean physically provisioning 5 or 10
machines, setting them up, and connecting with the current deployment of 5 servers. Once
the season is over and the traffic is back to normal, Amazon doesn't really need those addi-
tional 5 to 10 servers it brought in before the season. So either they stay within the data cen-
ter sitting idle and incurring additional cost or they can be rented to someone else.
What we just described is what a typical deployment looked like pre-cloud. There
was unnecessary physical interaction and manual provisioning of physical resources.
This is inefficient and something that cannot be linearly scaled up. Imagine doing this
with millions of users and hundreds or even thousands of servers. Needless to say, it
would be a mess.
This manual provisioning is not only inefficient, it's also financially infeasible for startups
because it requires investing significant capital in setting up or co-locating to a data center
and dedicated personnel who can manually handle the provisioning.
This is what the cloud has replaced. It has enabled small, medium, and large teams and
enterprises to provision and then decommission compute, network, and memory resources,
all of which are physical, in an automated way, which means that you can now scale up
your resources just in time to serve the traffic spike and then wind down the additional pro-
visioned resources, effectively just paying for the time that your application served the spike
with increased resources.
This automated resource allocation and deallocation is what makes a cloud elastic.
On-Demand Self-service/JIT
On-demand self-service can be thought of as the end point of an elastic cloud, or the appli-
cation programming interface (API) in strict programming terminology. In other words,
elasticity is the intrinsic characteristic that manifests itself to the end user or a cloud tenant
as on-demand self-service, or just in time (JIT) .
Every cloud vendor offers a self-service portal where cloud tenants can easily provision
new servers, configure existing servers, and deallocate extra resources. This process can be
done manually by the user, or it can also be automated, depending upon the business case.
Let's look again at our Amazon.com example to understand how JIT fits in that scenario
and why it's one of the primary characteristics of a cloud. When the devops (development
and operations) personnel or team figures out that demand would surge during the holiday
season, they can simply provision 10 more servers during that time, either through a pre-
cooked shell script or by using the cloud provider's web portal. Once the extra allocated
resources have been consumed and are no longer needed, they can be deallocated through
another custom shell script or through the portal. Every organization and team will have its
own way of doing this.