High-Level Strategy
Once an organization has determined it is ready to move to the cloud, there are a number of context-specific decisions to be made. Having a general, guiding strategy is critical.
Laying out your goals and the issues you hope to address through your cloud migration strategy can help ensure your business and technology strategies are aligned. What do you hope to achieve?
- Are you trying to cut costs or improve time to market?
- Are you struggling to attract and retain skilled staff?
- Are you trying to improve the quality of your product or services?
- Are these goals urgent or long-term?
- Do you have compliance requirements that need to be met when moving to the cloud?
These factors are critical for determining what your cloud migration strategy should look like.
Vendor Selection
For a relatively small organization with a homogenous set of workload requirements, a single-vendor cloud strategy might be most appropriate, as there is little need to invest in multiple cloud vendors for technical redundancy or to avoid vendor lock-in.
A much larger organization, such as a global bank with diverse workloads and varying levels of technical requirements, would be more likely to pursue a multi-cloud strategy, as that would give each project team the flexibility to choose the vendor that best fits their requirements. In addition, larger organizations are more likely to have internal and external compliance requirements to fulfill, and these may require the ability to move workloads between cloud vendors at relatively short notice.
A hybrid strategy, in which both a traditional data center and cloud vendor/s are involved, may also make sense for medium to large enterprises, especially if the transition to the cloud will span over a number of years. This strategy may also be relevant if there is a need to evolve your cloud migration tactics more dynamically as you learn more about the implementation of cloud technologies within your business.
The Six R’s
Once you’ve determined your cloud migration goals and vendor strategy, the next step is deciding how to go about migrating your workloads to the cloud.
First, you’ll want to conduct an audit of your existing applications. This can give you an idea of the level and nature of work required to move to the cloud. During this audit, you can classify your applications based on the approach you want the teams responsible for them to take to with their cloud migration. AWS outlines six “common migration strategies. These can be applied across the board or each team can choose the strategy most suited to their particular set up at the time, depending on the size of the organization and the complexity involved.
1. Rehost
The first and simplest strategy is rehosting your applications (also known as “lift and shift”). It involves moving them from physical servers running in a data center to virtual servers running in the cloud. Generally, this requires no code changes and relatively few changes to processes and surrounding technologies such as networking. It may also enable your organization to develop the cloud skills and experience needed for other cloud-native practices.
2. Replatform
Also known as “lift, tinker and shift,” this approach is similar to rehosting, but takes it a step further by integrating a number of fundamental cloud services at the application level. For example, AWS IAM (Identity and Access Management) might be integrated into your application to replace or complement more traditional data center-oriented IAM systems.
3. Repurchase
Also known as “drop and shop,” this approach involves replacing an existing on-premises application with a licensed cloud-based service. This may involve changing the licensing model your business uses, lowering the cost of maintenance, and potentially allowing a quicker and easier path to upgrades.
4. Refactor/Rearchitect
A more cloud-native approach is to take your existing codebases and modify or extend them to work within more modern cloud services. One example is to containerize your application code, run configuration, and run them within a cloud-based Kubernetes service such as Amazon’s EKS or Azure’s AKS. This may involve substantial rewrites to your existing codebase to enable it to function and to increase scalability; a complete rewrite may even be required in order to use truly cloud-native tools (e.g., serverless tools like AWS Lambda or Azure Functions).
5. Retire
With the last two “passive” strategies, the workloads are not migrated to the cloud at all. Your workload audit may uncover systems that are either redundant or no longer worth maintaining. These applications can be retired.
6. Retain
The final “passive” strategy, retention, involves keeping your application running and choosing not to migrate it to the cloud for the foreseeable future. There a number of possible reasons to retain your application outside the cloud, including:
- Regulatory constraints on where applications can run or high internal compliance demands on security
- Mission-criticality of software that can make planning a move to cloud technologies earlier in the migration cycle too risky and uncertain
- No business case for the disruption caused by moving the application
- Legacy systems not supported in cloud environments
Where to Begin
In addition to deciding your overall strategy and classifying the tactical approach per workload, you will need a plan how to build your cloud infrastructure to support the movement of workloads. One approach is to let each team choose how to build its own systems in the cloud. There are, however, several disadvantages to this approach, as teams may duplicate anti-patterns of implementation and repeat each other’s mistakes or violate internal/external compliance rules.
An alternative approach is to create a type of centralized “center of excellence” or cloud infrastructure team. This team can choose to lay down the core systems on which other teams can run their workloads.
When it comes to establishing these guard rails, there are certain design elements that should be prioritized over others.
Accounts
The most basic unit of your cloud architecture is the cloud account. Using one account across your organization almost always fails to scale, as you end up bumping into account limits. It is therefore important to determine account boundaries. Will the account be used to represent a particular business unit, an individual team, or a grouping of software services? How will this operate with your finance department? Who should receive the bill? It’s important to figure this out early on, as costs can rack up quickly.
IAM
The next most basic unit of architecture is the identity and access management system. As your cloud infrastructure grows, you will need to consider the security implications of user access to the various cloud services and data, and the sooner the better. Imposing these rules retrospectively on systems that are already running can be complicated.
Networking
Migration to the cloud involves either the virtualization of your existing network or a complete redesign. The VPC (AWS) or VNet (Azure) service allows you to set up an isolated network to run a separate set of services within your account. Careful consideration needs to be given to internetwork communication between your organization’s services and basic network resources such as IP addresses.
Data Migration
While it’s easy to move to compute services to the cloud, migrating data can be a little more challenging. Major data stores can be large, complex infrastructures that require careful planning to move. This requires a deep enough understanding of how to move your data to the cloud while conforming to your organization’s performance, compliance, and operability standards.
Conclusion
Once you are clear on your high-level cloud strategy, developing a successful cloud migration strategy requires meticulous planning and consideration of every aspect of your business. Choosing the right cloud vendor strategy for you—be it a straightforward single-vendor migration, a multi-cloud vendor approach, or a hybrid strategy—is the next step. Finally, you’ll want to architect your cloud migration by first considering the key infrastructural components before beginning to onboard applications.
I hope this blog post has been interesting and valuable.
Please look out for upcoming blog posts on containers/Kubernetes and serverless services.
If you’re starting your journey to the cloud, perhaps you’d like to read my new white paper about Five Best Practices for Secure Cloud Migration.
You can read more about Check Point’s cloud security solutions here or schedule a demo with one of Check Point’s cloud security engineers here.
To understand how to design and implement secure cloud architectures, check out this white paper.
Feedback