Image via Wikipedia
I’m running across the concepts of cloud computing more and more as I enter into accounts across the country. The awesome thing about this is that people are actually thinking “outside the box” and realizing that data is going to need to flow outside the confirms of their locality. Obviously, they’re a little timid when it comes to actually putting their data out there but, the concept intrigues them.
So, when it comes to SMB, what does a cloud look like? What information is part of that cloud? Does it make sense to have TWO clouds: one in the public IP space and one behind the firewall or…? How about internal applications? What applications are “cloud friendly” and which ones aren’t? All these questions have distinct bearing on approaching a cloud infrastructure.
To make things easier, I’ve broken cloud computing into 3 distinct parts: hardware, software, policy. The hardware part is made up of storage, hosts, and infrastructure. The software part is made up of the applications to be delivered. The policy part is made up of the “cloud engine” that dictates service, delivery, and management. (Note: these terms can and will be changed based on the development within the concept of cloud computing) Let’s dig in deeper to these components as a means of defining the SMB cloud.
Hardware: The necessary evil of a cloud architecture will always be the hardware required to run the services and applications needed. Hardware then needs to be broken out into several different sub-categories: storage, processing/compute, communication.
- Storage: where data is stored; reads/writes and applications will live here. Can be fibre channel, IP-based (iSCSI, CIFS/NFS, nearline archive), or otherwise. Obvious storage platforms here would be Clariion, Centera, Celerra, Symmetrix, et al.
- Processing / Compute: also commonly referred to as “nodes” or “clusters.” These cloud members are responsible for interacting with the data and applications. They can be “glued” together in any sort of fashion or format. Typically this could be done via Infiniband (SDR or DDR), Myrianet, or another lower latency fabric. Format could be as standalone blade servers or simple stacks of rack mountable servers.
- Communication: a mechanism or topology needs to exist between the Storage component of hardware and the Processing component. Whether it be IP-based (10g, GigE, FCOE, DCE, etc.) or otherwise, there still must be an interfacing layer of communication. Additionally, communication needs to existing between the processing nodes and the greater cloud in general (typically over IP).
Software: The second level of a cloud architecture will be the cloud software. Software itself has two distinct parts: applications and operating systems.
- Applications: These are the programs that are being served by the cloud to its “customers” (whether internal employees or external). VMWare‘s Lifecycle Manager, for example, is an application that sits within the cloud and allows end users to provision, check-in/check-out VMs, etc. Another “cloud” application can be seen as CVS or SVN style systems where distinct packages or applications are used in a test/dev environment. Current cloud applications out there are seen as part of web-based email (Gmail, Hotmail, Yahoo, Windows Live, et. al), web-based applications (visible in such shells as Facebook, et al).
- Operating Systems: underpinning the application set has to be a hardware-interfacing software layer called the operating system. Typically, you’ll see something like Linux (Red Hat, Suse), BSD (FreeBSD, etc.) or Unix (take your pick) as the underlying OS. Not to slight Microsoft at all but their architecture doesn’t promote clustering on the same scale as Linux in general. What has changed in the recent past is the emergence of OS virtualization products such as VMWare that can now be the primary OS in a cloud infrastructure (see above in the application section about their Lifecycle Manager).
Policy: the third level of a cloud architecture is the policy layer which manages both the Software and Hardware layers. It is responsible for managing the interactions between software and hardware as well as managing incoming requests from the cloud “customers.” An example of this “policy” component could be EMC’s Maui which, at heart, is a policy-driven engine for storage and Web 2.0 applications.
This is about all I’ve got the time for today. For the next post, I’ll try to dive into some of the other questions that have been listed in this post above.