How to mitigate cloud adoption risks?
Cloud adoption for large platforms should have a carefully thought out strategy and a risk mitigation plan — Use of Multi Cloud and Poly Cloud Strategies
I want to share my thought on the right cloud adoption approach and the architecture patterns that align with our customers’ strategic interests. Today there is heavy competition in the cloud space between the three major players AWS, GCP, and Azure. There is usually rich feature parity among the service providers although there is specialization in some areas. Even though we say that there is feature parity, the devil is in the details and we will talk about this a bit later.
First, I want to talk about the risks to consider during cloud adoption and why it should not be treated as any IT purchase.
Vendor Relationships: Over the long term, the strategic interest of the customer and the vendor may cross each other driving these critical relationships at risk.
Control of IT assets: The customer should have maximum control over their IT assets and should be able to manage it with maximum flexibility.
Failovers risk: It’s always good to have our strategic IT assets diversified across environments to have a foolproof failover strategy.
When I interview for positions, I do ask for their point of view on how they would mitigate these risks as architects. I usually get “multi-cloud” as an option to mitigate these risks. However, I feel that the answer is not in black and white. Before that, here is my simple definition of multi-cloud — it’s a strategy where more than one cloud services run a part or copy of the workload.
When companies like Netflix which has long been the poster child of AWS is testing waters with GCP for certain workload, it means — Multi-cloud is real and releasing in theaters near you 😊. Check-out tools like Spinnaker which has got considerable maturity.
There is no standard definition of multi-cloud — here is how I see it.
Poly Cloud — a variation of multi-cloud where a portion of the workload is deployed on a CSP that best serves that functionality. For instance, we could deploy the predictive analytics portion of the application on GCP for its AI/ML capabilities.
Multi-Cloud (Active/Passive for DR): In this strategy, we can use lean presence in a secondary CSP to handle DR requirements.
Multi-Cloud (Active/ Active): In this strategy, we can have 2 instances of the application running and serving the traffic. I have not personally seen this in practice. But technically this is a feasible option.
Application Portability key to freedom
The above-mentioned strategies of multi-cloud would help in the mitigation of the vendor relationships issues and failovers. Having a hybrid cloud approach with the ability to use cloud elasticity would mitigate the risk of losing full control of the IT assets to an extent. The ability to port the application from one CSP to another — application portability, should be considered as part of the architecture governance to make sure the candidate application adhere to portability standards. While reviewing the architecture for cloud portability we need to consider several factors as ‘Portability’ is a ‘nice to have’ feature for most of the application and a ‘Must’ for business-critical applications.
Cloud portability is ‘Nice to Have’ for the following workloads
- Startups at an earlier stage of the life cycle.
- Seasonal applications
- Non Critical business applications.
However for critical business application and assets its an important factor to
- De-risk from vendor locking
- Competitive pricing from cloud providers
- Failover recovery
Another important factor to consider is the cost associated with designing, developing, and testing the cloud portability of the applications across multiple CSPs.
Parity does not mean they are interoperable:
When designing the applications for cloud portability sometimes we take some of the cloud service capabilities granted to be the same although they may seem so the nuances vary.
To illustrate these subtle differences, let’s consider a basic service that is offered by all the CSPs. The object storage capability. Let’s compare AWS’s S3 and GCP’s GCS in this case.
- Assume that you are using S3 for storage and you want to now store in GCS — it does not support the S3 type of multi-part upload. Instead, you have to perform a chunk-parallel upload. The GCS multi-part upload is no the same — Refer https://cloud.google.com/storage/docs/uploads-downloadsMinimum storage capacity required for AWS is 40KB on Glacier but that does not apply for GCS.
- Although you can apply custom metadata you cannot have object-level tagging as you do in AWS.
- GCS supports 4 storage classes like Standard, Nearline, Cold line, and Archive. However, AWS has Standard, Standard-IA ( One Zone / Muti Zone ), Glacier ( & Deep Glacier ), S3 Outposts.
Architecturally we could employ abstraction and encapsulation to deal with differences and make the system work across the cloud service provider there is always a cost associated with this interoperability. It’s not just development, there is a significant overhead concerning security, overall management, and data management.
If your workloads are containerized, then Kubernetes help mitigates considerable risk. However, we should understand that not all managed Kubernetes services are the same. Let me give a couple of instances where we will have challenges.
- If we have TPU used in the machine learning payloads, then they would not be supported in AWS EKS.
- BareMetal support is not available GKE where else AKS supports it.
- The Kubernetes master controllers in EKS are managed by AWS and the logs for those masters nodes are not readily accessible. You must create a separate ticket to access it if we want to troubleshoot.
Each application has to be evaluated for its need to be designed for cloud interoperability. These decisions better-made upfront and architecture governance is critical in larger projects where several teams are involved.
