How to avoid paying API taxes this year
It’s tax time in the US, and you know what that means, don’t you? Yes, we’re all looking for ways to reduce that burden.
I’m sorry to say that though I once worked as a developer for a tax-software company, I’m really not qualified to give you advice on that front. But if you’re looking for advice on how to avoid paying API taxes this year (or next) then you’ve loaded the right page on the Internet.
An API tax is the overhead you pay when using APIs to automate the provisioning and configuration of infrastructure as part of the deployment process. The API tax (like all taxes) is not simple to compute because it’s actually two-fold: operational and technical.
Operationally, the API tax incurs costs in terms of resources and time consumed by excessive API calls. Even as something as conceptually simple as as load balancing service requires the creation, configuration, and enablement of multiple objects. Monitoring, pools, algorithms, IP addresses and networking attributes must all be configured, and each of these objects requires multiple steps (API calls) to do so. Add them all up and even a simple load balancing service requires multiple API calls to get going. Calls that take time to execute. Calls that consume network resources.
Those API calls are used by architects and engineers who write scripts (using Python, PowerShell, etc…) to automate these common deployment tasks. This incurs unavoidable technical debt. Changing the task at all requires changing the code (because scripts are code, whether we like to admit that or not) and testing it, which takes time and resources that add up to real dollars on the bottom line.
These costs – to develop, test, and maintain the systems and scripts – are the technical taxes on the use of that API. What that means is the scripts incur long-term costs in the form of technical debt, which relates to the costs associated with maintaining the code needed to automate via those APIs and the cost to change not only the automation but perhaps the infrastructure.
All this adds up to quite the bill that, like “real” taxes, is practically unavoidable. If you want the benefits of more fluid and automated deployment process, you’re going to have include the infrastructure and that means everything that sits between the user and the app and makes sure the two can communicate seamlessly and securely.
Alright, all that said, I promised to explain how you can avoid paying these taxes so here we go.
If you’ve been watching the orchestration space (and that includes the SDx players like VMware and Cisco and OpenStack) you’ll note there’s a growing emphasis on the use of templates. Templates are a lot like configuration files in that they codify a whole lot of information necessary to create and configure some “thing”. If you can create a single template that encompasses the deployment of that load balancing service, by way of example, you can ostensibly slash the API calls required to just one – the one to push the template to the on which that service is going to reside.
Using only one API call instead of, well, a lot simplifies automation and lets you reuse the script or system that’s pushing the template. That’s important, because when you use APIs, you have to write scripts that are not only specific to the service, but also specific to the application being deployed. That would mean for every app you deploy you’d have to write another script to automate deployment of the services it needs, like load balancing.
But if you use templates, instead, you can use the same script and just push a different template. That means less time waiting for a new script for every app, and fewer mistakes to hunt down, like when Bob copied and pasted for the fifteenth time and forgot to change line 33.
Templates are infrastructure as code, the holy grail of DevOps.
You still need APIs, but you don’t need to use them for everything. And if you can avoid it, by using templates, you’re going to be able to avoid paying the taxes associated with them and transfer those savings somewhere else.