When it comes to your cloud infrastructure, networking is more important than many people realize. Good networking increases efficiencies and cuts down troubleshooting time. Bad networking, or poorly planned networking, however, will cost you time, money and productivity.
When you’re beginning to architect your cloud network there are a several questions you have to ask yourself according to Bluelock Client Services Engineer Charlie Tavernier. By answering these questions not just for your needs today, but also with an eye towards growth for the future, you will be able to save yourself a lot of time and money down the line.
“What is your expansion plan for IPs?” Tavernier states as the first question. “It’s important to know how your application communicates and what all the inputs are. What does it need to talk to and what are its security requirements?”
“Specifically,” he explains, “are you planning on multi-tenancy or planning on needing your vApps to communicate with other vApps?”
“Many customers that come to cloud start with something small, but want to expand and grow later,” Tavernier explains. “It helps to think about the diagrams and how everything should be connected.”
When you begin setting up your cloud infrastructure you should evaluate not only where your cloud infrastructure will start, but also how you envision it growing. By architecting your network to optimally grow you will save yourself time, energy and headaches later.
There are a lot of networking options to consider when you’re getting started and the right option for you has a lot to do with the workloads you are bringing to the cloud. Some questions you will be asked include: “What will your network need to talk to?” “Are you planning on multi-tenancy?” and “Does your application function with NAT (Network Address Translation)?”
When working with a provider they will help you to determine the answers to questions that will help you evaluate between private circuits, external networks and internal networks. Depending on your configurations, you may have limitations on your full list of choices.
For our vCloud® user readers who are working with vCloud Director® and choosing between vApp networking and org-level networking, your decision will impact your network’s future capabilities.
According to Tavernier, an org-level network would typically have at least 2 Virtual Datacenters (VDCs) that share a firewall. The advantage is a lower cost, easier management scenario with easy communication between the environments. The diagram on the right demonstrates a typical Organization vShield™ Edge Network.
“A vApp network, while less cost-effective, would allow you the benefits of a completely separate environment. This would be helpful for security reasons or for certain testing scenarios,” Tavernier explains.
“If you are testing an upgrade of a firewall, a vApp network that had two separate firewalls would allow you to test the upgrades of the firewall in the separate test/dev environment without adversely impacting your other VDC,” he explains.
As you’ll see in the diagram to the right, this vApp vShield™ Edge Network is separate with separate firewalls and NATs, as required by your workload’s needs.
While the vApp Network is the right choice for some use cases and scenarios, there are some drawbacks to consider. You’ll need an org-level network to connect externally and you can’t use VPN with your vApp Networks.
“Both networks can do a lot of the same things, but generally speaking vApps would be recommended if your company runs multi-tenancy and you want to architect your design so you have a different firewall for each vApp,” Tavernier explains. “It’s basically a 1-to-1 scenario, so you can’t have multiple legs off of it.”
The key, however, to choosing the right networking model from the beginning is to evaluate your future plans as well as your present needs.
“When you’re thinking about how to design this in the beginning, even when you’re starting with a test/dev environment, consider the needs down the road of security, VPN and IPs,” Tavernier explains. “vApp level networking is usually best for strictly internal testing only.”
The simpler you keep your architecture, the easier it will be to troubleshoot in the future.