What “Moving to Cloud” really means
If you are an expat, you know what it means to move to a new country. You probably had to learn a new language, figure out the cultural norms and etiquettes, understand how the society functions in terms of laws, taxes, rules & regulations and so on. The effort involved in adapting to the environment and integrating into the new culture is significant. You have to change your approach towards socialising, expand your social perspective and sometimes even the mindset. Overall, this “move” results in tremendous growth in personality, influences your beliefs, and brings new clarity.
Moving to cloud from an on-premise system is not much different. Depending on the complexity of your on-premise eco-system, significant effort might be needed to perform this migration. In my experience, teams start out enthusiastically (sometimes not so enthusiastically if the move was mandated by the management) with cloud migration. But when they realise that it is not so easy as it seems, they get demotivated. This might result in migration efforts taking significantly more time than expected, and/or result in non-optimized setup on cloud. This in turn might result in huge bills and unnecessary maintenance overhead (which might have been the reason to move to cloud in the first place). So, let’s look at what factors should be considered before/during the move to cloud. In other words, what “moving to cloud” really means. This will help you in defining the right cloud strategy and managing expectations of both the management and the developer teams.
Assuming you have a fairly complex tech setup, for instance, a portfolio of products and applications running on bare metal servers which might include data driven applications, platforms integrated with the other internal and external systems, applications that needs powerful hardware such as GPUs, multiple data stores etc. Now, let’s look at individual steps of cloud migration strategy.
Have Clarity on how you want to Leverage Cloud
Answer the question — We would like to use the cloud as: (Most of the times it will be combination of 2 or more)
- Iaas : Infrastructure as a Service (Eg: EC2, Azure VM, GCE)
- Caas : Container as a Service (Eg: ECS, EKS, AKS, GKE)
- Paas : Platform as a Service (Eg: AWS Beanstalk, Azure App Service, Google Cloud Run)
- Faas : Function as a Service (Eg: AWS Lambda, Azure Function, GCP Cloud Function)
- Saas : Software as a Service (Eg: Amazon Cognito, Google Speech-to-text)
As you can see in the cloud service spectrum above, less maintenance means higher costs, but with improper solutions architecture left side of the spectrum might end up costing more, as you have more ways to screw things up.
Choose the right cloud provider
Obvious one right? Yeah, but choose the provider carefully. You might want to consider the following aspects before choosing one:
Regional Availability:
Does the cloud provider have a data centre in or near your region? This is very important if you store (intend to store) sensitive data on cloud. Check the regulatory requirements related to data governance. Also make sure that you have all the desired products/services available in the chosen region, as not all the regions provide all the products/services.
Quality of Resources and Services:
- Are the products/services durable and reliable ?
- What’s the SLA for resolving issues ?
- How good is the customer service ?
- Does the provider care about you (the customer) or are they busy building excellent solutions that nobody wants ?
Avoiding vendor lock-in:
- How easy it is to move away from this provider if needed ?
- Do they provide enough architectural options to have a vendor agnostic setup ?
Availability of Developers:
Are there enough developers/architects with the knowledge of the cloud provider available for hire in the market ?
Innovation:
- Does the cloud provider continuously improve their products/services ?
- Do they provider more relevant products/services ?
- Are they providing more tooling surrounding their services (Ex: DevOps enablement) ?
Community Support:
- Do I get enough support online (for free) if I screw up?
- Are there sufficient contributors to “Stackoverflow” Q&A ?
- Do other “smart” developers give a s**t about this cloud provider ?
- Does the cloud provider give a s**t about the developers ?
- Is there an ecosystem of tools and technologies (preferably open source) surrounding this cloud provider?
Documentation:
The official documentation and blog posts are the primary source of truth and acts as reference during every step of cloud usage. Hence it is extremely important to choose the one with excellent documentation and resources.
Define the Goals and Prioritize
- We want to reduce infrastructure costs (CapEx + OpEx).
- We want to optimize our products and services so that we provide uninterrupted services to our customers.
- We want to scale X times in the next 3 years and want to have a platform that will support this.
- We want to reduce maintenance overhead and reduce costs.
- We want to migrate completely to cloud before end of this year.
- We want to store the sensitive information (PII/PHI etc) also on cloud.
- …
Explore and Decide on a Target Cloud Architecture
Take a look at the existing product/application/platform architecture and the goals and then explore the available options and finally some reference architectures and case studies.
- Do we have a monolith or a micro service based application ?
- How much do we expect to scale in the next 3 years ?
- What’s the estimated growth in users/data ?
- Are we willing to setup and maintain the VMs ?
- …
Migration strategy
Based on the defined goals and target architecture, choose a migration strategy:
The important questions here are
- Are we willing to refactor the code base to have an optimized architecture on cloud ?
- Do we have budget and time to refactor ?
- Do we have enough cloud skills to build an optimized setup ?
Lift & Shift
This approach works for you only if you have a setup that is cloud friendly. For example, if you are running your applications in containers, orchestrated using an on-premise Kubernetes cluster, then moving the applications to a cloud based Kubernetes service such AWS EKS or Azure AKS can be termed as ‘Lift & Shift’.
In my opinion, just dumping everything on EC2’s with attached EBS volumes is not the best approach to cloud migration. If one has decided to move to cloud then it is worth do it the right way which often includes re-factoring and transformation of the complete architecture.
Cloud Transformation
This approach involves deeper understanding of cloud eco system. By transforming the existing solutions, we can achieve
- Cost Optimisation
- Reduce maintenance overhead
- Design a scalable and fault tolerant system
- …
Just like landing in a foreign country with your belongings without any preparation and considerations regarding the life in this new region, might not be a good idea (unless of course you are super rich). Starting the cloud migration without really thinking through and not having a proper strategy might end in disaster. In the upcoming posts, I will write more about how to derive at the right architecture and what steps need to be taken for the cloud transformation.
For more insights into Cloud, Kubernetes, DevOps and Data, follow me on LinkedIn.
