Considering migration to the cloud? Answer five key questions first

Editor's note: In this Q&A, Todd DeCapua of Shunra Software Ltd. and Senior Site Editor Anne Stuart discuss five key questions that every business should answer to minimize risk and maximize benefits in a cloud migration. DeCapua is vice president of channel operations for Shunra, which specializes in network virtualization for software testing. This Q&A has been edited for length, clarity and editorial style.

Todd DeCapua,
Shunra Software

You've said that, in your experience, very few enterprises feel that  has paid full dividends to their businesses. Why is that?

Todd DeCapua: Many of them have resulted in failure. The cost of a cloud migration is not cheap, but the promise is that the company will save over the long haul. Unfortunately, as we will discuss, many rush into the process without answering many key questions. Answering these questions will give organizations a better understanding on whether a migration is correct for them.

You also mentioned that many pitfalls and roadblocks easily offset the value and gains expected from migration to the cloud. Could you highlight some of the main ones?

DeCapua: The perceived benefits of migration to the cloud include reduced capital investment and operational expense, a service-level agreement (SLA) that includes guaranteed uptime and that it will scale with your business and that you can migrate with a simple "push of a button."

In reality, however, companies regularly find that there is always a catch to these benefits. Maybe it is the fact that the expense was more than expected or that it is not scalable given limitations and configuration issues. And, often, companies find out that their SLA doesn't have 100% uptime guaranteed, just 99%. That 1% downtime is what keeps CIOs awake at night, costs people their jobs and costs companies significant revenue, reputation and customers.

You've also mentioned five questions that you believe businesses must answer if they want to reduce risk and ensure that they receive maximum value from migration to the cloud. Can you walk us through them one by one?

DeCapua: Sure. It would be my pleasure.

Great. Here's your Question 1: "How will migrating to the cloud affect our applications -- and our business?" What should companies consider in answering this question?

DeCapua: Cloud providers trumpet scalability and elasticity benefits as the primary reasons to migrate your applications. And to varying degrees, their assessments are correct.

However, careful planning is required. Architects need to proactively consider whether applications can scale and be elastic and what development resources are required to realize these goals. Otherwise, they won't realize some of the cloud's benefits, such as reduced capital investment and operational expense, reduced headcount of monitoring, maintenance and support and full scalability.

Have a plan for what should happen when you deploy an application, it experiences issues, and you have to roll it back. If you can't roll it back, you are in a worse position than if you had never deployed.

Todd DeCapua,
Shunra Software

When designing an application, consider your definition of scalability and elasticity. For some, those terms mean spinning up additional clusters of front-end Web servers. For database teams, it means not corrupting data that could live in 40 or so cloud clusters. Understanding the constraints of the hosted infrastructure, and how it will communicate with an on-premises infrastructure, is a critical consideration during the planning phase of cloud application development or migration.

Infrastructure constraints extend beyond hardware availability. Network conditions and the three 'divides' of a cloud environment -- which I'll describe in a moment -- have a significant effect on application performance and end-user experience. The hosted application must be able to scale across each divide: from end user to cloud host, between tiers within the cloud host, and finally from host to distributed services.

Each of those divides may introduce different network conditions that affect application function and performance. For example, say you are purchasing an item online. The first divide -- end user to cloud host -- is from the user's device to the local cloud-hosting facility. The second, which is between the tiers in the cloud host, occurs each time a request comes in and is sent; it goes between the Web servers, the middle or translation servers and the data servers. The last divide -- cloud host to distributed services -- happens when it is required for the transaction, perhaps for a credit check or shipping address verification.

As you can imagine, for every customer experience, this exchange between these three divides contains unique conditions depending on the varying network conditions over which that transaction occurred.

You can quickly see how varying or degraded network conditions, especially over mobile networks, the level of complexity of a composite application and being exposed to the three divides of cloud easily can -- and does -- cause catastrophic results for all stakeholders: business, IT and customers. Planning for that impact in advance of development and deployment is essential for maximizing the potential benefits of the cloud to your business.

OK, let's talk about Question 2: "Are we refactoring our applications to perform in a cloud environment?" Why is that important?

