Apps

What to consider before moving your application to the cloud

When CXOs ask developers whether they can move their application to the cloud, these are the six factors they should think about before answering that question.

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.

Network needs

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.

Publicly usable

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.

Scaling needs

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.

Architecture

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.

Storage

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.

Business model

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.

J.Ja

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.

About

Justin James is the Lead Architect for Conigent.

2 comments
shanew
shanew

As a member of a software firm the last sentence of this article sums up a lot of observation and research I have been doing lately. "Things like perpetual licenses are deadly when you are paying for cloud resources on a monthly basis." So many of the large software vendors are adopting the primary sales model towards per-year (paid monthly) and per-month subscription packages, as to oppose a once off lump sum purchase. While doing this provides so many additional features to the customer (not to mention the cost reduction over a perpetual license purchase), it makes sense that these prices measure closely towards the cost of maintaining cloud infrastructure. My only answer to the increased "value for money" that a subscription plan can offer is that it provides a more regular purchasing process for a software vendor that doesn't release major titles more than 12-18 months apart. Can anyone provide insight to this strategy when it comes to selling software?

sysop-dr
sysop-dr

If your data is regulated and you require security clearances for all people who might get access to it, putting your data in the cloud might mean it being hosted in a different country and in violation of export laws or data privacy laws or whatever (depending on your regulations.) We require security clearances for everyone depending on their job and what data they may access. For sysadmins this can include security clearances in more than one country. Putting that data, even encrypted on a server outside our firewall would mean every sysadmin and every developer at the cloud provider would also have to have those same security clearances. (Developers included if they work on anything that might touch the same server that the secure data would be allowed on, think of the attack angles.) OR you could limit the exposure and the number of required clearances to a private network at your own facility. When you put your data onto someone else's servers you now extend your attack surface onto those servers and include all of that facilities employees as possible insider attacks. 95% of all attacks are made by insiders (or is that 90% you look it up) so unless losing the data has no consequence you have to look at the data and first say, is there a regulation I am breaking by putting this data into the cloud if the provider were to put this in a country other than my own. I can see some of our data being hosted in the cloud, some already is, the stuff we make available to everyone. But some of it is regulated and access is not outside the company, it would be bad if it got into the wrong hands and yeah I have seen this happen before and people got in a lot of trouble. (We do nuclear so you are probably not as worried about this as I am but you should still ask the question.)

Editor's Picks