A lire sur: http://www.techrepublic.com/blog/programming-and-development/what-to-consider-before-moving-your-application-to-the-cloud/6465
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.
Takeaway: 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.
Network needsIf 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 usableIf 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 needsApplications 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.
ArchitectureNot 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.
StorageOne 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 modelCloud 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.