Using SDKs to Manage Infrastructure as Code

The IT infrastructure landscape is changing and our skills need to change. With the continued growth of cloud-based solutions, code-based infrastructure management is an essential skill to develop. Using software development kits can ease the process of transitioning infrastructure management to code.

SDKs provide a programmatic interface to a system, abstracting the exposed API (such as REST) to provide a programming language-specific interface.

A vendor might release SDKs for multiple languages, allowing you to use your preferred language. It's important to know that features may vary between different language releases. SDKs from VMware for vSphere Automation support six languages, but look closer and you’ll notice features vary between languages. These differences are important when assessing which SDK to consume.

What does an SDK provide?

On the front end, an SDK provides an interface through functions, methods, and classes. This simplifies the task of writing code from scratch as a lot of the legwork has already been done. Generally speaking, the interface provides GET, PUT and POST operations. The logic for consumption and manipulation still needs to be manually coded.

An SDK provides a level of separation between business-specific code and backend-system code. A key advantage is that when reading the code, the business logic is much clearer.

On the backend, an SDK communicates to the system being managed. If using a REST API, the call could be made by adding the inputs to the headers and URI. Where a request body is required, you just need to provide the data for the SDK to build the request body.

SDKs vs. REST API calls

This example will demonstrate the difference between using an SDK and Native REST API call. I authenticate to UCS Manager using Cisco’s Python SDK for UCS Manager and Python Requests.

UCSMSDK.png

python requests.png

In the SDK example, the code is cleaner, and the intent is easily understood. In the Python3 Requests example, while the code is clean, it takes longer to read and understand the intent. This adds up quickly on larger code bases. Validation of the REST response requires additional coding.

Feature parity

When comparing features and functions offered by the exposed API and SDK, you’ll often see that the SDK is not at parity. This is because the SDK is written after the API and after new features are in late development stages.

If you require a feature, there are a couple of options. You can submit a feature request, highlighting the merits of the addition. This could be done through an account relationship or possibly directly to the development team. Or you can write the feature yourself. If the project is open sourced and resources allow, you might add the functionality and submit a pull request to have it added to the upstream code.

Another option is to use the native API functionality. This approach can introduce complexity into the code base as it breaks from the previously standard approach. But, sometimes you just need to get a task done.

When using code to configure and maintain systems, tracking function depreciation is critical. You don’t want a core part of your script to break because it uses a function that is no longer available. The problem is that keeping track is difficult and time-consuming.

Oftentimes, vendors document the supported product versions. Additionally, it is common for vendors to warn about functions that will be removed soon. When you see these warnings, don’t ignore them.

SDKs are excellent tools for improving streamlining your ability to manage infrastructure by code; they simplify your code and improve the ability to read the intent behind the code. Further advantages can be gained through the reduction of depreciation risks. However, like all code, understand that SDKs are going to have bugs or not be fully featured with the exposed API. Understand limitations and how to work within them.