IT Is Becoming All About The API
Posted by
Mike Fratto
February 02, 2011
During a visit to Sillicon Valley a few weeks back, I had the opportunity to stop in on Cisco, HP and Juniper and get demos of products that I have been briefed on and written about but haven't seen in action. These products include Cisco's Unified Computing System (UCS), Juniper's JunOS Space and HP's Intelligent Management Center. What struck me most about all three products is how much emphasis the vendors are putting on developing APIs, both for internal use and third-party integration. APIs, and, by extension, integrated products are going to become much more important in your buying decisions.
Obviously Cisco, HP and Juniper aren't the only equipment vendors making their products programmer-friendly. Arista and Extreme, for example, have APIs and scripting on their equipment. What's important is that the management methods we are accustomed to--closed management systems, screen scraping (which is error-prone and brittle) and SNMP (which supports only a small subset of switch features and has poorly written MIBs)--are being replaced by more robust and programmer-friendly interfaces. These APIs open up a world of new opportunity for IT to integrate and manage infrastructure.
To be successful, however, the APIs have to expose most, if not all, of the switch configuration parameters in a way that is programmatically simple, reliable and flexible. That hasn't been the case. In my experience, the thing I needed to do most on a switch was the feature that wasn't supported by the API. This means the next time you refresh your infrastructure, someone who understands programming needs to dig into the API documentation and see what is covered. Even if you don't do any custom integration, good APIs make it easier for your vendors or VARs to integrate their products and services. It's a win-win.
Language-agnostic APIs such as RESTful interfaces are by far the most flexible because you can choose the language to implement the client side of the exchange easily. However, it is up to you to build the low-level state changes and response codes. It's more work to build the code base, but you can tailor the integration as you need. In contrast, API libraries delivered from the vendor perform most of the low-level work for you, but you are restricted to the languages they support.
APIs matter because they open up a world of automation and management that would otherwise be difficult. One of the more powerful features of UCS that I saw was the stateless nature of the UCS hardware and how it is configured programmatically. Cisco's Sean McGee has a nice write up on stateless hardware and why it is useful. The hardware is dynamically defined--including BIOS version, settings, boot order, World Wide Names, MAC addresses and other hardware options--and sent as XML to the UCS server, C or B series, over HTTP or HTTPS. The API is RESTful since the configuration state is sent to the UCS server, which then implements the state on the computing platform. In fact, the UCS Manager interface uses the API to interact with the UCS Manager server on the 6100. You can replace that with a third-party management system or, if you can code, use tools such as Nagios or Zenoss to do your own integration. The 6100 maintains the UCS information, removing the need for a CMDB--your life just got simpler. The UCS manager stops at the hardware configuration stage of automated deployment, leaving application deployment and other functions to third parties. To me, a clear demarcation line is a strength because it lets UCS do what it does well and lets other systems do what they do well.
Page: 1 | 2 | Next Page »
