There was a chicken-egg problem I have been fighting for the last ten years – management platforms, for networking, are woefully behind, because of the networking systems interfaces They don’t expose many of the advanced, and very necessary, capabilities of a network. Why? Because exposing them is damn near impossible through a non machine readable interface, with no MIB support, no programmatic write capabilities, no ack/nack function for whether the command took, no programmatic roll-back capability, etc. The networking products have done very little/nothing to make it easy for management platforms to expose their value. For some companies I would argue this is almost by design, for many others they could just never get around to it.

Omar Sultan recently brought up a good quote from Henry Ford, to the effect of- “if I asked the people what they wanted tehy would have said a faster horse.” When I said the CLI was dead for cloud providers most everyone argued back either a) how the CLI was still useful for troubleshooting (I completely agree, btw). or b) How GUIs never replaced the 1:1 functionality of the CLI.

I never said GUI… I never said CLI was gone for troubleshooting….

I did say we needed a programmatic, versioned, machine-readable, extensible, easy to develop to, API that allows machine to machine communication and instantiation of network policy. Doesn’t have to be a GUI- could be XML/SOAP/XMPP based though….

dg

The Network is already Cloud-Ready, its the management systems that are not up to the job. Today’s networks are a marvel of loosely coupled design and implementation. The Cloud needs tightly coupled capability and that means management software, which doesn’t exist, and hasn’t been delivered successfully for the last twenty yeats.

And if the CLI is dead why did Microsoft (of all people!) introduce Powershell.

My response to this – http://etherealmind.com/2009/08/15/networking-cloud-ready-software-needed/

The GUI’s from the incumbants can get you through the basic setup – but the real power toys to tune and optimize still lie in the CLI.

The heart of the issue is that the admin GUIs are being written by a new geneartion of “developers” who have never used a CLI; they drag and drop widgets, toss in a couple of radio buttons and a pulldown and it’s all good. If the GUI was so good, how come it has a pulldown to ssh or telnet into the CLI?

Cloud products will need to be configured, managed, upgraded, monitored and backed up with a toolset that will allow access to the full set of product features yet provides intuitive (dare I say simple) output that a machine or a human can interpret.

Wouldn’t it be cool if the incumbants could clean the slate and design a product where the hardware, core O/S and management software all worked together in harmony?

I guess that would take away the opportunities for all those third-party developers; who would need their products if the incumbants built it in to the product?

Product management at equipment vendors should start revisiting the talent they have in their EMS team(s) to see if they are ready to shoulder the responsibility of driving the feature development process. As providers gradually expect real integration APIs, that’s where the burden will end up. Next step of course is to have open and well defined interfaces for direct device touch. NETCONF (http://bit.ly/kx19H) and YANG (http://bit.ly/4gTlNr) are good proposals but the political implications are vast.

Lots of stuff to think about.

1. End to end QoS has been seen many false starts (ATM, RSVP/IntServ) – it will be interesting to see if this will be any different now, especially when multiple network providers are involved.

2. Recognition that business as usual is not going to cut it is the first step. My box, my management system and how pretty my GUI looks, etc. is not a strategy for the long term. I am optimistic that vendors will address this – especially by recognizing that they cannot do it all (unless you are the biggest network equipment vendor). Partnerships/acquisitions might be one approach.

3. Agree that CLIs are not very interesting to a cloud provider who is looking for a greater degree of abstraction. It will still be a preferred power user configuration on a per box basis but how often you will need that is a debatable point.

Minor issue – there is a typo in the following text – should be “…know exactly…” instead of “…now exactly”