The cloud has enabled developers and testers to deploy complex computing environments quickly and, perhaps most importantly, without the need to ask IT to set up new servers, switches, and routers. But, while the self-service aspect of cloud computing simplifies resource acquisition it also introduces new challenges.
The explosion of information technology has led to the need to specialize. As a result, a rock-star Linux application developer may know nothing beyond the basics of networking or systems administration.
Similarly, network admins may know very little about compiled languages and software development. Yet, when a developer or tester makes use of the cloud they often must play the part of network, systems, and storage administrator.
One of the primary challenges facing developers and testers is networking. Configuring DNS, proxies, routing, etc., are time consuming and complex tasks. As a result, it can be frustrating for a developer who wants to perform a quick operation if she must change network routes, virtual machine (VM) IP addresses, and other network-related tasks in order for the virtual environment itself to just work.
For development shops that have adopted virtualization generally, or cloud computing specifically, individual developers and testers often work from the same template, or base image of a pre-configured computing environment. These templates are collections of VMs, networks, and storage and allow independent developers to work from a “golden copy,” which they can deploy and tear down at will. This model works extremely well when developers and testers are working in isolation. But if multiple identical environments have need to be networked together at the same time (build automation, for example), the model breaks due to IP and MAC address conflicts.
At Skytap, we have addressed this problem with our latest networking feature called NAT (network address translation). For example, let’s say that a team foundation server (TFS) resides in its own virtual environment and on its own network. We’ll call this the target network. Three developers, working with three identical VM environments, need to connect to the target network in order to access TFS. In the absence of NAT, connecting these VMs to TFS would be impossible without manually editing IP addresses. (Figure 1)
In order to make this work, the first step is to set the target network to require NAT for all connecting networks. The target network then has a pool of IP addresses it can distribute to VMs on connecting networks. As each development network connects to the target, 1:1 NAT relationships are automatically created between the development network’s VM IP addresses (internal addresses) and the assigned NAT IP address (external address). (Figure 2)
With these NAT relationships in place, potential IP conflicts are eliminated as each VM receives a unique external address from the target network. VMs on the development network simply access TFS as they would normally by pointing to the TFS server’s IP address or hostname. Conversely, TFS connects to the automatically assigned external NAT IP address to access any given VM on the development networks.
When a target network is configured to require NAT there is no need to re-IP VMs on connecting networks, making the deployment of identical environments both simple and fast.
If you have a question about Skytap Cloud networking capabilities, feel free to pose it in the comments section below, or get in touch with one of our cloud experts.
Learn more about Networking:
