Cloud computing — the provision of IT services through a massively shared, elastic platform — holds much promise. However, like many of the silver bullets that have come and gone in the past (client/server, CORBA, web services, service-oriented architectures), everything only hangs together if everyone plays the game and doesn’t try to be too clever.
This is why standards are important — if cloud platforms cannot be integrated, then cloud becomes JAPP (just another proprietary platform), no different to the long-running debates around mainframe v. UNIX v. Windows v. whatever else a vendor wants to go on about.
The wonderful thing about cloud computing is that there are good standards out there. The really bad thing about cloud computing is that there are lots of standards out there.
Take any area of cloud computing — the server, storage and network layers; security; software implementation; workload management; inter-application messaging — and you will find an industry body that is coming up with a standard (or three) around it. Ask how they are working together, and a perplexed look comes over their faces. Why would they have to look at what anyone else is doing? Surely, the way that sold state drives (SSDs) work in the cloud is the very heart of the matter? Why should the body that is looking at the heuristic mapping of read/writes to SSDs worry about workload management and data security?
The answer is, of course, that everything in the cloud is connected and that such an approach to standards is like blindfolding 10 builders, placing them 10 feet apart and asking them to build you a single, solid wall. Things won’t match up; the wall will be incomplete and anyone who wants to ruin things will easily be able to bring everything down.
Ah, but surely that is where the higher-levels groups come in, as guardians of all things IT-related? The Institute of Electrical and Electronics Engineers (IEEE) is, overall, the one group that could say ‘yea’ or ‘nay’ to any proposed standards, and is in charge of putting out lots of requests for comments (RFCs) and defining top-level standards. However, the World Wide Web Consortium (W3C) tends to come up with its own standards as well, and although these do tend to match up with IEEE standards, it is sometimes the case that not everything matches up quite as well as hoped for.
Other bodies, comprising a list of acronyms too long to define here, such as OASIS, SNIA, CSA, ODCA and the OGF (via the OCCI), are all bringing other standards to the mix. Even with the IEEE sitting over the top of everything, reacting in a coherent manner to all these bodies is like wading through mud — everything slows down and ceases to react fast enough for the markets.
So, then we get to the vendors. In the dash for open standards, they are signing up left, right and center to be seen as supporting the standards. However, reverting to type, many are then adding bits to the standards either to support legacy functions in their own systems or to reflect what they see as the needs of their customers.
So comes about the “120% standard” — the vendor nominally supports the actual standard, but its additions make the modified standard more functional in its own homogeneous environment.
However, the base levels of how standards interoperate are getting better. My advice is to stick wherever possible with the unmodified standards, unless there is a pressing need to adopt any variations. Be aware that the standards are still a movable feast, and there will be changes as the cloud matures. However, a lot of the work in cloud standards is still down to the user plugging them together. The cloud is still a turbulent place — if you plan on waiting for the “ultimate” standard, you could be left behind.