I left my position at Juniper on Friday. It was a happy-but-bittersweet parting because I really liked my team there. I received good cheer and wishes for great success and votes of confidence from nearly everyone. It’s really heartwarming and I get a bit misty thinking about it.
People who know me in my life as a computer geek know me as the network guy who will use any excuse to write another script. This is true. I’ve always been fascinated with the power of computers to allow a person to do more than he would be capable of alone. They say time is money. I say that well-directed code is time.
At early points in my career I remembering adding VBA logic to my Word and Excel documents and developing templates in Visio to make my workflow easier. This is the same thing as what I do as a network engineer: Remove the boredom of repetition.
Repetition does have a purpose. I used a lot of it when I was preparing for my JNCIE-SP exam. With a little study, I already knew the concepts for that test. The rest was a matter of practice and getting faster at doing things.
But once you have achieved the goal of learning or habituating something unfamiliar, the repetition no longer serves a purpose to you and it starts to make sense to code it away. This has always been a part of my work. When I am being self-deprecating and humorous, I say it is because I am “lazy”. When I am glorifying myself, I say I’m working “smarter”. The truth is somewhere in the middle.
I am moving on to join Salesforce.com to steep myself in the datacenter environment and to help them to build systems that will deploy and support their networks. For all of the scripts that I have written so far, they have managed to be useful tools with longevity but have not yet added up to a sustainable and supportable system that would stand long after I leave. This is what I hope to achieve.
This is an exciting time for me and other code-friendly network operators/engineers/architects. And it is a tough challenge to tackle. A lot of systems people consider the network as a black box, as a given, as a fundamental requirement that you do not mess with. Indeed, even some level of network state is required to configure the network devices effectively.
People often wonder in their blogs why the network has lagged servers in becoming agile, virtualized, and orchestrated. But servers couldn’t have become virtualized and orchestrated without the network already there connecting everything.
So deploying servers depends on the network being there. And complex network deployment depends on the of the network being there. This makes deploying the final network state a meta-problem. How do you deploy the network and guarantee you’re not breaking it and your ability to fix it? How do you change state as frequently as needed without killing your network devices by a thousand tiny cuts?
I don’t feel defeated by these thoughts. These are the challenges. These are the interesting sorts of problems to solve. And I intend to spend part of this week thinking about it, and part of it resting, and part of it just reading, and part of it writing posts like this one.
See you soon.
-Franco