Well, now that some time has elapsed, I have some more thoughts — after-thoughts — about Application Centric Networking (#ACI). And I’d like to share them. I include some thoughts about VMware NSX for comparison. (#NSX). For those who missed my prior blogs about the ACI Launch:
Matt Oswalt (@mierdin) seems to have been thinking along somewhat similar lines, and gotten his words posted faster — see Cisco ACI: As The Dust Settles. It appears we are both interested in what ACI profiles mean in practical terms, and in implications concerning network and server/app team communications. And we both see VMware NSX as the other major contender.
There is also some good information in the blog My Top 8 Cisco Application Centric Infrastructure (ACI) Videos To Watch by Ethan Banks.
Sticky Points
One of the key things with any new technology is spotting where the sticky points are, where it is unlikely to scale, or where there are other barriers to adoption. Some people may think I’m negative, I’d like to think I’m … pro-active. If you know the hard bits, then you can do something about them. At least avoid running into them.
So ACI is pretty nifty stuff. What are some things that might be problematic?
Sticky Point #1: Potential Concerns about Vendor Lock-in.
Do you want to bet your datacenter on Cisco? Or, with NSX, on VMware? In the latter case, you invest in a lot of GUI time clicking to create virtual networking elements, and end up with a complex VXLAN overlay if you’re not careful. If you don’t like VMware’s prices when a new release comes out (as has already happened at least once), you have some cost migrating away from that architecture. With Cisco ACI, the migration to it has costs, and if you change your mind, can you somehow re-use the results of the migration efforts?
Sticky Point #2: Is It Incremental?
Datacenters are expensive. Few can afford to rip and replace them. So any new technologies need some degree of backwards compatibility. As I understand it, Juniper QFabric had that problem — what do I do with the costly gear if I don’t like QFabric? To some extent, there was also a cost / minimum sizing issue, at least initially. Reportedly, Cisco vBlock and FlexPod ran into that as well — the smallest chunk of datacenter for sale was too big for most sites comfort zones or needs.
Well, VMware’s NSX seems pretty incremental. Perhaps even stealthy, as in the server folks can start doing it and the network team might know about it until … it’s too late. I happen to think the server and network teams ought to be talking, when it comes to future architectures that affect both teams. Will they?
Cisco ACI is incremental in the sense that you’ll probably deploy some spine and leaf, migrate some (not too critical?) applications to it, swat any early bugs, and then proceed if you like it. It might even be a “migrate by attrition” situation, where apps move when the old hardware they’re running on needs to be replaced. Long, slow. That’s not a problem, that’s datacenter networking and being careful.
So I’m coming up with “ACI is (very) incremental”. Cisco may produce some tools and ways to accelerate that — one thing to watch for.
Sticky Point #3: Backwards Compatibility
Will either be backwards compatible? Well, with VMware, you may need to migrate stuff to the new NSX environment. With ACI, there are some claims it will play with legacy Nexus gear (doesn’t it seem early to be calling some Nexus devices “legacy”?). What are the things that don’t work in terms of backwards compatibility? I suspect provisioning may work, but the telemetry side may not be as capable. Something else we’ll just have to wait and see about.
Sticky Point #4: Will They Talk?
Matt Oswalt raises a nice point about the ACI claim translating between dev/app people and networking-ese. It offers the opportunity for network and app/server teams to work more closely. And NSX perhaps allows the server team to ignore the network team. So the question is, will the teams talk and work together, or not? My observation over the years is that most IT people don’t communicate well or often, and are highly allergic to meetings. That really has to change.
A related concern is getting the server and app folks on board with ACI.
Sticky Point #5: Profiles
Application Profiles look like a Good Thing.
The reason I’m labelling them as a Sticky Point is that they will require some learning (we’re used to that) and some cultural change (harder!). They will need to be accepted by (at least) the network, server, application, and perhaps storage teams. Well, some storage folks are highly resistant to change, so maybe they come along later.
What I see in many networks today is lack of communication, lack of planning, and definitely lack of documentation. Nobody has the time. VMware vSphere in effect is not only a deployment tool for servers, but the GUI seems to have become the documentation.
Profiles offer potential there: they in effect end up documenting the connectivity, implied security, QoS and other needs of an application.
As far as time, profiles are about agility, speed of deployment. It will take time to get used to them, and to spending time up front planning. There has to be trust that by doing so, deployment overall will become faster and more reliable. Cisco ACI apparently will also offer big manageability bonuses on the back end of deployment. I’m looking forward to seeing what it can deliver, and suspect there are some interesting future announcements coming in that space.
I’m wondering how portable profiles will be. Back-story: I used to wonder for years why HP OpenView consulting teams didn’t build up best practices rules for events, so as to provide faster value to customers, instead of spending hours tweaking HPOV over and over again for each new site. Well, if Cisco Advanced Services is going out and doing some early ACI installs, will the profiles they build be (mostly) portable, and packaged up for re-use to speed other deployments? Is there going to be some learning? A Cisco downloadable library of profiles? Or is each site going to be one of a kind?
I’m thinking of the early iPhone commercials here. Will everything be handcrafted? Or will it be more like “there’s an app (profile) for that…“, i.e. app vendors and Cisco providing a marketplace of profiles facilitating deployments?
One alternative is what I’ve seen all too often with intra-datacenter security efforts. A firewall goes in, and sits there with the ruleset being “permit ip any any” since nobody has the time to develop rules, even though they know they should. There’s also fear of missing something, leading to career risk or yelling.
ACI reportedly will use profiles as whitelists, so anything not permitted will be denied. It might be interesting to have something like “ISE Monitor Mode” which Does No Harm. I don’t see how that might work, though. And one really doesn’t want “permit ip any any” to persist, which seems likely (human nature). The old “I’m busy, and if it works, don’t mess with it.” In other words, I’m not sure what the best approach would be here. It may well be pure whitelists, and migration just means Doing It Right.
I also have OpenFlow in mind, with the idea there might be some sort of hybrid mode, business as usual, and “ACI controlled mode”.
This whole profile area definitely looks like there will be more to come.One hopes, good news, tools, etc. I’m looking forward to some of the upcoming partner training on this.
Any automation of profile building might be interesting. My mental model for it is the OPNET App Xpert Mapping process. One app at a time, a bit labor intense, but at least they’ll be documented at the end of the process. With OPNET part of the problem was excluding DNS and other standard services such as PKI / certificates, to reduce noise. With ACI, those will definitely have to be part of the profile, to permit and to establish connectivity.
Sticky Point #6: Complexity
Complexity and ease of use, power and ROI on time invested are all key factors. And price, of course.
There’s a set of screen captures providing a NSX walk-through at http://www.vmwarewalkthroughs.com/NSX/. There’s a good bit more clicking than I’d expected. Although some of that is due to the simplistic scenarios, one where some of the vSwitches connecting things do not yet exist. I’m a bit disappointed, in that there seems to be more plumbing (GUI version of patching cables and defining VLANs) than I expected. That’s the sort of detail I’m somewhat hoping ACI can avoid miring us in.
Conclusion
Some tentative conclusions:
- Small shops likely don’t need either approach, NSX or ACI?
- NSX maybe looks easier for medium sized shops, at least initially. For some value of “medium”. Maybe it isn’t size so much as style of how a shop operates. To me, FabricPath may provide such shops with all the L2 VLANs and STP stability that VXLAN can provide. Leaving the virtual machine and appliance along with VTEP-enabled physical device deployment aspects of NSX as the real value add?
- ACI may provide the most benefit to medium to big shops, at least initially. And the profiles discipline will be good for agility in the long run. I see staff number and skills as a likely factor here.
- Which one will be better for managing cloud as well? In a cloud vendor-neutral way?
It’s fun betting on horse races or technology products. Be sure to place your bet and rationale in a comment!
Yet Some Other Thoughts
Instrumentation and management visibility! This is the other shoe that Cisco has yet to drop on the competition… What’s NSX going to be able to tell me about what’s going on with overlays vs. physical network and underlay network? How will it have the ability to report on the physical network’s health along overlay paths? Resolve slowness and packet loss issues. Report high error rates (> 0.001%). Etc.
Cisco has a big cash warchest for R&D. Are they going to leverage that and put on a full court press (not “bet the company”). Some people (see The Ghost of Application-Aware Networking) view prior Cisco application efforts as underfunded. Is 200 programmers at Insieme enough, or should and will it grow to 1000 or more Cisco-wide? Not my decision to make, just curious!
OnePK was the stealthy preparation for the future, whichever one, perhaps with ACI in mind (a long-range plan?). Does OnePK make it much easier to implement the back end agents for both configuration and monitoring? (Contrast other vendors and the primitive appearing state of Puppet agents as of #NFD5?). How fast can Cisco expand what ACI can manage or at least configure?
One other thought about NSX: how do YOU feel about server admins configuring routing … OSPF? BGP?
If there’s one thing I think of with OSPF, its the need for good design, especially area design. I’ve seen some striking cases of OSPF and failure to design / implement it well. One of the latest triggering a good CCIE level question: what happens when you have a discontiguous area 0? I googled it some, everyone says avoid having area 0 discontiguous, but I don’t see discussion of what goes wrong. (Lab time, in a free moment.)
Life Log
Thanks again to #TFD (Tech Field Day), for getting me together with the crew in NYC for this event.
Twitter: @pjwelcher