/var/blog
/var/blog
Is it really One Junos?
09.20.17

For years, Juniper has talked about its common operating system strategy, frequently short-handed as One Junos. The basic premise is that Juniper leverages a common operating system across the majority of the portfolio. And the theory is that commonality breeds benefits. 
 
Since we started talking about One Junos, people sometimes bring up examples of things that might be exceptions to the rule. Maybe the code has branched for some reason. Or some feature is not available on all platforms. Or maybe there are competing ways of doing something on a platform.
 
Internally, I used to be known as the One Junos guy. It wasn’t that I drank the Kool-Aid. In many ways, I was the one making the Kool-Aid. So I wanted to write a bit about my thoughts on the subject.
 
Does One Junos matter?

 

 

junosprotocols.pngThere are all kinds of ways to argue this point, but let me choose perhaps the simplest. If you were starting from scratch and you had to build a portfolio of different solutions, would you choose to stay convergent or divergent? Forget all the reasons that you might want (or even have) to diverge. If given the option, would you choose to be common or uncommon? 
 
You can argue the merits of common components and common development environments and common release cycles. Individually, you could probably argue either for or against them. For a particular component, you could debate the value. But in aggregate, commonality is a lot like freedom. We frequently have vigorous debates about the merits of freedom of speech or press or religion or assembly. But in aggregate, freedom is better than tyranny. Similarly, commonality is better than divergence. 
 
But why?
There are certainly arguments to be made around engineering efficiency. These translate into pricing advantages for customers and accelerated innovation as resources do not have to be spent reinventing the wheel. Common components can be tested once on reference platforms, which also means that test resources can be used working the edges rather than retesting a foundation that ought not vary.
 
These same benefits extend to customers. If you are deploying a single platform, the savings is zero. But once you expand beyond one platform, you get tremendous leverage in your qualification, training, and even tooling efforts. By the way, if everyone else is using the same thing, you also get the benefit of their work.
 
Having common APIs also creates a stable shim layer between the devices and the surrounding infrastructure. If you have integrated tooling or automated workflows, the API commonality means that platforms can change over time while the scaffolding around those platforms remains mostly constant. 
 
In Old IT speak, I would sum up the argument as driving lower TCO. In New IT speak, I’ll make the case that commonality reduces complexity, which is the most basic requirement for improving agility. 
 
But Junos is not all common!
Yes, it is true that Junos is not 100% pure. There are areas where we have made sacrifices or design decisions. There have been compromises based on attributes like performance and scale. We have at times chosen expediency over perfection. 
 
But ask yourself this: if you did not value the commonality, would you care where we have fallen short?
 
The reality is this. Customers like the commonality. They take advantage of the leverage they get across platforms. And this value, when it’s first unlocked, is hugely addicting. And so people notice when we stray from our values. They notice not because it doesn’t matter, but precisely because it does. The fact that customers can tell me with ridiculous detail the configuration differences between platforms tells me that it matters, not that we have failed. 
 
Undoubtedly, we can and should be better in some areas. As the One Junos guy, I have never claimed perfection. I have simply asserted that there is value in being more common. So if you find yourself agonizing where we are not perfect, stop and think a moment. Does that not mean that you wish we were? And if that is the case, then how do we compare to other options in the market?
 
By the way, even at our most divergent, if you use lines of code as a measure, Junos was probably on the order of 80-90% common. If you used configurable options as a measure, that number certainly drops a bit. Commonality is obviously buoyed to some extent by copious amounts of foundational code. But even when we were at peak drift, the vast majority of Junos was actually common. 
 
The bottom line
I don’t entirely know how I came to be the One Junos guy. It always just made sense to me that, given the choice, people would prefer a single operating system. It’s such a basic concept that I always felt a little embarrassed to explain it as a strategy. It’s really just good engineering design.
 
In fact, I imagine the reason it’s not more common is because while simple to say, it’s actually insanely difficult to do, especially as the portfolio grows beyond a single class of products operating on a narrow set of capabilities. 
 
Most of the arrows I have taken over the years were not aimed at the strategy. People didn’t question the premise so much as our ability to execute against it. They didn’t say a single operating system was bad. They said it couldn’t be done. I always took that as validation of the approach. 
 
Even today, I won’t say we are perfect in our execution of oneness. But I do think we are driving a whole lot of fairly unique value in our pursuit of it.

Top Kudoed Authors
User Kudos Count
29