Day 90 - Data & Application Mobility

Days/day90.md

@@ -1,5 +1,114 @@
 ## Data & Application Mobility
 
-Maybe we have been working on the same cluster since the start of this section and we have deployed several data services and applications to our cluster but now we have the requirement to move to a new cluster. 
+Day 90 of the #90DaysOfDevOps Challenge! In this final session I am going to cover mobility of our data and applications. I am specifically going to focus on Kubernetes but the requirement across platforms and between platforms is something that is an ever growing requirement and is seen in the field. 
 
-A new Minikube cluster, this could create a new cluster and then use Kasten K10 to move it over to the new
+The use case being "I want to move my workload, application and data from one location to another" for many different reasons, could be cost, risk or to provide the business with a better service. 
+
+In this session we are going to take our workload and we are going to look at moving a Kubernetes workload from one cluster to another, but in doing so we are going to change how our application is on the target location. 
+
+It in fact uses a lot of the charateristics that we went through with [Disaster Recovery](day89.md)
+
+### **The Requirment**
+
+Our current Kubernetes cluster cannot handle demand and our costs are rocketing through the roof, it is a business decision that we wish to move our production Kubernetes cluster to our Disaster Recovery location, located on a different public cloud which will provide the ability to expand but also at a cheaper rate. We could also take advantage of some of the native cloud services available in the target cloud. 
+
+Our current mission critial application (PacMan) has a database (MongoDB) and is running on slow storage, we would like to move to a newer faster storage tier. 
+
+The current PacMan (NodeJS) front-end is not scaling very well and we would like to increase the number of available pods in the new location. 
+
+### Getting to IT
+
+We have our brief and in fact we have our imports already hitting the Disaster Recovery Kubernetes cluster. 
+
+The first job we need to do is remove the restore operation we carried out on Day 89 for the Disaster Recovery testing. 
+
+We can do this using `kubectl delete ns pacman` on the "standby" minikube cluster. 
+
+![](Images/Day90_Data1.png)
+
+To get started head into the Kasten K10 Dashboard, select the Applications card. From the dropdown choose "Removed"
+
+![](Images/Day90_Data2.png)
+
+We then get a list of our restore points available to us. We will select the one we have as this contains our mission critical data. 
+
+![](Images/Day90_Data3.png)
+
+When we worked on the Disaster Recovery process we left everything as default but these options are there if you have a Disaster Recovery process that requires the transformation of your application. In this instance we have the requirement to change our storage and number of replicas. 
+
+![](Images/Day90_Data4.png)
+
+Select the "Apply transforms to restored resources" option. 
+
+![](Images/Day90_Data5.png)
+
+It just so happens that the two built in examples for the transformation that we want to perform are what we need for our requirements. 
+
+![](Images/Day90_Data6.png)
+
+The first requirement is that on our primary cluster we were using a Storage Class called `csi-hostpath-sc` and in our new cluster we would like to use `standard` so we can make that change here. 
+
+![](Images/Day90_Data7.png)
+
+Looks good, hit the create transform button at the bottom. 
+
+![](Images/Day90_Data8.png)
+
+The next requirement is that we would like to scale our Pacman frontend deployment to "5"
+
+![](Images/Day90_Data9.png)
+
+If you are following along you should see both of our transforms as per below. 
+
+![](Images/Day90_Data10.png)
+
+You can see from the below image that we are going to restore all of the artifacts listed below, if we wanted to we could also be granular about what we wanted to restore. Hit the "Restore" button
+
+![](Images/Day90_Data11.png)
+
+Again we will be asked to confirm the actions. 
+
+![](Images/Day90_Data12.png)
+
+The final thing to show is now if we head back into the terminal and we take a look at our cluster, you can see we have 5 pods now for pacman and our storageclass is now set to standard vs the csi-hostpath-sc 
+
+![](Images/Day90_Data13.png)
+
+There are many different options that can be achieved through transformation. This can span not only migration but also Disaster Recovery, test and development type scenarios and more. 
+
+### API and Automation 
+
+I have not spoken about the ability to leverage the API and to automate some of these tasks but they are there and throughout the UI there are breadcrumbs that provide the command sets to take advantage of the APIs for automation tasks. 
+
+The important thing to note about Kasten K10 is that on deployment it is deployed inside the Kubernetes cluster and then can be called through the Kubernetes API. 
+
+This then brings us to a close on the section around Storing and Protecting your data. 
+
+## Resources 
+
+- [Kubernetes Backup and Restore made easy!](https://www.youtube.com/watch?v=01qcYSck1c4&t=217s)
+- [Kubernetes Backups, Upgrades, Migrations - with Velero](https://www.youtube.com/watch?v=zybLTQER0yY)
+- [7 Database Paradigms](https://www.youtube.com/watch?v=W2Z7fbCLSTw&t=520s)
+- [Disaster Recovery vs. Backup: What's the difference?](https://www.youtube.com/watch?v=07EHsPuKXc0)
+- [Veeam Portability & Cloud Mobility](https://www.youtube.com/watch?v=hDBlTdzE6Us&t=3s)
+
+### **Closing**
+
+As I wrap up this challenge, I want to continue to ask for feedback to make sure that the information is always relevant. 
+
+I also appreciate there are a lot of topics that I was not able to cover or not able to dive deeper into around the topics of DevOps. 
+
+This means that we can always take another attempt that this challenge next year and find another 90 days worth of content and walkthroughs to workthrough. 
+
+### What is next? 
+
+Firstly, a break from writing for a little while, I started this challenge on the 1st January 2022 and I have finished on the 31st March 2022 19:50 BST! It has been a slog, But as I say and have said for a long time if this content helps one person then it is always worth learning in public! 
+
+I have some ideas on where to take this next and hopefully it has a life outside of a GitHub repository and we can look at creating an eBook and possibly even a physical book. 
+
+I also know that we need to take a look through and make sure everything is grammatically correct before making anything like that happen. If anyone does know about how to take markdown to print or to an eBook it would be greatly appreciated feedback. 
+
+As always keep the issues and PRs coming. 
+
+Thanks! 
+@MichaelCade1

README.md

@@ -138,4 +138,6 @@ This will not cover all things DevOps but it will cover the areas that I feel wi
 - [✔️] 🗃️ 87 > [Hands-On Backup & Recovery](Days/day87.md)
 - [✔️] 🗃️ 88 > [Application Focused Backups](Days/day88.md)
 - [✔️] 🗃️ 89 > [Disaster Recovery](Days/day89.md)
-- [🚧] 🗃️ 90 > [Data & Application Mobility](Days/day90.md)
+- [✔️] 🗃️ 90 > [Data & Application Mobility](Days/day90.md)
+
+🚧