Recent events have shown us that successfully landing on the moon is anything but routine and no easy feat. Somehow it seems we are surprised. Thats puzzling.
I recently read The Last Man on the Moon: Astronaut Eugene Cernan and America’s Race in Space by Eugene Cernan and Donald A. Davis
* NASA Images Photo by Astronaut Tom Stafford
Gene Cernan was the 3rd human to undertake a walk in space.
- We are coming up on the 59th anniversary of the first human EVA by Alexei Leonov in fact (March 18, 1965). It seems effortless to float around in space but the facts tell a different story.
- Ed White would be the second human to “float around in space” on the Gemini 4 mission just weeks later (June 3 1965)
- Gene Cernan left the Gemini 9a Capsule on June 5 1966
His EVA would be by far, the most ambitious and complex. It would ultimately be aborted. It involved exiting, working his way to the rear of the capsule (without any kind of auxiliary propulsion mechanism to make his way there or handholds), unpacking and putting on a “Jet Pack” (Astronaut Maneuvering Unit) and testing it out for the Air Force.
Handholds
While reading about this, it occurred to me that maybe thats why it has been so difficult to achieve the promise of automation. Looks easy..just floating around but really it takes tremendous effort and skill and ultimately it would take improved climate control, anti fogging material, handholds, specialized tools, and portable propulsion.
Thats what we need in Network Automation! EVA handholds and targeted propulsion!
In fact, strategically placed handholds, a clear understanding of the challenges, and the effort and skill it will take.
That thought has been rattling around in my head ever since.
Jack and the Magic Bean Tool
Just recently, I had an interesting exchange with a prospective client. This client was struggling with automation. The client had shared some clear use cases with our sales team. Our sales team had gotten us in front of the right audience, the networking team technical manager.
I spent three days working on a demo which showed how we could provide a significant automated solution for the clients use cases. I don’t usually feel good about demos but in this case I truly thought we nailed it.
We get on the call and the technical manager confirms his pain points. I know we are going to hit it out of the park.
I present the use cases we automated and then proceed with the live demonstration.
This involved observability, customized solutions, CMDB and ITMS integration.
As we all know, if you are the only one talking it is not a good sign. We demo the “money shot” again and still crickets.
Turns out our technical manager had solved this problem before…many years ago… with a free tool (the technical manager could not remember the name) and just a click of a button. Along with that revelation, the frustration of having to do some things manually when years ago it was done at the press of a button by this free nameless tool comes out.
The technical manager went on to say that while we had demonstrated a solution, they were really busy right now and would not have time to move forward.
I am rarely speechless but in this case I had nothing constructive to offer. I can’t say my heart rate reached 180 beats per minute like Gene Cernan’s on his space walk but it got up there a bit. How do you compete with a free tool from years ago that automagically automated (real or imaginary) the process.
And it hits me. The technical manager thinks automation is an effortless space walk.
What to do with these epiphanies?
There is some good news here.
Through the efforts of
– the Network Automation Forum bringing together the community
– innovators bringing us tools for critical functions like observability (Stardust Systems SuzieQ and SuzieQ Enterprise), sources of truth (really looking forward to what the OpsMill solution brings to the table), automation frameworks, orchestration platforms
– digital learning communities including Kirk Byers, Packet Pushers, Packet Coders, Network Automation Nerds, O’Reilly and so many others
– formal training and educational programs at the university level
i think we are on our way to making infrastructure as code a reality.
Eventually space walks became efficient (if not effortless).
Thats the good news but we still have signifiant gaps.
Ive talked about the ingredients. We now need the recipe. Make no mistake. It is a recipe and that is gap #1. It is not a tool. It is not hiring a Python developer.
You don’t have world class chili with an onion and some bay leaves. You need an onion and the bay leaves and many other ingredients skillfully put together in a very specific way with appropriate tools to make your world class chili.
How did we manage to successfully land on the moon?
Requirements, Tooling, Process and time to fail and find what works.
A structured path to the goal is always the answer to complex problems. Lets take a page out of NASAs book. Lets start setting some Mission Objectives.
Every mission had specific and discreet objectives in furtherance of the goal to get a man on the moon and return him safely to earth.
– Can we successfully launch a spacecraft and orbit the earth?
– Can we survive in space?
– Can we break out of the earths gravitational pull?
– Can we maneuver and dock in space?
– Can we land on the moon and lift off again?
– Can we survive re-entry and land with some level of precision?
– Can we recover if something goes wrong?
* Meadville Space Center Historical Documentation
The Mercury, Gemini, and Apollo programs were built around that goal and the steps needed to get there. This included specific equipment, tools, techniques, capabilities, and procedures needed at each step. Sound familiar?
Mission Objectives
Establish a multi-discipline and cross functional process of automation for the provisioning and operation of an organizations network infrastructure utilizing cloud and DevOps techniques and principles to achieve efficiency, predictability, reliability, and ultimately help the organization achieve its business mission.
We will call this “Infrastructure as code” for now.
Organizational progress will be measured in stages from beginner to intermediate to advanced: Mercury > Gemini > Apollo
The Mercury stage
Specifically, this beginner stage of Network Automation will seek to:
- Demonstrate the ability to execute simple automation activities on data
- Demonstrate the ability to execute simple automation to obtain state from live network devices (read only)
- Demonstrate the ability to execute simple automation to change configuration and verify state on live network devices (read/write)
- Demonstrate the ability to capture configuration standards in a template usable and customizable by automation
- Demonstrate the ability to use revision control systems to keep code and templates under revision control
- Demonstrate the use of these simple automation capabilities to solve a specific, well defined low impact network problem or gap
- Consider options for sharing automation across a team or teams
- Consider the levels of testing and verification which will be required for any change
- Demonstrate automated component testing methodologies
- Determine the existing teams and tools required to successfully automate a common cross team but low impact function
- Develop a skills matrix and understand any gaps
- Establish lines of communication and champions across technical teams and their management
- Establish the guiding principles of the Enterprises automation initiative. Clearly articulate the mission statement, acknowledge the complexity, stress that success will involve everyone and that every failure results in necessary knowledge.
The Gemini stage
Specifically, this intermediate stage of Network Automation will seek to:
- Evaluate the use of Frameworks in the Mercury automation functions
- Evaluate the use of Observability systems in the Mercury automation functions
- Evaluate all the data sources (sources of Truth) and their corresponding systems/tools required for success in their use in automation
- Demonstrate use of APIs
- Demonstrate the ability to use revision control systems to keep code and templates under revision control by multiple team members
- Consider options for sharing automation across organizational processes
- Demonstrate automated component testing and verification methodologies for proposed changes
- Demonstrate the use of multiple systems, frameworks, and observability tools to solve a specific, well defined problem or gap of moderate impact
- Evaluate existing APIs for automation suitability
- Develop go/no go criteria for automation
- Re-evaluate skills matrix and progress towards addressing gaps
- Evaluate organizational structure roadblocks
- Evaluate recovery methodologies
- Develop structured cross organizational communication and collaboration process. Silos must be obliterated.
The Apollo stage
Specifically, this advanced stage of Network Automation will seek to:
- Demonstrate the ability to orchestrate a change at scale
- Demonstrate the ability to execute automation across systems
- Demonstrate the ability to execute component and system testing and verification
- Demonstrate the ability to automatically trigger an automated process
- Demonstrate the ability to execute automation using continuous integration, continuous delivery processes
- Demonstrate the use of multiple systems and orchestration to solve a specific, well defined problem or gap of critical impact
- Develop recovery methodologies
- Review Organizational structure and evaluate it for efficiency and streamlining given the new processes
- Develop a structured cross organizational funding process. Funding silos must be obliterated.
We talked about the need for this type of structure at Autocon0. The above is just an example. I’m eager to see what is in store for us in the upcoming Autocons with respect to this topic.
Automation is not a space walk or a tool and its not going to be easy. I get no one wants to hear this.
Maybe acknowledging that is the first step.
…unless someone can remember the name of that tool…