Cloud Computing Deployment Models
A while back, I wrote a piece where I touched on cloud computing deployment models very, very briefly and very, very vaguely. I didn’t honestly expect anyone outside designers and the passingly curious to even take much of an interest in it, but I was wrong. Since I published that piece, I have been getting an unbelievable amount of requests to touch on this topic a little deeper, and show some of the other models I didn’t talk about.
Well, I’ve no problem with that, but none of us have time for me to list every one of them, so why don’t I stick to the cloud computing deployment models which are most commonly used? I’ll talk about what kinds of services each one is best suited to support as well.
So the first one, which we are all pretty familiar with, is the data center, or grid computing model. This model has a series of server machines in a connected array at a data center. We use this model all the time – any web host with more than one server is a grid cloud like this.
If the center is reliable, and the cloud computing tasks are just file retention or a single source with mirrors, this model works fairly well, but it has a few problems. The biggest problem it has is, everything remains bunched in one location, where it’s vulnerable and access is uneven depending on geographical location in relation to the center.
Another common one is clustering, where a series of servers nowhere near each other are connected through a higher management and entity thread, and become a location-independent intrinsic supercomputer or redundant host. This is safer on files and will result in finding servers nearest the client to perform tasks. It’s a bit messy logistically though, and tends to be a bit unsecure.
The other model, which I did not touch on before, is the grid cluster concept, which is potentially a way to overcome the obstacles of both and get the benefits of them in stead.
With a grid cluster, data centers form a chain of mirrors locations in a dynamic cluster, but once one is selected, all access and selection is handled within its specific grid, rather than disparate points all over the local map. This makes it more secure, while still making location and redundancy non issues for the most part.
There are a few other structures, such as peer cloud architecture, which uses fellow users’ idle CPU cycles in a cluster formation to make the software self0sufficient by way of supporting hardware. This means there is no guarantee as to how many computers are needed per task, and this is no good for hosting or coop of course.
It really depends primarily on what you need from a cloud computing service, which of these architectures you want to seek out. A gird is perfect for web hosting or super computing, while a cluster is excellent for co-op and realtime, low-latency computing.
If you’re not sure what cloud computing deployment models are most likely suited for you, then at this point it’s best to consult your tech people, who can answer the question now that you’ve been granted a clear way to ask it.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)