IT Is Becoming All About The API
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
February 2, 2011
![Network Computing logo Network Computing logo](https://eu-images.contentstack.com/v3/assets/bltde8121fc52c5c8f3/blt3f3d0318f746b1c2/65a530e4187606040a1d8b8c/placeholder.png?width=1280&auto=webp&quality=95&format=jpg&disable=upscale)
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.Of course, HP has been in systems management for years. The company has a long history of integrating its own and other vendors' equipment. In fact, HP claims to manage Cisco's equipment better than Cisco. While I'll leave that comment alone, the fact is that HP's acquisition of H3C netted it a new management platform for the A series of data center switches. HP has been busy integrating existing management software and building new software to automate nearly every aspect of your data center, from the hardware to software deployment and configuration. HP's integration and management software has more moving parts than UCS, which many view as a problem, but HP has more software management products that, combined, can do more than just manage hardware. What I'd like to see, or hear, from users is their experiences using HP's software stack for a fully automated app deployment--that is, a private cloud.
Few data centers are truly single-vendor shops. You may be standardized on single switch vendor, a single server vendor or whatever, but no vendor has everything you need to run a data center.
What's changing is the demand for faster IT provisioning of resources. Spinning up a virtual machine is just one aspect. The VM has to be brought up on a hypervisor with available power and networking; the application may have to be added to a load balancer; it may have to be added to the firewall rules, it may need to tickle a CMDB and do a number of other things just to get into a ready state. The more open, simple and robust the APIs, the easier it will be to integrate products.
Disclosure: I went to the Valley on my company's dime. Cisco bought me lunch in the cafeteria for $6.34. HP and Juniper gave me water.
About the Author
You May Also Like
Maximizing cloud potential: Building and operating an effective Cloud Center of Excellence (CCoE)
September 10, 2024Radical Automation of ITSM
September 19, 2024Maximizing Manufacturing Efficiency with Real-Time Production Monitoring
September 25, 2024