In this series of posts (
see Part 1 of the series), I'm looking at moving applications to the cloud and the scalability concerns around that.
The interesting part is that these problems aren’t unique to cloud computing at all. On one end of the spectrum, the promise of cloud computing and its expansive computing capacities has led customers to believe that simply moving their application to the cloud is going to solve all of these problems. On the other end, clients who have very important applications running on-premise are concerned that when they move their applications to the cloud they’ll have to share all that wonderful computational goodness with hundreds or thousands of other clients and their applications’ performance will suffer.
Regardless of which perspective you may be coming from, there are two things to focus on when looking at moving to the cloud.The first is raw computing capacity. At BlueLock, we’ve chosen to build our cloud computing platform on VMware virtualization technologies. One of the benefits of virtualizing applications on VMware is that multiple workloads (running within virtual machines) can be configured to run on very high-end server hardware and storage architectures – perhaps mutli-socket, multi-core server hardware with 32GB or 64GB of RAM and high-performance SAN(s). Those physical hosts can then be combined into clusters and that computing capacity can be even further aggregated. It’s important to understand how that computing capacity is assigned to your application(s).
Is infrastructure being “over provisioned”? Since it’s possible to abstract the underlying hardware from the workload running within a VM it’s also very easy to do things like allocate more memory or compute power to the VM than is actually available on the underlying physical hardware.
Can computing power be scaled (up and down) if needed? As the business grows, the demand on application performance may grow with it? It should be easy to assign and re-assign things like CPU and RAM resources.
How high can the underlying hardware platform scale? Different IaaS and cloud computing models are based on different technologies – VPS (Virtual Private Servers), dedicated physical hardware and virtualization platforms like VMware all work differently, for example. How much CPU and RAM in total (usually different based on the underlying model being used) can be assigned to the application(s) has an impact on the decisions you make about scaling.
Within the
BlueLock IaaS Cloud, compute clusters are carefully divided into building blocks called “cores” and these cores are assigned to customers – never assigning more “cores” to a computer cluster than are actually available. This goes hand-in-hand with dedicated versus shared computing models – just throwing everyone in the computer pool without regard to expected performance isn’t a good idea. It’s important to ensure that the capacity to application(s) is both dedicated and somewhat dynamic. At BlueLock, once one or more of these “cores” is assigned to a client they are combined together into a resource pool. This pool of CPU and RAM can then be divided among one or more virtual machines, assigning priority to different workloads if necessary and providing the ability (if needed) change how much of the resource pool each VM is allowed to consume. Behind the scenes, cool features of VMware’s virtualization platform like VMware DRS move VMs around from one physical host in the cluster to another without taking VMs offline. This ensures that a particular physical host is never over provisioned and that, if needed, the amount of CPU and RAM assigned to a particular VM is always available to it.
This model of cores and dedicated resource pools, along with the abstraction of physical hardware from the resources assigned to a virtual machine, allows clients to provision (and pay for) only what they need. As their needs change, additional cores can be added to grow resource pools and add to their application’s overall computing capacity.
In the next post, I'll look at the second item to focus on - application architecture.