Moving to the cloud is a big undertaking, and the process looks different for every company. Although the transition is a significant lift, it provides an opportunity to rethink — and improve — your architecture and workflows by eliminating underutilized resources, identifying vulnerabilities, and automating manual processes.
Our eBook, Cloud Bound: Preparing for Migration, highlights key considerations to take into account as you build your cloud migration plan. The first step is to answer three crucial questions:
- What do you have in your current IT architecture?
- How will your existing assets be impacted by migration?
- Which of those assets can be automated?
You’ll probably find that the answers to those questions are not as straightforward as you’d like, but thinking them through will have a significant payoff. Let’s take a closer look at each of these three questions and their implications for cloud migration.
What do you have?
Building a migration plan is exponentially easier if you have a clear picture of your IT estate. Chances are, you have an asset inventory in some form, but these often rely on manual updates and are woefully incomplete or out of date.
While it’s possible to take a “lift and shift” approach to cloud migration, the transition presents an opportunity to dig into what you have and develop a system to manage it. “Zombie architecture” in the form of hidden services, forgotten devices, abandoned networks, and unmapped containers can represent unnecessary cost and pose security and compliance threats.
In the cloud, this problem is exacerbated. The ephemeral nature of resources like containers is both critical to agile development and potentially problematic down the line. Developers create a container in Docker or deploy a virtual private server (VPS) for a specific purpose. Without a system to detect unused assets and decommission them when they are no longer needed, the costs associated with them will quickly pile up.
Automated discovery tools, such as simple network scanners like nmap or intelligent fact-finders like Puppet Discovery, combat this issue by sifting through networks and hosts to maintain a dynamic inventory. A comprehensive view of device and service status, configuration, and usage will become even more valuable as your architecture expands and evolves.
Knowing what’s in your infrastructure now is critical to building the best practices that will ensure any and all future assets are tracked and managed in real time.
How will your existing assets be impacted by migration?
A hybrid-cloud architecture crosses between private data centers and the cloud, introducing new challenges to application architecture. Once you know what you have — and especially which surprise services and containers you need to deal with — you can design a new application pattern to fit your needs.
Cloud migration requires changes to application architecture. Dev teams will take advantage of new cloud features and paradigms, and there are new tools and opportunities to deal with scaling, redundancy, and automated recovery. These can all impact the migration of architecture and system components.
Each component’s final destination will also be impacted by security considerations. Components with the strictest security requirements might need to stay on-prem, while larger components, such as databases, might need to be divided according to the level of security required.
Industries governed by stricter security and compliance regulations, such as health care and financial services, face additional data-handling requirements that affect both the storage and processing components of IT infrastructure. Before signing off on a cloud migration plan, it’s critical to ensure that the processes you put in place don’t expose sensitive data to new vulnerabilities. Consider a secret store like HashiCorp Vault, CyberArk Conjur and AIM, Azure Key Vault, and AWS Secrets Manager.
Which assets can be automated?
If your on-prem configuration utilizes clusters of containers or virtual hosts, you’re probably already utilizing some level of automation. But that automation likely originated out of necessity. Success in the cloud requires a shift to an automation-first mindset.
As you build out your migration plan, the need for automation will become apparent. Spreading assets across multiple data centers and architectures makes manual deployment and maintenance all but impossible. Applications need to account for different cloud service APIs and configuration strategies.
Automation is one of the most powerful tools for realizing value in a cloud deployment. Cloud providers have tools that auto-scale applications based on any number of criteria, from geography to load. Application deployment and replication can also be automated. This can be a hidden trap, however, because each cloud provider will have its own automation tools, leaving you to manually configure and scale services across data centers.
Planning for multiple clouds
About 75 percent of heavy cloud users provision resources across multiple cloud service providers. Multiple clouds provide a number of benefits that are crucial to the success of certain applications, including service redundancy to mitigate downtime or service interruption, cost control, and flexibility in providing the right menu of services.
While you may not be planning to go multi-cloud right away, it’s wise to plan for that eventuality to avoid the risk of vendor lock-in. Different cloud providers offer different interfaces and APIs for managing services, which can be a big barrier to successful migration. Choosing inventory and automation tools that work across multiple providers will set you up for future success.
For more guidance and best practices on cloud migration and management, check out these resources: