This is the first in a series of posts about network based software development for “typical” enterprise developers, and how onePK can help.
Network based software development is special. The main interfaces are based on CLI interactions and SNMP, not to mention using RADIUS as a RPC mechanism, various forms of XML/HTTP found nowhere else, and additional innovations. For a typical enterprise or script developer these kinds of interfaces are unusual, to say the least.
This is both as a technical problem, and a business problem. There really aren’t many developers who can grok the subtleties of screen scraping IOS CLI over telnet and SSH, and also factor in SNMP, to build stateful software systems. It can be done, but, from a business perspective, that peculiar skill set can be hard for a business to staff and build solutions. That’s bad for both our customers and our partners and bad for Cisco as a business.
The onePK SDK changes this problem equation. It is better in various ways that I shall explore in this blog series in detail. At a high level though, onePK is better as it allows typical developers to build on the Cisco network platform. As a teaser example for future blog entries, with onePK you don’t have to create a topology database from a combination of a parsed IOS show commands and SNMP notifications; you just call an API to get a Topology object.
With onePK the developer gets APIs, in C, Java, Python, and potentially others, that look, feel and behave just like the APIs they use for typical enterprise development. These APIs, and our SDKs, work with tools, like Eclipse, that are just the same as those used by the developer audience in general. We are positioning these APIs, with tutorials and example applications, squarely in the mainstream enterprise developer space.
I shall also be exploring some of the system design alternatives made possible by onePK, compared to more traditional EMS/NMS/OSS system architectures. I’ll examine the onePK container models, and what can be done when network software systems are moved off remote servers and hosted within network elements. The role of the EMS as a translation layer, and the NMS for aggregation of EMSs, may become less relevant with onePK. I’ll be tracking this and highlighting where I think I see it happening. I’ll also be looking for examples where OSS/BSS functions are being deployed directly onto onePK and discussing what that might mean for systems design.
To paraphrase what my friend Ric said about onePK in his earlier blog post:
- The network really is a programming and systems deployment platform.
- You can access information about your network, and the business running over it, that gives you the visibility and control you need.
- The APIs and tools are usable by the same developers that are creating your business applications.
That really is better. Now let’s start developing.