Continuing from part 1…
As I was saying earlier, I wrote a book about the progenitor of clouds (ASPs/SSPs, which appeared in the late 1990s) and after about 600 pages concluded that the idea, whatever its merits, would not survive. The key issues were security (lack thereof), service level predictability (or lack thereof) and sustainability (definitely a lack thereof). Same holds true in the case of contemporary clouds.
Security concerns continue to be among the top reasons why (smart) decision-makers are holding off on public clouds. As my old friend and former NSA operative used to say, “The only way to keep data safe in a network is not to put it there.” Yes, private IT also confronts security risks, but if I were a hacker, I would find a cloud with lots of corporate clients to be a far more target rich environment than an individual company with roll-your-own IT. More reading on this here.
Service level agreements are another source of failure for cloud arrangements. Violate a contracted SLA and the agreement is broken. How can you, Mr. Service Provider, guarantee a better level of service or better uptime or better accessibility or… than I can derive from operating my own plant. At a minimum, the vicissitudes of a Wide Area Network are introduced into the mix of technology that separates data asset from data consumer. Latency and jitter in the WAN, not to mention compatibility issues between the 10 companies that operate different pieces of the link, are bound to impact SLAs adversely. Plus, many cloud providers have introduced that often unstable technology stack called server virtualization into their architecture as an internal cost-reduction measure, which has the impact of binding I/O and creating the stability one finds in a tower of bricks after five minutes or so of active Jenga! play. SLA unpredictability remains a huge problemo.
Finally, sustainability is an issue. With ASPs/SSPs, we saw something happen to the original “share everything” model that doomed the providers. Basically to resolve perceived security and SLA predictability issues, folks decided to demand for their infrastructure to be build and allocated on a one-off basis. So, instead of sharing a common server complex or storage infrastructure, clients were given their very own dedicated kit. Maintaining dedicated kit required dedicated labor. With dedicated labor and kit, the cost of the solution quickly grew to equal or exceed the cost of doing it all yourself. QED. Unsustainable business model.
Clouds aren’t exactly like that, but there are other issues. For those trading in SaaS (that is, Storage as a Service not Software as a Service — note to cloudies, you probably need another acronym), how do you sustain a business model founded on “12 cents a gig” when 40TB 2.5 inch HDDs, leveraging bit pattern media from Toshiba, will enter the market shortly, and soon afterwards, will appear at NewEgg or Tiger Direct or… for $90 (or .00000022 cents per gig, if I am doing my math correctly.) When that happens, you will most certainly lose the mainstay of your clientele, the SMBs, who can now create data driving their business on a single disk and replicate to a second drive, which they store off site for pretty effective continuity. You get the idea.
For those aaS providers who are in this for the long haul, you need to look at how technology advance may well overtake you — especially as fortune favors the providers with access to the interexchange carrier network over those out in the sticks. Those using proprietary hypervisors to stand up workload on x86 tinkertoys need to understand that an IBM mainframe can do a much better and more stable job of hosting multiple workloads at a fraction of the price. Etc. etc.
Frankly, I am not impressed by the sustainability of any cloud business model I have seen. That is not to minimize the future of traditional IT outsourcing, third party hosting services, and the like. There will always be a home for these and they needn’t re-brand themselves as clouds. That branding is already losing its luster.