60. Automation and orchestration Module Introduction
I know it can be easy to do, but I don’t want you to confuse automation with orchestration. Automation is simple and will often refer to just a single task. Maybe, we want to take a virtual machine that’s in the cloud and take a snapshot of it. Okay? So, we automate that process. Every day at, let’s say, 11:00 PM, a snapshot is taken of the virtual machine. That’s an example of automation, and we obviously love automation. But what orchestration is the scheduling and the, you know, maintenance and the monitoring of a whole bunch of different automated tasks. And keep in mind, that a lot of times, you’ll have something be automated so that if any one of the pieces were to fail, then the entire task rolls back, perhaps, or maybe the entire task will complete and there’ll be a note about that one thing that failed. You get the idea. Orchestration systems can handle all of that kind of stuff for us. Well, we’ve got a lot of things to talk about here, of course. Let’s get started.
61. Backups
Backups are another topic where it really doesn’t matter whether we’re talking cloud or a traditional on-prem environment. They’re gonna be critical for our information technology team. Clearly.
And once again this is an area where cloud just really shines. Think about our various types of backups, types of backups of variety, and the types of backups that we can make. Really saves us when it comes to an overall data storage strategy. Think about it. You can do the full backup. A lot of times this is done off hours because it might even be disruptive due to the number of systems or services that need to be shut down or paused while this intense full backup is taking place. But realize that there’s something called an incremental backup, and this would be supported in the cloud as well. The incremental backup goes and backs everything up, let’s say, since a full backup and then marks those files as backed up so they won’t be backed up again. So, what’s gonna happen here is sure you take this full backup, let’s say, on Sunday, and then on Monday you just do the small incremental on Tuesday, the small incremental on Wednesday the small incremental, you get the idea, maybe, on Saturday the final incremental, and then it starts all over again. Now, sure, these incremental backups are very small. They’re only the things that have changed since the last incremental backup. But think about a restore. Boy, it’s gonna be a lot of work. We have to restore the full backup. Then we have to restore every single incremental. So, very quick times each day in order to back up but a much more intense process when we need to restore. Well, sure enough, there is a differential type of backup and this would be supported in the cloud as well. And with the differential type of backup, it says ‘I’m gonna mark everything that was not backed up since the last full backup,’ but it does not mark that stuff as backed up. So, now you get in a nice situation where as far as a restore goes, you’ll only have to do two files. You’ll only have to do the last differential backup that you took and that original full backup. But guess what? Why does moving to the cloud get really exciting in this area of backup? Well, because in the cloud we can do new technologies that we could never do before. Like how about taking a snapshot? You saw me do that in this course. You saw me take a snapshot of a disc. We needed to do it for a very interesting reason. We took a snapshot of a volume that could have been in use. The machine was stopped at the time but that machine could have been absolutely in use. And when we took that snapshot we were doing it to restore it as an encrypted volume. But you get the idea. Exciting types of new backups like snapshots that can have a machine fully running, fully being utilized, and an instantaneous, stateful snapshot of that device can be taken as a backup and restored at any time. It’s new things like this, and also the very many types of specialized backups that exist inside of services that make the cloud very appealing from a backup perspective.
62. Perform Disaster Recovery Tasks
So, this is pretty funny, a little story within the story. I was going to correct the DR on this slide. It’s not incorrect. It stands for disaster recovery, of course. I like to spell things out, especially on title slides. But I was getting ready to make that correction and I said, ‘You know what? This is something I’m not gonna change because this does serve as a nice little kind of almost flashcard test for you to see the letters DR and in this context of cloud immediately think disaster recovery, which is really-really important when we talk about cloud tech.’ Did you ever pretend you’re really-really important? Like the President of the United States? Or the President of Japan? Or whatever! Someone really-really super important. Well, think about if you could go ahead and you could be the designer of a massive private cloud.
So let’s say you work for an organization the size of Facebook, right? Or Netflix, and you are gonna be designing the private cloud that is helping to power this organization. Well, guess what? You would pattern it right after what AWS does, or Azure does, or the Google Cloud platform would do. Sure, you would pattern it right after what they would do. You would divide the world up into regions, right? Regions. There we go. And let’s try that again, shall we? You would divide the world up into regions. That’s right. So, you would have, you know, regions defining the portions of the globe that you are giving coverage to. Just like the big public cloud vendors do, you would then create availability zones. These availability zones would consist of three or more data centers, high speed connections between them. But note, they are, you know, different data centers in that availability zone. And, of course, there would be another availability zone inside of this region. Over here we would have AZ1 and AZ2. So, you get the idea. If we had the budget, we would be taking even our private cloud resources and we would be putting them in like the USA region. And how about the Asia Pacific region? And then inside of there, we would be doing availability zones with multiple data centers. Why are we talking so much about the geographical layout and the overall structure of how the cloud resources are organized? Well, because it ends up becoming critical in our discussions of DR.
What happens if there is a flood and this availability zone goes offline? Well, have we been properly replicating our data periodically so that the other availability zone, the one we’re not actively in, does that have a nice backup copy ready to go of all of our data? So, we get to practice DR, disaster recovery tasks, when we have a multi-region, multi-availability zone set up like this, we can set it up for disaster recovery and we can go in and we can test that disaster recovery scenario. It’s so neat. In the world of hacking, we will have penetration tests where we will come in acting as the bad guys. We’ll act as the Black Hat Hackers, even though we’re not. We’re forces of good, right? So, we come in as this red team attacking the organization, and we are good guys on the payroll, but in a blind style of attack, they don’t even know it’s coming. So, the security team gets an amazing test. Think about it, we can do the same thing with DR. We have a team that is responsible for the disaster recovery, let’s say in our cloud. And we’ll give them one heck of a checkup or a test, won’t we? We go ahead and we go in and intentionally fail a portion of the infrastructure and we see, do they get a gold star or a check mark; or do they get an X and no gold star? So, these types of tasks are gonna be critical for disaster recovery and it’s always great for you to go into your solution, go into your actual infrastructure and do testing to make sure it does work just as you designed it. Thanks so much for watching.