DeCapua: It is generally easier to architect and build an application for the cloud from the ground up. But today, more often than not, existing applications are slated for migration to the cloud.

Moving to the cloud introduces new production-environment considerations and conditions as part of the migration process. When you combine that with the complexity of composite applications and their underlying infrastructures, you're likely to find the need to redevelop and/or 'refactor' existing code because of the differences in the underlying architecture of cloud-hosted applications and systems.

By 'refactor,' I mean restructuring or writing a body of code or architecture, resulting in a change in internal structure or design, yet the behavior remains the same. Code refactoring is often done to optimize the performance of an application and needs to be considered when changing the deployment infrastructure architecture.

To properly refactor, you need to discover the cloud architecture and conditions across the cloud divides on which you will deploy. By virtualizing the cloud environment, you can accurately test and optimize the refactored code. The virtualized environment must account for the network conditions, expected user load and third-party services that will affect application availability and resiliency.

That brings us to Question 3: "What are we doing to test cloud deployments differently than with traditional two- or three-tier applications and associated testing methodologies?" Please talk about why that matters.

DeCapua: From the earliest developer desktop compile to the production deployment, testing is what ensures that the application or system meets business and user expectations for functionality and performance. Virtualizing the users, networks and services as they will occur in the cloud environment provides key insights into how the system will function and perform, where the security vulnerabilities are, what the impact of an increased user base on mobile devices will be and when the system fails, how it will fail.

These insights, in turn, enable you to test and optimize your applications or systems prior to deployment under the same conditions they will face in production.

 Because you don't always have control over where your application will be hosted in a cloud environment, you should be sure to consider how your application will perform when placed in different locations within the cloud farm. Some of the most common cloud hosts have 10,000-plus miles of network cabling at one location. You need to know how these network conditions -- latency, bandwidth, packet loss and jitter -- and dynamic allocation of computing resources, anywhere in the cloud host, for any period of time, will affect the system's performance.

DevOps teams should also consider cloud-burst testing against the cloud host, either in a pre-production or a 'live-live' environment, in which the production environment is blocked from public access. The burst test will confirm that you have the scalability needed for peak conditions, and the cloud host has configured the environment as specified. That will tell you right away whether the application will perform well under load or whether you will need to roll it back and retest or reconfigure.

In Question 4, you say that businesses should ask themselves "How will our deployment and management strategies change with the cloud?" What's the biggest factor they should consider?

DeCapua: When you have complete control over the deployment of an application, you have carte blanche to deploy, test, back out, re-deploy, re-rest, etc. However, once you sign on with a cloud provider, you give up much of that control and flexibility. Even if you still have those abilities, the cost is often more and you are reliant on the timetable of others for critical applications and data that might need to go live immediately.

The biggest single factor to consider is the potential for failure. None of us wants to consider that possibility. But it happens. You need to have a plan for what should happen when you deploy an application, it experiences issues, and you have to roll it back. If you can't roll it back, you are in a worse position than if you had never deployed. Users will blame you -- not the cloud provider -- for any downtime.

And, finally, here's Question 5: "Now that we've migrated to the cloud, do we still need to monitor things, or is that someone else's job now?"

DeCapua: Many successful organizations employ teams -- often made up of performance engineers, capacity planners and disaster recovery teams -- in a never-ending feedback loop to continuously improve end-user experience, establish accountability for development and testing, and hone monitoring metrics. But once you've undergone migration to the cloud, you may well wonder: 'Is that still my responsibility? Or can I trust the cloud provider to handle it?'

The answer: Just because you had a successful deployment doesn't mean the process is over.

If the performance of the application or system affects your business, you shouldn't give up control over monitoring. The cloud provider is your partner, but if something gets overlooked, it's your customers or clients who will complain and your business that will suffer.

The bottom line in all this: When you're evaluating the success of a cloud migration, finding the right balance between reducing risk and maximizing value creates significant ambiguity. But correctly developing, testing and evaluating the network conditions of the cloud environment can tilt the equation toward success. If you can confidently answer these five questions, you should be able to confidently migrate your applications to the cloud.