Rawpixel - Fotolia
Map hybrid cloud applications to your VPN address spaces
Enterprise networks can easily become your Achilles' heel in hybrid cloud. Follow this advice to effectively manage your VPN, as well as scale and redeploy hybrid cloud apps.
Every corporate VPN has an address space, whether it's one your company assigns to it from the public address inventory or a private one that you use internally. There are differences, benefits and risks to each of these approaches, but if you have a VPN today, you've already committed to one of them, which will influence how you manage your network for hybrid cloud applications.
Addressing defines your network and, in at least some sense, defines your workflow. It's critical to carefully plan your addressing strategy to ensure agility in a hybrid cloud network.
VPNs and addresses in hybrid cloud
A corporate virtual private network (VPN) delivers packets to endpoints where users or applications are connected, based on addresses; think of it as a virtual black box with everything connected at the edge. Once a packet exits the VPN, local routing policies direct it to a specific user or application. User addresses are normally fairly static, based on the facility where each worker resides. Application addresses, on the other hand, can vary depending on where the application is hosted, and this creates challenges in hybrid cloud.
Applications are normally known to users and other applications via URLs, rather than IP addresses. If an application uses a logical URL address, you can simply redirect the URL to the new address to accommodate a change in hosting location. This requires you to update the URL decoding, which is done through the domain name system (DNS). While this reduces the need to manage addresses, it doesn't eliminate it. Remember that dynamic address assignment can create collisions, so be sure to organize your addresses regardless of whether you use the URL or DNS approach.
The optimal logical VPN structure for a hybrid cloud network is something like the one shown in Figure 1. The goal is to establish a hierarchy that separates your address space into two segments: one for users and branch offices or facilities and the other for applications, data centers and cloud providers. Most users who adopt this approach will then divide their user address space according to the office or facility where the users are located. However, for hybrid cloud management, it's the application address space you have to focus on. Think of a two-tier assignment: a range of addresses for applications overall and a subset of that range for each hosting location, which could be a public cloud provider or one of your own data centers.
This enables you to assign high-level groups of addresses to groups of hybrid cloud applications, such as those for payroll, order tracking and inventory, which makes it easier to manage user access. For each application group, you'll have a range of stable addresses that access control policies can reference, and you'll be able to map application addresses into your VPN without worrying about collisions in assignment.
This model divides application groups not by the individual applications, but by where and how they're hosted. Within each hosting domain, you may find specific rules for local address assignment. In data center container, virtualization and bare-metal hosting, it's common to assign IP addresses from your VPN to the application components. In public and private clouds, as well as some container technologies, it's common to deploy each application into a private IP subnetwork and expose specific addresses to the outside.
Your VPN mapping process will be slightly different for each.
For example, if your hybrid cloud applications map directly to your VPN address space, which is often the case for companies that have their own public IP address, assign each application group to its appropriate address space within the application branch of your address tree, as Figure 1 shows. Since most application integrations will be within the same application group, you can use policies to restrict access to internal APIs.
As mentioned above, modern public and private clouds, along with container technologies, will deploy an application within its own subnetwork, which is almost always a private subnet address space that's local to each deployment. From this set of private address spaces, selected addresses that are connected to other applications or users will be exposed by translating the local address to your VPN.
To start, expose your external application interfaces into the appropriate space for the application group. Then, assign them, within that group, to the subaddress space for the cloud provider or data center where they're actually hosted.
Redeployment and scaling
If you need hybrid cloud applications within a group to scale and redeploy on the same hosting platform, you can handle scaling and load balancing without changes to your VPN mapping. If something fails, you can redeploy it and expose its address into the VPN as the same address of the original component. If something scales, then the load balancer address is exposed into the appropriate application and hosting group address space.
If you think you'll scale or redeploy across multiple hosting points, don't change application addresses each time. Instead, expose application components into the pan-hosting address space -- as shown in Figure 1 -- rather than a host-specific space. For that address space, you may need to create specific forwarding policies that then point one of the pan-hosting addresses to the new hosting location.
Address spaces have to fit into physical networks, and Figure 2 shows an optimal physical network map. Users find that, to simplify hybrid cloud addressing, deployment and scaling, it's helpful to handle data center and cloud connectivity outside the VPN itself, which means that the application address space will connect to a corporate data center and cloud network. This ensures that all your hosting options are connected to the VPN in the same way and minimizes unnecessary "spaghetti" routing if you move something between cloud and data center. It also makes it easier to make any changes in hosting location more transparent to workers.
