Network & Security VMUG Community

Back to discussions
Expand all | Collapse all

NSX and public cloud

  • 1.  NSX and public cloud

    Posted 01-31-2019 09:55 AM
    Good Morning Everyone,

    My current employer has a heavy push by corporate to investigate public cloud and savings. When so much interest is placed on cost savings, have any of you been able to sell the benefits of NSX on AWS, AZURE, etc.? The interest here is to stay as close to native applications and any NSX discussions seem to skew that conversation or planning.

    Thank you for your input on this matter.

    Sam Teel

    ------------------------------
    Sam Teel
    VCIX-NV, VCP-DCV6
    Sr Network Engineer,
    MAXIMUS Inc.
    ------------------------------


  • 2.  RE: NSX and public cloud

    Posted 02-01-2019 11:47 AM
    Most public offerings have layer 2 links, but NSX-T is still tough to find in these environments and less than reliable.  The extra cost of bolting on NSX-T or layer 2 extensions for public cloud would off-set the cost savings to some degree.  The 'close to native application' argument is also tough to decipher, as I am not sure if you currently use NSX to any degree, VXLAN backed networks, or what.  I may be biased, as I work for a cloud service provider that offers NSX-V backed public cloud which is possible since we run on ESXi, but I would recommend a small to medium sized cloud service provider as the time and attention during deployment and design that you may not get at AWS or Azure could go a long way in ensuring your as close to native applications as possible.

    ------------------------------
    KEVIN HEMLER
    1989
    Reisterstown MD
    ------------------------------

    Original Message


  • 3.  RE: NSX and public cloud

    Posted 02-01-2019 12:42 PM
    Hi Sam,

    I think the first thing I'd point out is that Public Cloud and cost savings aren't typically a cohesive bundle, if you're just looking at straight numbers.  If pure cost is really the driving factor, you're probably better off looking at ways to automate, and drive efficiency with your private cloud.  If you've been tasked with investigating the options, you might want to start by going upstream and digging deeper into the business objectives, outside of cost.  Why public cloud?

    For example, is there a need to accommodate spiky workloads? Is there a need to reduce risk?  Improve application or decision response times?  How about reducing operational overhead? (Be careful with that one, as some people may think it means reducing headcount.)  Is this a DR play, Dev/Test, or for Prod workloads?  Is the long term play to migrate to SaaS or PaaS for as many apps as possible?

    Lots of questions to help define the use cases and drivers behind it.  Once that is more clear, you'll be closer to answering your NSX question.  Personally, I see NSX driving benefits for consistent security, reducing risk, enhancing automation for infrastructure delivery or disaster recovery, etc.  That's where NSX makes a ton of sense.  If reducing risk, or driving efficiency is looked at as a cost reduction, then you've got a great argument to bring them together.

    Final note: NSX will continue to tighten the integration with all major public IaaS services, and our perspective is to create a seamless bridge between all private and public clouds.  If you currently leverage any other VMware tools in your private cloud, such as vRealize Operations, vRealize Automation, SRM, or others, there may be an even stronger case for integrations, and consistent architecture and monitoring for your future hybrid cloud.

    Hope that helps provide some clarity on how you could approach it.

    -Brad

    ------------------------------
    Brad Gunderson
    Staff Systems Engineer
    VMware
    ------------------------------

    Original Message


  • 4.  RE: NSX and public cloud

    Posted 02-02-2019 08:07 AM
    I'd second this - "cloud native" apps, which is what I assume the company are seeking, tend to leverage "direct-to-web" networking - the app presents an internet facing URL, and secure exchanges are managed through L7 encryption (i.e. TLS):   the network isn't really something that comes into it.   You may have some kind of peering to your own network, but this will happen at L3: for the cloud native stuff, it's usually just redirection of URLs or some subnets.

    On the flipside, if you're building IaaS in the cloud, then NSX-T can be really useful for abstracting your cloud-providers networking into something you control.
    Where is really becomes amazing, however, is when you start stretching:   want to scale on-premises infrastructure to the cloud without having re-IP hosts, or re-engineer firewalls: NSX-T might just save you all that work.   Want to go "Poly-Nimbus" and have your infrastructure live in multiple cloud-providers, but without the hassle of each one having independent networking (and their own challenges:    try sending an ARP in Azure and see how far it gets!) and NSX will remove all that complexity and cost:   stuff gets deployed with a consistent network configuration and "just talks", without having to worry about getting the subnets added and routing configured between the sites.  You just do that once.

    NSX abstracts the network, in the same way that ESX abstracted servers - if you abstract your VMs and your networking properly, they will "just execute" wherever you place them.

    The cost savings appear in terms of firewalling and configuration (as well as less routers etc) and of the ability to do "infrastructure stuff" far quicker than having to stop and redesign every time a new subnet is required.

    ------------------------------
    Steve Bristow

    ------------------------------

    Original Message