News Stay informed about the latest enterprise technology news and product updates.

HP trains partners, developers and engineers for SDN app store

HP's SDN app store needs apps, so HP is training partners, developers and engineers to build them. HP and its partner, Kemp Technologies, discuss.

HP Networking remains a proponent of OpenFlow-based SDN, with a broad portfolio of OpenFlow switches, a controller and an SDN app store. HP sees the app store as the key to translating SDN into business value. In theory, network managers could shop the app store for applications that solve a specific business problem, download the app and install it on top of the OpenFlow controller.

To deliver on the value of that app store, HP needs to build an ecosystem of developers. So the company has been running a series of summits and training sessions that brings together partners, developers and network engineers to learn the basics of SDN, as well as HP's application programming interfaces (APIs) and software development kit (SDK). The most recent session took place immediately after the close of the Open Networking Summit in Santa Clara, Calif. In this Q&A, Jacob Rapp, senior manager of SDN marketing at HP Networking, talks about HP's goals with these sessions, and Michael Worlund, technical director of strategic alliances and product management at application delivery controller (ADC) vendor KEMP Technologies Inc., discusses his company's ambitions in the HP SDN ecosystem.

What is the purpose of these workshops and training sessions that HP has been leading?

Jacob Rapp: If you look at a lot of the shows, like Interop, they hold panels that look at, 'What does SDN mean to my job? What are skills I need to have in place to move things forward?' We don't think network admins and engineers are going to lose their jobs by any means. They're gaining new sets of tools to up-level their interaction with the business and applications.

We've been building up an SDN ecosystem that we announced around September of last year, with an SDN app store and a development environment. From there we started to bring customers and partners in on the development. This kicked off a set of development workshops and trainings to bring different partners up to speed in SDN application development.

Our first workshop, in December of last year, had a pretty good turnout of 30-plus people looking to develop applications for our app store. From there we've been running a set of formal training processes to bring in not only developers but network administrators and help them get a handle on how to develop for SDN.

We start off the day with kind of an immersion experience, starting from the beginning of SDN development, making sure the development environment is up and running [and] that they can get everything going. We run through examples of what the development experience is about. We run through sample code and sample applications. The crux of it is getting our engineering team and our research and development team in front of our partners who are developing SDN applications [to] help our partners kick-start their own innovation and process of getting things developed for an SDN app store.

What's the difference between SDN application development and other application development experiences?

Rapp: We want make it as similar to developing any type [of] application as possible, so we provided abstractions in APIs northbound of the controller. In the development process, you don't need to really know a lot about the underlying OpenFlow technology that is running and programming the network. We create a set of APIs and abstractions to program in the environment.

We also provide a full set of documentation around the APIs and the Eclipse environment that most developers are used to.

Michael Worlund: From our perspective [at Kemp], we're focused more on Layer 4-7. What this gives us is a more universal level of networking at a lower layer and being able to affect more of the traffic; the ability to do more intelligent distribution based on things like bandwidth and congestion that maybe before we couldn't necessarily affect.

Is Kemp looking to deploy its platform on top of a controller as an SDN application?

Worlund: Potentially. We could still be inline and be able get information that's of interest to us, and then utilize the controller for forward congestion or avoidance. We're working on applications right now that we are going to test on the HP platform that look pretty promising in preliminary testing.

So you're looking at an app that lets your load balancer interact more intelligently with the network?

Worlund: Exactly. If we want do a Java applet, we can do [it] within [HP's] controller, or we can use the APIs. We've looked at their SDK, and we're able grab some of the information that we need as it is today. HP has already done a lot of work upfront that enables us to do a value-add from an application delivery perspective.

Are these training sessions for network engineers or software developers? 

Worlund: I'm traditionally a network engineer by trade. We saw a mix at the four-day training session I was at. It was around developing applications in Java for integration within the controller itself. There were developers and there were network guys -- it was really kind of an even split.

The way the material is delivered, it was easy to pick up [for both programmers and networkers]. Me not being a programmer, I looked over a programmer's shoulder to get up to speed on Java stuff. When going through networking stuff, I was able add value to the programmers. The class was paced to the point where we were able share knowledge, and all of us walked away with a much more balanced understanding of everything.

Application developers and network engineers looking over each other's shoulders. Is that the way development will proceed, with teams of developers and network engineers collaborating like this? 

Worlund: I think initially that's how it has to happen, and eventually you're going see a melding of two organizations with two skill sets. We're already starting see a lot of network engineers starting to pick up coding, and with SDN you're starting to see a lot of programmers gaining network knowledge. I think some of that is a natural evolution anyway.

Rapp: Instead of network engineers living in in a CLI [command-line interface] level that no one but them can understand, they're taking the knowledge of networking up a level and seeing how we can utilize this for integration with applications for real business benefits.

Worlund: It really started a few years ago with [F5 Networks' application delivery controller scripting tool] iRules, at least from the network guy’s perspective. They had to learn a little bit of Perl, a little bit of TCL, maybe some Python. So they were already getting their feet wet from that. This is just a natural progression.

App dev and network engineers were already melding a bit, since both teams often have joint ownership over those F5 ADCs and the iRules scripting.

Worlund: Absolutely. iRules is really there to compensate app dev, so those teams were already talking together. The application developers were coming to network guys or the application development engineer and saying, 'We have this problem when we're testing. Can you help us troubleshoot that and figure out why?' Typically what it came down to is putting some form of scripting down to assist that application in completion of the session.

You mentioned network administrators are coming to these training sessions to learn SDN app development. Do you anticipate HP SDN customers developing their own apps?

Rapp: Right now, through this year, I think mainly it will be customers adopting applications that our partners write. I don't see a lot of customers developing their own set of applications unless they're on the bleeding edge of something. For example, we work with CERN on some interesting use cases that fit their business, and they collaborate on working on their own applications.

But I think that's not going be norm. We want work with partners on our app store so that customers can look at all the applications and say, 'What is my use case? Which one is most beneficial?' Then they can start their journey down SDN. As they get used to the SDN framework and how things work -- in 2015 and 2016 -- I think some organizations that have some unique staff and unique challenges will start working with their own applications and their own integrations into the set of tools they have.

Does Kemp see the things it's learning with HP as transferable to other SDN stacks?

Worlund: Certainly. We're approaching this pretty aggressively, and we're trying to develop to where -- depending on how the controller thing hashes out -- it's agnostic to the controller. And I think HP is doing some of the same stuff. They're looking at things like OpenDaylight and making sure we cover all bases.

Rapp: We've noticed with some partners developing applications that if you program in a way where you are object-oriented anyway -- where you have some level of abstraction to begin with -- you don't have to change a whole lot to go from one controller to another. It's just a set of API calls right now. We're hoping those connections will be standardized in the future.

When will we see the fruits of all labor? How long before customers see it?

Rapp: The first half of this year, and 2014 in general, will be the year of the app store for SDN. We're looking at problems and finding solutions. We're not just saying, 'Here is a solution looking for a problem.'

Does Kemp anticipate putting out an application on HP's app store this year?

Worlund: We are shooting for at least a live demo for HP Discover in June. That's our target right now.

Let us know what you think about the story; email: Shamus McGillicuddy, News Director, or follow him on Twitter @ShamusTT.

Dig Deeper on Software-defined networking

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

How do you want to consume SDN apps?
For developing new applications that can shape how the network functions or is secured for end user applications or mission critical business applications.
without upsetting Virtzilla