When you’re in the process of establishing your cloud architecture, figuring out what can be moved to the cloud, and when it should be moved, is job one. That can seem like a daunting task, depending on the size of your organization, the number of applications in use, the complexity of your network architecture, and so on. But it’s not as hard as it first seems. You can kick start your cloud migration by looking for applications that share some or all of these five characteristics:
- Apps that are already virtualized
- Apps that are loosely coupled and modular in their design
- Apps that have low requirements for privacy and security
- Apps that can tolerate latency
- Apps that are unencumbered by regulatory requirements
Mapping your path to the cloud will be easier once you understand how and why these characteristics matter, so let’s drill down into each.
1. Apps that are Already Virtualized
Bert Huelman is Senior Solution Architect at SHI.com. He was formerly solution manager at Microsoft. He blogs on cloud issues at the SHI Cloud Blog.
There are three types of applications you’ll find in the cloud: browser-based apps designed from the ground-up for cloud computing; mobile apps designed from the ground up for cloud computing; and desktop or server applications migrated to the cloud. The first two cases don’t apply to this conversation, as they’re built from day one to run in the cloud. Examples include SaaS apps such as Salesforce.com or Google Apps, or mobile apps such as iCloud for the iPhone and iPad.
But rebuilding your entire application portfolio from scratch isn’t a viable option for most organizations, nor is replacing every application with a SaaS alternative. Every company eyeing the cost savings and productivity advantages of cloud computing is also considering migrating their desktop and server portfolio. And when you’re moving apps to the cloud, one thing is certain: The apps will be virtualized, using technology such as VMware.
Virtualization isn’t limited to the cloud. Organizations have been using virtualization to consolidate data centers by creating multiple virtual servers inside individual physical machines. The more VMs you deploy, the fewer physical machines you need. The potential for space, energy, and hardware savings is obvious.
Virtualization is also being used to make desktop deployment and management easier. Images of user desktops are easily created and maintained. Virus outbreak? No problem. Roll the user’s desktop back to a previous image. Backup? Copy the virtualized desktops to another server. Remote user? Send them their personal virtualized desktop. OS or app upgrades? Upgrade the master image and replicate it to users.
If your organization is already using virtualization, you’re in a great place. Systems, servers, and applications already virtualized are ideal targets for a move to the cloud. The effort to virtualize them has already been done. Moving them to the cloud can be as simple as copying the VMs to your cloud provider’s data center and adjusting network connectivity.
2. Loosely Coupled Modular Design
The second characteristic is a loosely coupled modular design. This is the ability of an application to tolerate latency (more about that in a second). In a loosely coupled application, when the program needs to pass information to a server, it puts the information in a queue and continues working on other tasks.
It doesn’t wait for the server to complete the transaction. Eventually, the server will hit the queue, process the info, and place the result in another queue to pass it back. Neither the application or the server is waiting for the other, because they’re loosely coupled.
If your organization is already using virtualization, you’re in a great place. Systems, servers, and applications already virtualized are ideal targets for a move to the cloud. The effort to virtualize them has already been done.
Obviously there are situations where this approach will or won’t work. It works best when the transaction is small, there is only one of few steps to be done, and the time it takes to complete the transaction is immaterial. In a loosely coupled application, it doesn’t matter how long the queue is or how long it takes the server to get to it; all that’s important is the work eventually gets done, and results passed back to the application.
The advantage of a loosely coupled modular design is that you can easily scale one component or another without affecting performance or cost. You might also be able to break an application apart in such a way that critical and sensitive components are maintained on an internal cloud, while less critical pieces are put in a public cloud.
3. Low Security and Privacy Requirements
Another characteristic to look for: low security and privacy requirements for a given application’s data. This is especially important for credit cards, personal identifiable information, and information covered by HIPAA. Many organizations don’t feel comfortable processing this type of data in the cloud. If that describes your organization, then applications with high security and privacy requirements are not good candidates for the cloud.
That said, it should be noted that cloud computing, done right, can be as secure as computing in your internal data center. You will need to work with a partner, such as SHI, that can provide the industrial strength security such applications demand, and which many cloud computing platforms lack.
4. Tolerance of Latency
Earlier I mentioned loosely coupled modular design. The next item is related: tolerance of latency. Applications in the cloud have a longer response time (measured in milliseconds) than those connected to a local server on a local network. The time it takes a system to respond is called latency–and the lower, the better. Applications that require real-time access to data, servers, or services are not going to fare well in the cloud.
For example, there are high-performance databases that are tightly coupled with application and web servers (example: trading systems like NASDAQ or the NYSE). For these systems, every millisecond counts, and the need for speed outweighs the benefits of cloud computing.
Then there are “chatty” apps, where the application or web servers communicate frequently with the database server. Each “message” requires a round trip between the application and the database. Often times these apps operate synchronously, meaning they pause and wait for replies from the server.
Moving chatty apps to the cloud, and adding few milliseconds to each message’s round trip, doesn’t sound like much. But when you’re talking about, for example, a web page that requires 100 round trips to load (header information, page layout, images, and database content), and then you add 10 milliseconds each trip, an application that once ran smoothly suddenly feels slow, as the load time increases by 2 seconds.
Applications that work best in a cloud computing model don’t have real-time or chatty communication requirements. They’re optimized to tolerate latency, operate asynchronously, and pass messages efficiently.
5. Minimal Regulatory Requirements
Applications with low regulatory requirements are also low-hanging fruit for cloud migration. If you’re in a business with a high regulatory environment (e.g., industries like banking, insurance, and pharmaceutical), some of your applications have requirements about how data is gathered, compiled, and stored. If your data has to be protected, provide a specific audit trail, or must remain in a given country; and if your cloud service provider can’t guarantee all such requirements will be met, then the applications are not immediate candidates for cloud. So, a review of the regulatory environment is essential.
When you move to a cloud, your existing internal controls must extend to the cloud, but they are no longer enough. To some degree, you are now depending on the infrastructure, practices, and procedures of your cloud provider.
When you move to a cloud, your existing internal controls must extend to the cloud, but they are no longer enough. To some degree, you are now depending on the infrastructure, practices, and procedures of your cloud provider. Data location, multi-tenancy (where your apps and data are co-resident with the apps and data of other cloud customers), and provisioning (what to do when a user leaves your organization) are factors to be considered. You also want to think about your auditing process, and how you will be able to integrate the cloud services provider into your compliance management.
Make or Break: Must All Apps Meet All Five Requirements?
It’s natural to ask if an application must have all five of these characteristics to be a candidate for the cloud, or if some characteristics are more important than others when evaluating applications. I’ll state the obvious: If an application meets all five criteria, it’s a slam dunk for fast and painless cloud migration. Move such apps first, and use them to build your organization’s cloud IQ.
But that doesn’t mean that answering no to any one of them means that you can’t move that app to the cloud. What it does mean: Now you know the issues that must be addressed in your cloud migration, and the topics that you have to put on the table when you’re talking to your cloud services provider.
Have questions? Feel free to write to me at [email protected], or comment here.
