From Silos to Services: Cloud Computing for the Enterprise

Apr 18 2015   12:22PM GMT

Advice to Product Teams – Think “API First”

Brian Gracely Brian Gracely Profile: Brian Gracely

Cisco UCS

A few weeks back, a friend of mine asked me to help him create some live demos for a big event that his company had coming up. As with any demo, we spent some time focused on the target audience, what we expected of their knowledge background, and then the actual story that we wanted to tell. Then making the technology actually work was the last piece of the puzzle.

In this case, he wanted to showcase some next-generation technology, which was targeted at a “DevOps-centric” audience. As we built out the storyboard, we walked through the tasks he wanted to be shown and how they would be displayed. What struck me as odd was how often he wanted to show each layer within his demo (infrastructure, management, apps) and how many times he wanted to showcase a GUI. The audience he was going after would typically never use those tools, instead focusing on either CLIs or more likely APIs to integrate between the layers. It was becoming a demo of functionality that a customer would never use in real-life, but it looked pretty on stage and a big display. I tried to get him thinking like this, like his target DevOps audience would think:



In reality, this wasn’t really HIS specific problem, it was two other problems:

  • GUIs often make demos easier to view because of the visual nature of the interface
  • GUIs don’t require (hardly) any pre-work to allow them to show things

But here-in lies the problem – are you building a product for a demo or for real-life customer usage?

Far too often, product teams create the GUI first, then the CLI and maybe, just maybe an API. In today’s world, this is completely backwards thinking. Everything should start with the API. It should be properly built and expose all of the ways to interact with the product. And it should be open and publicly documented. Then CLIs or GUIs can be built to interact with it, with the flexibility to customize them as needed. An excellent example of this is how Cisco built the Cisco UCS product. The API is the core interface, and then the GUI and CLI expose interfaces that layer on top of the API. Google’s Kubernetes project does this as well. Starting with the API allows 3rd-party developers (who could be your customers) to then customize the interface interaction to meet their needs. Here’s an example that the EMC {code} team built for a CLI on-top of the vCloud Air On-Demand API (also works on vCloud Director instances).

Going forward, as more product functionality evolves to being software-centric, I hope that we’ll see more products built with an API-first mindset. It might make an initial demo a little different than before, but if you’re targeting customers that ultimately won’t use your GUI, it makes so much sense in the long-run. It will allow customers to more easily integrate the product into their operational workflow, and it may allow 3rd-parties (or customers) to shape the look of a GUI to better meet their needs vs. your generic approach.

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: