The Commander’s Intent

Apstra Blog
The Commander’s Intent

A young Lieutenant delivers an OPORD at Infantry Officer

Basic Course 2-95

It was about twenty-five years ago when I was given my first copy of The Ranger Handbook (with every page laminated!) and was tasked with delivering an operations order for some squad-level patrol, probably a linear ambush or movement to contact or something simple to learn on. The real goal was to teach the Army Operations Order format and gain a familiarity with it so we could use it for a variety of mission types. I still remember the five-paragraph format well and have actually often applied it to business communications, especially when starting new projects:

Situation: what is going on, what does the world look like, where are we, where is the enemy, what does the weather look like, etc. In a business context this may be applied as market conditions, competitors, market share, new products or technologies coming on, or regulatory changes.

Mission: this is where you, as the commander, state what you want your unit to do. A simple statement of who is doing what, when, where, and then the two most important parts — why, and how you measure success — when do you know the mission has been accomplished. Too often in the business world we forget the ‘Why’ — it is very important for people to know what they are doing and what it matters, how it connects to the rest of the business or corporate objectives. And ‘Success Criteria’ are very important to define up front — what does an actual ‘win’ look like, what do we consider a win versus a loss and how do we know to continue the mission or not.

Execution: This is where you get down to telling each unit in your command what to do, specifically, to achieve the mission. The goal here is not to be micro-managerial, but to give them timeframes and objectives that when all of the units work together the mission is achieved. The first part of the Execution paragraph is also very important — the Commander’s Intent.

Commander’s Intent: the first part of the execution paragraph is dedicated for the commander to restate not only what his mission is, but also the mission of the next higher up command. This is so everyone knows not only their role, but the role of their organization, and the overall mission of the next level up. This is important, not only so everyone feels connected to the mission and understands their part, but also in succession planning and mission continuity.

Support: The next two paragraphs get into Support — what resources we have available and on-call when we need them, budgets, headcount, etc and Command and Signal — how we plan on communicating throughout this mission. This could also specify email lists, Slack channels, and so on. But based on the title and focus let’s come back to that concept of Mission and Intent.

We used to joke that IT would be incredibly fun if it were not for the user. You get to feel like a kid with one of the most amazing Lego sets in the world assembling component after component and making everything work together. But when you get down to it, there is a reason that we build something. There is a reason a budget exists for us to procure all of these amazing tools. There is a mission we are expected to achieve. Sometimes it is to connect up a campus in a hospital to improve patient care, sometimes it is to create a financial trading platform to improve our order volumes and competitiveness, sometimes it is to distribute videos to millions of paying customers, sometimes it is to index the entire Internet in near-real-time. Each mission is unique, carries its own challenges, and for each mission there is an intent that needs to be derived.

Too often as practitioners in IT we jump into the nuts and bolts of a project, selecting carriers, vendors, and link types based on what we know or have used before because time is critical and we need to move fast to garner competitive advantage. I would offer, though, to take a couple hours at the beginning of each project and sketch out your own Operations Order — what is your situation, what is the mission, why is this project important to your organization, what really matters this time, and then what are the subordinate unit tasks that need to be done to ensure the overall mission is realized — take the time to describe your own and your next-level manager’s intent on this project.

Then think about applying that concept down a level. Not just by saying, “Hey guys let’s use a high radix leaf-spine network this time, ok?” But instead looking at technologies that work within this, so far, human workflow. While, according to the Gartners of the world, ‘Intent-Based Networking’ is the new hotness — the concept of using and defining your intent to achieve mission success. What is new is having a set of amazing tools available that allow us to define the outcome we want in our applications, our infrastructure, and our workflows and define them in an easy to understand taxonomy. Then using that capturing of intent to create the test plans and configurations that ensure our intent is being realized by the implementations our organizations are deploying.

By 2020, more than 1,000 large enterprises will use intent-based networking systems in production, up from less than 15 today.

Think of it as an ongoing inspection. In the military you create phase lines and checkpoints in a mission where each subordinate unit radios in to the commander to let them know their mission progress, or before graduating Basic Training there will be a formal inspection to ensure everyone’s personal gear and common facilities meet the standard expected. Inten-Based Networking systems are similar — they capture your intent and then automatically and
continuously inspect your infrastructure and applications to ensure that they are meeting your standards for your business.

