Cisco ACI, VMware NSX and Programmability

One of my readers sent me a lengthy email describing his NSX-versus-ACI views. He started with [slightly reworded]:

What I want to do is to create customer templates to speed up deployment of application environments, as it takes too long at the moment to set up a new application environment.

That’s what we all want. How you get there is the interesting part.

I'm now at the point where I can supply a YAML file to a python script and the environment is deployed on ACI. Next is programming vCenter to link the VM's to the port group.

And yes you've got me here. I guess programming to vCenter + NSX would be easier?

As always, you have to figure out where you want to add value. Do you want to develop scripts (or Ansible playbooks or whatever other tool you might want to use) that will do the job in your unique snowflake, or would it be better to use off-the-shelf tool that already gets the job done, and then adapt your environment to whatever those tools can work with.

Cloudify and Terraform immediately come to mind. Cisco CloudCenter or VMware vRealize Orchestration might be a good fit for you environment (and you’ll be locked into something anyway). I’m positive there are tons of others.

Usually it makes sense to start with what your users care most about (= application deployment tools or cloud orchestration systems) and work from there. Starting from “we have this cool product or technology” and then going down the path of “let’s develop all the glue we need to make it work” might be a cool project, but maybe not the best use of resources.

Speaking of glue, keep the number of moving parts in your infrastructure to a minimum. The more moving parts you have, the more probable it is something will break, and the more fun you’ll have troubleshooting it (it does sound like a wonderful job security, but let’s not go there).

In the specific example of NSX versus ACI, assuming you’re bound to work with vSphere (some enterprises still prefer using familiar products instead of jumping into the Linux/KVM/OVS/whatever waters), figure out how many tools from different vendors you’d need to get the job done when you use one or the other product, and then select the simpler one (assuming it can meet your requirements and scalability goals).

In the ideal world you’d start with your application deployment tools using a well-established cloud orchestration API. Right now the most popular two are AWS and OpenStack, which means (assuming you have to use vSphere) you might consider VMware-integrated OpenStack (VIO). It uses vCenter, VSAN and NSX behind the scenes, so things keep working once you create them even if OpenStack sucks. Unfortunately I have no idea how stable VIO is though. Feedback and alternatives are highly appreciated.

4 comments:

  1. Would it make sense to start with the tools that are already used in this environment to deploy and configure the rest of the application stack, and see if you can extend / complement them to include the networking piece?

    P.S. AFAIK there is very good coverage for vSphere and NSX-v (through PowerNSX) in PowerShell.
    Replies
    1. Interestingly, I'm sitting in a PowerShell session at this very moment ;) Yes, PowerShell is great for configuring vSphere and NSX objects, but if you want to start from application deployment recipe, there's still some glue to be deployed.
    2. Brings to mind your recent podcasts talking about SaltStack and StackStorm, doesn't it? ;)
  2. Azure Stack supports the resource template deployment model from Azure. That coupled with PowerShell DSC can build and control the configuration drift of really complex topologies/architecture.

    How do you do it right now? You need developers.
Add comment
Sidebar