You could ask 100 people what cloud computing is and I’m pretty sure you would get 100 different answers. You have to admit that it’s a loaded question. Ask 100 people what TV is and unless you have a couple of aborigines sprinkled into your focus group, you would likely get 100 very similar answers. Point is that cloud computing by definition is still up for grabs. The 800 pound gorillas can’t even agree but regardless of all the bickering surrounding the definition and semantics, the march continues.

My definition of cloud computing is quite simple… It’s groups of servers working in tandem to provide a redundant, scalable and elastic platform which you can use to offer services via a web browser. There are plenty of people who would disagree with my definition but I don’t care because I’m one of those 100 people that I mentioned earlier. Now let me break it down in a bit more detail.

We’ll start with “groups of servers working together in tandem”…
When I say groups I don’t mean two, but rather cabinets full of servers. Lets say for example we have (1) cabinet with (36) dual proc, quad core Dell PowerEdge servers with 32Gb of ram each. Let’s also say that we have a SAN w/16 TB of disk space. Since the current cloud hosting standard (and I use the term standard loosely) is based on how many instances you can squeeze out of a single server, let’s assume that number is (16), although it could be considerably higher or lower depending on client requirements. I’ve arrived at that number by taking the (2) processors that I have on a single server, multiplying that by the (4) cores per processor and then multiplying that times (2) which gives me (16). BTW I’m using very rough numbers and I’m leaving lots of things out because this is intended to give you an example of how it works. So, we are left with (16) instances that can run on a single server. Based on that math if we multiply (16) instances by the (36) servers that we have in the cabinet and you have the capacity to provide (576) instances. Since all clients are different and some require greater resources than others, you can rest assured that you will not have (576) identical instances running on this cloud. It’s more likely that you will have (100) clients using the equivalent of (2) instances. Maybe (50) clients using the equivalent of (4) instances. Probably even some single clients using all of the resources of a single server and then of course at the bottom of the revenue-generating totem pole you have the clients who only want the least expensive option and they will get the tiniest slivers available. Anyway you’d never want to sell all (576) instances on the server because then you would leave no room for clients to burst for additional CPU or memory requirements. I’m not going into the software and operating system side of this but let’s make the assumption that your server instances can be either Linux or Windows based. Now that we have the technical details out of the way, let’s move on to the basic concepts of server instances and how they’re created, moved around, backeded up and restored.

On to the “redundant” part of my definition that I mentioned earlier…
The coolest thing for me about cloud computing is that everything is virtualized. The hardest thing for most people to get past when they try to grapple with the concept of cloud computing is the fact that your server instance doesn’t physically exist, yet it looks feels and acts exactly like a physical server. When you reboot it you can access the BIOS just like a physical server. You can slam off the power to it just like a physical server. It can get hacked into oblivion just like a physical server. It can be backed up and restored just like a physical server (but that process can be way better in the cloud).

Another great thing about this is the ease and speed of deployment. If you need (50) servers in (5) minutes, you can have them. If you want to configure (1) server perfectly and launch another similarly configured server, you can convert your server into a template and then spin up another instance based on that template. Another option is to use local storage. When I say local storage I am referring to the physical hard drives that typically live within the physical server that your particular instance happens to live on. The reason it’s best to not do that is that you lose redundancy across the cloud. If you have an attached storage device and all of your server instances live on that device, physical servers simply connect to that storage device, grab the instances that they need and spin those puppies up. What this means for the average user is that if your instances are running on a particular server and that server happens to fail, your data is still intact because it lives elsewhere. And if the cloud is configured properly, available servers that have adequate amounts of free resources will be notified automatically that a physical server failed and it will redirect other physical servers to lend a hand and spin up any instances that need a new home. This is the auto healing feature of cloud computing has so many people sitting at the edge of their seat. Also if you have all of your data stored in one location it’s much easier to back that up and again if the cloud was built properly, you would have redundant storage devices or at least a storage device with lots of redundancy built into the chassis.

