In our recent analysis of the State of IT Transformation, 91% of the companies that we worked with admitted to having no organized, consistent means of evaluating applications for cloud. There is a well-defined set of criteria that should be used to determine whether or not a legacy app is suitable for a public cloud platform. Sometimes a single criterion can drive the decision; sometimes it’s a combination. To determine which apps are suitable for a public cloud, you need to consider the technical architecture of your app, your business considerations, and your cost goals. For discussion purposes, it’s probably easiest to identify criteria that make an app not suitable.
Let’s cover the technical characteristics first.
Network Latency
Is your app highly sensitive to latency? For example, is it real-time? Does it require two-phase commit for database transactions? Or can it tolerate some time lounging around while it waits for the network to get a message across. Here’s an interesting little site (that works in lots of browsers) that shows how long it takes for your browser to ping each AWS region http://cloudping.mobilfactory.co.kr. Run it a few times to see how variable latency can be and how it changes based on where you are. When considering latency as a cloud-suitability criterion, be sure you understand how it might affect your SLAs and what your cloud provider can guarantee, and at what price.
I/O
Does your app have high, sustained I/O rates? It probably will run in a public cloud, but how expensive will that be? You can read and write all you want in your own private cloud and no one is going to charge you a cent extra. But you might want to take a look at your app’s disk stats over several time periods to really understand it, and then see where your potential public cloud provider starts charging extra.
Integration
How often does it interact with other systems or apps? Where are those systems located? How many systems or data sources are in play? Locations and frequency of interactions between the app and external systems will affect the complexity of moving your app. If you have more than 5 data sources and/or legacy apps to integrate with, it’s not going to be a simple exercise to put this app in a public cloud because you might just introduce latency problems where there weren’t any before.
Now let’s talk about some of the business considerations.
SLAs
Applications in today’s customer-facing, highly competitive marketplace will likely require consistent and guaranteed performance and availability levels. If you consider that a typical public cloud provider offers 99.95% availability, you may be placing your application in jeopardy. While complete system downtime is rare, your app could be down because one or more services that your app uses are down. If the service level falls below 99.95%, what do you get, besides unhappy users, employees, or customers, and potentially lost business or data? Service credits. And of course you have to submit a claim, with documents and logs that show the downtime, to ask for the credit – you are not going to automatically receive a billing credit just because you said something was down. You will have to prove it. If your business cannot take downtime on the app you are thinking of moving to the cloud, it’s probably not a good fit. Also consider if require formal, documented monitoring of service levels for your app.
Disaster Recovery
Closely related to SLAs is disaster recovery. If there is downtime, how does it affect your business? How long can your app stay down before you have a serious business or regulatory compliance impact? How much data loss can you take? If your business is ok with the app being down for 4 hours and/or you can operate with a 4-hour data loss, then a public cloud may be suitable. If you need zero data loss and <1 hour RTO, then you will probably not want to pay what the public cloud provider wants to guarantee that. But suppose you did contract for that, and there was a failure under that agreement, what damages can your business recover? Service credits.
Data Confidentiality and Regulatory Compliance (Security)
Data confidentiality and regulatory compliance requirements will vary by industry and country. Be sure you understand exactly how the vendor meets your particular security requirements. Note that if your app processes Personally Identifiable Information (PII), or Sensitive Personal Information (SPI), as used in US privacy law, a public cloud provider will need to have ISO 27018 certification.
One last thing – are you going to write a new app? Planning to use the unique services/APIs and data stores that the cloud provider offers? Make sure you do that knowing that you could be locking yourself in forever to that vendor, and some vendors make it extremely difficult to migrate out of their environment.
