|By Lori MacVittie||
|November 5, 2009 11:00 AM EST||
Infrastructure 2.0, from a purely developmental standpoint, is about APIs. It’s about offering up the functionality and capabilities of a wide variety of infrastructure – network, storage, and application network – to be externally controlled, integrated, and leveraged for whatever purpose a developer might dream up. It enables providers and enterprises alike to turn infrastructure functionality into services. Need compression? Caching? Routing? Load balancing? Via service-enabled management APIs these can become services, provisioned and released through the invocation of a service. When expanded to include the sharing of actionable data – performance statistics, status, availability of application services (context!) – this integration becomes the mechanism through which a dynamic infrastructure is created. One that reacts to events and conditions in the network, storage, application network, and application infrastructure in real-time.
But all of this functionality, the automation of functions, the codification of processes (orchestration) requires integration. Where previous generations of administrators evaluated the manageability of network and application network devices based on the CLI (command line interface) the next generation of administrators and the developers who will support integration efforts, will almost certainly look to APIs as a means to determine suitability of solutions within their architecture.
APIs are the new CLI
In the past network administrators would compare the CLI syntax and functionality of network and application network devices to Cisco’s IOS. IOS became the de facto standard for command line interfaces and even today you’ll find reviewers and discussions that mention how “IOS-like” any given CLI might be. But as infrastructure 2.0 and the need for dynamic infrastructures continues to drive administrators and developers toward APIs for integration and automation the CLI will wane in importance and the API will rise to take its place. That’s because the APIs provided by network and application network devices will be the primary interface through which the device is configured, controlled, and managed.
Luckily network and application network vendors learned from the trials and travails of enterprise software and the first implementations of these APIs have been primarily standards (web-services, XML) based. Service-enabled APIs means both administrators and developers can take advantage of the functionality and do so in whatever language or environment they are most comfortable. This flexibility is key to adapting to the myriad possible environments and architectures in which such devices may be deployed.
The danger in this shift toward APIs is that it is infinitely more difficult to replace systems that are integrated via an API or library – any programmatic-based integration, really – than it is to replace those for which the CLI is the primary administrative route. Administrators comfortable with the APIs of a Cisco router or switch will be less inclined, for example, to replace those core networking devices with a Juniper or other networking solution because of the inherent difficulty and time involved in learning – and using – a new API. This is true across the infrastructure spectrum; the APIs that allow complete control and management over BIG-IP (iControl) are very different from those available for Citrix Netscaler, or Cisco ACE or any of the other API-enabled application delivery platforms.
It is quite possible that whomever can win the “API wars” for Infrastructure 2.0 will become the new de facto standard for that particular “tier” (for lack of a better term) in the infrastructure architecture. Eventually one API will be preferred over the other – either due to saturation and usage or specific demand and it will give the vendor an edge that will not easily be dulled.
EAI and Adapters
But it’s not just network-facing IT that will help set the direction of APIs. Because part of the premise of infrastructure 2.0 and the APIs that are part of parcel of the standards and devices within its domain is integration there is a developer-focused component to the success of infrastructure APIs. While administrators are most likely to be closest to the APIs of network and application network devices, developers are most likely closest to the applications that drive orchestration and integration with business-focused systems.
One of the ways software application vendors knew they’d “made it” was the inclusion of adapters in EAI (enterprise application integration) systems for their product. ODBC drivers for databases, message queuing adapters for MQ and JMS, and more recently “salesforce.com” and other SaaS offerings. The inclusion of adapters for specific solutions in EAI and development environments is tantamount to declaring that solution a “win” for the enterprise. Thus it will be important to vendors of network and application networking solutions to court management and orchestration system vendors to include at distribution an “adapter” or samples, at a minimum, as the means to integrate and include their particular solution.
This seems counterintuitive, as most APIs are service-enabled and thus the bulk of the integration work is implicit in the API. But the ease with which those APIs are used and integrated by developers is paramount to successful adoption of infrastructure 2.0 APIs. The inclusion as an “adapter” provides the ease of use, often via a GUI, necessary to garner use and support from developers and business-focused orchestration analysts because of the inherent differences in the data plane. Mapping of objects from one device to another, from one system to another, is required and it is this core requirement that is fulfilled by middleware systems such as EAI and ESB (enterprise service bus) implementations. The easy integration with these middle-tier applications will be increasingly important as we move from operational policies based purely on technical metrics toward data centers driven by both technical and business metrics.
APIs are the new basis for standards
The first generation of the Internet used protocols and structural definitions to engender interoperability and even portability. Infrastructure 2.0 heralds the coming of a second generation of the Internet just as Web 2.0 signaled the beginning of the second generation of the Web. This next generation of infrastructure interoperability and portability will certainly be driven by protocols, but those protocols will include APIs and encompass a broader set of functions at higher layers of the network stack. Many of the ongoing efforts in the standards arena today are based not on structural definitions of data but on the APIs that will enable integration across the infrastructure and the Internet, a la “InterCloud.”
Both are necessary components to ensuring interoperability and portability, but until we see standardization of meta-data and component definitions, the emphasis will continue to be on the APIs.
Related blogs & articles:
- Infrastructure 2.0 Is the Beginning of the Story, Not the End
- Infrastructure 2.0 Isn’t Just For Cloud Computing
- Infrastructure Integration: Metadata versus API
- Does a Dynamic Infrastructure Need ARP for Applications?
- The Cloud Metastructure Hubub
- Cloud Computing Makes Servers Obsolete
- Business-Layer Load Balancing
- Cloud Balancing, Cloud Bursting, and Intercloud
- WSO2 Carbon, WSO2 API Manager and WSO2 Governance Registry Increase Speed, Scalability and High Availability Through Hazelcast
- Acquia Appoints Martyn Eley as General Manager of EMEA Operations
- U.S. General Services Administration Moves Order Management System to IBM SmartCloud for Government
- The DevOps Way to Solve JVM Memory Issues
- Cisco Web Security Webinar: Ensure World Class Protection
- SDN: Uncovering Amazon's Secret Sauce
- Mobilizing Business Data: The Holy Grail of Enterprise Mobility
- What Doesn't Kill You Makes You...Smarter
- On-Premise or Cloud ERP - Which Is Right for Your Business?
- Ten Questions to Avoid a Classical Business War Room Scenario
- What Business Leaders Want from IT Monitoring
- The Final IT Evolution – Cloud
- WebRTC Summit at Cloud Expo Agenda Announced
- OneLogin Raises $13M to Power Expansion
- Gartner Hype Cycle 2012 – Emerging Technologies
- Five Technology Trends That Require Scrutiny
- Nine Stunning 3D Printed Objects
- User Accounts Are Only the Tip of the Iceberg
- The Zacks Analyst Blog Highlights: Ford Motor, Microsoft, Volkswagen, General Motors, Autodesk, Apple, Google and Adobe Systems
- Fathers of Clouds – A Tribute
- Acquia Appoints Martyn Eley as General Manager of EMEA Operations
- Open Server Summit Reports Doubling of Registration
- Drupal 8: A View into Performance
- The Top 150 Players in Cloud Computing
- Who Are The All-Time Heroes of i-Technology?
- Where Are RIA Technologies Headed in 2008?
- Success, Arrogance, Rise and Fall
- AJAX World RIA Conference & Expo Kicks Off in New York City
- The Top 250 Players in the Cloud Computing Ecosystem
- Personal Branding Checklist
- i-Technology Viewpoint: Attack of the Blogs
- Exclusive Q&A with Jeff Haynie, Co-Founder & CEO, Appcelerator
- Web 2.0 News and Wrapping Up "Real-World AJAX" Seminar
- Passing Parameters to Flex That Works
- Cloud People: A Who's Who of Cloud Computing