By Joep Piscaer
Multi-cloud is often talked about as if it’s a deliberately chosen and executed strategy—something you think about, design for, and then execute. The reality is often vastly different.
Cloud usage grows organically, across both the number of services used, as well as the per-service spend. For many organizations, this means running the risk of losing control over their cloud estates: it’s easy to just start consuming services without first considering the security, scalability, and cost ramifications or involving teams responsible for these aspects.
Often, it wasn’t a thought-out plan, or part of any architecture, design, or budget discussion.
Chances are, you already are multi-cloud, even if you don’t realize it. In other words, multi-cloud often “just happens”—and things that “just happen” are hard to control.
Balance
With easy-to-consume cloud services that solve actual issues for those using the services, there’s a need for a balance between control and agility that keeps the security and compliance teams, as well as the DevOps teams, happy and moving forward.
DevOps teams are used to a short-cycled work tempo, quickly iterating and adapting to changing business requirements. Long-change management and approval processes do not fit into their way of work, because end-users expect a quick turnaround of requests and changes. If IT processes don’t adapt, those users are quick to swipe a credit card and use a service without approval (i.e., Shadow IT).
This is bad news for security and compliance practices. Imagine having to fix security and compliance issues retroactively, given the many different disconnected islands, each with incomplete, badly implemented, unaudited security and compliance standards.
Real-Time Topology Insights Are Crucial
There are many cases where agility trumps compliance for the sake of fast delivery. When this happens, security can take an “eventually consistent” approach of staying out of the DevOps team’s way while also not sacrificing regulatory and security requirements.
When it comes to network visibility, “eventually consistent” starts with knowing what you don’t know: real-time insights into the changes of the network, and its topology. In practice, this means being able to see what firewall rules are configured for a given EC2 instance running on AWS, what DNS server is configured for an on-premises VM, or which distributed firewall rules apply to a VM.
The emergent behavior of a network topology of cloud services and the application service landscape means it changes constantly and in hard-to-predict ways. Thus, it requires tooling to help ITOps teams keep tabs on changes automatically.
Network Topologies in vRealize Network Insight
vRealize Network Insight keeps tabs on different types of topologies, including on-premises VM-to-VM traffic, to and from Amazon Elastic Compute Cloud (EC2) VM instances, and much more. This broad support for network virtualization with overlay networking and underlay transport networks, SD-WAN and NAT deployments, routed networks, L2 bridges, and other network constructs is crucial for a consistent, up-to-date, and complete view of the network. Without support for all these, the topology would be full of black holes without visibility. What value does a network topology map full of unknowns have?
The power of vRealize Network Insight is the ability to traverse the network, end to end, to see the network configuration and traffic flow between any two endpoints. vRealize Network Insight’s support for many of the “intermediate” network technologies, such as network virtualization, SD-WAN, and hardware manufacturers ensures there are no blank spots when taking inventory and creating topologies.
Let’s look at a couple of the supported network constructs to see how vRealize Network Insight helps manage the complex nature of multi-cloud networking.
VM-to-VM Topologies
vRealize Network Insight’s basic “building block” for creating topology maps is the VM.
Topologies are drawn between VMs, with support for many of the intermediate technologies, like network virtualization (NSX-T, NSX-v), WAN (VMware SD-WAN), cloud providers (Amazon EC2), and much more. See Figure 1.
In its simplest form, vRealize Network Insight draws VM-to-VM path topology maps, with detailed information of the network components between the two VMs in an environment.
As you can see in this example, vRealize Network Insight shows both the overlay and the underlay information, constructing a complete map of the environment. This allows admins to quickly see the state of the network between these two VMs, troubleshoot issues, adjust configuration where needed, or tighten and improve security.
Figure 1: Virtual machine path topology
It goes beyond VMs, though—while they are still predominant in the data center, containers are becoming a standard part of any enterprise network. vRealize Network Insight supports Kubernetes container constructs, like Services and Pods, and also shows worker node information.
In addition to on-premises scenarios, vRealize Network Insight also provides insights into the VM-to-VM path between on-premises VMs and Amazon EC2 instances. vRealize Network Insight supports intra-VPC VM-to-VM paths (inside a specific Amazon Virtual Private Cloud, or VPC), as well as inter-VPC visibility (via peered connections), EC2-to-Internet, and EC2-to-Datacenter via an AWS VPN connection.
In Figure 2, vRealize Network Insight shows traffic between two Amazon VPCs. At first glance, it’s a simple visualization. But with the complexity of VPC and its routing capabilities, being able to only see the networking constructs relevant for these two VMs, and nothing else, plus the ability to see the VPC networking configuration without leaving the vReazlie Network Insight UI, is a very powerful aspect of troubleshooting.
Figure 2: Inter-virtual private cloud traffic
VMware Cloud on AWS deployments are also supported in vRealize Network Insight, as seen in Figure 3. And again, vRealize Network Insight makes creating visual representations of complex network configurations easy, so that admins can effectively troubleshoot, optimize, and prepare cloud migrations.
Figure 3: VMware Cloud on AWS topology map
In addition, vRealize Network Insight supports VM-to-VM paths in NSX-T and NSX-V scenarios, with traffic flowing between distributed routers and edge firewalls. The topology in Figure 4 shows the overlay and the underlay maps.
Figure 4: Topology maps in NSX-T and NSX-V
Additionally, vRealize Network Insight supports topology maps through NAT translations for NSX-V, NSX-T, Fortinet, and Checkpoint. This is useful because NAT traditionally is hard to visualize in topology maps. In a similar vein, viewing VM-to-VM paths through a VMware SD-WAN deployment is supported.
These examples show how vRealize Network Insight helps cloud and network admins get insights into their applications, no matter where they run or what network constructs support the application services. Via application discovery, dependency mapping, traffic flow monitoring, and topology maps, admins fully understand their applications, making it possible to first asses, then execute, cloud migration scenarios.
Learn More
This post covered the why of network visibility in multi-cloud environments while scratching only the surface of the path topology capabilities in vRealize Network Insight. The product documentation has all the details on each of the supported networking constructs.
