The importance of APIs
Since the rise of the cloud era, user expectations have changed quite dramatically. Customers want easy & direct access to their own virtual slices of the data center. For its part in making that happen, SDN provides APIs that make the networking part as responsive as users and their application workloads need it to be. Admins can define global policies, while customers can do whatever they want with their own part of the cloud.
And they do that through APIs.
We all love APIs. At least I do. It allows us to become “machine whisperers” and build some new things that nobody had even thought about. But let’s be realistic.
Imagine a blender. Let’s add an API so you can control it through ReST. Now, that’s a sweet blender! While I’m sure someone, someday, will come with a revolutionary idea that will need a ReST-capable blender, I personally just want to press one button to get my smoothie.
The missing link
While you might want (and should be able) to control the state of an independent cluster of your hard drive, most of the time copy and paste will do the trick.
If you look into what is actually happening when you copy and paste a file, you’ll see a lot of different low-level actions. Getting the file address and size, jumping over fragmented locations on the disk, enforcing permissions, creating a destination file, opening a binary stream, and so on. That’s just me guessing. I didn’t check what’s exactly happening at such a low level. And most other people never will either, because it’s already working just the way it should be.
The copy command simply took a high-level everyday need & concept (I want to copy that thing here), and translated it into a well defined sequence of low-level actions. People got used to it, and so everyone knows how to copy a file, even my grandmother (but she rocks with computers, so that doesn’t count).
The same thing is happening with SDN today. To turn up applications, people had become used to thinking about and configuring the details of their addressing plan, firewall configurations, quality of service (QoS) parameters etc. But that now we have the APIs and network automation tools to simplify all of this, we need to think about the real goal. Is it about creating a bunch of firewall rules for the sake of doing it, or instead about securing the data flows between two clusters of servers? Is it about giving IP address 10.0.1.2 to that particular server, or really about being able to tell that it can actually talk MySQL to that other one? While the low-level tasks are basically the same, the user mind set and experience is totally different.
APIs enable programmability as they abstract and perform low-level operations. So, the missing link lies between the APIs and the desired workflows.
Give me buttons
If you think about it, a simple push of the right button can do an incredible number of tasks. From “simply” saving a document, to deploying an entire application on a private network with policies, virtual machines and firewalls in a remote data center. Even tweeting about what you just did. The smarter the buttons, the more productive you will be.
We just need to show the right buttons that do the right things in the right places for the tasks at hand.
VSP Architect — the user interface for our Virtualized Services Platform (VSP) — can be used by different groups of people. From data center administrators to developers who just want to focus on the applications they are working on.
They want to test the performance of their application under degraded bandwidth conditions? Just add a QoS Policy. They want to simulate what would happen if the business logic tier can’t reach the database tier? Simply forbid MySQL in a policy.
While they could script all of that (or even worse, call their IT department), if we are able to give the user a nice button that does all the work for him, I’m sure he’ll prefer the button. Configuring things requires a lot of time and learning while everybody already knows how to click a button. User interfaces are the instantiation of the user experience. The ideal user interface needs to rise up, look at the big picture, find what users really want to do, and then present the most intuitive, ergonomic and sexy way to make it happen.
VSP Architect is built on the top of our APIs and provides an additional level of abstraction that enables users to quickly define and perform what they want to achieve. We are continuously building new things, like the forthcoming Application Designer that will dramatically decrease the time and knowledge required to set up a fully operational network for a particular application. And this is only one of the many new things we are working on.
The final word
Cloud providers and IT people expect programmability for their networks so they can respond to their customers’ requests more quickly. Nuage & our VSP Architect gives them that and much more. We allow them to let their customers do what they want to do by giving them a streamlined interface that handles everything.
The networking world has not been known to be user friendly. But at Nuage Networks, we think it’s time to make the networking parts of the cloud cool and fun and easy to use. User interfaces are key components in achieving this goal.
Salut! I’m Antoine, the UI guy at Nuage Networks. I’m also the lead developer of the Archipel Project, an open source XMPP-based VM orchestrator working on the top of Libvirt, and a Core developer of the Cappuccino Web Framework (coincidence? I don’t think so). I like things that work right out of the box because I hate reading user manuals. When I’m not working on making VSP better, I like playing old forgotten video games, traveling around the world, and drinking some good rum.
Follow me on twitter @primalmotion or on Github https://github.com/primalmotion