The Cloud Migration Gotchas..

All leading cloud providers have a well defined Cloud Adoption Framework that will help you shape up your cloud migration strategy. Customers would eventually end up with one of the 5 'R's of rationalization - Rehost(Lift&shift) , Refactor, Rearchitect, Rebuild or Replace.  Once you have identified the approach , next steps would be planning and execution. However the best  plans laid out by  a professional services team can be driven off the track by  customer specific environment challenges. If you are helping customers with cloud migration, here are few things that you might want to think through again and prepare for before you go all in .

1.Start with stakeholder buy in

The first step called out in Azure Cloud Adoption Framework is Strategy or rather the motivation of the organization to move to cloud. Though this would usually be done in the presales phase and might have the buy in of the C-Suite, it is very important that this acceptance trickles down to stakeholders of respective application. There could be resistances in terms of adopting new technology i.e. fear of the unknown. Most often this can be traced back to lack of skill up efforts . Ensure that you factor in Skill development efforts during the plan phase . Remember,  you might be an expert in the cloud but for the customer it could be all very new and scary. It is important to give confidence to customer stakeholders that you will not just help them cross the bridge to cloud, but also help them survive there. It could be through extended support after migration , trainings or engagement with support team for ongoing support.

2. DevOps is  not just for software development

Be agile in your cloud migration plan, learn from your mistakes and continuously optimize . The waterfall approach of completing the planning of entire suite of applications before migration will impact your migration timelines. Integrate  DevOps culture and agile methodologies in your migration process. For eg:  leverage IAC for idempotency of  base infrastructure. Identify and automate all migration patterns as much as possible. The success of a migration projects  depends on the cohesiveness of teams involved, be it the migration team, application team, infra team and the stakeholders. The culture shift to DevOps helps where responsibilities are equally owned by everyone involved

3.Assumptions can be dangerous

While working as a service provider helping customers with cloud migration, it is important to reach a common understanding on  the scope of migration. To be more direct - don't assume that scope of work is crystal clear for everyone involved just because there is a document that is signed off on the same. It is prudent to have  a scope discussion during initial phase of migration with stake holders so that everyone is clear on  roles and responsibilities. If there are any add-ons in your agreement with the customer, for eg: enabling monitoring, backup , DR etc.. ensure that there are no grey areas on the same.   For eg; enabling DR once the application is migrated to cloud can become a project in itself . The activities that will be done post migration for DR has to be clearly defined and agreed with customer to avoid scope creep during execution. Be customer centric, but keep the expectations very realistic and get buy in from stakeholders.

4. When in doubt do a POC

In case of complex system migrations, factor in time and effort to do a Proof-of-Concept( POC) before touching the production systems. This could be  a separate environment in itself or one of the non-prod environments of the applications. Especially when you are integrating new cloud native services in your architecture, doing a POC is inevitable irrespective of whether you had done individual component testing independently. This could delay your migration timelines, but its worth the wait than resorting to firefighting post migration. 

5. Take Legacy systems with a pinch of salt

Often customers  prefer Lift & Shift of legacy workloads to cloud. There could be multiple factors contributing to this - unknown dependencies, efforts required to refactor , application sunset being planned in the long term etc. You can use tools like Azure Service map to detect dependencies to an extend. However its always better to err on the side of caution and factor in buffer time to mitigate any blockers that could crop up due to legacy components. As discussed in the previous case this could be one of those scenarios where a POC might be required before the migration if feasible.

Read more about Microsoft Cloud Adoption framework that is designed to provide end to end guidance for customers on the adoption strategies best suited for your business scenarios here :https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ 

Read More

Azure Arc integrated Kubernetes cluster

Multi and Hybrid cloud deployments have become more of a norm than exception and how seamlessly you can manage resources deployed across multiple environments would determine the success of your digital transformation. Azure Arc enables this by providing a solution that enables consistent management of workloads across environments. It helps onboard resources from  heterogeneous deployments  and manage them using familiar premises of Azure Resource Manager. Azure Arc currently supports VM, Kubernetes clusters(preview) and databases(preview) , and you can monitor and manage them from Azure irrespective of where it is deployed.

Azure Arc can  be used for centralized monitoring and management of k8s clusters deployed across different cloud environments or on-premises. This service is currently in preview. As part of my weekend tinkering , I explored Azure Arc enabled Kubernetes cluster. The process for setting it up for a lab is pretty straight forward, and you will get most of this information from publicly available documents. I have made few tweaks to get them to suit the k8s clusters that I created

To start with, you need to get the kubeconfig file of the cluster that should be integrated with Azure Arc. For testing purpose I created a k8s cluster for testing the integration though kubeadm. That was an interesting experiment in itself as the deployment was done in an Azure VM. The steps to be followed are based on the following article: https://www.mirantis.com/blog/how-install-kubernetes-kubeadm/ . However to make the cluster accessible over  a public DNS, some additional configuration was required. For instance, the kubeadm deployment exposes the API server over port 6443. So inbound connection to this port has to be enabled in the NSG of the VM.

My tweaks for to get Kubeadm based cluster deployment working in Azure in addition to the steps mentioned in the document are as follows

1. Deploy an Ubuntu 18 machine from marketplace

2. Create  a DNS entry for the VM and map it to the public IP.

3. Create NGS with that allows inbound connection at port 6443 from internet in addition to  the default SSH port

4. Use the DNS name of the VM in the kubeadm init command while creating the cluster. Else the certificate will not be bound to the DNS and you will not be able to access the cluster from external and add it to AzureArc. Sample command I used is given below

        

  kubeadm init --pod-network-cidr=192.168.0.0/16 --control-plane-endpoint  kubeadmclstr.eastus2.cloudapp.azure.com

5. Calico installation should be done using the following steps

curl https://docs.projectcalico.org/manifests/calico.yaml -O

kubectl apply -f calico.yaml

You can  check out the below video for the full installation process 

Now our K8s cluster is created using kubeadm.  Copy/upload the kubeconfig file to the environment from where you are configuring AzureArc integration. I configured the AzureArc intergation from cloudshell, hence uploaded kubeconfig file to be Azure CloudShell session. Follow this document to enable integration with AzureArc: https://docs.microsoft.com/en-us/azure/azure-arc/kubernetes/connect-cluster 

 I have recorded a video of the integration process, you can refer to it below.  

There my k8s cluster is listed in AzureArc!! Now if you want to get additional insights into your cluster performance, enable monitoring of the cluster using the steps in the  MS document. Its easy-peasy really, you can simply follow through the document. 

I tried it for one of my AzureArc enabled clusters , you can refer the video below to view the process .

Note: I enabled monitoring through Bash and integrated my k8s cluster with an existing log analytics work space. For automated CI/CD deployments , you can also use service principals as described in the doc

Viola, Now I can view my K8s cluster and view the associated metrics & logs directly from Azure portal. Of course in real world, this would be your production k8s clusters. As the service is now in preview, you can use it for test and dev purposes and not in production. Hope this blog + videos will help you get started with that. Happy learning!!

Read More