The biggest pushback will likely come from the guardians of the application life cycle. In the data center model, applications are identified, architectures defined, and hardware and software procured -- then comes the agonizing manual labor of loading and configuring, which can take a week or more. In the cloud, there's still agony in loading and configuring, but instead of grunting over individual servers, the heavy lifting is associated with building templates and scripts that will auto-build, or orchestrate, servers and apps.
Your application life cycle guardians will remember well what an effort it was to configure the servers for that legacy system. Though they may smile politely while you unveil your big cloud plans, as soon as you reveal that those plans involve destroying their servers and rebuilding them off-site using templates and scripts, the conversation is over, in their minds.
This isn't always the case, but the point is that IT leaders think, "No big deal. Just write some scripts and templates and move the app to the cloud." Application and infrastructure teams often view this quite differently and will push back that the app shouldn't be moved outside of the life cycle. Frankly, it's hard for a CIO to argue with that, especially when teams point out the amount of effort required. Yet if we wait until the end of life for applications that may hang around for a decade, we lose much of the benefit of cloud, and for what?
4. We'll end up locked into some cloud provider.
There are many ways to migrate an application to the cloud. Some involve consultants, manual processes and being melded to a cloud provider. However, there are tools to help avoid lock-in while bringing the benefits of automation.
You can follow the lead of The Associated Press, CBS Interactive, Zynga and a slew of sophisticated startups: Use a platform such as RightScale, Scalr or enStratus that abstracts complexity. These systems provide management and orchestration and are typically built around components of on-the-fly provisioning technologies, such as Puppet and Chef.
Using a platform like RightScale requires a completely different way of thinking than what enterprise app teams are accustomed to and, to be fair, while these management platforms have templates for building things like SQL Server, you won't find templates for most legacy applications. Your app team will have to build these, and, as we've said, it's just about as much effort as creating the server farm in the first place. Don't expect people to be excited about this, particularly because there are new technologies to be learned and new obstacles to overcome, such as creating a virtual private cloud or dealing with a new and borderless server architecture.
Another issue that tends to bring IT pros outside their comfort zones is when outside services require internal resources. When a customer used CliQr to deploy a .NET app into a cloud provider's infrastructure, the question of how to print on site came up. The answer was to use a CliQr feature that allows for service proxy of given services -- no VPN was needed. Creativity is required.
5. It's not broken, so why the heck risk a security breach?
To paraphrase Dilbert, do you trust a vetted cloud data center with a crackerjack security team and a CSO who used to be with the FBI more, or the programmer who's been outsourcing his job and sending his physical authentication token to China via VPN?
In shops with hundreds or thousands of apps that are working just fine -- apps that people like, that are reliable, that provide benefits to the business -- there's no compelling reason to burn it all down and rebuild it in the "cloud way." But make no mistake: Today's rich IaaS provider ecosystem means low prices and little risk of lock-in, and automation means you can quickly provision systems to meet your organization's needs.
So start now, and be pragmatic with legacy apps. If you sit back until applications run their natural life cycles, you'll be waiting a long time.
(registration required)
.svg)
.svg)
