The story goes like this, a contractor that Microsoft hired didn’t perform a backup before updating the production Sidekick SAN. Microsoft didn’t follow extremely well established operational best practices in their datacenter and now their customer’s customers are now out of contact (pun intended) and the reputation these of three companies has been sullied. This isn’t cause to cloud-hate. This should be cause celebre of proper application and infrastructure architecture! The cloud just forces you to acknowledge these established best practices. A friend at Google tells me, if any part of the code they write fails to compensate for infrastructure failure or issues, then it gets kicked right back to them. Period.

Datacenter Operations Fail

I did a stint in corporate IT and Microsoft’s failure is similar to the time I arrogantly neglected to shut off the computer I was repairing before taking a screwdriver to it. I blew out the entire accounting department’s unsaved afternoon productivity (to my defense, afternoons were never that productive). Was that also a #cloudfail? After all, a large percentage of data in a corporate network is stored on an individual desktops or laptops. Isn’t that like remote server storage? Furthermore, a study from Carnegie Mellon reports that hard disk replacement is typically 2-4% per year with up to 13% per year in some systems, largely dependent upon operating conditions and surprisingly independent from age. The operating conditions that we worked in there were terrible! Dusty and hot, and an accountant’s idea of a good computer fix was to kick the machine under their desk. Shouldn’t CIOs be more concerned about that data loss?

Then what does this epic fail mean for the Sidekick? It means Danger designed a crappy application which had no checks and balances for server synchronization to local devices. It means T-mobile and Danger forced their Sidekick users to subscribe to this model without giving them the ability to back up their data locally. And it means Microsoft ran it on a poorly architected infrastructure and never set up any backups of critical customer data. Danger was running on dedicated hardware, the same type that any IT department would rack out. Consequently they had to do more work to solve the gotchas inherent in their own application design (such as giving users backup options). There is no standardization of data redundancy (like in S3 for instance), and apparently there was no predictable operational process in place either.

If you control your own hardware, it doesn’t matter whether it’s in a colo, a closet, or an IaaS provider; you and only you are responsible for the uptime of your application. Natural and freak disasters will happen (trucks running into your datacenter, earthquakes, fires, extended power outages, exploding power rooms). Cloud computing is an operations model, not a technology. Data loss and server failure is a reality, never unavoidable. So think about the implications of all of this and don’t put all your eggs in one basket (or one disk, or one server, or one datacenter, or one availability zone, or one geographic region, or one anything). Have a contingency plan in place, invest in best practices in cloud/datacenter portability (management tools/operations procedures/standards) and avoid lock in to any one infrastructure location. After all, if your application is your livelihood shouldn’t you take more responsibility for it?

Plan for failure, follow your runbook and know where the exit is!

President Obama has deployed his own Cloud Vanguards, including the first ever Federal Chief Information Officer Vivek Kundra, and his appointed “Cloud Czar” Federal Cloud CTO Patrick Stingley.  They’re armed with billions to spend on building cloud infrastructure and procuring cloud services, spreading the wealth of money and innovation around.  Contracts for government use of cloud computing have already been awarded and large batch processing jobs are being doled to public clouds and platforms.  Government websites like usa.gov have been moved up into the clouds.  Moreover the NIST had done the unthinkable just a few weeks earlier during the heat of Manifestogate; they had the audacity to apply a definition of the cloud.  Although they predictably try not to make anyone all pissy about it, noting that this is a “new paradigm” with “many definitions” in a “large ecosystem” of providers.  This draft, like the Open Cloud Manifesto, are signs of things to come.  The Obama administration’s interest has thrust the cloud into the realm of politics fostered much spirited debate over cloud legislation and international business law with efforts to make US-based cloud services more attractive to the rest of the world.

