Cloud computing has put an updated focus on our approach to provisioning and deprovisioning applications. In this video, you’ll learn about scalability, elasticity, and orchestration of application instances.
<< Previous Video: Secure Deployments Next: Secure Coding Techniques >>
Provisioning is the process of making something available. If you are provisioning an application, then you’re probably going to deploy a web server, a database server. There may be a middleware server and other configuration and settings to be able to use this particular application. That’s one of the reasons why, when we describe the deployment of an application, we’re referring to it as an application instance, because it usually involves many, many different components all working together.
Of course, the provisioning of this application instance also includes security components. We want to be sure that the operating system and the application are up to date with the latest security patches.
We also want to be sure that our network design and architecture is also secure. So we might want to create a secure VLAN just for this application. There might be a set of configurations and a firewall for internal access and a completely different set of security requirements for external access.
And if we’re deploying software to a workstation, we may want to run our own scans of that software and make sure there’s nothing inside of that binary that may look malicious. This also would be a good time to check the security posture of the workstation and make sure that the workstation itself is up to date with the latest patches and is running all of the latest security configurations.
The workload associated with this provisioned application can vary widely depending on many different criteria. Maybe at a particular time of the year, an application gets busier, or maybe the popularity of an application has taken off. And suddenly, a lot of people are wanting to use this application.
When we first build this application instance, we’re creating a particular level of scalability. We know that based on the particular web server, database server, and all of the other components that make up this application instance– that we can support a certain load. For example, you might build an application instance that can handle 100,000 transactions per second. And everything that you put together would be able to handle any load up to that point.
But if an application becomes very popular, you may find that 100,000 transactions per second isn’t enough. Maybe you need to increase the capabilities of this application to support 500,000 transactions per second. To be able to do that, we may deploy multiple application instances.
That increase or even decrease of available resources for an application refers to elasticity. We define the elasticity as the ability to increase or decrease the available resources for this application based on the workload. As this application becomes more popular, we can create new application instances to increase the number of available transactions per second. If we know that our application scalability can support 100,000 transactions per second and we suddenly need 500,000 transactions per second, then we can take advantage of this elasticity and create five separate application instances all running simultaneously.
If the application becomes less popular, then elasticity works in the other direction. And we can decrease the number of application instances available, thereby decreasing the number of transactions per second that can be supported by this application.
Once you have this application that can be provisioned, you might want to automate the process of making this application available through a method called orchestration. Orchestration is really the key to cloud computing because you’re able to automate the provisioning and deprovisioning of these applications.
This orchestration allows us to instantly provision an application without any type of human intervention. So we could deploy servers, network configuration, security components, and anything else associated with that application.
You can even orchestrate where this application instance will be provisioned. So you may want to have a provisioning of the application in Europe for the times that Europe is awake and then create new application instances in the United States when those particular users are available.
You can then automatically deprovision the application instances in Europe as the day is ending and then, ultimately, deprovision the ones in the United States once the sun sets there. Then the process can restart itself the following day through the automatic provisioning and deprovisioning of the app.
Not only are we provisioning the application components, but we’re also provisioning all of the security components as well. So the automation that you’re building with this orchestration is going to apply to all aspects of this application and the security components as well.
If we’re building out and provisioning new applications, then, eventually, we may be deprovisioning or removing those application instances as well. This is not simply turning off the application. This is completely removing any remnants of that application from running in your environment.
If you’re deprovisioning a web server or database server with an application instance, then you also have to deprovision all of your security components as well. Not only are you removing the firewalls and other security devices, you may have to remove individual rules in the existing firewalls that remain. So make sure that if you are provisioning and opening up those firewall rules– that you are, during the deprovisioning process, removing those firewall rules.
And, of course, decisions have to be made over the data that was created while this application was in place. It may be that the data is copied off to a secure area or it may be that everything that was created during the use of that application is now removed during the deprovision process.