In the cloud, things happen fast. In this video, you’ll learn resiliency and automation can be used to maintain the uptime and availability of these dynamic computing platforms.
<< Previous Video: Security in the Cloud Next: Redundancy, Fault Tolerance, and High Availability >>
If you’re maintaining a cloud-based infrastructure, then there’s going to be a lot of automation and a lot of scripting. Cloud-based services tend to change from minute to minute, so it’s important that an automated system is able to handle those changes instead of relying on manual processes to do that. Many cloud administrators rely on this automation. That way if a particular event occurs, an automated response could be made to that event.
For example, if the storage drive begins getting full, you can monitor and identify that problem, and then automatically script an automated process to clear out drive space so that that drive does not become full. That means that continually monitoring for these events becomes very important. You want to be able to identify when any of these types of events might occur and then react with a set of automation. A good example of this might be monitoring for certain security events. If somebody is performing a brute force attack or somebody is trying to attack with a set of known vulnerabilities, you can adjust firewalls and intrusion prevention systems to automatically stop those attacks.
A cloud-based environment may be changing constantly. So it’s important to be able to validate configurations before an application instance is applied into production, and it’s important to constantly monitor and evaluate that configuration once the application instance is live. For example, you may want to provide ongoing vulnerability scans and security checks of all of the instances that may be live at a particular time.
What if you wanted to roll out an application instance? Now what if you wanted to roll out a hundred of those application instances? You can’t build all of them from scratch every time. So instead, we use templates to be able to build a basic structure of an application instance, which makes it very easy to then deploy.
For example, you may find that an application instance needs a web server and a database server, but you need to define exactly which web server software you’re going to use and which version. If you’re going to be using PHP, which version of PHP is applicable for this application instance. You’ll need your corporate SSL certs to provide encryption. You’ll need firewall rules that allow all of this traffic to flow. And the list goes on. All of this needs to be combined together to create this application instance template.
This template is the basic structure. There will still need to be changes and customization once this application instance is moved into production. You’re still going to need to change IP addresses, internal settings, and other things that might be specific to that particular deployment. Those changes will be orchestrated with scripts and application programming interfaces to make the entire process automated.
As you’re building out this application instance template, you’ll probably also want to create master images of the individual servers. You’ll have a perfect deployment that has been built specifically for that application instance. This will be saved as a master image, but you’re still going to need to make changes after the image has been deployed. There’ll need to be changes to IP addresses, firewall, security configurations, licensing updates, and other customizations that are unique to this server once it’s deployed.
Once you’ve built your master image, you’ll still have to go back and make changes to this master image over time. There will be security patches for the operating system and the applications running on this server, and this might take a good bit of time to be able to understand exactly what changes need to be made to the master image. You’ll need to test those changes to make sure that the application will still perform properly. So you may have to allocate a good bit of time whenever you need to make changes to this master image.
Many application instances are not persistent. They might be built up and torn down in a matter of moments. The cloud is constantly in motion, and you need to take into account when these changes might occur and how you can manage them. We rely on snapshots to capture a point in time of a particular configuration or application instance, or to be able to maintain data should there be changes to things happening in the cloud. This might preserve everything about a particular server or perhaps just the configuration of that server so that you could build it again later.
Some of these snapshots also allow us to revert back to the configuration at a previous point in time. It’s very common to take a snapshot before deploying and making changes to an instance. So if there’s any problems, you can revert back to the previous configuration. Some of these snapshots also allow you to roll back to a previous configuration, but leave all of the data in place. In that example, you might be able to upgrade the application and then be able to revert to a previous application without changing any of the data that was changed in the meantime.
And some application instances may run completely from a live boot media. This means you have some type of removable media that you can attach to hardware, run the particular instance. And if you need to move that instance from place to place, you simply remove the media and connect it to a new piece of hardware.
One of the biggest advantages of a cloud-based infrastructure is the ability to change and move whenever the conditions require it. Elasticity is one where you would add new resources as they’re needed and be able to scale things down as things slow down. That way, you’re only using the resources required to perform a particular task when it’s needed. Host availability allows you to implement this elasticity. You can click your mouse and build out a single server or an entire application platform.
As you can imagine, this requires a good bit of orchestration. There’s a number of automated processes when you click that mouse to build out an application instance, and there needs to be automation of where these virtual devices are created, how they’re connected, and how they may be moved from place to place. You may have a scenario where your services are following the sun. And as people are waking up in one part of the globe, you’re building out new applications in those local data centers. And when they go to bed, you’re moving those application instances to a data center where there’s more activity.