Key Cloud Migration Decisions Most legacy applications have implicit assumptions about operating systems, hardware, geography, latency, throughput, scalability, governance, access rights, monitoring and other aspects that must be carefully addressed before deploying to the public cloud. by Alex Veytsel, Steve Lerner and Tony Greenberg as published by Microsoft TechNet When faced with the many opportunities afforded by a cloud infrastructure—on-demand scale, potential cost reductions, elimination of complex maintenance processes, etc.—the decision to build a new application in a public cloud is often a no-brainer, especially for the buyer with the mindset of prioritizing agility and speed-to-market over customization and the perceived security/reliability advantages of internal infrastructure. Migrating an existing application, however, is a different beast. Most legacy applications have implicit assumptions about operating systems, hardware, geography, latency, throughput, scalability, governance, access rights, monitoring and other aspects that must be carefully addressed before deploying to the public cloud. Some of these have been addressed through the experiences of adapting these applications to function correctly in a private cloud, but the provisioning of shared resources in a public cloud remains a more difficult leap.
Migration DecisionsWhen deciding whether or not to migrate existing functionality to the cloud, the decision criteria are more complex than for new builds. Key questions in “cloud planning” include:
- Should I migrate to a public cloud (and if so, which one), or a private cloud within my existing data center?
- How can I tell if my application can be moved to the public cloud at all? Should I engage in an application remediation strategy to accommodate such a move or rebuild from scratch?
- Should I hybridize my application to move some part of functionality to the public cloud while keeping other components on an internal private cloud?
- When should I consider public cloud SaaS solutions for my end-users, and how should I approach the build? If so, is portability across multiple heterogeneous clouds important for my application and how can it be achieved?
Public Cloud vs. Private CloudMany of the advantages of the public cloud can be achieved with a private cloud capability as well — by deploying similar mechanisms used in a public cloud, but within the existing data center and implementing an on-demand, API-driven orchestration layer. Key criteria that would lead buyers to choose this approach instead of public cloud include:
- Predictable Demand — if you know what amount of compute capacity and storage you will need a year from now, you can provision virtual or even dedicated servers to meet the demand. If every month brings new surprises, private cloud deployments can prevent overprovisioning waste or under-provisioning congestion, not to mention the stress of hitting tight deployment windows.
- Consistent Demand — for services that have the same amount of volume each hour, day of the week, and each month, a private cloud deployment may make sense. The same goes for those whose divisions have that peaks are asynchronous enough to benefit from optimizing utilization among disparate user groups. When considering projects in industries like retail (with a Black Friday spike and a broader December plateau) or online games, where winter weekends spike demand, the public cloud becomes more attractive.
- Tight Coupling Between Apps and Devices — if an application is tightly integrated with other applications or hardware (such as network attached storage devices) that you are not yet ready to move to the cloud, it may encounter latency issues or other problems when moved by itself. A private cloud deployment will help mitigate this issue.
- Specific Network Access — if applications are required to access specific networks for connection 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 mix of networks.
How to Diagnose Moving DifficultyIn our experience, the customers that could benefit the most from moving to the public cloud were often the ones least able to do it due to core assumptions in the design of their applications. Some of the ones we have seen in the past include:
- Hard-coded Geography and Network Topology — applications may have implicit assumptions as to where they are on the network and in the world. Hard-coded IP addresses are the easiest example, but other decisions may assume geographic or network hop proximity to resources that 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 — many cloud storage providers shy away from high performance database storage altogether because of an inability to hit IOPS targets. Even services ostensibly designed to support databases don’t always offer the consistent high throughput of dedicated hardware. Applications built on high-performance throughput assumptions may not be able to adapt to the more variable – if not outright lower – performance of their cloud instance.
Hybridizing AppsAnother interim step is “hybridizing” an application to run some instances or functionality in the public cloud while retaining the core on an internal private cloud. Key decision criteria that would make this approach desirable include:
- Limitations in Existing Infrastructure — a hybrid approach is often useful 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 or in Europe while retaining centralization / 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 when your app must be available 24x7x365, a light version of an app hosted in a public cloud that can hold down the fort during datacenter outages or maintenance can be a life saver at a fraction of the cost of extra redundancy.
- Event-Based Demand Spikes — if your spike demand (say due to a promotion or media coverage) is different from your regular demand profile, it may be possible to build functionality just for that extraordinary bulge in the public cloud, trading in some performance for extra flexibility. The interface or functionality or response time might be a bit off, but your one-time spike users will never notice.
The Final Step: Migrating Apps to SaaSThe last key migration question is when to make a more wholesale change from a client application to software as a service (SaaS), and if so, how much to rely on pre-built functionality of a PaaS or SaaS supplier rather than developing in house. Rather than a classic migration dilemma, this is more of an architectural decision, and is made at a more strategic level 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 possible conflicts this engenders. 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 often runs into problems absent client-side workarounds, while local apps work better.
- Can I Support Constant Releases? — a major advantage of SaaS approaches is the constant addition of incremental functionality. If developing significant functionality in-house but 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 with relatively little pain. PaaS and SaaS platforms are much easier to get started on but may be much harder to leave. If Microsoft or salesforce.com is a strategic supplier that you trust implicitly, the tradeoff is worth it. If you envision changing platforms down the road, a more generic approach may be better.