IS IT REALLY ACI VS. NSX?
The Software-Defined Networking (SDN) world has been ablaze the last 12-18 months around mainly Cisco’s Application Centric Infrastructure and VMware’s NSX. Many feel it is a knock down drag out fight between those two. The question is, does it need to be?
One of the biggest challenges I have seen is that each vendor tends to go into their customer base with the network team or the virtualization team, not both. For many organizations that have teams divided like this, a silo-based sales route will often end up as a losing proposition, not just for one of the vendors, but more likely the customer.
The reality is that you need everyone involved in a Software-Defined whatever-you-want-to-call-it (SDN, SDDC), which means we have to get application, network, server, storage, and virtualization teams involved collectively.
Application profiling is key.
The real fight here should not be about choosing one vendor or the other, it should be about change in general. That change is about us knowing how our applications work. The goal of software-defined architecture is to define policy. How do we permit an application to talk end to end properly with all the Layer 4-7 services? Answering this question ultimately forces us to know what is traversing our infrastructure and how. There are too many cases where application teams are asked how the application communicates and what ports with blanks looks like in response. Policy-based networking will force an organization to be on top of this and to monitor activity. Ultimately, this means a lot of design, planning, and research to develop these application profiles before going live. Once complete, your organization will know exactly how each application communicates and traverses your network. Think about how much easier it will now be to troubleshoot your applications because they are properly documented and profiled.
Current networks have been the “Wild Wild West” – anything goes until someone makes a new law. While you can still implement SDN architectures like that, SDN is really a catalyst to drive change. This change will make application implementation much easier and faster in the long run. You could implement this new architecture stronger than ever with an “Implicit Deny All” strategy no matter which vendor you choose.
Think about how you can profile a multi-tier application:
The profile would contain the firewall and load balancing rules, how to access the front-end servers securely, and how server-to-server communication occurs. There would be no need to go to the separate firewall and load balancing appliances to put specific rules there. Instead, it would all be done for you via the SDN L4-L7 integration.
On top of that, those servers would not be accessible via other services unless you explicitly state they are due to the “Implicit Deny” architecture. On the flip side, decommissioning applications becomes a lot easier. How many times have we seen firewalls, load balancers, and ACL’s with entries that haven’t been touched in years simply due to fear or not knowing the affect? Now, you can get rid of the application profile in the SDN architecture and it removes the firewall and load balancing policies as well!
You don’t have to choose just one.
Don’t feel like you have to be locked into one SDN strategy either. There is no unicorn out there that does all SDN components well. Keep in mind that Cisco ACI and VMware NSX both cut off abruptly at the data center. Many situations could even call for both ACI and NSX in the same data center. One example could be the need for a multi-tiered application that has some physical servers on the backend. ACI could control the application profile for network access while NSX would handle the micro-segmentation and firewalling for front-end virtual machines based on Active Directory attributes. It all comes down to requirements. You would still need to look at things like Cisco’s APIC-EM to support your Enterprise LAN and WAN policy.
All teams have ownership with SDN.
Within the data center you have to ask many tough questions. Who will manage NSX or ACI? Will it be the server team or network team? The best answer is that it really comes down to everyone. In almost all SDN architectures there is the concept of Role Based Access Control. That means application folks can help define application specific policies and network teams will help manage network functions such as routing, switching, etc. Again, it comes down to that topic of change. Everyone now has ownership in the architecture, and we can’t look at it as being just the network team’s baby.
But how does either architecture affect visibility and troubleshooting for all teams involved? Even though NSX is independent of hardware, you will still have to have a solid data center infrastructure in place. You may want to consider if the network hardware can see what is happening inside the overlay network. Does that drive choice if an upgrade is pending?
The best thing you can do for an SDN strategy is to get everyone in the room, then work together to define the requirements and set the goals. Having a partner such as AHEAD come in and help define that roadmap, based on our experience with SDN strategies, can help weed out a lot of the challenges. We have the luxury of being able to test and demonstrate technologies such as ACI and NSX in our AHEAD Lab and Briefing Center. Soon we will even have both of these technologies integrated in our lab along with integration of L4-7 services such as F5, Cisco SourceFire, and Palo Alto.
To see these technologies in action or learn more about SDN, request a briefing led by our team of experts at the AHEAD Lab and Briefing Center.