An important characteristic of cloud computing is the ability to easily deploy perfectly configured application instances at any time. In this video, you’ll learn how infrastructure as code can be used to simplify and streamline the deployment of cloud-based application instances.
<< Previous Video: Designing the Cloud Next: Virtualization Security >>
In previous videos, we’ve talked about deploying new application instances and having those new deployments occur automatically behind the scenes without any type of human intervention. But how are we able to deploy very complex and multi-serviced applications without having anyone physically installing those apps? Well, we do it by implementing infrastructure as code. We’re able to describe the application instance in a series of code that we can then deploy any time we’d like. This is very similar to writing code for an application, except we’re writing code that would help describe the application instances that we would then deploy.
For example, we might describe infrastructure as code as being certain hosts such as mail.example.com. There would be web servers that would also have hosts associated with them, and there would be, for instance, database servers associated with that application instance. And within this description of the infrastructure, we can add other configuration settings that would be specific to those individual servers.
This means every time we deploy an application instance, we use this description of code to be able to deploy it identically every single time. This is a fundamental characteristic of cloud computing. It’s this ability to easily deploy application instances and have those application instances follow a very specific configuration setting.
We cannot only deploy application instances with this same type of infrastructure as code, we can perform a similar function with our infrastructure devices. This would be SDN, or Software Defined Networking. With SDN, we are separating the functionality of our networking devices into two planes of operation.
One of these is the control plane, which handles the management and ongoing configuration of the device, and the data plane is the part of the device that handles the actual operation. For example, on a router, you might have a control plane that allows you to configure the router and set up any routing tables, and then you would have the data plane of the router, which is performing the actual router forwarding. This allows you to separate the functionality of these devices into these separate planes of operation, and it allows you to configure the device without affecting what’s being forwarded through that device.
Another important characteristic of SDN is that it is agile, which means you can make changes dynamically at any time. This is especially important for cloud computing, since we know that cloud computing application instances can change dramatically from moment to moment. It’s also important that we’re able to manage this SDN from one single point of view. We call this a single pane of glass, where we can sit at one management console and see the deployment for all of our SDN devices.
This should also be a technology that we can programmatically deploy, so if we have a new application instance deploying, we can also deploy the appropriate networking infrastructure along with it. And we also need this entire process of automated deployment to follow a set of open standards. That way we’re not locked in to any particular implementation of an SDN. Instead, we can use a very open and standard process regardless of the underlying infrastructure.
Here’s an example of deploying security devices using software defined networking. Let’s say that we have an internet connection that’s coming into a load balancer, and that load balancer is providing a load across multiple web servers. But we would like all of these web servers to be able to communicate with each other, and we would also like to provide connectivity to a database server, but we’d also like to make sure that all of this communication is safe.
So we might deploy an internal firewall using software defined networking that would connect web server A, web server B, and the database server all to each other, but be able to manage the flows of traffic between all of those devices. We also might want to deploy a firewall or IPS between the internet and our load balancer to provide additional security to the web server front end. What’s important to keep in mind is that all of these devices are software-based, and they can be deployed automatically using software-defined networking.
As cloud-based architecture is constantly in motion, we are installing new application instances and tearing down additional instances, and the amount of data that’s moving in different locations is changing all the time. But we still have a need to be able to monitor and understand what the traffic flows are for all of these different application instances. And the way we do that is through SDV, or Software Defined Visibility. This allows us to deploy next-generation firewalls, intrusion prevention, web application firewalls, and other security devices while at the same time being able to understand exactly what type of data is flowing between all of these systems.
This will almost certainly include something like a Security Information and Event Management, or a SIEM, where we can roll up all of that data to one central consolidated database. It’s also important that this software defined visibility understand the VXLAN, which is the Virtual Extensible LAN, which is an encapsulation method used in cloud-based technologies, and also understand what type of data might be encrypted using SSL or TLS. The foundation of what we are deploying and the way that we’re deploying these applications is changing all the time, so our SDV has to also understand all of these new technologies as we put them into service.
Here’s an example of some of the information we might be able to get from software defined visibility. We would deploy our security devices, and those devices would be able to understand the application flows that are traversing the network. From there, we’re able to get real-time views of web usage, host name usage, and the top applications in use based on what these devices are seeing on the network. And if we identify a potential threat on the network, we can use APIs to control what these application devices may be sending across the network.