Many of us in the tech community have seen the rise of better and better tools for automating some of our most common tasks. Historically, developers tend to think about how we have strived for years to automate unit and regression testing to help with code stability. At this point, automation has grown far beyond us just testing our code and it’s performance. Growing over the last few years is the realm of DevOps automation to assist with everything from automating builds to automatically creating the servers where those applications will live. Our lives as developers have become infinitely easier by adopting these tools.
With the push for automation impacting every single aspect of our tech stack and processes, one question we may ask is, “is it possible to improve our API Management platform and experience by using automation?”. The answer is yes! And I’m going to give you some details on the benefits of automating your APIM as well as how Tyk enables you to do so!
What types of automation paradigms are supported?
Automation generally comes in two common flavours: imperative and declarative. Likely, if you are using automation anywhere in your setup, your methods will fall into one of these two categories.
Imperative automation is usually defined as a more step-by-step approach. In the real world, it’s similar to following a GPS route in the car where each step must be executed perfectly in order to end up at the destination. You have a defined starting point, and through the supplied instructions, you end up at your desired destination. In the technology world, it would likely look like something along the lines of a typical setup or build script for your infrastructure and once all the steps are completed in order, you end up with the server and configuration that you desire.
Declarative automation is a bit simpler, in concept, than imperative automation. Declarative automation, to compare to the above example, is more similar to taking a ride-share service or taxi. You start at your location, tell the driver where you need to go, and know that when the car stops you will be at your destination. You don’t need to worry about how the driver arrives, just that they did. In technology, this usually takes the form of supplying some type of specification to a tool which will then use this specification to build the resource exactly as expected.
What are the benefits of each paradigm?
Imperative automation tends to be widely supported by many platforms and is a very common way to do many tasks in developers’ lives. Some simple examples of an imperative approach to automation would be:
- Writing a .bat script to run some common tasks.
- Having a shell script that you’ve created to set up a server environment on a new build.
As developers, we are very used to this step-by-step approach, so it’s no surprise that many platforms have tools in place to support it.
Imperative automation comes with the benefits of being commonly used and easy to grasp. It is also largely supported throughout many of the platforms we use today, If it is not supported directly in the tool we are using, likely there is still a way to imperative automate the operations we need to execute.
Declarative automation is beneficial because the premise is very simple: let the tool know what needs to be built and then let it build it! Developers only need to know how to write the specification and don’t need to be concerned with the intricate details of knowing exactly how to get to that outcome. The system will handle it for them.
A great example of this would be when we use a relational database and execute a SQL query. We simply write the data that we want and the SQL engine knows how to retrieve and format the data returned. This could also be said for the use of GraphQL queries.
Declarative automation comes with the benefit of allowing users to describe what the outcome of the process should be without needing to know or understand exactly how the system will get to that output. Quite simply, it just works and produces the required output.
What are the challenges of each paradigm?
The challenge with a more imperative approach to APIM automation is that generally, you must execute this type of automation with the system in a certain state. This dependency on state means that if the processes that are configuring your system are not executed when the system is in a certain state, you might end up with a failure during the setup or will be left with a system that is misconfigured.
In order to account for different scenarios that may arise when using an imperative approach, there is a lot of trial and error. Once an issue arises, the users may then tweak the scripts to accommodate for the possibility of the error or issue occurring again and handle it.
With an imperative approach to APIM, it tends to take more time to ensure that the system and APIs get configured correctly. Even though this is a very common way of introducing and supporting automation it can lead to less predictable results than those using a declarative approach since a declarative approach doesn’t require the user to accommodate for edge cases and are instead handled within the automation tooling itself without user intervention.
There seem to be less challenges within the declarative approach to automation since the tooling itself requires less troubleshooting and less risk of misconfiguration. By simply being able to tell the tool or platform what you want the output to be, the results are much more consistent. The challenge with declarative automation would more likely be centred around learning the platform and syntax required in order to define the desired system state.
There may even be a case where both types of automation may be used in conjunction in order to alleviate the pain points of each approach.
Regardless of the challenges faced in both approaches to automation, there is still going to be an exponential amount of consistency, risk reduction, and time savings compared to a manual approach to configuring a system.
How does Tyk support imperative API management?
The imperative approach to API Management is fully supported within the Tyk platform. As part of Tyk’s offering, APIs are available through the dashboard in our enterprise version and through the gateway in our open-source offering as well as our enterprise version.
Users and administrators are able to create a procedural, step-by-step configuration of how they want Tyk configured as well as fine-grained control over their APIs by using the exposed Tyk APIs. All available features within Tyk and our APIM solution are exposed through the Tyk APIs which means that users looking to configure the platform can do so by creating simple scripts which interact with the APIs.
For our enterprise users, it is important to note that our dashboard is actually designed around the Tyk APIs, an API-first approach. This means that the dashboard UI actually directly leverages the underlying APIs to configure the system so in short, anything you are doing within the Dashboard can be done using the underlying APIs directly.
By using the Tyk APIs one can very easily create end-to-end automation of their Tyk setup and APIM processes.
How does Tyk support declarative API Management?
Recently we introduced the Tyk Operator to help power organisations in need of declarative API management support. As part of this initiative we are now able to fully support declarative APIM within Kubernetes.
What does this look like? For those familiar with using Kubernetes Operators, you’ll experience the same syntax you are used to in terms of configuration files that are easy to create and use. Using the Tyk Operator in your Kubernetes setup will allow you to configure all the details of your Tyk instance and configure each API in a declarative way. This may allow you to include API definitions used by Tyk right alongside the actual source code for the API that Tyk will proxy traffic to. Now, instead of having one repository for your API source code and another repository or process for the configuration of your API, you could simply have these live together. As an API is built or modified, its consequent configuration from an API management can also be updated to reflect this. Then, as part of your CI/CD pipeline you could have your new API built, deployed, and configured as part of this flow. This is a great move towards a more GitOps-centric approach for creating, deploying, and managing your APIs.
If you’re not currently using or thinking about adopting Kubernetes, you may also think about using a platform like Ansible to declaratively automate the setup of your Tyk instance and configure your APIs. You could fundamentally do the same type of setup and configuration that the Tyk Operator exposes but without running within a Kubernetes environment. You’d leverage Ansible to create the Tyk instance, update the Tyk instance and its global configuration, and also use it to configure Tyk for each individual API that is proxied through the gateway.
Regardless of what approach is taken, automating your API management in a declarative way may help to make your APIs easier to build, deploy, and manage compared to doing things manually (or even partially automated).
Try it out today!
Want to know more about Tyk and applying the above automation strategies? Start a free trial today and check out our documentation on Tyk’s gateway and dashboard APIs, our Kubernetes Operator, and our work with Ansible.
