The Keys to Making Smart Decisions About Migrating Applications to the Cloud

Migrating Applications to the Cloud

You want to migrate legacy applications to the cloud, right?

To meet the needs of your enterprise, it’s become an imperative. It might sound simple, but you’ve discovered it’s not.

Let’s take a look at the keys you need to consider before you pull the trigger.

 

If only application migration was as simple as application creation

The benefits of running apps on a cloud infrastructure have become fairly familiar:

  • Scalability on demand
  • Cost containment
  • Elimination of complex maintenance processes

The decision to build a new application in a public cloud tends to be a no-brainer. You’ll realize greater agility and accelerate time-to-market.

Migrating an existing application is a different beast. With legacy applications, you’ll have a number of specific requirements:

  • Operating systems
  • Hardware
  • Geography
  • Latency
  • Throughput
  • Scalability
  • Governance
  • Access rights
  • Monitoring requirements

These, and other aspects, must all be considered before cloud deployment.

6 key questions to examine before migration

When planning to migrate applications to the cloud, six pressing questions emerge:

  1. Should you migrate to a public cloud or a private cloud within your existing data center?
  2. Can the application be moved to the public cloud?
  3. Should you engage in an application remediation strategy or rebuild from scratch?
  4. Should you “hybridize” the application to move only some functionality to the public cloud?
  5. Are public cloud SaaS solutions feasible for end users?
  6. Is portability across multiple heterogeneous clouds important?

If you have a large application portfolio, the evaluation process gets increasingly complex. Often, you’ll need to establish scoring systems to evaluate which applications are or are not suited for the cloud. Then, a number of thorny issues are likely to arise because you’ll be faced with:

  • Governance
  • Regulatory constraints
  • Security restrictions
  • Access rights
  • SLA commitments

A private cloud is often the answer

A private cloud can often deliver many of the same advantages of the public cloud.

You may be able to deploy similar mechanisms within the existing data center and implement an on-demand, API-driven orchestration layer.

The private cloud offers a viable approach when:

  • Demand is predictable. If you know the compute capacity and storage you’ll need a year from now, you can provision virtual or dedicated servers to meet the demand. When capacity is unpredictable, private cloud deployments can prevent the waste that comes from over-provisioning or the congestion woes of under-provisioning.
  • Demand is consistent. A private cloud deployment makes sense for services that have the same amount of volume every hour, day, and month. In industries, such as retail and online gaming, where demand spikes at various times the public cloud is the smarter option.
  • Apps and devices are tightly coupled. If an application is tightly integrated with other applications or hardware (such as network attached storage devices), it may encounter latency issues and other problems when migrated to a public cloud. Private cloud deployment will help mitigate these issues.
  • Network access is specific. If applications must access specific networks to connect to clients, offices, or other network dependent entities, private cloud may be the only choice (due to the ability to deploy hardware on a specific network or combination of networks).

When to stay away from the public cloud

The needs of your applications often make the public cloud a bad fit. The following problems may emerge due to the design of the applications.

Hard-coded geography and network topology. Applications may have implicit assumptions as to where they are on the network and in the world. The best examples are hard-coded IP addresses, but other decisions may assume geographic or network hop proximity to resources the cloud instance will no longer have nearby.

Tight/undocumented latency needs. In designing data center deployments, we have worked with buyers whose SAN needed to be no further than 20 feet away from their servers because their applications would time out otherwise. In a cloud environment, even if your storage is in the same location (not always guaranteed), it may be a mile away in the same data center campus.

Extreme throughput. Applications requiring high throughput may not be able to adapt to the variable performance of cloud service. Many cloud storage providers shy away from high performance database storage because they’re unable to achieve IOPS targets. Even services ostensibly designed to support databases don’t always offer consistently high throughput.

If you face any of these challenges, now is not the time to migrate applications to the public cloud.

The hybrid approach may work best

Another approach, which you might think of as an interim step, is “hybridizing” an application to run some instances in the public cloud while retaining its core on an internal private cloud. Criteria that would make this approach desirable include:

Limitations in existing infrastructure. A hybrid approach might allow you to overcome specific gaps in the original design. For example, if a company has a single data center on the West Coast of the U.S., a public cloud extension or instance can better serve customers on the East Coast while retaining synchronization to the master database.

Low cost added availability. A Tier IV data center can cost up to 50% more than a Tier III data center while offering only 1.2 more hours of uptime annually. So if your app must be available 24x7x365, a light version of an app hosted in a public cloud can hold down the fort during datacenter outages or maintenance and be a lifesaver at a fraction of the cost of extra redundancy.

Event-based demand spikes. If application demand spikes (e.g., due to a promotion or media coverage), it may be possible to build functionality in the public cloud to accommodate the increased demand. Keep in mind, however, the extra flexibility will come with a performance compromise.

The final step: migrating apps to SaaS

The question to ponder is when to make a wholesale change from a client application to software as a service (SaaS). If you decide to, you’ll then examine how much to rely on pre-built functionality of a PaaS or SaaS supplier, rather than in-house development.

The SaaS question is more of an architectural decision than a migration dilemma. It’s made at a strategic level and should be based on the following questions:

What’s less predictable, configuration or access?

The bane of the desktop application is the plurality of desktop hardware and software configurations and the inherent conflicts. If the desktop is not locked down, client-side apps are harder to build and support than browser-based apps. Conversely, if access to the Internet is more inconsistent, then SaaS presents serious issues.

Can you support constant releases?

A major advantage of SaaS is the constant addition of incremental functionality. If you’re developing functionality in-house without tight QA controls, this advantage can turn into a liability quickly as bugs are introduced along with new features on a weekly or monthly basis. The discipline of the development process becomes key.

How much lock-in is acceptable?

IaaS approaches, while not perfectly interchangeable, can be switched relatively painlessly. PaaS and SaaS platforms are much easier to start on, but may be harder to leave. If Microsoft or Salesforce is a strategic supplier you trust implicitly, the tradeoff is worth it. If you envision changing platforms down the road, a more generic approach may be better.

Migrating Applications to the Cloud is bound to become easier

With a stigma of risk still hovering over the public cloud industry, you’re likely to have fears. When migrating existing applications, your risks expand.

As public cloud technology matures, many of the issues will evaporate. What will remain is a tradeoff between easy and rapid scale and customization and control. And as connectivity becomes more ubiquitous and development discipline reduces the need for fine-tuning hardware, all three flavors of public cloud, IaaS, PaaS, and SaaS, will become increasingly viable targets, not just for new apps, but for migration of legacy functionality.

What issues have you run into with application migrations? What questions do you still have?

RampRate has quick spin solutions for quantifying your cost of compute for candidate workloads and finding the best fit cloud deployment model and suppliers.  To learn more about our Cloud HyperSourcing solution, click here.

Any questions? Don't hesitate to ask us.

Leave a Reply