Apstra has a very interesting product, particularly if you’re involved in configuring devices from multiple vendors. That is, Apstra is vendor agnostic, supporting a wide variety of switch vendors in the disaggregated switching space as well as switches from the more traditional vendors.
The company’s presentation at Networking Field Day 13 started out a bit… unpolished, differently… but soon entranced the #NFD13 attendees (techno-geeks at heart). All demo action and little marketing talk wins techie friends! I recommend viewing the streaming videos just to appreciate the different approach and enthusiasm.
What Apstra Does
The point to Apstra is “intent-based networking” and multi-vendor automation. This is mapped along with under-the-hood awareness of vendor features to deployed configurations along with a degree of error checking.
I’m personally allergic to mixing vendors in any given network or portion of a network, from a support/headache perspective, but that’s another discussion.
The Apstra offering lets you work with one or more vendors’ products of your choice, or replace one with another (subject to like-for-like constraints in terms of port counts and speeds, I believe).
Right now, what Apstra has is an intention-based engine and a working fabric model. If you’re in the business of rolling out spine-leaf fabrics with MLAG and VLANs, they can get you there in an automated fashion.
As the basic GUI and automation engine are now in place, Apstra feels their tools can help others automate in a broader range of use cases — some of which they plan to tackle next. Or which you might tackle. Their offering does seem to be getting some favorable attention from a selection of big and smaller organizations.
Some Design and Value Philosophy
To me, the value proposition with Apstra is related to two recent themes:
- Various organizations and people saying things like “Everyone needs to learn to program, or at least talk intelligently to programmers”
- Blog discussions of cloud vendor economics
You may be wondering how the two are related.
To get their costs down, cloud vendors have to automate. Employing huge numbers of people to deploy and manage at cloud scale is a fail. It will not be precise enough, nor is it viable in terms of ongoing costs. Rumor has it that various wannabe cloud vendors have discovered that the hard way.
Turning that around, only cloud vendors and large companies can afford the costs of doing automation well. I’ve previously built a twisty maze of scripts and programs, and tried to train others to use it and maintain it. The bugs, corner cases, and need for user friendliness improvements and feature enhancements just keep on coming. I’m not ever going to do that again, if I can help it! My name for it: “fiddle-ware.” As in, requires constant fiddling to make it work.
Well, there’s a third possibility, which I’ve been calling “canned products” — where somebody foots the bill, spreading the costs across multiple customers. As in commercial, supported automation platforms. Cisco ACI, Cisco APIC-EM and related apps, and some others perhaps fit into that category — Cisco-specific, of course.
Supported automation is good for most of us. It does mean we have to learn to live within the constraints, and not customize the heck out of things. We can build our skills and spend our time on higher value things, and perhaps a broader technical range.
Conclusion: The Apstra engine might just be the canned (supported, commercial) multi-vendor automation tool the rest of us have been waiting for.
I say might, because the NFD13 delegates saw some great demos, but weren’t exposed to the underlying tools Apstra uses to make things happen, nor to exactly what goes into building the model describing the intent around what’s to be built. I think I heard “Ansible” and “YAML.” I do like the idea that some smart, careful people built those models for us, and will take on the job of fixing them as bugs and ways for users to get into trouble occur.
This leads us to cattle versus pets, as in standardization versus one-off designs. I’m noticing that a lot of people still do one-offs. That’s a habit we all need to break.
Along those lines, for a given fabric, sure, you might want different VLANs and names than I do; that’s just branding the cattle differently, so to speak. (PETA disclaimer: No cows were actually branded for this metaphor.) It’s still a fabric.
In thinking about designs I’ve done over the last several years, unless the customer needs something exotic (FabricPath, OTV, LISP, Datacenter Interconnect), the designs are really pretty much the same.
Here are what I think of as the common building blocks for enterprise networks:
Campus
- L2 to access layer (I don’t like it, but some people/requirements need it)
- L3 to access layer
Datacenter
- Older L2 or L3 to access layer models, 2-tier or 3-tier
- Newer spine-leaf fabrics (MLAG-based, or “raw” VXLAN, or VXLAN + EVPN, or ACI automated)
WAN
- There are some new design models both NFD13 SD-WAN vendors brought up that I’ve recently been discussing/considering in other contexts (I’ll save those designs for future blogs)
- Layer 2 WAN/MAN VPLS, MetroEthernet, whatever (Not a fan of point-to-point EVCs for a WAN)
- Routed WAN, single or dual path, where path = MPLS, DMVPN, or some form of IPsec tunnel
- The above with IWAN or SD-WAN for traffic shifting when there are link quality issues
Internet Edge
- OK, the Edge gets a bit more complex; most of those seem to be one-offs. I still think there are only one or two basic designs there.
If you’ve been paying attention, Cisco tools like Nexus Fabric Manager, or APIC-EM/IWAN, or Glue Networks, or SDWAN are automating those.
But! The basic unit of what is being built has shifted. We configure a fabric, or a WAN, or a datacenter, or a big chunk of a datacenter. Yes, individual devices get configured, but they’re the cattle — they’re not really the focus anymore. Which is good!
I’ll say that again: It’s all about “configure the fabric” for values of fabric equaling campus, datacenter, or WAN.
Apstra does that with fabrics. You describe the fabric you want, it builds the BOM, in effect, and supports your deployment, down to the level of verifying the cabling.
End result: working fabric, built far faster than if done manually, cabled correctly. One person required to rack and stack per the plan, one moderately skilled person putting in the fabric specs (number of spines and leaves, number of edge ports needed, desired link speeds) and picking from the matching vendor switch models. Oh, and someone to write the check and buy it all.
In other words: cost and time savings.
Apstra is getting advice from Doug Gourlay, who recently wrote a blog that resonated with me: SDN: What It Should Have Been. Key points:
- OpenFlow is an interesting 1.0, but are there real use cases?
- Scale requires simplicity
- Cloud requires automation
- Skills gap
If Apstra can get the job done in less time and with less technically skilled staff, and tell you when something basic (connectivity or configuration) is wrong, isn’t that a win?
Potential Issues
The obvious considerations: product in early days, lots of potential, maturity, bugs, company viability.
Right now, Apstra does a L2 datacenter switch fabric. Getting from there to L2 campus is probably pretty easy. L3 datacenter or campus, a bit more work. As far as WAN, the SD-WAN folks have that covered.
I do keep thinking “all hardware is not equal.” But Apstra lets you pick the vendor and hardware you want to use. So no problem.
Thought: Is this a step toward flipping value back to private clouds?
I’d say it’s a step in that direction, but there are several remaining steps needed. Service catalogs and server and container automation, security — there’s a lot more value that a cloud provider supplies. Cloud is not just a pile of hardware in {your, colo, Amazon’s} datacenter(s) (pick one or several). Nor is it a network-only pile that was automatically configured. The network fabric is the foundation for the rest.
Links and Other Blogs
If you want to learn more or see the demos (NFD is big on demos), be sure to check out the streaming videos of Apstra presentations and related blogs. There were also some hints about coming features.
Other blogs and links of interest:
- The Datacenter Network You Wish You Had
- Apstra Intents Greatness Beyond Sparta
- Apstra: The Intent-Driven Cure for Network Blindness
Comments
Comments are welcome, both in agreement or constructive disagreement about the above. I enjoy hearing from readers and carrying on deeper discussion via comments. Thanks in advance!
