Relieving cloud migration headaches

One look at the exponential increase in Amazon Web Services revenue, which has grown by an order of magnitude over the past five years, makes clear that we are on the cusp of a generational transformation in how IT organizations provide application infrastructure. Indeed, Gartner, which estimates that infrastructure-as-a-service revenue grew by nearly 43 percent in 2016, said organizations saved “14 percent of their budgets as an outcome of public cloud adoption," a ratio that is sure to rise in the coming years. And many government IT organizations are at the forefront of the cloud conversion due to executive-level mandates, tight IT budgets and demand for increased access to information and online services.

Given the massive installed base of IT infrastructure and billions spent every year on equipment, software and services in the public sector, shifting deployment models from on-premise to in-cloud won't happen overnight.  It will span generations of technology and applications. So government IT organizations have time to do it right and learn from rookie mistakes made by early, overly hasty adopters.

Cloud migration scenarios and the problems they create

Many cloud migration mistakes are generic and could be seen with any major IT project, but some are a function of how cloud services are used. Most migration scenarios involve data movement, such as using a cloud service for backup and disaster recovery or redeploying an enterprise application that relies on legacy, on-premise data sources. In these situations, it can be challenging to ensure the completeness, integrity and security of data migration.

When moving applications to the cloud, IT faces the choice of how to maintain access to necessary data sources. If opting for a hybrid architecture, with applications in the cloud and master data copies remaining on premise, it's easy to make mistakes setting up network connections, security policies and replication settings.

For example, there are no hard rules for choosing the data to replicate, how often and how long it's to be retained and how many replicas should be kept. Also, is it better to migrate all application layers to the cloud or just the user interface and business logic, leaving databases behind? Indeed, IT must decide whether the complexity of a hybrid design creates more trouble than dealing with the expense of fully replicating all data to the cloud.

Other migration scenarios, like replacing on-premise applications with software as a service, are simpler.  However, they create problems of application governance, feature mismatch, policy compliance and client support, particularly for organizations with a large fleet of legacy devices long overdue for upgrades. Although cloud migrations shouldn't mean modifications to security policy, they do change how that policy is implemented. As Google Senior Solution Architect Loren Hudziak pointed out, "Government and other regulated industries have no shortage of accreditation and certifications to consider, but to simply check the box of a cloud provider as meeting one of them isn't enough."

Regardless of the technical details, migrations are a major undertaking, and organizations face the pitfalls of any large project.  Skimping on planning, product research and testing, starting with overly ambitious goals and failing to manage internal politics and stakeholders are all recipes for failure.

Best practices

Government IT departments face some unique challenges when migrating to the cloud because of regulatory, security or application requirements. Mistakes can arise from inadequately vetting the provider for fit with current application requirements and user needs, but aside from the technical hurdles, don't underestimate the organizational challenges of a cloud migration.

According to a General Services Administration spokesman, "It really has to start 'at the top' with buy-in from the CIO and senior leadership." GSA, which manages the Federal Risk Authorization and Management Program and offers a range of cloud services through its various acquisition vehicles, has also learned the need to start small and not jeopardize ongoing operations.

"Trying to transform an organization overnight, for example, asking them to move production to the cloud when previously it’s been off limits, can be an intimidating milestone for a traditional CIO organization," the GSA official said. "So an effective approach creates a 'sandbox' -- contractually, technically and organizationally, to allow the knowledge to incubate and grow."

Indeed, a bimodal IT structure can be an effective way to introduce cloud services to a government agency, often in concert with other innovative IT practices such as DevOps, Agile development and continuous integration and delivery processes.

Hudziak emphasized the importance of exploiting cloud services to do things in new ways and not just "lift and shift" an existing environment. "Making the move to the cloud should be taken as an opportunity to revisit the organization’s functional and business requirements," he said.  "CIOs should ask: have we been doing things the way we have because the technology has historically forced us into that pattern?"

GSA officials pointed to an example of the incremental approach to cloud migrations at NASA, which funded its first cloud contract with just $25,000, then doubled it as IT managers learned and grew confident in the technology. NASA realized that "a massive 'broker' contract was inefficient and instead separated out the roles of consumption metering and billing from consulting or the assistance with integration and delivery," the spokesman said. "This led to increased transparency in tracking spending and contracting efficiency, as the cloud accounts and operational services did not have to be transitioned concurrently with support contracts."

