Automation & Programmability
Showing results for 
Search instead for 
Do you mean 

Empowering the Tool Builders

by ‎04-04-2014 04:26 AM - edited ‎04-04-2014 11:44 AM

 

Pradeep Sindhu, Juniper's CTO, inspires us to "Connect Everything and Empower Everyone".  I believe in this message.  I've spent the better part of the last two years working directly with the Field, exclusively focused and with the expressed purpose to create value around Junos programmability and automation.  The networking industry is going through a multi-dimensional paradigm shift.  It is not about SDN, it is not about leaf/spine datacenters, and it is not about NFV.  It is about choice and control - it is about empowerment.

 

I believe our industry needs better tools.  Network Engineers don't need to be programmers - that is an artifact in the lack of good tools.  By way of comparison, look at the innovators in IT – the server teams and DevOps movement – they have incredible tools.  These tools do not require their user-base to be programmers; but it helps of course.  The innovations and advancements in server automation and tooling has strongly been a function of: (1) time, (2) the open-source community and (3) orientation around business value.

 

 

The networking industry has been stuck at "Mr. Red" and at best "Mr. Orange" - unless they have an army of software engineers creating custom networking management software.  Most customers, if you ask, will tell you they simply want better tools – they want to be "Mr. Yellow".  Better tools – what does that mean?  It means they want tools that they can extend, without requiring them to be a programmer, without going back to the vendor for feature enhancements and waiting, and waiting, and waiting.  They want tools to be in the open-source.

 

There is a difference between products and tools - a necessary and important distinction.  A product is something that a vendor can sell that serves a business value which in turn can monetized.  A tool, at least in the content of this discussion, is not motivated by "monetization", but by the need to complete a job.  Perhaps a tool can be monetized, perhaps not.  For each of the major DevOps IT Framework companies (Puppet, Chef, Salt, Ansible) there is both an open-source and a commercial offering.

 

There is a vicious cycle that occurs in network tooling because it cannot be monetized (or at least thought not so).  No-one builds good, vendor-agnostic, open-source tools because there is nothing "in it" for them - there is no ROI; there is no business plan.  There are many, many large companies that spend a lot of money, time, and energy building their own internal, custom, closed-source networking tools.  They don't write these tools because they want to; they write these tools because they have no choice.

 

Network Engineers are now faced with an even bigger problem – our world is orienting more heavily around APIs, automation, and programming.  Network Engineers are made to feel that they have no choice but to learn to be programmers or they will become obsolete.  They need a way forward to help them up the learning curve; not to becoming better programmers, but to create better tools.  We can help them.  We simply need only to follow the same historical success in DevOps.  It is on the "shoulders of giants" that we can move forward.

 

 

Who will build the IT tools for networking ("Mr. Red") that will empower Networking Engineers to effectively leverage automation technologies ("Mr. Blue") that will in turn define the user experience for effective Operations ("Mr. Green")?  I don't have these answers, but I know we need to empower the tool builders. These tool builders may be Network Engineers or they may be from DevOps.  They may be a collaboration of the two.  Consider what if Facebook open-sourced multi-vendor networking tools and drove the industry much in the way they are doing with the Open Compute Project (OCP) initiative?

 

As a vendor in the networking industry we sell products.  I believe we must empower tool builders.  We can do this by creating the technology that aligns to the philosophies, design principles, and community engagement we see in DevOps.  The Junos "Python EZ" micro-framework is simply a result. 

 

Everything I've done flows from this belief – Empower Everyone.


-- Jeremy (@nwkautomaniac)

 

Comments
by David Gee
on ‎04-04-2014 07:20 AM

Great article Jeremy.

 

Reading that left a giant smile on my face. Extendable tools that are built on an easy to understand and well documented framework would help accelerate the adoption of tools in the networking space similar to what the compute and storage technology streams have already experienced. As heavily sweated assets, we do not often have the time to learn anything other than what we need to. It’s the age old business adage of running hot to maximise output.

 

