Lately when I talk to architects and administrators about the Appistry fabric, I often hear the same question: "Is your fabric the same thing as a grid or cloud?"
The confusion is understandable. We software types can’t construct a good naming convention without someone else trying to overload them. In this post I am going to provide my best definitions of the phrases cloud, grid, and fabric. Each are valuable tools, but with different meanings and usage patterns.
Cloud computing
Cloud computing is the newest term on the block. We often hear of clouds available at Google, Amazon, or IBM, but what is it?
A cloud is simply a collection of computational and storage resources which can be dynamically allocated and made available for use on demand.
That’s it. There’s not much more to it.
Given the interest in virtualization efforts, it shouldn’t be surprising that organizations are assembling large numbers of machines to be dynamically allocated. The cloud isn’t the software that is your application, but it could be your system’s computational foundation.
The most visible cloud out there is Amazon’s EC2. With an EC2 account, you can rent machine time to your needs. This makes EC2 very interesting to organizations looking to reduce hardware and operations cost.
However, clouds have their drawbacks. As the cloud resources are dynamic, your system configuration will need to be able to handle changing situations. For example, in some cloud implementations the IP address you have today may not be the same as the IP address you get tomorrow. Additional effort is needed to tie your overall system together and make sure that it stays together.
Grid computing
Grids have been around since the late 90’s. The first time I encountered the term was in reference to the Globus toolkit.
A grid is collection of confederated machines providing directory services, security, auditing, and remote execution.
In its early stages the purpose of the grid was to share access to large computers. Universities might have a large system that sat idle some of the time but overtaxed at other times. By joining the grid, a university could trade access to their machine when it was idle for access to another institution’s machine when they needed more than one.
One well known grid system is the SETI@home project. Most of us have seen machines running the SETI@home screen saver as the desktop computer searched radio telescope data for extraterrestrial intelligence. Each of the desktop machines became a participant in the SETI@home grid.
In time, the concept of grid evolved past cross-institution boundaries and into the data center. An organization might put together many machines into their own grid. The grid infrastructure creates a directory of machines and available resources. These systems provide an application developer with a tool to partition out segments of processing. These jobs can get allocated, scheduled, and submitted to the grid for processing.
A challenge of traditional grid computing originates from its roots of tying together independent machines. Elaborate work must be done to create islands of responsibility within the grid. Some grid machines are responsible for creating the central registry of machines and resources while others are machines doing processing work. Grid administrators have the responsibility of making the appropriate connection and keeping the individual grid components running. A traditional grid can be a difficult tool to install and maintain.
Fabrics
When we at Appistry started referencing our product as a fabric, one goal was to abstract away the complexity of building traditional grid systems.
Fabrics are a grid-based software infrastructure enabling virtualization of application services with reliable execution and simplified operation across any number of computational resources.
One characteristic of fabric systems is that they will appear as a single computational resource independent to the number of machines that actually participate in the fabric. We wanted to refer to the application and its distributed infrastructure as a single entity you can depend upon. All of the plumbing to tie together the fabric is "under the covers" and made simple for developers and administrators.
Fabrics are enhancements over traditional grids with their simplicity and reliability. The fabric administrator doesn’t have to partition and manage separate traditional grid-level software services such as directory services and computational nodes. The user doesn’t have to discover or schedule work to individual machines. When hardware failures occur, the fabric handles the error mechanisms so that the user is unaware that a failure even occurred. Fabrics are well suited for either SOA style request/response applications as well as large scale HPC applications, where as traditional grid systems are often best suited for HPC style applications.
Fabrics can have cost/performance advantages as well. Fabrics are typically built from commodity hardware as failures are handled automatically by the fabric. These attributes reduce hardware and operational costs. We have customers using 100+ worker fabrics managed by less than one person.
Putting It All together
So the question becomes, can we put these systems together? The answer is a resounding yes. Once you understand the strengths and weakness of each approach, you can see how clouds, grids, and fabrics can work together.
For example, we at Appistry are seeing more and more organizations try to take advantage of cloud computing concepts. These groups are "renting" clouds from groups like Amazon or building their own clouds to dynamically allocate within their organizations. Cloud administrators rapidly find that their cloud solutions are not sufficient. They need a fabric infrastructure to facilitate the scale, reliability, and management needs of the overall system.
In Conclusion
I hesitated to put this post together. Surely, as soon as I hit "post" another use of the terms cloud, grid, and fabric will be thrown into the community. However, when trying to build distributed systems, it is good to understand what each of these solutions brings to the developers and administrators.
Comments on this entry are closed.