FedRAMP is no panacea

For agencies following the cloud-first policy and the Federal Cloud Computing Initiative, FedRAMP is supposed to provide a standard, centralized system to streamline the assessment, authorization and procurement of cloud services; however, it doesn't obviate the need for due diligence including a service-level agreement. For example, a September 2016 audit by the Government Publishing Office's Inspector General found that although GPO's cloud service provider was FedRAMP-approved, important problems persisted:

• GPO policy did not include cloud computing and/or hosted service definitions, principles, rules and guidelines.
• Personnel did not follow configuration management policy during the transition to the Amazon Web Services.
• Contract language did not address hosted services.

"Lack of appropriate contract language for data ownership established an increased risk," the IG said. "Such a risk could have allowed the cloud provider with unnecessary access to Federal data." The audit also noted that GPO did not incorporate new AWS instances into its existing configuration management database and procedures, an oversight that illustrates an important point: Every cloud migration must include process and admin integration and not treat the cloud as a one-off environment.

Recommendations

When planning cloud migrations, government IT organizations should avoid reinventing the wheel. Exploiting the expertise of cloud pioneers and the other resources available can dramatically simplify migration planning. For federal agencies especially, there are now expertise and communities of interest around FedRAMP, the Trusted Internet Connection efforts and the Data Center Optimization Initiative.

Agencies should also draw upon existing standards and guidelines. As the GPO IG's audit points out, the Federal CIO and Chief Acquisition Officers' councils published best practices for acquiring IT services. Creating Effective Cloud Computing Contracts for the Federal Government: Best Practices for Acquiring IT as a Service includes guidelines for selecting cloud services, writing contracts and SLAs, delineation of responsibilities between providers and agencies and standards for security, privacy, e-discovery and Freedom of Information Act requests.

However, agencies at all levels of government should take care not to interpret government standards too liberally and extend them into situations and technologies they couldn't anticipate.

"The government IT landscape is made up of policies and accreditations that keep it locked in the past," Hudziak said. "Many of these standards were created years ago when things were very different -- not just the technology, but entire development processes and languages, as well as how we leverage modern solutions like virtual machines and containerization.

Standards and frameworks like FedRAMP are a step in the right direction, he said. "But for government to move to the cloud, the notion of innovation needs to be holistic, and regulations need to keep up with the technology developments."

And again, leave the big bang to physics; starting too large is a common mistake. Cloud migration is a journey that should start with small, relatively low-risk applications and data, adding more complex systems as agencies gain experience and refine governance processes

Other migration planning tips include:

Don't underestimate migration costs. As a report on the Federal Cloud Computing Initiative from the Congressional Research Service points out, "One commonly cited cost is migration. If a user needs to move resources such as data from its own local facilities to those of the cloud provider, there will be a cost for such migration. That cost will depend on several factors, such as the size of the resources being moved, the method by which they are moved and whether the resources will need to be modified. Such costs are also a consideration with respect to a potential move from one cloud provider to another."

Avoid sticker shock resulting from naive underestimates of costs and resource usage. Have a complete cost model that accurately reflects service usage and that can be used to lower spending by opportunistically using both reserve (for steady-state workloads) and spot (for batch or asynchronous workloads that aren't time critical) instance discounts.

Don't get caught with inadequate staffing for migration projects. Also, plan for training in cloud technologies; don't assume staff can quickly transfer existing skills and expertise to the cloud because their roles will often change from operations and administration to system integration and capacity management.

Think about automation and orchestration up front, before doing the first application migrations. Tools like AWS CloudFormation and Opsware, Azure Templates or third-party software like Ansible, Chef, Puppet or Salt can streamline migration tasks, maintain consistency and reduce ongoing operations overhead.

Define cloud-specific management processes and associated tools. Have staff assigned to actively monitor cloud deployments, resource usage and application performance, and don't put cloud deployments on autopilot.

Use either multiple cloud services or independent regions at the same provider when planning for disaster recover or continuity of operations. You never want a primary and backup site taken out by the same infrastructure failure.