I feel a change coming. As a fraternity, more of us are picking up arms and learning technology that we know will change the face of what we do without direction from employers, a drive to becoming the blue man is already underway and you can feel the excitement coming off the page when reading articles from yourself, Kirk Byers, Jason Edelman and Brent Salisbury [insert many more people here]. It’s a great time to be in the industry.

 

For those who are wondering what all of the fuss is about, enterprises more often than not get used to the tools provided by VMware, the ease of use of a public cloud offering such as RackSpace and the overall experience of a dramatic reduction in time to market. The network is the last ‘person’ to come to the super cool kids party. It’s time to have a shave (trim not butcher), don some new clothes and burst in to the room. This however isn’t as easy as putting on a Hawaiian shirt and walking in with a Mojito; a thinking shift has to happen. For something to change, confidence needs to be built by the people who are responsible for taking a kicking when things go wrong. VMware has done this over time but has been successful due to the cost savings and rapid time gains from the painful 'provision to tin' history that we all come from. There have been car crashes along the way and there will be enterprises that have had their fingers burnt more than their fair share, but the gains outweigh the damage most of the time. How many times have you experienced a VM being created but have had to wait for the network change to be accepted by a board of technical and non-technical people? With flexible and well understood networking tools, the cultural change that’s beginning to emerge already will start picking up pace. I welcome the opportunity to become part of the Intel blue posse.

 

Keep up fuelling the fire!!!

by
on ‎04-08-2014 06:19 AM

Great article, Jeremy!

by Juniper Employee
on ‎04-16-2014 11:08 PM
Very well written and thoughtful article Jeremy.
Announcements
Juniper Networks Technical Books
About the Author
  • Ben has been working with service providers around the world for the last 15 years developing business cases for a variety of product concepts and new ventures. Ben holds an MBA from MIT and a BS & MS in Mechanical Engineering from Johns Hopkins University.
  • Part of Juniper PS EMEA since 2005 Primarily interested in making technology do the boring repetitive work so I can do fun new work.
  • Donyel Jones-Williams is the Director of Service Provider Product Marketing Management overseeing all of Juniper's Service Provider Products for Juniper Networks. In this role, he leads all of the internal and external marketing activities for Juniper with respect to routing, automation, SDN and NFV. Prior to joining Juniper Networks in January 2014, Donyel was a Senior Product Line Manager for Cisco Systems with in the High End Optical Routing Group managing product lifecycle for multiple products lines helping telecom providers operate efficiently and effectively including; ONS 155xx Product Family, ONS 15216, ONS 15454 MSTP, Carrier Packet Transport Product Family, ME 2600x, & ASR 9000v. He also negotiated favorable agreements with 3rd-party vendors furnishing components and parts and conducted both outbound and inbound marketing (webinars, case study-development, developed and delivered both business & technical at Cisco Live 2005-2012). Donyel graduated from California Polytechnic State University-San Luis Obispo with a Bachelor of Science in Computer Science. While attending Cal Poly SLO he was a collegiate student athlete playing football as a wide receiver and a key member of the National Society of Black Engineers. Donyel is now an active volunteer for V Foundation.
  • Dwayne loves everything related to automation and enjoys talking about it: Automation benefits outweigh any associated disruption.
  • Ebben Aries is a Principal Engineer for Junos Manageability in the Juniper Development and Innovation Division.
  • Marcel Wiget is a member of the Routing TME team. His career within Juniper started back in 2009 as a Senior Systems Engineer driving one of the first MX based Broadband Edge deployment to success. Prior to Juniper, Marcel held various positions in pre-sales, professional services and development at Chantry Networks, Spring Tide, Nortel Networks and Wellfleet.
  • Michael Pergament, JNCIE-SP #510, JNCIE-ENT #23, JNCIP-SEC
  • Pallavi Mahajan is Vice President Engineering, Junos Engineering, and leads the Junos Programmability & Automation teams
  • Product Manager, JUNOS Automation