This is part two of three posts about moving to the cloud. Read Pack your bags, we're moving to the cloud! (part one)
So how do you evaluate a Platform as a Service? Some of the questions you should ask when deciding on a PaaS provider are:
- Is the PaaS standards based or will you have to learn a new language to customize it?
- Will the system work offline?
- How much does it cost?
- What are the licensing issues and do they suit your project?
- Does it work with your company's web browser or mobile devices?
- Can you move it to servers inside your firewall if you need to?
- Will the customizability of the PaaS suit the needs of your particular problem?
- What are the security options available?
- What happens if the Platform runs into a brick wall and you need to move your data to another system?
- Does the vendor lock you in?
- Does the platform you are using run on an environment similar to your own systems?
- How easy or difficult will it be to integrate the remote platform with your other internal or cloud hosted systems?
- Does the provider offer an API?
- Can it ingest data from other providers and systems?
- Can you make your internal systems accessible by the external platform for integration, either by push or pull?
Of course there are more questions than that, but let's move on to the situation where you have an existing application running inside and want to migrate it to the cloud. In this scenario you may have a code base that doesn't lend itself easily to simply dropping that application into cloud host. You have to evaluate all the components of your system and find a cloud based infrastructure provider that offers the hardware and software components that will support your system.
For example, your system may be written in Java, Rails, or .NET in which case you will need to find a cloud that will accommodate applications built with those languages. Another consideration is the need for persistent storage and database access. Does your system use MySQL, MS SQL Server or Oracle? You'll need a provider that offers the database or the mechanism by which you can install it yourself.
It won't always be easy to find or fix these problems because if you are building and debugging the code on your local computer or network systems, they won't exactly mirror the cloud system so sometimes you will have to make a change locally that will break it in your local system so it will work on the cloud. There are various techniques you can use to determine where your application is running and then do different things based on the environment so it will run in both places. You could use some intrinsic property of the environment like the servername or something foreign like a config file. You may need to discuss these issues with your provider, but they almost certainly will crop up.
Some things you'll need to think about that you may not have to worry about when running systems internally is how to integrate your cloud application with other systems you are building internally. These questions are similar to the ones for a PaaS, but in this scenario, you will have to build the web services and APIs yourself and ensure that connectivity exists between the cloud and your internal systems. This may or may not be a trivial issue. For example, you may use LDAP to provide authentication to your internal systems, but integrating your cloud app with your internal LDAP may not be an option. so you'll have to roll your own security mechanisms.
In the next installment I'll talk about some of the testing issues you should consider. Continue to Pack your bags, we're moving to the cloud! (part three)