Globalization is also a catalyzing factor here.  IT resources and innovation have been spread thinner around the world over the past decade.  The cloud paradigm has offered a unique opportunity to level the international playing field by creating a common marketing and infrastructure ideology.  The United States is currently 7th in search frequency for cloud computing on Google.  Number 6 is Taiwan.  Using WolframAlpha (one of my new favorite  tools) we can easily use the cloud calculate that Taiwan has only 6.619% of the total number of internet users of the US (14.76 to 223 million).  While it’s obvious that there is a demographic difference for internet use, it certainly illustrates the point.  Public and private clouds are popping up in all geographic regions.  Companies are using clouds to bring IT to corners of the world that never seen this type of infrastructure investment before.  Small companies in Cambodia, Lithuania and Venezuela are leveraging public clouds to deliver services to new markets, IBM has built cloud datacenters in Brazil, South Korea, Vietnam and India, governments all over the world are rapidly building clouds to compete both economically and militarily.  Emerging and growth economies have proven to be very agile in their positioning against the lumbering giants and this has largely been due to the global adoption of the word cloud to describe the metered consumption of resources over an external network.

Of course, cash is king.  The Motley Fool is blasting newsletters to their millions of followers about investment opportunities in Amazon and Google, saying that their clouds are going to help take down Microsoft’s empire and cloud companies are the next big stock picks.  This is pushing the term cloud computing into the common dialog and attaching to it a brand awareness.  Control of the terminology is already breaking away of the sphere of IT influence.   Even Oracle CEO Larry Ellison, who’s become a somewhat notorious cloud villain, always seems to hedge his bets.  After his infamous cloud rant, where he flippantly asks “what the hell is cloud computing?”, Oracle releases database images for EC2 weeks later (although he doesn’t change the licensing model), and then buys Sun for billions after their big cloud announcement and IBM’s failed offer.  Despite Larry’s tirade about there being “no money” in cloud computing, he sure has been throwing a lot at it.  Makes me wonder what is really insane; swooping in to buy Sun certainly seems like a more aggressive and perhaps overcompensating play then just altering the wording on Oracle marketing materials.

“They’ve gone to plaid!”

The cloud as an idea, as a term, and as a method of doing business in IT, is too big to fail. The height of marketing hype and cash investment directly into so-called cloud solutions has provided what is now evolved into a stable platform and a common thread for discussion and innovation.  Whether companies are ready to forge ahead is going to play a big part in the reformation of the IT world and the word cloud will ultimately define the tech giants of the early 21st century.

P.S.: Is the phrase “too big to fail” too big to fail?

The investment in the server resources is important, but that’s the easy part.  It’s what you do with them that is going to be the most critical part of any application of infrastructure (yes, that’s a pun).  Cloud Management Platform vendors are aware that we’re on our way to a multi-cloud world.  Every major player has jumped into the game with some type of platform or infrastructure offering–I’m assuming my audience at this point won’t require me to list them all.  The point is, it should matter to companies interested in deploying their applications or services on the cloud that the vendor they select is pushing hard for support of multiple infrastructure providers and creators.  Tools for cloud management will be the biggest contested space in the race for cloud supremacy.

It’s obvious really, why would anyone think that the War for the Clouds would take place on the ground?

Cloud management software should be a big decision in the strategy and investment of any organization moving their infrastructure into the cloud.   Don’t just stare at numbers on a spreadsheet and compare the cost of the cheap commodity hardware purchased and racked at deep volume discounts with state of the art server management technology.  There are many sunk costs associated with developing without a multi-cloud management platform.  Consider these, all of which could be classified as $$ per hour per cloud:

Learning Curve(s)
Commensurate costs should be estimated inclusive of RnD costs, trial and error, and scattered nature of educational resources, documentation and support resources for DIY integrations.  They should also account for ongoing education around new cloud infrastructure developments.  Just trying to keep up with the firehose of information about cloud computing is a full time job in and of itself (although most of the work is sifting through the hype).

Integration Development/Training
Engineering cycles will be spent integrating an application or service into the cloud regardless of which way it’s approached.  Cloud computing is not plug and play, so you should take care to work with a company that is working fervently on creating switchboards where it can be.  Isn’t that what you wanted in the first place?   Then there is a matter on training staff on operating procedures around development, testing, deployment and administration.  How many times can you afford to do that?  Invest those cycles into something with longevity in interoperability.  A cloud agnostic API is also a big plus.  Eventual standardization of an API would be great and many vendors will likely adopt components of it; but ultimately an API that you pay for should provide much more then the basics.

