Cloud Migration Strategies for Enterprises
Cloud Migration Strategies for Enterprises
This advice will help frame your enterprise's cloud migration strategies and architecture in a developer-centric way with thoughts on some tooling and services out there.
Join the DZone community and get the full member experience.Join For Free
Insight into the right steps to take for migrating workloads to public cloud and successfully reducing cost as a result. Read the Guide.
It's a big challenge for enterprises to plan and execute a Cloud Migration Strategy. There is a valid concern of getting stuck with a cloud provider and making switching to another provider difficult . for example, but if your current provider jacks up prices or if you do not like their services.
Infrastructure orchestration tools like Terraform can help. Terraform is an open source tool that serves as the orchestration layer for your application infrastructure in the cloud. As a bonus, you will also be able to version control your infrastructure, and it will make it easier for you to switch providers if you ever need to.
Other valid concerns in cloud migration are security, control, audit, separation of duties/roles, etc. Most companies are doing some POCs and a few teams are directly migrating their applications to the cloud and calling it an early success.
This model is not scalable.
Very soon, these teams will realize the pain of sharing VPCs and other resources with hundreds of other applications, not to mention the challenges of supporting multiple environments for each application.
Cloud Migration statergy should be much more streamlined, with each cloud instance/account divided into organizations and projects.
Both GCP and Amazon Supports this . AWS Supports this using Organisations , Single-Sign-On/Third party Providers and Active Directory Integrations.
For an enterprise approach to cloud migration, you need to get "your head in the cloud."
Centralized API Control for Projects and Applications
Think of your cloud as a big API. For large enterprises, it will be important to manage it through a frontend application or other API level programming that they can control and manage underline Cloud Infrastrcutre. API strategy is going to play a key role in cloud migration.
Start with a naming Convention for your Project :
Example : PRJ001, PRJ002 etc.
Defined Roles for Each Team/Project/Product/etc.
Think in terms of Roles. Essentially, roles can be defined as admin, write, or read access for each cloud resource. Define your Roles clearly for each team member and for every project/team/application/etc. Make the application owner/approver responsible for making sure that they approve each request with diligence.
Ownership Role : PRJ001_Pri_Approver, PRJ001_Sec_Approver
Developer Role : PRJ001_Dev
ReadOnly Role : PRJ001_Read_only
Internally accessible Public Projects/Frameworks
If all teams are using the same archetype/framework/etc., have an open access area for your architecture framework and common applications. It makes integration easier on the Product level. I am assuming here that an enterprise product consists of multiple applications.
Internally accessible Git Repo for Framework Projects (Hosted SCM Repositery )
Internally accessible hosted Repositery for Frameworks reuse. ( Nexus/Artifactory ).
Think of All Enterprise Offerings as a Service
Think of all the enterprise offerings, such as databases, security, compliance, audit, etc. as a service and try to extract each service from the cloud API frontend. Also, each cloud provider has some paid offerings to extract some of these reports directly. In cloud terms, that means considering your available managed and unmanaged services.
IMP: Come up with a Naming/Tagging statergy for each Cloud Resource.
AWS Cloud use taging for each Resource and for each environment ( eg: DEV , INT ,PRD )
PRJOO1_DEV_Ec2_01 - EC2 DEV instance No. 1
PRJ001_INT_DB2_03 -- Database Instance No. 3 for Integration Environmnet.
PRJ001_PRD_Vault -- Security /Vault Services for production instances .
As always , feel free to comment or reach out to me if you have any questions .
I can be reached at email@example.com.
Opinions expressed by DZone contributors are their own.