In the last several years, moving applications to the cloud has gone from a big risk that only a few companies could justify to a sensible alternative to self-hosting an application. Here are some things you need to look at to determine if your application can or should be moved to the cloud. Perhaps only one or two of them stand in your way, and you can re-engineer those.
If your application needs a high bandwidth or extremely low latency connection to systems within your network, it is not likely to be a good candidate for being moved to the cloud, unless you can also move those other systems to the same area. On the other hand, a good cloud provider is likely to be able to provide high bandwidth, low latency delivery to your users if they are not in-house users. Maintaining that kind of network is a headache, and it can be a joy to let someone else deal with it. The more you can keep the data transfer to being within the application and not between the application and the screen, the more suitable your application is for the cloud.
If the application will be used by people outside of your organization, moving your application to the cloud gives you two major benefits. First, it moves your network needs off of your network. Second, it creates complete separation between your internal network and your application. While many IT departments will do this anyway, I have seen IT departments that have not done it (often for good reasons), which creates a security risk.
Applications that need to scale or that may need to scale are good candidates for the cloud. One thing the cloud can do really well is provide you with resources on-demand. Advanced providers will have the facilities to let you schedule additional capacity for peak hours or to detect high loads and bring extra resources online.
Not all applications can just be deployed to a server in the cloud and run. For example, some applications depend on other systems that just are not available in the cloud or can't be located there. If your application relies solely upon standard, commodity technologies (Windows or a common Linux distro for the OS, MySQL, Microsoft SQL Server, or Mongo DB for data, and ASP.NET, PHP, Java, or Ruby on Rails for the application language), then it is a great candidate for moving to the cloud.
One thing I detested dealing with during my various system administrator jobs was storage. And not just "where do we put all of this data?" either — even more frustrating than that was backups. To make it worse, systems would get slow, and the issues were traced to I/O speeds, but solving those issues was not the easiest or the cheapest thing in the world. Applications that have demanding storage needs are the kind that are nice to send into the cloud.
Cloud providers almost universally charge based on the resources you use: storage, number of servers online for how long, bandwidth, and add modifiers based on the capabilities of those resources (the more RAM per virtual machine the more you pay, for example). If your business model cannot monetize your users in a way that scales with your cloud costs, you are going to be sunk quickly, unless your profit margin is so high that all but the heaviest users are profitable, and heavy users need to be rare. Things like perpetual licenses are deadly when you are paying for cloud resources on a monthly basis.
Additional cloud resources
For more on this topic, check out the ZDNet and TechRepublic special feature Cloud: How to do SaaS right and our downloadable Executive's Guide to Best Practices in SaaS and the Cloud.Keep your engineering skills up to date by signing up for TechRepublic's free Software Engineer newsletter, delivered each Tuesday.
Justin James is the Lead Architect for Conigent.