It’s because I had an Aha! moment when they walked me through what AOS is and how it intends to change the way networks are managed. I’ve experienced these sorts of moments a few times in my career and they’ve always led to transformational shifts in the industry, and for me personally, as I grew in my career.
I came out of school with a Computer Science degree, only to put it on the shelf because I joined one of the networking giants where the world consisted of protocols, and the knobs I needed to tune to make those protocols work just right. I spent a lot of time helping network operations and engineering teams manually configure those protocols via CLI into services that they could deploy for their customers and applications. HyperTerminal and putty were my hammer and chisel, and I loved every minute of it… even the time wasting from repeatedly entering the same commands over and over. What a ride!
Aha!: Model-driven Automation
It wasn’t until I became a network operator and service provider that I had my first Aha! moment: I needed to automate, and it had to be model-driven.
Internally supporting the various network teams that all ran different architectures for different services, all deployed on multiple islands of vendors that rarely inter-operated, I quickly realized that designing and certifying all of these services and vendor equipment was not sustainable. It took us several months to qualify a single code release and validate all of the combinations of architectures they were meant to support. After all of that, we had to hand it off to the teams that would build, deploy, and operate these services and equipment, which took several more months.
Finding no network management tool or element manager that would adequately handle the scale I needed (even for simple configuration management) I turned to the next logical step… design and build a system from scratch that would take care of inventory, configuration, state, service modeling, deployment, risk assessment, and baking apple pies… all while having a high level abstraction layer for the services and the devices that supported them. Easy!
Aha!: Sources of Truth come first
It was easy enough to design this massive model-driven system… it was another to actually build and deploy it. The enormous complexity involved in this venture uncovered another Aha: without clean sources of truth, you can’t automate a single thing!
Having gotten to a point where we were deploying a router from scratch using model-driven automation methods, we got stuck with dirty IPAM, non-automated DNS management, surprise equipment, and surprise configurations. Cleaning up these sources was crucial to moving forward.
The Apstra Aha!: What Intent means
Finally… the reason I couldn’t wait to join this amazing team at Apstra:
Coming from a background where I had to control every aspect of the automation and the configurations it managed, it was hard to imagine that there was any other way that I could get clean, safe, repeatable results. CLI? Humbug! Scripting? Amateur hour! Massive aircraft carrier of an automation system that I spent many years and millions of dollars implementing and deploying (and likely millions more maintaining)? Sign me up!
But with Apstra’s AOS… Aha!: what if we started questioning the premise of network complexity that we have always considered inevitable? What if we started designing our data center networks with proven and scale-tested reference architectures? What if we started off with a clean break from the older architectures that supported older applications? What if we didn’t care HOW our networks were deployed as long as they did WHAT THEY WERE INTENDED TO DO and within the security, redundancy, and performance requirements that our modern applications demand? (Oh yeah, and you can do this without caring who the equipment vendor is underneath).
This is Intent. Apstra did not eliminate configs, security, or performance. They took all of that mountain of work we previously had to do and groomed it, integrated it, validated it, and abstracted it. Now, instead of wondering what the command was for that one BGP knob, datacenter engineers and operators can focus on enabling the applications that will move their business forward.
Intent is not the latest buzz word or marketing label, it’s a profound improvement in how we build and operate complex systems and Apstra has used this powerful innovation to build a platform for managing the entire network as a system, not a collection of features. I believe in that vision and intend to help others as well in my new role at Apstra.
I strongly encourage network engineering and operations teams to think about what this transition means for them. The freedom from mundane tasks is valuable. The peace-of-mind from knowing that there’s a system that knows how the network is supposed to run and will tell you exactly where your problems are is priceless. Take a look at what Apstra has to offer your organization and schedule a demo. You’ll be pleasantly surprised.