You’re traveling through another dimension, a dimension not only of sight and sound but of mind. A journey into a wondrous land whose boundaries are that of programmatic bits and bytes. That’s the signpost up ahead – your next stop, the Cloud!
As customer begin to embrace digital transformation and start to implement their previously adjudicated ‘Cloud First’ strategy the most common and important question that arises is which application should we move to the Cloud? This decision is usually not made on a single factor alone. The choice of which applications to move (and not move) to the cloud should be based on a thorough analysis of your IT landscape. Below are a set of categories and questions that will help guide your decision on application migration from on-prem into the cloud.
Enterprises need to begin their journey to the cloud by deciding how to get their application from where it lives today to where it needs to be tomorrow. From this perspective there is one key question to ask: How will you migrate this application into a cloud?
Rehosting – Lift-n-Shift
Every IT organization has a set of large-scale legacy application that must have continuity maintained but cannot incur the cost, time or effort of refactoring. Rehosting is essentially a forklift approach to migrating applications to the cloud, essentially moving them without any modification. This is an efficient non-resource-intensive migration process. Often however, lift-n-shift migrations don’t benefit from cloud-native features like elasticity. And while they may be more cost-effective to run in the cloud than on-prem, it could be even cheaper if you were to replatform or refactor.
Replatforming – Lift-Adjust-n-Shift
Replatforming can be considered a lite weight or pseudo-refactoring. Instead of rearchitecting the software entirely it may be possible to optimize or tweaks basic elements of your application to operate successfully in the cloud. While this path is more glacial than rehosting, the approach offers a middle ground between rehosting and refactoring, allowing workloads to take advantage of native cloud functionality and cost optimization, without the huge resource commitment you find with refactoring.
Refactoring – Redeveloping an application
Rearchitecting or redeveloping an application is typically driven by business need to add features, scalability, or performance that would otherwise be difficult to achieve in its current state. This approach is the most time-consuming and resource-intensive but offers the inherent benefits of being able to leverage native-cloud functionality and maximizing operational cost efficiency in the cloud.
Repurchasing – Move to a different product
Most enterprise software vendors have or are in the process of creating cloud-based versions of their application. If it makes business sense, this is often a suitable way of getting your application into the cloud. If your current vendor does not offer a cloud-native solution their marketplace is wrought with competitors who likely do have an application that fits your needs, already designed to operate in the cloud of your choice.
Retiring – Getting rid of the application altogether
In the IT landscape there are a lot of legacy products that might be able to be replaced or remove without replacement. Once you’ve discovered everything in your environment it becomes a worthwhile exercise to determine if an application is actually needed, and if not, reitre it.
Retaining – Keeping the application in its current home
You should only migrate what makes sense from both a business and technical perspective. If the cost is too high, compliance is too limited, or the complexity just makes things impossible in many cases it may make sense to NOT migrate an application into a cloud. An alternative strategy would be to employ a hybrid cloud model where some of the application (or data) reside on prem but still are able to leverage the computer and elastics powers of the cloud.
When considering application migration (not just to the cloud) organizations must review each applications architecture and determine viability for its new platform. Reviewing the application architecture ensures that potential migration of these applications to the cloud is or is not the right decision. Let’s consider two common architectural questions.
Does your application require a specific operating system?
You must consider the obvious question, does the cloud provider you are contracting with support that OS? While you can often upload or configure whatever you want, have some level of built-in support is important for a business-critical application. If a problem occurs, can you get assistance? What is the time-to-resolution from the point of view of the cloud provider?
Does the application have hardware or infrastructure requirements?
When it comes to public cloud providers we generally don’t have any clue about the underlying hardware. Does the use of unknown or commodity hardware pose any risk? Are there external hardware dependencies that must be in place for things to work correctly (E.G. a Load Balancer)? Does the application have external software dependencies and if so, can this application work in the cloud without migrating all the dependencies? (E.G. NIS, AD, etc)
For operating system dependencies there is an obvious go/no-go here. If a Cloud Vendor doesn’t support your required OS then this is rate limiting. The same is true if there are hardware of infrastructure dependencies that cannot by properly setup or configured in a cloud setting. However, a solution to these problems is often a Hybrid Cloud scenario where the dependencies can be “on-prem” and the application can still function in the cloud.
One of the biggest areas of consideration in this journey to the cloud is around the applications themselves. When it comes to specificity versus universality software developers run the gambit from writing code that is highly compatible (think open-source Linux projects) to extremely specific in its requirements (think SAP). Thus, it is very important to consider the needs of each individual application from an internal operability perspective. Let’s consider these five questions.
Does the application observe consistent or fluctuating CPU usage?
Having applications that constantly run versus ones that spin up and spin down upon completion of the job can significantly change the cost analysis. For example, in AWS On-Demand instances, you pay for compute capacity by per hour or per second depending on which instances you run. Thus, the architecture of your application (including the container, VM or other higher-tier controller software) is critical to the cost-effectiveness of using a cloud model.
Does your application have latency and throughput requirements?
Public clouds can only guarantee certain levels of IOPS and latency requirements. The biggest culprit is usually network bandwidth. Bandwidth utilization increases and network links often become oversaturated, which can degrade overall application performance. Furthermore, network architectures, where the traffic is routed to a common gateway in the data center, cloud-based applications end up traveling a greater distance to reach users when compared to on-prem.
Does your application have specific compute requirements?
Public clouds are an ideal place to garner more compute resources without CapEx expenditure. But, applications that require vertical scaling may not be suited for all clouds. Vertical scaling means that you scale by adding more power (CPU, RAM) to an existing machine, which ultimately can cost significantly more money.
Does your application have supportability requirements?
If your application needs ongoing support, does the cloud provider meet the basic listed requirements for supportability? If so, can your (or the vendors) support team gather the necessary information and do troubleshooting when issues arise?
Are there any software licensing issues that prevent or limit cloud usage?
Some of your contracts may not address cloud computing specifically because the licensing model may predate cloud. While others offer cloud-specific software licenses which can introduce its own complications. It behooves of each IT organization to thoroughly examine the licensing models of all core-software before undertaking a cloud migration.
Business and Industry Criteria
The last and arguably most important areas of consideration around cloud migration are that of the business. Thus far we have discussed technology but that is all for not if basic business requirements cannot be met. This will include area such as business continuity, compliance and security – all of which we will discuss.
Does your application have specific backup, HA or business continuity requirements?
Clouds are fully featured when it comes to backup to be sure your RTO’s and RPO’s can be met. However, can those requirements be met within the defined cost structure? Storage space is cheap but having alternative HA sites and higher end business continuity plans could be more expensive in the long run – it just depends on your business requirements.
Does your application (or business) have compliance specifications or requirements?
Not all cloud technologies are suitable for all compliance issues. HIPAA, SOX, GPRD or any other regulation can be met in the Cloud but must be considered and evaluated beforehand. The first area of importance is to be fully aware of the type of cloud services that are being use. Once you have done that, you can look at the data that will be migrated. The second area of importance to look at, once you know which data you are going to put on the cloud is to look at the contracts with your cloud provider. If it is an internal cloud, are you going to have internal SLAs and internal compliance checklists? If it’s external, you have to clearly identify with the provider what type of data should reside on their cloud services, how they’re going to protect it, how they’re going to back it up and how you may reserve the right to audit that process.
Does your application (or business) have stringent security requirements?
While at a high level, cloud environments experience the same threats as on-prem data centers, they also offer a unique set of threats and risks. Those include:
- Consumers have reduced visibility and control
- Immediate self-service functionality makes unauthorized use easier
- Public API’s offer an attractive target to hackers
- Multi-tenancy increases the chance of a surface attack
- Data deletion is unrealistic
- Credentials can more easily be stolen
- Cloud vendors have access to your data
By moving into a public cloud there will be some compromises on security. Taking a hard look at your application and business requirements from this perspective is a crucial step in determining cloud-hosting viability.
Keep in mind that these are common, but still general guidelines, and your decision about moving applications to the cloud should be based on your own situation. However, if you apply all these questions to your application and IT landscape you will be well-positioned to know what should and should not be migrated. I hope that your move to the cloud is expedient, efficient and effective.