Now that we’ve learned how instances spin up and how they can be moved around, now let’s talk for a moment about how they are backed up and restored…
Unlike traditional backup systems that connect to your server, analyze the data that has to be moved and then they download the data either on a file by file basis or a block by block basis, cloud computing typically uses what is referred to as snapshots. Snapshots are essentially the equivalent of a photograph of your instance and its state at the moment that snapshot was taken. Snapshots are instantaneous, easy to archive and are fully functioning replicas of your server instances. The key thing to remember about that is the “fully functioning” part. What that means is that they don’t have to be restored, they just have to be booted up. There are people out there who would say “yeah that might be true but they have to be moved from the storage array back to the.. wait a minute, you said everything lives on the storage server, never mind”. In a nutshell this essentially eliminates the need for time-consuming and often problematic server restores from backup devices. If your cloud is configured properly, you should be able to set snapshots to occur on a recurring monthly, weekly, daily and even hourly basis if needed. You can then select the number of instances that you want to retain and you just created a vast library of backups that you can access if needed. Another great thing about snapshots is that they are (1) ginormous file which makes them easy to move around and securely upload to an off-site location or even to your corporate headquarters for extra safe keeping. Of course, they should be encrypted because they could contain sensitive data.

Now let’s talk about the “scalable” & “elastic” part of my definition…
Scalability is quite easy with cloud computing because it’s typically something that you can do on-the-fly and from a web-based control panel. Unlike expanding the disk space on a dedicated server which requires taking the server down, transferring the data, swapping the drive, etc. Cloud Computing allows you to resize the drive from within the control panel in real-time. Depending on how the cloud is configured it might require a reboot but I would take that any day to double my disk space. Same thing with memory (RAM) because that is something that can be adjusted at the user level through a control panel and you can typically expand up to the available resources on the particular server node where your instances happen to live. But let’s take it a step further and make an assumption that for some reason you feel you need 24GB of RAM for your environment. It’s very unlikely that the physical server your instances would be living on would have 24 GB of available memory for you to utilize. However with a few clicks of a mouse on the control panel your instances could be transferred to a server node that has no other clients on it and just happens to have 32 GB of RAM. So yes it is very possible for a single server instance to have 24 or more GB of RAM. The only limitation that I’m aware of is the amount of physical RAM installed on the server node that your instance happens to live on in that particular moment. But again since all of your data lives on a separate storage device, it’s easy enough for the controllers to instruct a server node that has 32 gigs of RAM to spin up your instances thus providing you with this ridiculous amount of memory that you might need. CPU scaling works the same way so there’s no need for me to go into the gory details again. Bandwidth is a non-issue because most respectable providers have an over abundance of available bandwidth to provide to you.

I could literally go on all day about cloud computing because I am completely fascinated by the possibilities. Clients love it for the ease-of-use and power that it gives them over their environments. Providers love it because of the economies of scale and centralized management. As the clouds of the world mature, I believe that power users will begin to let their guard down and start dropping dedicated servers in droves to hop on the cloud. As long as you don’t take a significant performance hit by moving your application to cloud, the benefits of being on a properly configured cloud are astronomically lopsided when compared to a typical dedicated server environment.

Cloud computing has evolved past bleeding edge and some would say even passed cutting edge but like any emerging technology, there will be pain aplenty. You can mitigate your exposure by easing into it and testing the waters rather than taking your website that earns $1 million per month and yanking it from your perfectly stable dedicated servers and tossing it on the cloud. Rather I would recommend that you incrementally migrate your environment or better yet, build out a virtual development environment that mimics your current production environment. Since cloud instances can be purchased by the hour or by the month, the cost to do this is relatively low. Point is you can build a full-blown development environment that would cost you thousands and take potentially weeks to deploy, probably within a couple of hours while you sip on a latte in your home office. You could stress test this environment until you develop a level of confidence that would allow you to migrate into the cloud without sacrificing your peace of mind.

Thanks for reading this and I really do hope it was helpful.