Ethan Banks Not writing about IT.

Friday News Analysis: Lightweight Junos for Cloud Builders on an Open Switch

F

Finally! An Open Switch With a Reliable Operating System (Juniper)

Today, Juniper Networks announced a fundamental transformation in the networking industry. Until now, disaggregated networking software and hardware has been in the domain of only those customers who had a large amount of resources to take “unproven software,” combined with original design manufacturer (ODM) hardware, and then self-integrate and deploy.

Other customers will have a new option to consider moving forward. Juniper announced the OCX1100 that combines the carrier-class capabilities of the Junos® operating system with Open Compute Project (OCP) enabled hardware that is maintained by Juniper’s award winning 24×7 support services. Alpha Networks will be Juniper’s ODM; the hardware has been submitted to OCP for approval.

Another cringe-worthy title from the Juniper marketing machine, which is too bad. The “fundamental industry transformation” costume wasn’t needed. (We should try that on the podcast. Packet Pushers — fundamentally transforming the networking industry…EVERY. SINGLE. WEEK.) Ahem. So…um…in short, Juniper has entered the whitebox switching fray. To poke at the quote a bit…

  • Every NOS vendor releases unproven code. That’s why we most of us wait for a couple of point revs to go by before installing the new shiny version. To uniquely categorize all NOS vendors (Cumulus and Big Switch for starters) as “unproven software” is silly, and should send up a red flag to any reader. Do a POC, and see how whatever NOS you might like to run works in your environment when that NOS is running the feature set you require. In my experience, the vendor producing the code is decoupled from the quality of that code.
  • The 24×7 support services notion is not unique to Juniper. Dell Networking offers similar one-stop shopping for support if you are going the open networking route. This early value proposition is attractive, and will become a normal thing over time, I strongly suspect. OTOH, JTAC hasn’t impressed me that much. It’s nice to be able to call someone 24×7, but only if they can help. How well is JTAC prepared to support this specific platform? Time will tell, and while my expectations are hopeful…they are not high.

Okay, stepping away and thinking this through, is this announcement interesting? Do we care that Juniper has made a lightweight version of Junos targeting cloud builders that runs on at least one switch slated for the Open Compute Project? Eventually, most of us will care because of what is represented by this move. This means that Junos should be able to run on other open switching hardware, which highlights something key — for many consumers, the silicon is becoming less of a differentiation. Rather, the OS is the big deal. And frankly, Junos is a nice environment to work within, at least from my perspective. On those occasions when I come down from Whiteboard Mountain and enter the Valley of Configuration, I’d rather walk through that valley with Junos than just about any other CLI I’ve used. And the CLI isn’t even the big deal, really – it’s about the other configuration options available to me with Junos as I look towards automation.

But think bigger picture. Juniper has taken Junos and placed it on a whitebox switch. Arista could certainly do this. Harder for Cisco to get there for some flavors of their OS (I suspect), but the Nexus 3K & 9K lines are at least partially merchant silicon. Right now, it’s still leaders who are stepping into this model of “buy a whitebox, run a NOS of your choice” model. But how long will it take for market pressure to insist that all networking vendors offer this sort of flexibility? Some have already gotten the message and announcements will be coming, although I can say no more about that for now. Assuming this networking consumption model takes off, the economics of switching will change dramatically as the customers catch on to the trend and sort out how to make the most of it. Lots of moving parts here (customer operations, capex/opex modeling, hardware compatibility lists, pushback from investors who don’t want the sales model to change, etc.), so it will take years to settle into a new normal.

Read more of the hand-waving post here.

Read a much more technical post about the Juniper OCX1100 here. (When you read “Atom” for control-plane and go whaaaa? Think OCP spec. Bulk buy, lowest possible cost, very specific consumer the OCX is aimed at. Not most of us.)

9 comments

  • So, I think you might be being a bit hard on our friends at Juniper. Maybe a better way to have phrased it is that the JunOS codebase is battle tested – more so than any code from an emerging vendor can ever be. There is a certain amount of maturing that comes from behind broadly deployed that cannot be attained otherwise. While I have no experience with JTAC, I think you could likely extend the same concept–that they likely seen more of the interesting things that turn TAC engineers’ hair grey than folks just spinning up their support staff.

    Regards,

    O

    • Your point is reasonable, Omar, and I agree that deploying broadly across a customer base reveals bugs that QA teams do not. That said, I’ve had so many negative experiences with software from “battle-tested” code trains from various vendors, that I can’t give Juniper’s assertion much credence. I think they are making a weak argument.

      That’s not to say the other open NOS code trains from the startups are wonderful. They’re probably rough around the edges. I don’t see how they can’t be. But if I’m the customer, I assume nothing. I’ll take any code I’m considering for a production environment, and beat on it before deploying. It’s got to pass muster, whether it’s from Cisco, Juniper, Big Switch, or anyone else.

  • At least to me, code that’s been shipping since 1998 is more “battle hardened” than code that’s been running in the wild less than 2 years and I suspect that’s what they mean by unproven. I certainly agree in that context.

    I agree that new releases adding features need some “proving” as well but to me at least that’s a different thing.

  • ‘Battle hardened’? Often, I find this means scarred, patched up, drinks heavily and requires regular therapy in order to function. I’d favour the young private who’s read and understood the memoirs. I’ll provide my own proving ground.

    • Scarred, stitched and medicated is still better than cavalier, over-confident and un-tested in my opinion. When the chips are down I want a marine not a cadet every time.

      Proven isn’t something shiny and new at least by most people’s definitions.

      • I understand that point of view, I’ve held it for longer than I haven’t. Nowadays, I think it holds us all back and we need to be more open to new things.

        If you can test it and prove it, why not? Sure, be cautious but lets not forget the baggage that comes with the old and the lessons that have been learnt and applied to the new.

        Regarding Marines, Cisco’s hasn’t had my back for a long time!

        • I’m open to new things and agree that if you know the use case and can test adaquately you should be ok. I’m just trying to make the point that juniper making the statement that their os is “proven” seems reasonable certainty when compared to a newcomer.

          Marine and cisco reference had me laughing!!

  • Ethan,

    with regard to, “When you read “Atom” for control-plane and go whaaaa?”, i suspect that an atom is still faster than the 1200mhz and 600mhz processors we have in our 7600 and 6500 vss respectively, and remember, since it will all be run from a SDN controller, it’s basically only programming the hardware which it should handle just fine…

By Ethan Banks
Ethan Banks Not writing about IT.

You probably know Ethan Banks because he writes & podcasts about IT. This site is his, but covers other stuff.

Get the details on his about page.