Open Letter to Cisco: Improving the DevNet Developer Experience
What I wanted to do today is, show you some of the challenges, My teams and I are having interacting with DevNet.
This is the developer portal, that you guys put up. To help ease teams like mine and find access to API documentation, software development tool kits, and both closed and open source code.
My Perspective
I’m a CCIE. I have automated and some large data centers using a wide range of API’s. I’m not a great programmer, luckily I hire people who are. My software development teams and I are building our own application stacks.
They run and put on Amazon right now. Our goal is to make sure that they easily and automatically deploy onto UCS platforms. And Nexus 9000’s, 5000’s, 7000’s with cool open source projects like OpenStack and OpenDaylight get integrated with them.
Feedback - DevNet is Impossible to Use
I’m going to tell you something, that’s probably really hard to hear. It is near impossible, to use DevNet to find information that we need to be able to achieve our goal. I think that’s your goal, helping guys like us integrate our software with gear like yours.
Example - Finding SDK’s and API Docs
The first thing, a really easy example, a basic thing that you’d want to do or that you’d want a developer to help a team be able to accomplish, is find SDK, find API documentation, and find software development tool kit. To allow us to hook into your gear.
However when me or anyone from my teams attempt to navigate to through devnet to find API / SDK’s the default is to pop us to a product page that has nothing to do with software development.
Instead of having my first and easiest navigation option go to the software that I’ve already made the decision to go ahead and integrate, I get sent to a product page that is trying to influence me to buy a server.
I’m looking for the information of, how I can integrate it. Why another product pitch? It makes no sense, absolutely no sense.
The Hardware is Not Important, the API and SDK’s Are
I don’t care what hardware data sheets there are. It’s not important. I’m looking at programmatically integrated to my system.
Sorry if that’s very aggressive, but this is really, really frustrating. This feedback as I bring new developers into my team, they get me too. “You told me to integrate this stuff, but where is this stuff?” First question, where’s my SDK?
Normally what would happen, is I would go open up my local git clone and do a get/pull (this is a linked clone of a source code repository owned / hosted somewhere else). If found the SDK before, I normally wouldn’t navigate to a site to see an update. I would have that repo integrated not only with my my local dev setup, but it would also be integrated into any tooling that I have. (Listed as a dependency, and auto built by Jenkins)
An Example of What to Do - Insieme and Webex on Github
One place that I love to go is http://www.github.com/CiscoSystem. This place is where the the WebEx team and some of the guys from, NOSTG push a lot of information. Kyle and Mark put a lot of stuff here too on GitHub. This is a place where developers collaborate.
This allows me, as someone who is integrating applications on their stuff to go ahead and, not only through a web page, go ahead and see some interesting stuff.
Very specifically, a great example, the Insieme team. Mike, an awesome guy on that team, has posted some interesting SDK’s information for the Nexus 5000.
It’s easy for me to find. I could Google it. I could search for it on GitHub. I can do a lot of cool things, things that are important to me, in my software development work flow.
Nexus 9k API Docs on Github
In this example I talk about Mike Cohen’s code for Nexus 9K. This is how it should be done. Example -
Over the years I’ve had to hack these stupid expect scripts and interactions with NetConf to do shut/no shuts and do network testing. You get 1,000, 2,000 nodes, and with four links each you’re going to have transceiver failure and cable failures all over the place.
You end up writing these scripts, to go ahead and exercise the network and start tests on either end. One, it takes forever. Two, it’s a giant pain in the rear, especially when you have to diverse platforms.
I was poking around, and I see, “Oh, wow, someone wrote some interesting code, which, if you look at it, goes in and provides a link test.” This is really, really cool. This is code that I can use. I can integrate it into my own stuff, my own operational procedures. Not so bad.
Use of Developer Toolchains for Collaboration
As a developer, Git provides a set of the tools that are used to track, communicate and collaborate. We use this to answer questions like - “who the heck wrote this?” The first thing we would do was go ahead and check the log.
- Who wrote this stuff? OK, I see Mike Cohen. I’ve got his email address.
- I can even go so far as to see when he did it. OK, that was at the end of December, December 19th.
- I can see exactly what was added each day. Now there’s a log for the entire repository, Mike from Nexus repository.
- I can see that there’s another developer who was contributing early on to the repository.
- I can see that if I need to get clarity or have a question about utilization of this code, I can ping Mike Cohen.
Collaborating on Code via Pull Requests
Say I improve the code. I find something unique and novel that I can use in my own networks, but I’m not in the business of maintaining a small patch to this.
I can go ahead and make my patch. Then I can submit a pull request back to Mike. Mike just gets an email that says, “Hey, please merge this. I found this useful. Inspect the code, test it, validate it. If it’s good, merge it.”
That makes it something that all the community can use. I’m not in the business of maintaining these minor patches. They distract from the effectiveness of me and my team. I want to be able to submit that.
My Experience Trying to Do This with the UCS SDK on Communities
I downloaded it from some community’s page. I don’t know who wrote it. I don’t know who to contact. I can extend it. I can keep that private. It’s a top down community. It doesn’t support the community development, that’s been really key to the growth of open source.
Collaboration between Manufacturer, Integrator and Customer in OpenSource
We saw a move of Open Source projects from SourceForge to GitHub. It’s been real. GitHub has allowed this interaction between us that’s key to our development collaboration on OpenStack and OpenDaylight, SDN controller.
My team is one use case. Our company is not huge, but not small. We do about a half billion in revenues, but we’re big enough that we’ve been contributing for OpenStack for two years now and OpenDaylight since mid 2013.
We can push code back. We can contribute into the community. Where we find things that support an unfair advantage market, a new secret sauce, things that support it, we can share the burden, we can be good stewards.
We collaborate with Cisco, with Red Hat, with IBM, with HP in the open domain. What I’m pointing out here is there is no method enabled within DevNet to support that collaboration.
Cisco DevNet Needs to Support That Collaboration
There’s a huge opportunity to do that. I’m hoping you take that chance. It’s not about tools. It’s about the back-end. It’s about the collaboration in the community.
My Recommendations
Don’t Point Me to Product
If I’m already looking for software integration information, I have made my purchasing decision. Shoving product in my face just gets in the way of my job.
If I’m so frustrated where I can’t find the API documentation and, very specifically, SDK’s, as a developer. I’m going to go to the competition and try to find theirs. It’s all about the software integration, not the tin can that we wrap a CPU in. We call that a server, right?
Please, Please Consolidate Information onto GitHub
In the open source domain right now it’s not only where we collaborate, but it’s a tool chain that allows us to collaborate. It is the standard for open source communication and collaboration.
Linus Torvald invented it for a reason. The guys at GitHub have been really doing a great job in enabling this innovative community. That breaks down the barriers between manufacturer, integrator, and customer.
Set up an IRC Channel in This Community
Every day OpenStack, OpenDaylight, my own internal development teams’ use IRC channel’s to collaborate. You can see all my teams up on the public open source channels. Get Cisco channel up there. Make it so it’s integrated with DevNet. It’s not that technically challenge. That’s a huge opportunity.
What You Should Take Away from This
Fundamentally you need to communicate and collaborate. DevNet should not only be we can be pointed to the software but a tool to encourage that collaboration.
Make sure that we know very clearly who is maintaining that repo, that there’s someone dedicated to evaluating emerging pull requests. Use us as a tool.
There are a lot of people that use Cisco gear out there, Cisco routers, phones, servers. There’s a small number of people there that, for many, many years, have been writing code that configures it.
If you can enable DevNet to be what it can truly become, which is a collaboration point, integrated with the common open source collaboration tools and platforms, GitHub…Maybe I’m dreaming of this day, when I don’t have to re-factor my code every three years.
You can really start to create that community. Frankly there are a lot of us that are just waiting for it to happen. I’m looking forward to you creating a conversation and seeing this become what it could be.
Resources
Related Posts
Quick Links
Legal Stuff