Welcome to the third post in the Converged Data Management series: API-Driven Architecture. To best understand how this property impacts the modern data center, it’s important to take a step back and view how today’s services – meaning the various number of servers that construct an application offered to the business or its clients – are created, consumes, and retired. This is often referred to as lifecycle management.
As a service is instantiated, there are a number of lifecycle milestones to reach. These include the details needed to request a service from a portal or catalog, the provisioning tasks to build the service, various care and feeding events while the service runs, and ultimately the retiring and archival aspects of the service. More often than not, these milestones are wrapped into various orchestration engines and front-ended by a Cloud Management Portal (CMP) for administrative and tenant based consumption. In other scenarios, there are still automation workflows being utilized by way of point-and-click scripts and customization tasks.
An API-Driven Architecture comes into play as IT professionals work to progress a service through the various lifecycle milestones along with other third-party tools and infrastructure stacks. As technical teams attempt to piece together the solutions required to build a service – such as carving out storage, building out networks, ensuring the workloads are being protected and archived, and so forth – there comes a need to fit together any number of moving parts. APIs are the glue that makes this a reality and allow an orchestration engine to call a series of tasks to bind the parts together. Each task can request a unit of work to be completed by sending or retrieving data from API endpoints using methods such as get, put, and delete. As an added bonus, RESTful APIs are largely software-independent – it doesn’t matter much which language you use, only that you adhere to the published schemas and models.
There are a few differences between solutions and how they offer up their API. Some vendors will present an API as a bolt-on feature, often requesting additional licensing costs to activate the software stack. This is because there isn’t an API-Driven Architecture to consume underneath the covers and the vendor’s API was added later, as an afterthought, requiring engineering time to create the API endpoints and making it work with the internal code operations. Think of this as a “middleman” method of adding extensibility to a software stack and frequently results in a feature latency between the API and access to core functionality. The bolt-on API requires a new layer of testing and validation to reach production readiness. In some cases, feature parity is never reached or the API is abandoned.
The ever elusive bolt-on API, photographed in the wild.
This is where Rubrik is very different: we consume the same API that is published and provided to users and tenants without any additional licensing hoops to leap through. In order to perform the functions necessary to supply scale-out data protection to data center services, we have to drink our own champagne and consume the RESTful API endpoints. Having an API-Driven Architecture means that the API is always a first class citizen, is highly developed with core engineering talent, is subject to the same rigorous testing and quality processes that the new and enhanced features undergo, and remains available for technical professionals who wish to build out lifecycle management for their data center services. It also allows our partners and customers to invest relatively small amounts of effort to build out some pretty amazing open source projects for engines like vRealize Orchestrator and Windows PowerShell.
Sound interesting? If you’re attending VMworld 2015 in Barcelona, we can go into a deeper dive. Make sure to catch the upcoming VMworld session STO6287 entitled featuring Rubrik’s Arvind Nithrakashyap, CTO, and myself. And yes, I’m doing the LEGO Battle of Hoth series giveaway in Barcelona!