Probably the biggest benefit of using an intent-based networking system is succession planning. While most businesses do not have to take as direct an approach as the military does to determining what to do if a commander is unavailable, every manager should be able to take a vacation for two weeks and simply know that while they are gone the network will continue to operate to the same standard as if they were there providing oversight for each change.

So on your next project take that extra hour and explore what an Intent-driven platform could do to improve and maintain the consistency of your operating environment while you are there providing oversight or while you are enjoying a well-earned summer vacation with your toes in the water and tail in the sand.

Composition @scale with AOS 1.2

Apstra Blog
Composition @scale with AOS 1.2

Apstra just released AOS 1.2 which is a major step towards delivering on the vision of an intent-based Self-Operating Network.

The key features introduced in AOS 1.2 allow network operators and developers to leverage and hone in their programming skills. Whether you’re a network operator learning some programming skills, or a full-fledged developer, AOS 1.2 was built for you; and you’re my primary audience for this blog.

So why is this release so important?

Delivering on the Apstra Mission with AOS 1.2

Apstra Blog
Delivering on the Apstra Mission with AOS 1.2

Delivering on the vision of a Self-Operating Network™ is the core mission of Apstra. As we have made clear, this is not an easy challenge, but one that requires careful steps forward that address customer requirements. Today, we take a significant step forward in our commitment to this challenge by releasing Apstra Operating System™ Version 1.2 (AOS 1.2). It is an exciting release because it includes significant capabilities you, our customers have told us were most important to you since GA of AOS 1.0 nine months ago. Together we have made a big leap forward towards our mission of delivering a Self-Operating Network!

What have we heard from you, our customers? Well, you told us, as a network engineer, you spend a lot more time operating your networks than building it the first time. Operating your network mainly includes the tasks of managing change operations and troubleshooting your network when problems arise.

In 1.2, we have made significant enhancements to AOS’s day two operations capabilities — both change operations and troubleshooting activities. Here are a few new capabilities that I am super excited about:

Full network transparency with powerful graph queries

The blueprint in AOS represents all the state associated with a specific infrastructure (say, a POD) under the control of AOS. It captures user intent, the topology, the specifics of the device roles and their positions in this topology, interfaces, links, the cabling diagram, all the policies pertaining to virtual networks, and all the resulting configurations for all devices. The blueprint also captures all the telemetry and the results of the tests that run continuously in closed loop to validate intent. We have always stored this blueprint as state in the AOS distributed data store, and it has been accessible through RESTful APIs and a streaming interface.

In AOS 1.2, we expose the blueprint as a graph, and integrate this graph representation as part of the state-driven distributed data store. In addition to the RESTful APIs and streaming interface, you now have the ability to visualize these relationships with ease; and use powerful graph queries to traverse the graph and get answers to any question you have about your network: intent, topology, policies, telemetry, and how they interrelate.

Anyone that has access to the AOS libraries can now get visibility into the network — the network teams, but also the compute teams, devops teams, or application teams. The network, which is traditionally an opaque entity is now fully transparent to everyone!

 

 
Extensible telemetry

You know that telemetry is important to understand how well your network is working, and we delivered on this in our previous release. In AOS 1.2, we made this telemetry extensible. Let us consider a scenario whereby you realize that it would be really nice to correlate the telemetry collected by AOS with some other piece of telemetry, say CPU on a server or latency parameters from your business application. With the extensible telemetry that we have productized as part of AOS 1.2, you now can use the Apstra development environment to collect any arbitrary telemetry of your choosing! Through its libraries, AOS will create the appropriate structures to store this telemetry within the AOS distributed data store, and you are now able to correlate this telemetry with all the other parameters tracked by AOS.

And as with AOS 1.1, you can stream all this telemetry using Google protocol buffers to any third party system of your choosing. With AOS 1.2, we have built integrations with InfluxDB and you can use Grafana for visualization.

Stage/Commit/Deploy day-2 operational workflow

You have told us that you are making 1000’s of changes to your network in any given month — adding servers, racks, virtual networks, and network policies. You have told us that you would like AOS to help you streamline these change operations, while minimizing the risk of error.

