"Most of this is just common sense," he told the crowd. To a practiced architect it may be common sense, but to some first-time implementers, it's clearly a challenge. The fact that 17 steps are involved may indicate that when it comes to cloud computing, common sense may be less common than some imagine.
From that point on, I started listening to speakers for one particular thing: the moment when they hit the point of pain, where common sense didn't seem to be enough. Here are a few examples.
[Want to learn more about cloud computing's maturity? See Cloud Computing Is Still In Its Adolescence.]
Patching Systems While Keeping Them Up For Physicians
Bill Gillis, director of eHealth technologies at the Beth Israel Deaconess Medical Center and Beth Israel Deaconess Physicians Organization, implemented an online system that provides electronic medical records to 1,600 physicians at over 300 locations.
That's a ticklish assignment. The records naturally contain personal health information and had to be kept private at a Web site that, according to Gillis, was being attacked every 10 seconds. As his IT group set about building the electronic records site, he thought, "We could build a grand hotel, but maybe nobody checks in." Getting physicians to adopt new technology has been notoriously difficult. He completed this project with the help of government stimulus funds for physicians participating in electronic health record projects.
Gillis said his team used TrendMicro firewalls and deep security surveillance for protection, but his pain point was keeping electronic medical records continuously available while still patching his virtualized systems promptly to ward off threats. There was no window in which systems could be taken down for patching. He was relieved to find his VMware virtual machines could be patched live through an automated process. "We would not have been able to go live without virtual system patching," Gillis said.
The product that does this is VMware's vCenter Update Manager; Gillis didn't name it. VMware claims on its Web site that neither Citrix nor Microsoft can do this from inside their virtualization management systems.
The Complications Of Another Mobile App
Phillip Easter, director of mobile applications for American Airlines, described how he used Microsoft's Azure cloud to power mobile apps for the Windows Phone. It's pretty nifty, but Easter's presentation highlighted the difficulty of having a good mobile application with functionality that works for multiple mobile devices.
One of the most frequently sought pieces of information by air travelers is whether their flight time has been modified. "Modified, not delayed," said Easter, tongue in cheek. The American Airlines mobile app for the Windows Phone can let travelers check in, store a mobile boarding pass that gets them through security, check the gate and status of the flight, and even find out whether the time of the flight has been modified. As best I can tell, some of the same functionality is available through American Airline's applications on the iPhone, Android, BlackBerry, and iPad. But American, which is headquartered in Dallas, connected with Microsoft engineers also in Dallas to add features such as where-you-parked reminders, maps of the terminal you're in, and access to your AAdvantage frequent flier account.
Adding features was challenging enough, but making vital corporate data on flight scheduling and other data available to the public via a partner's cloud service proved to be a particularly complicated job. In this case, American had to create a Web service proxy server that brings the data out from behind the American corporate firewall and makes it accessible to Microsoft's Windows Azure, which in turn makes it available to Windows Phone users.
Easter didn't speak directly to APIs, but American must have already created well-defined, simple APIs for each mobile application's services that are used by both Windows Azure and American's own Web service site. Doing so would give American developers a clear way to build applications that access core services from different devices.
Through the accumulated expertise of Easter's team, American Airlines has built mobile apps to smooth customers' paths to flight information, check-in, and flight status updates. But his talk illustrated that doing this wasn't simple. It required a series of coordinated steps, architected in a way that didn't shortchange any particular device while leaving corporate data intact.
Thinking You're Not A Cloud User When You Are
Geva Perry, San Francisco Bay Area startup advisor and author of the blog "Thinking Out Cloud," said cloud computing so far has been a bottom-up phenomenon, with developers in many organizations being the early adopters.
According to Perry, surveys show that cloud adoption is slow in many companies because employees are looking to CIOs or IT managers, many of whom have a negative attitude toward the cloud. "The last person you should ask about the cloud computing adoption is the CIO or senior IT executives," he said. "Amazon adoption was developer-driven. Amazon understood this and built its service in a very developer-friendly way."
Cloud services make it easier to route around IT staffs: line of business users can swipe a credit card and establish an account in the cloud for a virtual server that effectively feels like the one IT said it couldn't supply for several months. The way to avoid this, Perry advised, is to set up private cloud services within the company, allowing employees to self-service through "a minimum-friction, low- or no-touch process" from IT.
Linux and other open-source code came into the company through the back door as well. It's less painful to give up some control than it is to discover you are being viewed as the chief impediment to accomplishing the next project, Perry pointed out.
Legacy Apps Don't Migrate To The Cloud
James Staten, lead cloud analyst at Forrester Research, said Forrester predicted in early 2011 that "lots of enterprises would put applications in the public cloud, and they would fail. And they did."
A pain point in some of these failures involves system dependencies that need to move to the cloud with the application, such as secondary applications, database systems, identity management, and the fact that some or all may need to be converted from mainframe or Unix platforms to x86. The real pain in moving legacy apps to the cloud is financial. Legacy app owners want to reduce their cost of operation, but a migration to public cloud infrastructure will not prove cost-effective, Staten warned.
"If you can't activate cloud economics, you shouldn't go there," he said.
I'm not sure how widespread such attempts are. Many managers have perceived that legacy apps aren't going to make the move cost effectively, if at all, and have left them where they are.
But Staten went on to propose a way to make use of legacy apps as part of a cloud computing initiative. Where possible, he suggested identifying particular services within the application, transforming them into separate, callable services, and making them accessible as Web services. This gives companies the option of designing and running "green field" cloud applications on public infrastructure while still obtaining key services from the data center.
At Cloud Connect, the voice of painful experience kept asserting itself. The potential benefits of elastic and scalable cloud architecture were less emphasized and taken more for granted this year.
Perhaps the final word came from Jesse Robbins, chief community officer of Opscode, a supplier of automation software for data center operations: "Remember, if you're depending on three cloud services, each with 99.9% uptime, you are likely to experience an operational uptime of 99.7%."
This is the mathematically precise new realism of cloud computing.
Find out how to move beyond server virtualization to build a more flexible, efficient data center in the new Private Cloud Blueprint issue of Network Computing. (Free registration required.)