A Wedding Thank You and Season's Greetings on our 1st Anniversary by James Kelly

Together in Paris, September 2018

Together in Paris, September 2018

One year has flown by. Two bands are now melded onto our ring fingers. Three days of celebration stories have been shared over and over. Seventy-seven guests need to be thanked. Thousands of flowers have colored countless happy memories. And at least a million emojis have been exchanged between Linh and James. All of this since our wedding day, November 19, 2017.

Oh… and a number that most people don’t know: all of them. That’s how many celebrities across the world thanked us for providing them peace for a day because our wedding seemed to pull all the paparazzi. Kidding aside, we’re still so thankful for all the photographers, organizers, musicians and staff, and hope all our friends caught the albums we shared.

On our first anniversary today, Linh and I are back together in Hanoi, and we are reflecting back on our year, especially on our wedding day, one year ago.

Thank you!

Our gratitude is the best place to start, not only because it’s Thanksgiving this week in the States, but because our wedding happiness was truly magnified by those of you that attended and celebrated our union.

Many of you traveled so far and filled the day with so much love. We have been fortunate to see many of you through 2018 so far, and others we still plan to visit. Either way, everyone has been in our hearts and memories when we often think back to our wedding day or watch the photos go by on our digital photo frames at home. It was such a beautiful day. Thank you for being there for us to all that were able to make the hike. And to those that gave to our Worldvision cause on Crowdrise, we value your kindness and generosity. 

Since our Wedding

We’ll never forget the wedding day’s the sore cheeks from laughing, the hugs, tears and cheers of love, and tearing up the dance floor all night. Speaking of Felicity (the dancing queen that night), we can’t wait to see her, Edward, Victoria and Rob over New Years. For Christmas, we’ll be in Nantwich, England with Barb and Michael. And working backward from now, here’s a quick recap of our 2018 together:

  • We’re in Hanoi and Phu Quoc, Vietnam this week to celebrate our anniversary, seeing many friends and family, especially our dear Minh Anh and her team perform their choreographed dance in traditional Ao Dais at a school show

  • Front row at the Jay-Z and Beyonce OTR2 concert in Vancouver

  • Traipsing around Paris to revisit our old neighborhood and remember our stint living there in 2015

  • Catching up with Jeroen and Giang in Amsterdam

  • Wine tasting in the Yarra Valley, and drinking Magics in Melbourne

  • Visiting Hieu Down Under in Sydney

  • The inaugural camping trip in BC with dad Kelly and Minh Anh, and a BC wine tasting tour in the Okanagan Valley with Jill and Abhik

  • Cruising around Copenhagen, Oslo and Stockholm

  • Standing in the sakura snow of the Kyoto and Tokyo cherry blossom festival

  • Remembering and honoring dad Pham at his funeral after he sadly passed in January

  • And getting warm by the fire and sharing holiday family meals around the table with dad Kelly and Minh Anh in Vancouver

It has been another fast-paced, jet-setting year for us as my manager keeps us busy as usual, and by my manager, I mean my wife Linh. The only slow stuff has been waiting for Linh and Minh Anh to get their paperwork sorted to be able to come Stateside…something it seems will take at least until the summer of 2019.

As we proceed into the holiday season of Thanksgiving, Christmas, New Years and Lunar New Year, we are very blessed and happy to be spending time with family and friends. Thank you for being a special part of our wedding and our lives. We wish you friends and family much love and joy this season.

-James and Linh

The Tale of the Network Automator: From Knight Errant to Engineer by James Kelly


Podcast on YouTube

Perchance the temptation of technology and for certain the pangs of toil have persuaded some networkers to stray from the path of the CLI and *IE certification race.

Swinging APIs, they’ve heard, is the promised land and wielding shiny tools like Ansible can, not only confirm their chivalry, but also chase away any lament of rote configuration changes and misfortunes of fat fingers.

“Tonight, Sancho, we drink from the cup of automation. And we will be safely protected from any insurgent application issues rising to the heights of our virtuous network.”

Chapter 1: Initiation

And so once upon a time, after the ecstasy of donning the automation helmet and downloading a few horses, networkers looking for a rite of passage into the world of automation looked bravely in the mirror and said to themselves, “what is there to do that’s dangerous around here?”

The way many networkers made haste to an automation quest was ostensibly with all the strategy of the ad hoc adventures of a knight errant, looking to prove their worth.

These trailblazers were defined by the natural signposts in their workflows, by vendor toolkits, and by tools imported from the far away land of sysadmin. And so, often under the tutelage of nothing but their own trial and error, the networker knight errants learned to conquer a couple of the workflows that they were presented with, slaying manual steps one by one.

Chapter 2: Calamity

Shortly thereafter, while riding proudly toward a well-deserved weekend, the knights were so enchanted with their new weaponry and so pleased with themselves—their heads, swollen with victories, may have tightened helmets to their heads—that their attention and vision was impaired. And it was while fantasizing of their next rout that the slings and arrows started flying.

