7 Self-Inflicted Wounds Of Cloud Computing

Anthony Skipper at ServiceMesh assembled a comprehensive list of the common holes in companies' approach to cloud computing for his presentation at Cloud Expo in New York in June.

Skipper is VP of infrastructure and security at ServiceMesh, a supplier of IT service management and lifecycle governance. His presentation was titled, "Cloud Scar Tissue: Real World Implementation Lessons Learned From Early Adopters." It was also cited by cloud blogger Andrew Chapman.

Skipper explained seven self-inflicted wounds. I've tried to warn about some of these myself, but I find Skipper's list nearly complete. I'm repeating them after reviewing his slide presentation--and adding a few of my own thoughts, too.

Self-Inflicted Wound 1: Not Believing That Organization Change Is A Requirement

Skipper says delivering an integrated cloud solution in a timely manner "is hard to do with an IT organization separated into fiefdoms based around storage, network, compute, and platform." Cloud computing automates the provisioning of new servers and reviewing requests for them, "freeing up a significant amount of capacity with your carbon-based units, which is good because you need them to help in all the new kinds of roles." They include: defining policy, migrating legacy solutions, or building new stateless, auto-scaling solutions, supporting continuous delivery processes.

This is a neat summary, once you decipher those "carbon-based units." He means, of course, the human capital, the IT staff. Implementing cloud computing tends to erase well-established boundaries, forcing the network manager, system administrator, and storage manager to work together to come up with server archetypes that are acceptable to major segments of the business. Their collaboration allows definitions to be laid down and policies set around what types of servers end users may have. Having done so, the provisioning of new servers can be automated, and IT staffers are freed up to meet the new agenda named above.

Skipper concluded, "Architects are not just for ivory towers."

My interpretation: the enterprise IT architect can play a key role in setting requirements for the cloud infrastructure and defining server templates. Infrastructure architects are often viewed as disconnected from and little involved with the business realities that line-of-business people face. The closer the architect is to the nitty gritty action of the business, the better match the cloud services that he designs will be for business operations. Servers can be designed to be more secure or less secure; operate with lots of memory and caches for high performance or in a less expensive and slower fashion; have lots of I/O bandwidth or little. It's the architect's job to make choices that are best for the whole organization and come up with an integrated cloud computing plan that serves it. It's not easy, but implementing the new paradigm offers a chance of achieving an old goal: aligning IT services with the business.

Wound 2: Boiling The Ocean

As Skipper said: "Trying to do all compute platforms at once doesn't make sense." His points were: "Mainframes aren't going anywhere quickly. Most Solaris/Power architectures have already migrated to zones. It's not viable to move all your applications at once. You need time to learn and for your organization to adapt. Some percentage of applications will need work to be ported. Some applications are simply not a good fit for cloud at the current time. The more cloud providers you use, the more scattered your infrastructure and the higher your costs."

There's a number of points to embellish here, and I'm sure Skipper did so during his Cloud Expo presentation. But I didn't get to sit through it. So here's my take: There's no equivalent to the mainframe in the cloud; cloud computing is essentially an x86-server creation. It's hard to even test a mainframe connection in a cloud application. All you can do is simulate and hope that in real life, it will work as expected.

So don't boil the ocean and assume you will forcibly push mainframe apps into the cloud, a Sisyphean task if there ever was one. Likewise, the work running on Sun Sparc and IBM Power servers doesn't fit easily into the cloud. Besides, IBM and Sun adopted strong virtualization technologies of their own, where one copy of the operating system manages several applications but the applications have been placed in isolation zones. Some enterprise applications will need to be ported to x86; SAP and Oracle have already done so, but not all enterprise applications move easily to Intel architecture. Trying to find cloud providers that satisfy custom needs guarantees your workloads will be spread around and, in the end, that much harder to manage. Wound 3: Failure To Simplify

"Complexity Kills," warned Skipper in big red letters on his first of three slides to make point number three. The second slide said spinning up a virtual machine often means it will need to have 80-150 integration points. "Half the technologies in the existing IT portfolio don't have good cloud implementations or are incredibly proprietary (Power architecture, Fibre Channel over Ethernet, Infiniband). It's counterintuitive," he added, "but you can build solutions with five 9s of reliability without using a single component that has better than three 9s of reliability."

He continued, "Use the cloud as an excuse to fix complexity problems by adopting ruthless standardization: x86 servers, NAS/iSCSI storage, 10-Gb Ethernet. Eliminate technologies that add complexity, especially gold-plated solutions in the traditional [high-availability] space." His accompanying points were: "Replace any systems that can't be automated or scale; make configuration driven by policy where applicable; keep standardizing up the stack towards PaaS" [platform as a service].

This, I think, is actually one of his strongest points and vastly underestimated by those who don't see anything new in cloud computing. The cloud imposes simplification on what heretofore has been a self-reinforcing march of complexity in the data center. The demanded best-of-breed solution was always one of a kind--an MPE system here, a Sparc/Solaris system there, and over there in the corner, a VMS minicomputer operating system.

The cloud imposes a standard architecture on all future systems. There's no reason why there couldn't be a Power or UltraSparc public cloud, but their manufacturers would have to find ways to bring their operations into line with the economics of clustered x86 servers. By adopting only x86, cloud implementers have eliminated the primary source of complexity at a stroke and imposed a uniform architecture.

