Organizations — such as engineering firms — planning to migrate all or a portion of their applications or services to a public-cloud environment will benefit from the experiences of early adopters.

Many organizations today are looking for ways to cut costs but at the same time drive competitive differentiation via greater business agility. Companies see adopting public-cloud services as a way to accomplish these goals faster. But is agility and cost savings the only reason IT organizations are adopting or considering adopting public-cloud services? The answer is simple: no.

To understand another underlying driver, consider two of the most populous countries in the world: India and China. Many of their citizens are just now getting internet access and only through the use of a mobile device. They represent an enormous untapped market opportunity for many companies. Now, consider the dramatic worldwide growth and adoption of mobile apps that have reset user expectations in terms of performance, scalability and availability.

Today’s mobile user has high expectations for anytime, anywhere access and flawless performance. With the ability for mobile applications to go “viral,” mobile application solutions need to be able to handle spikes in traffic, making scalability a must. Perhaps most important is global availability. Will the application be available and perform well for the fastest-growing segment of the internet-enabled population?

Mobile access and massive scalability tie into the two other “whys” of cloud migration – cost and agility. To build a resilient application that delivers consistently good performance across the entire globe, an organization would need to build out a worldwide data-center infrastructure or engage with multiple service providers to deliver the resources. Regardless of the hosting strategy selected, they would need the ability to automatically scale up and down to meet fluctuating demand; a situation likely to result in higher capital costs (if hosted internally) or increased support/indirect overhead (if managed by multiple service providers).

Public-cloud service providers offer all these capabilities. It typically offers high levels of customer self-service, usually as simple as selecting some parameters and clicking a button to deploy resources. Public-cloud providers also offer support for auto-scaling natively within their product set to handle spikes in demand and need. Further, these instances also can be brought down automatically once the spike in demand has passed. Finally, they offer a global services footprint, allowing organizations to deploy resources across most geographies.

The other key benefit is agility. Enterprises quickly can create and launch new services in the public-cloud without much investment in supporting infrastructure. And if a test of the new service doesn’t work, they can easily bring it down.

 

What to migrate

Consider the different characteristics of applications and different ways of classifying broad sets of workloads. The goal in that particular set of exercises is to identify which applications are prime candidates for cloud migration and which are more suited to stay onsite. One way to classify applications is either as standalone, often known as commercial off-the-shelf (COTS), or as highly-customized.

Standalone application examples include Microsoft Exchange, Sharepoint and MS Dynamics. These already have instances and images created within public-cloud environments that simply need to be selected during the initial server launch. They run automatically and you can move licenses over to these cloud-based applications. Ultimately, the largest task is that of transferring the data.

Highly-customized applications are more nuanced. These can’t simply be selected from a dropdown list of offerings provided by your public-cloud provider and need to be evaluated individually. Many of these custom applications are built in-house, often with software that uses direct API calls and hard-coded direct IP addresses rather than using variables. They also are not containerized pieces of software designed to run anywhere, all of which makes many of these applications ill-suited for the cloud. This is where third-party migration-focused tools, such as Racemi, come into the picture. They provide the ability to analyze the code and, for example, evaluate the number of direct IP address calls and how well-suited the application is for public-cloud deployment.

 

What are the steps to cloud migration?

Build versus buy: First, an organization has to decide what type of public-cloud service they want to use. Or more simply, do they deploy this application as a PaaS, SaaS or IaaS-based application? For example, does it make sense to run an exchange server in an IaaS environment or use Office 365 as the platform? Are the extra capabilities available with Exchange in a cloud environment needed or can they settle for the core capabilities provided by Office 365?

Forklift: An organization also has to decide its approach to cloud adoption/migration. Are they going to forklift applications? If so, what is the purpose? Is it to provide for colocation? If the purpose is to provide colocation and you will not be using any of the on-demand optimization abilities offered by public-cloud providers, you may find running it in a public-cloud to be not nearly as financially effective as going with a traditional colocation service provider.

Embrace: In this stage, organizations begin to design their applications and deploy them with the cloud and cloud capabilities in mind. This often is done in small steps. For example, instead of deploying 10 GB of storage at the outset for a particular application, you will deploy the application with a much smaller block of memory and design the application to add more memory as needed.

