Your Resource for All Things Apps, Ops, and Infrastructure

Use Cases for Integrating NSX with vRealize Automation

I can spin up a virtual machine by deploying it from a vSphere template. That is so two years ago. Deploying a virtual machine from template isn’t cool anymore, but deploying micro-segmented VMs and new networks is. VMware vRealize Automation, together with NSX, can provide organizations the ability to not only spin up a virtual machine, but spin up new networks that are either private, routed, or translated. 

I’m told that just because it’s cool to be able to spin up networks on the fly, that isn’t a good enough reason to implement a technology. So what are some good reasons to look at vRealize Automation with NSX?

The dreaded compliance checklists, pesky viruses, and the new fangled DevOps movement are all great motivators for automating your network deployments. Let’s face it, manually creating new vLANs, updating routing tables, and creating IP address pools just isn’t much fun. Not only is it not fun, but whenever a real, live person gets involved, there is a chance for a mistake to happen. Software Defined Networking (SDN) solutions were invented to allow us to create rules for our networks and then let the software robots do all those little repetitive tasks.

So how about some examples of how solutions like NSX are being utilized?

Private Networks

Sometimes you just need to deploy applications for testing purposes and can’t have them interfering with your corporate network. Maybe you’re testing the deployment of a new application that modifies your AD schema. You’re probably going to want to make a clone of your AD server and test this thoroughly, but you definitely don’t want the new AD server to communicate with the old ones.

Routed Networks

Compliance purposes often necessitate that in-scope servers are deployed in a different network and are segmented from out-of-scope machines. A routed network allows you to spin up a new segment so that you can stay in compliance with your corporate security policies.

Network Address Translation (NAT)

Network Address Translation is still used in almost every network unless you’ve jumped head first into IPv6, and even then is probably used somewhere. NAT is a great tool to deploy multi-tiered apps with IP address schemes that are identical to the corporate network. Being able to do this allows you to deploy an application in a NAT network to test and then easily move it into production, while knowing that even the IP addresses will stay the same during the promotion of the app.

To take this a bit further, NSX can provision load balancing policies as well as just networks. If you’re deploying multi-tiered applications, there’s a great chance that you need to load balance some traffic as well. Automating a load balancer can really cut down the time necessary to test new applications without involving multiple teams and processes.

It’s all software right? We’re not leveraging SDN to build networks just because we can; we’re using it so that we can put rules in place and let the networks build themselves when we need them. We build a blueprint and let the solution build our servers, applications, and even networks.

At the AHEAD Lab and Briefing Center, we spend a lot of time exploring these technologies and building blueprints. You can come in and spend time speaking with us or testing NSX and vRealize Automation too. To get started, learn more about our automation and orchestration briefing below:

Build your automation and orchestration stategy at the AHEAD Lab and Briefing Center.

Defend against ransomware with our resiliency health checks.

Subscribe to the AHEAD i/o Newsletter