Thread: Cloud Computing & Architechture Advantages

Tweet

Introduction

Cloud computing is a relatively new way of referring to the use of shared computing resources,
and it is an alternative to having local servers handle applications. Cloud computing groups
together large numbers of compute servers and other resources and typically offers their
combined capacity on an on-demand, pay-per-cycle basis. The end users of a cloud computing
network usually have no idea where the servers are physically located—they just spin up their
application and start working.
Cloud computing is fully enabled by virtualization technology (hypervisors) and virtual
appliances. A virtual appliance is an application that is bundled with all the components that it
needs to run, along with a streamlined operating system. In a cloud computing environment, a
virtual appliance can be instantly provisioned and decommissioned as needed, without complex
configuration of the operating environment.
This flexibility is the key advantage to cloud computing, and what distinguishes it from other
forms of grid or utility computing and software as a service (SaaS). The ability to launch new
instances of an application with minimal labor and expense allows application providers to:
• Scale up and down rapidly
• Recover from a failure
• Bring up development or test instances
• Roll out new versions to the customer base
• Efficiently load test an application


Architectural Considerations
Designing an application to run as a virtual appliance in a cloud computing environment is very
different than designing it for an on-premise or SaaS deployment. We discuss the following
considerations. To be successful in the cloud, your application must be designed to scale easily,
tolerate failures and include management tools.
Scale
Cloud computing offers the potential for nearly unlimited scalability, as long as the application
is designed to scale from the outset. The best way to ensure this is to follow some basic application
design guidelines:
Start simple: Avoid complex design and performance enhancements or optimizations in favor
of simplicity. It’s a good idea to start with the simplest application and rely on the scalability
of the cloud to provide enough servers to ensure good application performance. Once you’ve
gotten some traction and demand has grown, then you can focus on improving the efficiency
of your application, which allows you to serve more users with the same number of servers
or to reduce the number of servers while maintaining performance. Some common design
techniques to improve performance include caching, server affinity, multi-threading and tight
sharing of data, but they all make it more difficult to distribute your application across many
servers. This is the reason you don’t want to introduce them at the outset and only consider
them when you need to and can ensure that you are not breaking horizontal scalability.
Split application functions and couple loosely: Use separate systems for different pieces of application
functionality and avoid synchronous connections between them. Again, as demand
grows, you can scale each one independently instead of having to scale the entire application
when you hit a bottleneck. The separation and reusability of functions inherent in SOA make it
an ideal architecture for the cloud.

Network communication: Design the application to use network-based interfaces and not interprocess
communication or file-based communication paradigms. This allows you to effectively
scale in the cloud because each piece of the application can be separated into distinct
systems.
Consider the cluster: Rather than scale a single system up to serve all users, consider splitting
your system into multiple smaller clusters, each serving a fraction of the application load. This
is often called “sharding” and many web services can be split up along one dimension, often
users or account. Requests can then be directed to the appropriate cluster based on some
request attribute or users can be redirected to a specific cluster at login. To deploy a clustered
system, determine the right collection of servers that yield efficient application performance,
taking any needed functional redundancy into account; for example, 2 web, 4 application and
2 database servers. You can then scale the application by replicating the ideal cluster size and
splitting the system load across the servers in the clusters.
You’ll soon realize the advantages of cloud computing when it comes to scalability, such as:
• Inexpensive testing - testing can be done against a test cluster without risking the performance
or integrity of the production system. You can also test the upper limits of the ideal
cluster’s performance by using “robot users” in the cloud to generate load.
• Reduced risk - bring up a test instance of the cluster to prove a new code base, and roll out a
new version one cluster at a time. Fall back to an older version if the new version doesn’t work,
without disrupting current users.
• Ability to segment the customer base – use clusters to separate customers with varying demands,
such as a large customer who wants a private instance of the application, or one who
requires extensive customizations.
• Auto-scaling based on application load – with the ready availability of resources, applications
can be built to recognize when they are reaching the limits of their current configuration and
automatically bring up new resources.
Fail
Inevitably, an application will fail, no matter what its environment. When you design an onpremise
or SaaS application, you typically consider several “doomsday” scenarios. The same
must be true for designing an application that runs in the cloud.
Build-in resiliency and fault tolerance: To tolerate failure, applications must operate as a part of
a group, while not being too tightly coupled to their peers. Each piece of the application should
be able to continue to execute despite the loss of other functions. Asynchronous interfaces are
an ideal mechanism to help application components tolerate failures or momentary unavailability
of other components.
Distribute the impact of failure: With a distributed cloud application, a failure in any one application
cluster affects only a portion of the application and not the whole application. By
spreading the load across multiple clusters in the cloud, you can isolate the individual clusters
against failure in another cluster.

Get back up quickly: Automate the launching of new application clusters in order to recover
quickly. Application components must be able to come up in an automated fashion, configure
themselves and join the application cluster. Cloud computing provides the ideal environment
for this fast startup and recovery process.
Data considerations: When an application fails, data persistence and system state cannot be
taken for granted. To ensure data preservation, put all data on persistent storage and make
sure it is replicated and distributed. If system state is stored and then used in the recovery
process, treat it like data so the system can be restarted from the point of failure.
Test your “doomsday” scenario: Cloud computing makes it easy to bring up an instance of your
application to test various failure scenarios. Because of the flexible nature of cloud computing,
it is possible to simulate many different failure scenarios at a very reasonable cost. Single
instances of a system can be taken off-line to see how the rest of the application will respond.
Likewise, multiple recovery scenarios can be planned and executed ahead of any real production
failure.
Be aware of the real cost of failure: Of course the ideal situation is avoiding any application
failure, but what is the cost to provide that assurance? A large internet company once said
that they could tolerate failure as long as the impact was small enough as to not be noticeable
to the overall customer base. This assertion came from an analysis of what it would cost
to ensure seven nines of application uptime versus the impact of a failure on a portion of the
customer base.
Manage
Deploying cloud applications as virtual appliances makes management significantly easier. The
appliances should bring with them all of the software they need for their entire lifecycle in the
cloud. More important, they should be built in a systematic way, akin to an assembly line production
effort as opposed to a hand crafted approach. The reason for this systematic approach
is the consistency of creating and re-creating images. We have shown how effectively scaling
and failure recovery can be handled by rapid provisioning of new systems, but these benefits
cannot be achieved if the images to be provisioned are not consistent and repeatable.
When building appliances, it is obvious that they should contain the operating system and any
middleware components they need. Less obvious are the software packages that allow them
to automatically configure themselves, monitor and report their state back to a management
system, and update themselves in an automated fashion. Automating the appliance configuration
and updates means that as the application grows in the cloud, the management overhead
does not grow in proportion. In this way appliances can live inside the cloud for any length of
time with minimal management overhead.