This is the third and final installment in a series of posts discussing issues to consider when moving to the cloud.
If you haven't read them already, you may want to start here: Pack your bags, we're moving to the cloud! (part one)
andPack your bags, we're moving to the cloud! (part two)
The next three steps in the move to the cloud are test, test, and test. Testing is important whether you choose a PaaS or an infrastructure provider. In the best case scenario you can use automated test tools against your remote url just like your internal apps. You will want to simulate worst case scenarios like your internet goes down or the provider accidentally deletes your data files or crashes. What is your contingency plan if something like that happens? Make that situation happen and see if your fail over works appropriately. These are the same issues you will have with an application in a traditional environment -- they are just a bit more complicated in the cloud because your cloud environment is not totally within your control and identical to your development environment. You will almost certainly have to work with more limitations in the cloud than in a local environment.
The next type of testing you will want to do is for performance. Implementing a scaling solution is easier with some clouds than others. Some solutions scale automatically, some do not. What kind of latency should you expect and can you optimize your code to improve performance?
This performance testing will also help you better understand your cost to host the system in the cloud. Every cloud has their own method to determine utilization. You'll need to understand how your application uses the cloud environment with respect to disk storage, processor utilization, memory, and bandwidth. Because each provider charges a bit differently for each aspect, you will need to understand how your application uses the environment to understand how much it is going to cost you. It's almost impossible to predict the costs without actually testing your application in the cloud and estimates may not be as simple as extrapolating the number of users. Depending on the nature of the application itself, its growth could get out of control quickly. The Animoto case study is an example. Is your app a viral candidate? How will the data grow over time?
The third type of testing would be for security. The nature of cloud hosting is different from internal apps because there are more security concerns in the cloud. For example, you may not care if anyone within your corporate network can sniff the HTTP packets for an internal phone book application, but moving that into the cloud may require SSL security to prevent hackers from gaining access to your internal contact information and employee lists. Moving an app like this to the cloud would provide many benefits, including work from home, client and vendor extranets, and the like, but you may need protect the information by limiting access to an IP range or domain, secure files differently, use OpenID, etc. Your security testing should address all these issues that may be irrelevant when building an application to run internally.
As I reread this, it sounds like it's a lot more difficult to build cloud apps than internal apps and in some respects it is, but you need to evaluate whether the cost savings from reduced private infrastructure and hardware maintenance outweigh the additional development times, learning curves, and security concerns. I think in an increasingly large number of circumstances, it makes a good deal of sense to move to the cloud. The extra concerns and difficulties of the cloud are usually not as significant as the costs to host your own infrastructure, but your mileage may vary.
I hope this helps clarify some of the issues and things you'll need to consider. How to evaluate decisions based on all the factors is a much more lengthy topic and very dependent on the particular situation.