The actual assault is not important: a sudden unreachability, an impetuous line-of-business change request, a cloud VPC meltdown. It was as unexpected as it was inevitable. For some of the knights the affliction would uncover a weakness in armor. For others, it may have been the sting of the automation sword that was erratically swung and cut the wrong way, this time automating and thus swiftly amplifying an accident.

Chapter 3: Dedication

For some beginners, the setback of an automation blunder was so vexing that they turned back to peasant life. For many however, after finding their feet again and after some commiseration with knight companions, they found the strength to press on, carrying the lesson of their lapse forward to not repeat that unforgettable venomous mistake.

In knighthood, the networkers aspired to be so valiant and so adroit that they got the notion that if they’re doing it right, they won’t have difficulties. But difficulties, it turns out, are precisely the best circumstances for learning.

Ergo, the knight automators that persisted and persevered learned to be magnanimous with themselves first and foremost. To uphold future reliability, they resolved to automate around the woes that wounded them. In this way, an indiscretion, once defeated with automation, would never weasel its way back to a second sour encounter.

Chapter 4: Trials

Again and again in the hardship of automating their accomplishments, the networker knights became more astute and attuned to their environment. They began forging their own armaments and virtual squires to do their bidding. They also became less foolish and blunt on their escapades, taking what was useful from other toolsmiths and intrepid automators with software engineering skills.

In their training, the knights’ tenacity grew used to absorbing the lessons of failure, but they grew tired of the disrepute and thorns of trial and error.

As fortune would have it, one day they encountered software sages that spoke of staged replica battles. “But what is the use of repeating the past if we have integrated its teachings?” the knights inquired. “Not the past;” explained a sage, “we stage in preparation for any future change and crusade with many possibilities accounted for and tested.”  Testing and practice ahead of affronting a matter: it sounded ingenious, and so the knights too started building training grounds to rehearse their affairs.

Through testing, stressing and staging, and then automating and strengthening that preparation work too, the knights became known for their fastidious preparation and resulting dependability to conquer new projects and change conquests in production, and now with less havoc than sorely familiar from the past. Soon they became so mighty that their automation could take on more incessant action and circumstances of increasing variety.

Chapter 5: Consummation

Becoming even more zealous about automating trials not to error, the knights decided to consummate their erudition and experience by taking new identities as knight engineers.

See, each knight’s struggles and the many stories shared at the inns gradually made them less wandering and more disciplined and deliberate about their path. Their practice became more ritual and rigorous, and their automating more rewarding. Through their evolving wisdom, they had transformed from errant to engineer, worthy of an order or iron ring.

In due course, through tournaments and their own track record, the knight engineers decided they could not be passionate, proud engineers unless they could also measure and show their success. After all, they vowed reliability to others. And so, they decided to build public displays for every pledge of reliability that would maintain accurate assessments of their results. Constructed with even more automation, these displays objectively told of the current conduct and past performance of the systems in their lands.

Ultimately, so well-known these reliability signs of service became, that the ardent automation engineers are today called network reliability engineers.

Coda: The Canons of NRE

There are two discernable standards to which the knights held.

First, reliability was their utmost value. They determined that at the base of the hierarchy of needs for their service, if the network was not measurably reliable in the ways they promised, that nothing else mattered. Instead of trading off reliability with other values like agility, efficiency and so on, these boons were incidental because they first solved for reliability with automation.

Second, engineering is the best road to take as an automator. The processes and skills of software engineering guide far better than getting consumed with happened-upon technology, tools and APIs. Networking workflows are the battleground in which to practice automating and a brilliant place to start ad hoc, but ultimately the rigors of software engineering will provide strategy and structure for the tactics and tools.

For more on the culture, skills, processes, behaviors and common technologies of network reliability engineer (NRE) roles and teams, look to the famous older cousins: site reliability engineers (SRE). Check out the free online SRE book and my past blogs.


Thanks to the NREs, SREs and network automator forebears for your inspiration, enlightenment and advice in putting together the 5-step journey to automated NetOps. With that guide, may the path of forthcoming automators be smoother and more straightforward than your own story.

Cliff Notes Translation

For those unfamiliar with the famous humor and satire of the book Don Quixote, the above story and style may require some explanation. However, I suspect that those, even the slightest bit attentive to the network automation space, can see the parallel between this metaphor and real life.

Here are the Cliff Notes of the stereotypical story:

Chapter 1: Not looking before they leap into automation, many people progress in a rather ad hoc manner, tuning tribal knowledge and apparent workflows into an opportunity to learn while aggregating manual tasks. This is mostly governed by the tools they know or those put in front of them—which may or may not be the best tool for the jobs at hand.

Chapter 2: Many people get stung by automation in one way or another. Especially with config management automation, one small issue could easily get propagated to a massive blast radius. Change workflows aren’t the safest place to learn, but they are the most infamous for some reason. Automating directly in production when learning and without testing is also a catastrophe waiting to happen.

Chapter 3: Continuous improvement and learning is always the foundation of good automation. People learn that small changes and sometimes small mistakes are where the lessons lay to help discover what to automate next. This can be taken all the way to NRE concepts like chaos engineering, where failure is induced on purpose.

