Nowadays, it is increasingly easier to lose one’s self in dashboards, visualisation tools, nice graphics, and all sorts of button-like approaches to cloud computing. Since the last decade, UX work has improved tenfold; nevertheless, there is a side that usually goes unnoticed unless extremely necessary. That side belongs to application user interfaces (APIs).

An API constitutes a set of objects, methods and functions that allows the user to build scripts, or even big applications, to make certain things in the cloud happen that usually cannot be made to happen through a dashboard. This can be for various reasons; whether it is not yet being available to the end user; being very specific to the business, such as a competitive advantage; or being an automated portion that is not widely needed and may also be specific to the business.

Of course, there are other reasons. The cloud may not have the maturity to enable the user to do certain things. In all those cases, APIs are most welcome and, contrary to popular belief, the learning curve to build something with it is usually not steep.

Widespread use throughout the industry

Virtually every cloud has an API. Sometimes, it is not offered as an API, but as an SDK. Although they are not the same thing, they are sometimes seen as equals, or at least close siblings. SDKs come in different flavours; it may be a Python SDK, a Java SDK, a Go SDK, or one of many others. The ones mentioned seem to be the ones broadest in use, but there are also many others, such as JavaScript/Node.js, that we see frequently in AWS, Oracle Cloud, Google Cloud Platform, and even Azure.

From luxurious to essential

Although there is little luxury in writing tools that make use of an API, I would like to think that some things can be made more elegantly when built from scratch, or from first principles, instead of simply using what is on the market. Nonetheless, although I am an advocate of not re-inventing the wheel, if off-the-shelf tools and technologies do not fit the bill, it is necessary to come up with something from scratch, be it proprietary or open source.

APIs can be used to write code that will create complementary features, such as high availability solutions that are not provided ad hoc, or certain automations that are intrinsic to the business case at hand. Sometimes these may not be indispensable, and in those cases they may be considered luxurious.

On the other hand, there are things that you will inevitably need, such as building a tool that creates havoc in your cloud architecture in order to test your incident response. Chaos Monkey, for AWS, is a key example of this. I believe these are towards the essential tools model, and should not be taken lightly.

What is needed to use an API or SDK

This depends on the cloud used, of course, but it generally goes along the lines of the following:

• An authentication key: This will be used to authenticate the tool against the endpoint that the cloud has proposed. Some cloud platforms allow for instance principals, in which case a key is not even needed
• An SDK package: As an example, in Oracle Cloud Infrastructure, in order to use the Python SDK, it is necessary to ‘pip install’ the OCI package – something as simple as typing a one-liner
• An initial read within the SDK documentation: Sometimes it takes less than an hour to come up with a prototype and scale from there. It is not necessary to be an expert in the inner workings of the SDK, although it helps
• Some familiarity with the language of the SDK: This is a given, but nevertheless it would be unfair not to add to the list

The recommended approach

Usually SDKs come in the form of what is known as CRUD (Create, Read, Update, Delete). This is a simple approach, known since the dawn of time and as common-sensical as humanly possible, so it should not scare any seasoned engineer in the least.

The top-down approach: Starting in a very detailed manner can be daunting, so in this case it is my belief that a top-down approach is well suited, starting from a list of resources until familiarity with common structures is gained. Not to mention that in some cases, Paretto’s Law is in plain sight, meaning that in the first 20% of an SDK lies 80% of its power.

I have found this when I started to build tools for Oracle Cloud; with some simple methods in Python, leveraging resource listing and drilling down on some objects, I was able to gather all the data necessary to start devising a data science model of resource usage. A major gain for our team.

From documentation to source code: Although documentation is helpful, it will never be as helpful as exploring the source code. It is clear to one’s self that an hour going through the source code is equivalent to around five hours going through the documentation. I understand in some cases watching a YouTube video may be easier than reading a book on the same subject, but the depth acquired and the mental training is much greater when reading a book. With an SDK or any program it works in the same way. Reading the documentation is nice, is good and helps, but nothing will shed the same light as going through the source code.

The MVP: Since The Lean Startup hit the bookstores, the concept of MVP has gained popularity significantly. I am referring to the minimum viable product, a product that contains only the basic features and that is not meant to cover all cases but the standard base ones. This concept is well stated in The Lean Startup and though is attached often with Agile, it is an older concept.

Although it would be ideal to have a product with a perfect set of functionalities since version 1.0.0, it is often if not always utopic. There is no perfect set of functionalities and waiting to launch can lead to catastrophic failure. In IT, it is often significantly better to have a minimal product with a small client base that desperately wants the product, than have a big base that is relatively indifferent – if they have it they will use it, if not they can live without it.

Conclusion

At the end of the day this can be simplified into six points:

• APIs are a significant advantage for automation and solutions such as HA or DR that are sometimes not provided by the cloud platform
• Paretto applies everywhere – APIs are not focused only for big applications. A simple script can save several hours of weekly toil work
• Start with broad strokes and slowly go into the details
• Do not be afraid to examine the source code – it is often a gold mine of knowledge
• Start with a small minimal version, instead of several features that may or may not be used
• Look for hidden treasures in the cloud platform that are not easily spotted through dashboards and UX

Happy cloud automation – and until next time.

Editor’s note: You can read more of Nazareno’s articles here.