I have worked at Juniper in various capacities for the past 11 years. I started off as an engineering trainer, teaching our engineers how to develop on Junos. The classes I developed and delivered included a heavy dose of architecture, a bit of product training, and some obligatory process topics. In the hundreds of classes I delivered over the first few years of my career here, I learned pretty quickly that my students had an emotional tie to two specific areas.
Let’s face it, engineers love architecture. Our software and hardware developers love hearing the ins and outs of how we design and construct our platforms. But beyond that, they wanted to know about why we made certain decisions and what our more philosophical positions were. To that end, the stuff that really killed in these classes was the magic behind our engineering DNA and what was important to us as a company. Looking back now this might not seem surprising, but in the moment I guess I didn’t fully appreciate how deeply the need to understand not just what we do but why we do it is ingrained in an engineer’s psyche. .
So after 11 years at the company, how would I describe our engineering philosophy? In a word, maybe it all comes down to karma. We all accept help when we need it, but it is perhaps more important to give back when you can. So whenever I get a chance to do something meaningful for the people and organizations who have helped us become a networking leader, I jump at the opportunity.
Juniper’s flagship software, Junos, has a 15-year history with the FreeBSD community. At the heart of Juniper’s network operating system is a FreeBSD kernel. FreeBSD provides the underlying software architecture on top of which Juniper delivers its networking capabilities. The networking functionality is basically a set of applications that run on top of FreeBSD. The kernel then handles all the communication between these applications, along with basic OS stuff like memory allocation and scheduling.
Juniper doesn’t just use FreeBSD, we actually expose it to our customers. For instance, if you log onto a Juniper platform, you can access a FreeBSD shell, which gives you some pretty nifty tools. You get access to a file system so you can move things around (configurations, logs, etc). We actually make extensive use of this internally in our lab environment. We have a system set up so we automount directories so that our engineers can just copy configurations and binaries from their Unix directories onto devices they are testing on. We also use many of FreeBSD’s debug and tracing faculties. In that regard, FreeBSD is more than just a component in our software; it is in fact a big part of engineering life more broadly.
When you benefit so heavily from the work of so many selfless individuals, you just have to give back when you can. So when I found out that the FreeBSD assets were moving from a datacenter in Santa Clara to another datacenter literally right across the street, I jumped at the opportunity to help. The cluster administrator for the hosting datacenter reached out to one of our FreeBSD committers and asked if we could provide some switches so they could support the work. In response, we gave them three EX3200s with full support contracts – free of charge.
In the end, this is just one more way that we can help serve a broader community. It wasn’t the first and it won’t be the last time that we try to pitch in and help out. But the experience reinforced what I knew from my years as a trainer. Our engineering DNA is strong here, and when we have the chance to give back, people will go out of their way to be a part of it.