Revisioning and Lifecycle Management
Internal engineering resources would be required to revision and support all cloud server components. In addition to your own applications.  Cloud management tools should focus on more then just launching servers.  They should focus on making it easier to maintain a variety of useful components and utilities and should address the fact that there is both power and confusion in numbers.  Disposable servers mean lots to keep track of over a long period of time.  Software should track these resources beyond their instantiation at a given moment.  This is about business continuity after all.

Ongoing Cloud Development/Maintenance/Support
Resources would be needed to evaluate, develop, test, QA, and implement, new features as they are released to the public from various infrastructure providers.  Do you have time to keep track of that all?  Your revenue is directly generated by your application or service; not by spending time on more RnD in a space that’s rapidly changing the IT landscape by the day.  Cloud platforms are competing for your dollars in this place.  So you can bet that they are paying close attention to what’s going on so you don’t have to.  This is the cloud mentality; companies should start acclimating.

Monitoring, Emergency Support
Commensurate costs would include development/integration of cloud monitoring systems, on-call engineering resources and incident response time.  These costs would be multiplied by the number of servers you’re running.  Some infrastructure providers do offer these services as an additional cost, so you’re going to pay for it either way.  This is an obvious and critical component of a cloud management platform and there should be both I and AI based resources available to leverage in the case of an issue.

Remediation
Warn and Automate! Not all problems would need to be addressed manually with an engineering resource; and problems are not 9 to 5 employees.  Constant systems administration is required for any infrastructure, yet much of it can and should be automated, especially in the cloud.  Incidents that require manual intervention could potentially lead to additional overtime costs at less-then-social hours.  Using cloud management software to set up automated remediation decreases the likelihood of a critical escalation.

Partner Technology
The cloud is the ultimate technology deliver platform for ISVs as well.  Independent Software Vendors should also be leveraging a cloud platform when considering their deployment strategy.  How will you deliver your technology to multiple infrastructures and reach the largest number of users with the least amount of effort?  End users should also welcome the emergence of cloud appliance federation tools.   Cloud platform vendors again will be competing for a piece of the cloud app-store.  Apple and Facebook’s model examples will be followed.

The bottom line is that investment in cloud management software will mitigate many of these costs in the long term through software innovation.  We’re still at the tip of the iceberg.  Make sure you’re comitting your valuable engineering and dollar resources to something that will ultimately provide you with better agility in the clouds–especially when it comes to base infrastructure providers.  When you first heard buzz about hosting your servers in the cloud you probably envisioned cloud management software…

Invest in your instinct.

If it wasn’t already apparent, with this blog I intend to discuss cloud computing and the emerging marketplace around it.  Blogging is a new endeavor for me, but what better time to start.  I’ve got a passion for cloud computing and a passion for sales.  I’d like to share some of my learnings and experience working in the industry and helping lead the growth of the market for one of the most respected companies in the cloud.

I chose Cloud Vanguard for the name of my blog because I’ve been manning the front lines of the battle for the clouds.  We’re fighting for our piece of a multi-billion dollar industry.  The pace of the battle has been staggering!  Every day companies are breaking new technological ground in the clouds.  Organizations and alliances are forming on different sides of heated arguments (Manifestogate anyone?).  Academia and private enterprise are coming together and throwing millions of dollars into research and development for all sectors of study and industry.  Competative products and services from startups to major vendors are cropping up all over the place attempting to define the markets though their innovations.  Everyone is scrambling to define and understand the meaning of this IT revolution.

The implications of the cloud are immense.  Regardless of what the critics say, every company can benefit from the use of the cloud.  Disposable infrastructure satisfies our desires to be selfish and sloppy.  It’s like using paper plates for every meal and never washing a dish; all the feasting and none of the fuss!  Only it’s better for the environment then the alternative.  From development and testing beds, scalability labs, media processing arrays, financial and scientific computing, web applications, API services, and OP-EX optimized, fully automated systems adminstration, the cloud has features that anyone can leverage at all levels in an organization.

I hope that you enjoy my posts and continue reading.  I’ve got a lot to write about and share.  I welcome your comments and look forward to insightful discussion.  I also invite you to follow me on twitter and connect with me on LinkedIn.