Cloud Computing on Ulitzer

These three things have a lot more in common than you might think and all three tend to evoke similar levels of frustration.

A very real problem women face when shopping is this: no two brands define a size the same. If you usually wear a size 8 in “Brand X” you might actually wear a size 10 or 6 in “Brand Y”, depending on how the brand decided to define its sizing. Customers, women in this case, cannot count on consistency in sizes across brands. This makes shopping annoying because every time you change brands you’re never quite sure what you need and if the size increases across brands, well, it becomes obvious that perhaps brand lock-in is in part the reasoning behind these differences in sizing.

Now, consider the differences in the definition of “The Cloud”. We have IaaS (Infrastructure as a Service). We have PaaS (Platform as a Service). We have SaaS (Software as a Service). All three have very different definitions of what makes it “a cloud” and there is very little consistency across those definitions. Oh, there are vague similarities: elasticity, automation, easy provisioning. But those are nebulous terms that are about as useful as slapping a “Size 8” on a pair of jeans and expecting a woman to know what that means. She doesn’t, and neither does the consumer of “cloud.”

Dig into “cloud computing” and “intercloud” and standards efforts and you’ll see this is true at the infrastructure layer, as well. The challenge of defining standards around intercloud computing and cloudbalancing and just collaboration within a single cloud computing environment is made infinitely more challenging because infrastructure Vendor X “size 8” doesn’t match up with Vendor Y “size 8.” Features, naming, resource models, capabilities – all different. Yet all must be able to communicate and collaborate to not only provide the basic foundation for a cloud computing environment, but to be able to migrate from one provider to another.

API versus RESOURCE MODEL

This is what’s going to make defining standards more challenging than ever: we’ve got to not only standardize protocols but common industry and market definitions as well. The former will likely turn out to be much easier than the latter because it’s more abstract; it’s about management and control without regard to implementation. It is the resource model that will be difficult to nail down.

William Vambenepe writes in Separating model from protocol in Cloud APIs:

Things become a lot more sensitive when you touch the resource model, which reflects the actual capabilities of the Cloud management infrastructure. How much flexibility in the network setup? What kind of application provisioning? What affinity/anti-affinity control level? Can I get block-level storage? Etc. Having to implement the other guy’s interface in these matters is not just a matter of glue code, it’s a major product feature. As a result, the resource model is a much more strategic control point than the protocol.

William nails the problem with his assessment of the differences between the resource model and protocols. Given his obviously intimate knowledge of web services standards and thus SOA, this is no surprise. One of the core tenets of SOA is the separation of these two very different but very vital components. The interface should be separate from the implementation. In InterCloud, we must separate resource model (data protocol implementation) from interface (command and control protocol) in order to achieve standardization.

Interestingly enough at the last Infrastructure 2.0 Working Group, which is focusing on this problem, Vint Cerf mentioned out of hand that the separation of IP from routing “in the beginning” was actually accidental. If you read the IP RFC you’ll note that it ends up being just a “resource model”; it describes the format of information being exchanged and mentions how packets should flow across internetworks, but it defines no API-style protocol for doing so. It offers only minimal guidance on the higher level interfaces that might be used to transmit and receive Internet Datagrams. That accidental omission turned out to be the best thing since sliced bread. Routing protocols have come and gone since then, but IP remains at the heart of the Internet. Basically we need to duplicate that, but at a higher layer in the stack.

Any InterCloud protocol will almost certainly be easier to develop than the resource model. While there already exists some commonality across components and concepts in the infrastructure, still there are many more resources for which every vendor has their own definition. It is that disparity that needs to be addressed independently and codified in a common set of resource models that at the same time allows for extensibility on a per vendor basis to account for uncommon resources.

This is no easy task. Consider a very simple example – persistence in load balancing solutions. Persistence is a commonly implemented feature in all load balancers that can be achieved in a number of ways. Among the most common are: source IP, destination IP, Cookie, and SSL session ID. Now take a look at the difference in definition of these - from a purely naming standpoint – between Citrix Netscaler and F5 BIG-IP:

Looking at both implementations – and remember this is just naming – you’ll notice that the most common methods of persistence exist in both solutions, but use very different naming conventions. Netscaler defines source IP-based persistence as “SOURCEIP” while F5 uses “PERSISTENCE_MODE_SOURCE_ADDRESS_AFFINITY”; same concept, different terminology. Once you get beyond the common methods you find even more disparity and it becomes more difficult to map between the two without a firm foundation of knowledge of both systems. For example, is the Citrix “CALLID” the same as the “PERSISTENCE_MODE_SIP” definition? Perhaps they are, perhaps they aren’t. You can imagine that at the operation level, the API, the naming conventions used there are so drastically difference that attempting to map the two would drive even the most experienced integration developer a bit insane.

STANDARDS TAKE TIME

Just as cloud computing providers continue to roll out new services over time, behaving in a manner similar to Web 2.0 applications that never quite come out of beta, so, too, will the standards of InterCloud need to evolve. It’s going to take a lot of comparisons, discussions, and mappings to figure out what is an acceptable common resource model for each infrastructure component and in the process we’re going to have to abstract quite a bit. Less challenging will be the need for a common namespace for this resource model across all infrastructure components. After all, an IP address is the same whether it’s used by a virtual machine, an IPS, a load balancer, or a firewall. But these are easier to discover and define than elements unique to a particular solution space and once we get the ball rolling one can hope that the momentum keeps it rolling.

The Internet wasn’t built in a day – really, it took the ‘founding fathers’ quite a bit of discussion and hard work to get the standards defined that allowed mass interoperability and collaboration. But I am willing to bet that we’ll see InterCloud standards long before the fashion industry decides to standardize its sizing for women.

Long before then, I’m sure.