We have listened to you. AOS 1.2 now allows you to create a staging blueprint that is separate than the active blueprint. You make your changes safely in the staged blueprint. AOS algorithmically pre-validates the semantic consistency of these changes and flags any errors. These changes can then be committed to the active blueprint — at which point AOS activates the appropriate telemetry to verify that the changes you are pushing are consistent with the infrastructure under control. For example, AOS is able to tell you if the switch you plan to add is really there, and whether all the cables are connected as they should be. Inconsistencies are flagged as anomalies. Once you resolve these anomalies, you are ready to deploy — at which point AOS pushes the appropriate configurations, activates the full set of telemetry collection, and enters its closed loop, continuous validation mode to insure that your intent is indeed being realized.

With AOS’s enhanced day-2 operational workflow, our goal is to make your change operations as streamlined as possible, while minimizing the risk — this way, you can spend less time orchestrating change operations manually, and more time for other responsibilities. You can also potentially reduce the intrusion of operations on your always-important personal time! You may even have time to take our trainings to learn devops tools and Python to expand the set of telemetry that AOS collects, or learn about AOS’s powerful graph queries.

In addition to these major enhancements, we have also added new enterprise features such as the ability to snapshot various versions of AOS and the ability to restore previous backups. We have also included neat new visualizations including topology heat maps, as well as improved WebUI workflows.

Delivering on the Apstra mission

When we launched Apstra, we took on the mission to enable Self-Operating Networks. We recognized it as an enormous challenge. We were upfront that we could not deliver on the whole vision in one step — it would be a journey, just as it has been with self-driving cars. We also told you we had made a major investment in building an intent-based distributed operating system which acts as the foundation. It would scale to the largest data centers, support all your data center use cases, and allow for full extensibility. Now, with AOS 1.2, this major step forward validates our investment in our distributed operating system and shows our commitment to our core mission.

We invite you to try AOS 1.2, and experience the power of the platform. See how it can help you streamline your change operations, and get unprecedented visibility into your infrastructure. See for yourself how it advances your goals towards a self-operating network.

Ansible Automation Integrates with Apstra Intent-Based Networking

Apstra Blog
Ansible Automation Integrates with Apstra Intent-Based Networking

Things are moving quickly here at Apstra. We have so many cool things to announce in the next few months, and today we get to share a little bit about our integration work with Ansible 2.3. This update will be short, because we feel this integration effort deserves it’s own webinar. On April 20th at 11:00 AM PST Andrius Benokraitis from Ansible and Damien Garros from Apstra will take webinar participants on a detailed walk-through of the work they’ve done. So definitely sign up and put it on your calendars!

Coal Fires and Self-Operating Networks

Apstra Blog
Coal Fires and Self-Operating Networks

Recently I had the opportunity to make a series of videos talking about some of the challenges Network Engineers have in their day to day work.  They are located here:  Part 1, Part 2, and Part 3.  Specifically, I talk about how we are, in many situations, our own worst enemy.  So what kind of behaviors and thinking do we engage in that have a significant negative impact on us?  And is there a vision for getting us out of this mess?  Let’s find out, but first…

Transition to a Self-Operating CLOS

Apstra Blog
Transition to a Self-Operating CLOS

This blog is about how to transform a 3-tier (core-distribution-access) network into a multi-vendor L3 CLOS using the Apstra Operating System (AOS). This can represent a big step forward for most enterprises with big benefits including complete lifecycle automation.

Chasing Mavericks – Catching and Surfing Market Transitions

Apstra Blog
Chasing Mavericks – Catching and Surfing Market Transitions

I remember my first time surfing — Ken Hook took me out to Linda Mar in Pacifica, California early on a chilly Sunday. I bought a wetsuit, borrowed a 9’6” ‘soul board’ from Ken and proceeded to inhale enough water to fill a bathtub. I got pummeled on the swim out and turned into a washing machine, never understood how to ‘turtle’ to take a big wave, and maybe got to a knee coming back in two hours later. I didn’t surf again for twelve years.

The swim out is the hardest part for me and I have always been a fairly decent swimmer, but swimming with waves crashing into you, getting pushed back 2-3 lengths for every 3-4 you go forward can beat you down both mentally and physically. There is a magic spot though, once you get past the waves, where you can sit on your board and feel the burgeoning swells grow under you and pass by without crashing on top of you. Whether you meditate, do yoga, or just find a shady spot and daydream — that spot past the blast zone is a similar place, one that lets you experience the power and the tranquility at the same time. It is a true gift.