Optimization: This is where the most cloud-mature organizations sit in this lifecycle. In this stage, applications are constantly honed and developed in a DevOps fashion. Truly designed to take full advantage of the powerful capabilities public-cloud providers offer, this is where the true cost benefits begin to show themselves. Whereas organizations that first begin using public-cloud services may only use 10-15% of the capacity of the compute they are paying for, mature organizations at the optimization stage use the majority of the compute they have purchased.

 

When to migrate to the cloud

Legal requirements: The most obvious legal requirement to consider is data sovereignty. Some states within the United States are beginning to consider prohibiting the transmission of citizens’ data across state boundaries. As governments become more cloud-centric, the trend of governments protecting their citizens’ data and companies’ data will only increase. From a security perspective, a cottage industry of vulnerability testers has developed. As cloud-centric applications are developed, they can be tested by trained hackers for vulnerabilities to ensure they are as secure as possible.

Personnel: At the end of 2013, Viavi technology partner ScienceLogic did an in-depth survey of more than 1,000 IT professionals. Perhaps the most striking find was that a full 50% of respondents who had cloud initiatives planned for 2014 identified lack of skillsets/education in cloud-based technologies as one of their core challenges. While this was awhile ago and many IT professionals have “skilled-up” since then, there still is a significant gap in workforce knowledge when it comes to cloud computing technology.

While many public-cloud offerings provide similar capabilities to those IT professionals work with on a regular basis (such as firewalls), there are important differences. For example, AWS’s DNS service — Route 53 — doesn’t work the same as a traditional DNS server. It is similar, but with subtle and important differences. There also is an entire new set of terminology and best practices to be learned.

Another aspect related to personnel has to do with an age-old problem in IT: siloed departments. If your security teams, network teams, systems teams and apps teams are not working together during a cloud deployment, it will fail. All pieces of your public-cloud-based service need to work well together and, should there be an issue, your teams must collaborate to quickly find the root cause of the issue.

 

Where to migrate

Public or private: Beyond the public-cloud environment there is the private cloud option. The first aspect to consider is where to migrate your applications and workloads. When deciding whether to migrate to a public versus private cloud, organizations should consider the type of application, the level of security needed and any data sovereignty issues at play.

Type of cloud service (IaaS, PaaS, SaaS): A decision around the type of cloud service is ultimately focused on the tradeoffs between level of control and operational overhead. Infrastructure as a service (IaaS) is a standardized offering where compute, network and storage are owned by a service provider and delivered on-demand. Platform as a service (PaaS) can be thought of as an offering between IaaS and SaaS, in that it is simply a platform with all the tools and hooks developers need to quickly build applications. Finally, SaaS is exactly what its name implies: a piece of software delivered as a service to an organization. No underlying operational support is needed.

Local provider or global provider: Another decision you will inevitably have to make is whether you want a local cloud provider or a global cloud provider. Most readers will be familiar with AWS, Azure, IBM SoftLayer, Verizon Terremark Cloud and Rackspace compared with your local managed service provider. The mega-cloud vendors often will offer services that allow you to view some of the performance and availability in your public-cloud environment, but typically the data available is not kept for long and it is not granular or comprehensive enough for many production applications.

To provide granular visibility into these environments, many organizations will deploy external monitoring solutions such as the Viavi SightOps hybrid IT monitoring platform. Either way, the responsibility for ensuring service is running at peak performance and availability rests with the organization deploying the cloud-based applications. Alternatively, a managed service provider, such as Datapipe, will provide managed services for cloud-based environments often in both the mega-vendor clouds and in the managed service provider’s own cloud offering. The MSP is responsible for the performance and availability of the applications and services in this instance.

Migrating to the cloud involves careful assessments and a solid understanding of operational and business objectives. The right tools, resources, planning and personnel can simplify the process and ensure your migration to the cloud is successful.

 

Editorial note: Viavi Solutions submitted this white paper. The company delivers end-to-end visibility across physical, virtual and hybrid networks with software and hardware platforms. To learn more, visit www.viavisolutions.com.