If an application is optimized to an older version of the operating system on an outdated chip, it's possible to move both application and operating system to a new server in a virtual machine. That is, x86 lends itself to long-term, simplified operations and management, less time spent on upgrades and maintenance. Good arguments can be made with this position--the mainframe can be managed with great efficiency and high utilization rates--but it's difficult to argue with the long-term economics. Fibre Channel over Ethernet is a promising technology and Cisco's Unified Computing System, which adopts it, is a strong cloud building block. But FCOE is also a Cisco-leaning standard that competitors have been reluctant to adopt. The cloud benefits from multiple manufacturers competing to produce the most widely adopted technologies. I lean toward x86 servers, iSCSI storage (Skipper said "ISCI" storage; I hope he meant iSCSI) and 10-Gb Ethernet as examples of those technologies.

Wound 4: Not Understanding How Vendor Management Works

On this point, Skipper's presentation said simply, "It's common for enterprises to spend 6+ months negotiating a contract with a cloud provider." I wasn't sure what he meant so I turned to Chapman to see if he had any amplification. In his June 9 blog, he said: "Negotiating contracts with cloud providers should not be underestimated as a task, especially for a large-scale contract. This can take 6+ months just to negotiate the deal and this has been known to actually stop a project."

I see. OK, don't let your project get derailed just because the lawyers are involved. This to me is another argument to start small, then evolve as fast as you are comfortable toward a bigger commitment to cloud. Wound 5: Believing The Vendor

Skipper said, "When a data center automation vendor tells you they can take their existing product and simply add a plug-in or new related product that makes everything cloud-ready... You should think of unicorns..." Next slide shows a pug dog in a pink unicorn outfit, not the happiest of marriages.

This is that moment in every presentation when you realize it's being given by a vendor with a self interest, and along with much valuable information comes a swipe at the competition. When I think of cloud vendors, I think of Amazon.com or Rackspace or Terremark. At ServiceMesh, they think of those competing vendors in the data center automation space. No, you can't necessarily believe someone who says there's an instant answer to becoming ready for the cloud. Okay, now let's move on.

Self-inflicted wound number five continued with two more slides. Cloud vendors come with cloud management tools. Skipper asked: Can the tool provide end-user self-provisioning? Can it calculate chargeback on a pay-by-the-hour basis? Can it automate storage provision? Does it work with multiple hypervisors?

Good points, Anthony. Let me note here that most cloud service suppliers, from Amazon Web Services on down, have limited interest in working with multiple hypervisors. Amazon likes Amazon Machine Images that run under the Xen hypervisor. AT&T and Verizon Business like VMware virtual machines. Microsoft likes its own and Citrix Systems' virtual machines. But most customers already have multiple hypervisors in operation and only a few clouds are willing to run all of them.

Skipper continued in another slide: "All cloud projects will require some level of integration." "Skepticism is healthy for everyone" on the integration front, he said. Not all cloud APIs are created equal, another good point. And cloud providers who also provide their own management software "represent a dangerous dose of lock-in," a dart probably directed at VMware.

Wound 6: Getting Addicted To Cloud

Many early implementers have realized immediate savings in moving a workload into the cloud and reacted with enthusiasm. If a little is good, then a lot must be a lot better. Skipper warned, "There are solutions that are initially cost effective in the cloud, but which later grow to scale where they become incredibly expensive."

I would say one place to look for this is in the charges for data movement into the cloud, or in Amazon's case, between availability zones within the same data center. There's a charge based on the amount of data. In other cases it's based on numbers that are hard to predict, such as the number of http requests, storage consumed, or number of I/Os used. The cloud vendors mix up their charging mechanisms, making it hard to compare one to another as well as predict what the charges might actually be. In most cases it's cheaper to move your data into the cloud than it is to get it back out again, a built-in discouragement to considering another vendor.

Skipper wisely warned against too much enthusiasm and not being able to calculate what your costs will be if your workloads needs to go big and start consuming more resources. "Have the ability to bring things back internally or to another provider at any point," he advised. Again, point well taken.

A company that has clearly learned to do this is the online game supplier, Zynga, which launches its new creations in the Amazon cloud but brings the game logic and services back in-house, once it sees what the demand will be. It tries to manage the Amazon cloud and its own Z Cloud as one environment and move workloads fluidly between them. For more on this, see CTO Allan Leinwand's comments in Lessons From Farmville.

Wound 7: Failing To Implement Policy From The Beginning

Another way to cause your move to cloud computing to fail is to make no decision on how you will manage cloud workloads, Skipper said in his concluding point. "You'll miss the window to drive major process improvements. It's not possible to fully automate everything if you don't have configuration generated by policy. Even though it's technically possible to move anything anywhere, that doesn't mean it is legally possible. Cloud means a business unit can open a Salesforce or EC2 account with a credit card and be using it in minutes."

So if you've achieved simplification by moving to a standard x86 architecture and scrupulously followed standards in networking and storage, you can still blow it by adopting cloud use willy nilly without an ability to impose your governing policies. It does no good to allow end-user self-provisioning if you don't have the policies in place that determine the appropriate amount of networking and storage for the type of server spun up. You'll be resorting to constant manual interventions if you don't have security policies that match the use of the virtual server.

And I would add those security policies must follow it around if a virtual machine is moved from one location to another in the cloud. Good policies are one of the few ways to free up those carbon units we were talking about earlier and let them work on further improvements--your ultimate pay-off.

All in all, a fine summary on how half-measures, traditional thinking, and refusal to change can kill the most promising cloud project.

Charles Babcock is an editor-at-large for InformationWeek.

Security monitoring, incident response, and forensics are essential, even in the cloud. But the cloud by definition implies relinquishing at least some control, which can make these practices problematic. In this report, we identify the challenges of detecting and responding to security issues in the cloud and discuss the most effective ways to address them. Download our report now. (Free registration required.)