One of the things that’s interesting to watch in our industry is evolution. We see companies evolving everything about themselves. Typically, we see companies do this with their technical designs or with their marketing messages. Personally, I’ve been paying attention to how these companies are evolving something subtler. What I’m talking about is APIs.
APIs have become very integral to those of us that try to automate as much as possible of our infrastructure. We all know that this is a requirement to getting our organizations “moved up the stack”. APIs are a necessity, however, they also come in many different flavors. Let’s not also forget that even if you utilize these APIs, you may also have to worry about your orchestration system and how it can interact with the APIs of the many different companies you may have in your data center. All of this ambiguity between tech companies and orchestration systems leads to something I’ve heard referred to as “API lock-in”.
API Lock In?
I’m going to guess that we’ve been countlessly directed to many blog posts about how vendor lock-in is bad for our datacenters. The same could be said about API lock-in. Let’s say that you (the reader) are actively participating in infrastructure-as-code projects within your organization. You spend a significant amount of time getting code to work so that you’ve recreated a business process reflection of consumption of your datacenter. Now, how would you feel about the constant need for maintenance of that code if your organization decides to change routes. One day you are using Orchestration System X and you now have to start using Orchestration System Y. This may present itself as a problem for that code in question. To get it to work with Orchestration System X, you spent a long time with that company’s SDK and you integrated a vast amount of their APIs into your code to make it work together. You are now staring at a daunting task of re-writing the entire block of code for Orchestration System Y because of all those intimate integrations. To me, this is API lock-in. It heavily reduces portability of the code from system to system and I lose much flexibility when thinking long term for that code.
With APIs and potential lock-in in mind, I want to highlight a company I’ve been watching for the last 12-16 months. I first got my deep exposure to this company, SimpliVity, back at Cisco Live 2015. You can read up more on what the company actually does by following the link: SimpliVity. I won’t focus directly on their technology and what they do. They have an interesting evolution of API story I wanted to highlight.
What caught my attention at Cisco Live was that SimpliVity was highlighting integration into the Cisco UCS Director orchestration platform. There’s no secret that I utilize this orchestration for my day-to-day job for automating and orchestrating my employer’s datacenters. It was nice to see some other third parties integrate their systems into the platform, but knowing how many of the integrations in UCS Director function, I felt compelled to ask a simple question during the briefing. “As you roll out new functionality into your product, how are you making that new functionality quickly available for those that are using UCS Director?” The reason I asked this is that many of the functions within UCS Director, in my opinion, are horribly outdated and take a very long time to be updated by Cisco and some of the third parties working with them.
Little did I know it, I was already asking questions about potential API lock-in issues before I even knew this was even something to worry about. The answer I got was the usual third party answer of “We will work with Cisco to ensure functionality is available ASAP…”. To me, I felt that answer wasn’t good enough and that eventually, as the infrastructure developer, I was going to have to figure out how to interact with SimpliVity’s API mechanism and update code myself to keep up with the latest functionality they provided in their software.
Providing a Facelift to Cumbersome APIs
I’ll be honest, I had really forgotten about looking into SimpliVity’s API structure after Cisco Live 2015. This was mostly due to the fact that I did not have access to an environment with a SimpliVity solution contained within. However, that changed when I was contacted, again, by SimpliVity, to be invited to another event of theirs, SimpliVity Connect. I was unable to attend the first event in question, but I was able to reestablish contacts and was surprised to find out that they were going to be announcing a new version of software that included a RESTful API. No secret that I love interacting with RESTful APIs. They are extremely easy to work with and JSON is much easier to work with instead of custom XML responses. I feel that many of the methods we used to use for APIs (SOAP/XML and SSH/CLI screen scraping techniques) are too custom and require me to spend a lot more effort on the return structure rather than the information contained within.
This lead me to go back and figure out exactly how the earlier generation of APIs worked for the SimpliVity solution. Ultimately, I discovered that the UCS Director integrations was nothing more than a SSH/CLI screen scrape method, combined with wrapping heavily custom XML tags around the data. UCS Director had code blocks that would parse the XML tags and pull the information out and work with that information within the workflow engine. In today’s RESTful API integrations, this was not ideal.
What I’d like to believe is that someone within SimpliVity saw this and realized it was not going to be good enough for whom the software was going to be worked with. Those of us in the infrastructure realm want to get to that data as quickly as possible, without having to worry much about custom structures wrapped around that data. It also allows for us to easily integrate the data from the SimpliVity software into other parts of the infrastructure through code.
I was extremely excited to see a company realize that and get RESTful APIs baked into their product. This opens up a multitude of ways in which I can choose to implement their solution through code. Going back to UCS Director, instead of having to worry about the SSH/CLI/XML components, if I wanted to utilize the “Execute PowerShell Command” task, I could just setup PowerShell scripts that call upon the RESTful APIs. Now, as the coder, I have something that’s not coupled directly to code maintained by the writers of UCS Director and I can make the changes when needed when SimpliVity makes API improvements. The best part is that the very same PowerShell script can be more easily modified and ported to another orchestration platform (especially if that platform has means of calling out to PowerShell scripts).
We, in the industry, should be doing more to get companies larger than startups (SolidFire and Rubrik come to mind) to adopt this mentality. Nothing perturbs me more than having to rely upon NaviSecCLI for EMC storage array access through SSH wrappers in orchestration platforms. That isn’t good enough for the generation of infrastructure people now growing up with coding skills. I say kudos to SimpliVity for identifying this and making some of our lives easier when working with their product in our datacenters.
In my RESTful API usage example, I highlighted PowerShell. I want to also let you know that many other languages can and should be used with these APIs. I suggest reading up more on SimpliVity’s specific API usage with Python, by heading to a blog post authored by Hersey Cartwright (@herseyc on Twitter) and have a quick read into more details into SimpliVity’s RESTful API. You can head there by clicking on the following link: Automation with SimpliVity’s REST API