Chapter 4: The rigors of software engineering like test-driven engineering, continuous integration and delivery (CICD) and automated deployment are critical to success and safely moving quickly, instead of trading off reliability for velocity. Automation is learned in pre-production and environments like labs or virtual labs. Over time, engineers also create well-tested in-production continuous response.

Chapter 5: Instead of relying on only general monitoring tools, NREs, like SREs, engineer what matters most: service-level indicators to objectively measure success of higher-order service goals and promises. With the help of data, they manage their way to truly measured continuous improvement.

Podcast on YouTube

image credit blitzmaerker/pixabay

Introducing NRE Labs by James Kelly


“The 80s called and they want their CLI back.” Until recently, that was basically the beckoning call of the network automation and programmability plot. Like a broken record, the replayed attention on tools and APIs talked of new NetOps technology, but it didn’t paint a picture of the promised land. It didn’t provide a map and it didn’t prepare anyone professionally.

Today, as Network Reliability Engineering (NREs) roles pave the way from CLIs to SLIs and other higher-order SRE-inspired methods and metrics, the picture of automated NetOps is crystalizing. Juniper Networks has elaborated the 5-step map of the journey. And now, with the launch of NRE Labs, Juniper is introducing the virtual training camp to support the trip to the promised land. It’s open—open source and open for use—and it’s by and for network engineers.

People are the greatest asset or predicament to any transformation like automating NetOps, so this is where the focus was on democratizing NRE learning for all.

An Automation Dojo in the Browser

For most network engineers, automating has either been an ad hoc adventure, or the barrier to entry has stopped engineers from starting. And without the right roots, asking for automation from network engineers is like asking for pears from a pine tree. Hands-on time is needed to form the software engineering skills and experience needed to architect and automate.

Providing a cheap, quick and easy solution, NRE Labs is free and easily accessible. It includes live terminal access to one’s own network devices and linux systems, right in the browser. Each learning lab topic is pieced apart into lessons that are, in turn, comprised of short lab steps that each take only a couple minutes. This is important because it eliminates those overwhelming obstacles to getting started with hands-on learning.

  • It removes the risk of learning by trial and error in production

  • It doesn’t require a sign-up and doesn’t have a classroom or a teacher

  • It doesn't require a long download or physical or virtual lab setup times

  • It doesn’t demand expertise or painful piecing together of all the background infrastructure

  • It demands zero prerequisite knowledge of tools and programming

Without any major impediments, anybody can jump right in and click through a few lessons right in their web browser.

The main NRE Labs runtime sponsored by Juniper Networks is available at: https://labs.networkreliability.engineering

Learn by Doing

Education that isn’t applied is quickly forgotten. That’s why the topics and lessons in NRE Labs are organized into real-life NetOps contexts and workflows. NRE Labs is also built with useful systems and tools that are widely available and applicable to network engineers today.

NRE Labs was created to be accessible to anyone, so it starts from scratch with a learning topic for basics, but users can move around lessons as they see fit. Other topics include troubleshooting, configuration, testing and verification. In the future, additional lessons will take these topics deeper and additional topics will take learning broader. This includes covering the spectrum of NetOps workflows; structuring automation and infrastructure as code with gitOps rigor; evolving troubleshooting into proactive testing; orchestrating testing, delivery and deployment with a pipeline; and using telemetry and analytics for monitoring and measuring service-level indicators and automating network remediation and regulation.

Open for Contributions

NRE Labs needs to be open to democratize learning across different networking environments, but it’s also open to keep up with the rate of and scale it to all kinds of innovators broadly automating their networks that have something to share.

The NRE Labs back-end infrastructure and front-end lessons are all open source as the NRE Learning Antidote project and code repository on GitHub. The project’s documentation explores some background on the Kubernetes-based Antidote infrastructure and explains how to run a standalone instance of NRE Labs to develop, test and contribute improvements and lessons.

For the express documentation, Juniper has open sourced the NRE Labs project summary as a poster.

While NRE Labs is live today, it’s in tech preview and we’re looking for quick iterative progress over delayed perfection. We welcome contributions! Other than curriculum development, some of the back-end work revolves around hardening and scaling the infrastructure and shortening start times of network nodes. We’d also greatly appreciate front-end work such as mobile optimizations. Suggestions are welcome and are already flowing in. Use the project’s issues tracker on GitHub to find work or share feedback.

To be Continued

Notice that NRE is learning created by and for network engineers and free of external marketing. You can use it anonymously, but we hope you’ll tell us what you think. 

Beyond learning new NRE and automation skills, NRE Labs aims to spark new, open conversations to listen to or chime in. Follow @nrelabs for updates on new content, improvements and more. We also created an #nre_labs channel in the Slack spaces for the Juniper Engineering Network (EngNet) (Join here) and the vendor-neutral space run by Network2Code (Join here).

Please spread this day-one news and follow the blogs as lessons continue to roll out.

See you in the community,

@mierdin@cloudtoad and @jameskellynet from the NRE Learning Team

This blog was originally published at https://forums.juniper.net/t5/Enterprise-Cloud-and/Introducing-NRE-Labs/ba-p/381850