Manage your API deployments
At the very beginning of your API Gateway journey, everything seems to be easy and magic to expose your APIs within the Gravitee.io constellation, and you’re feeling like a unicorn horse in a fantastic world...
You, as an API publisher, just have to declare and define one or more APIs in the publisher portal, deploy them across multiple instances of API gateway and… that’s all, you are now ready and wait for consumers. Well done guy!
But one day, your company wants to explore other skies, other businesses and is looking to expose APIs not only for its internal developers, but also to partners and, why not, expose them to a larger public because you think there are some big business challenges to achieve thanks to your services / your data.
Deployment strategies
Fortunately, Gravitee.io is coming with some facilities to manage your API deployments which allow you to distribute APIs among multiple API Gateway instances. This is the well-known sharding-tags feature.
Look at this big middleware!
When starting with API Management, the easiest solution is to expose an API Gateway instance (or multiple instances, it doesn’t matter) and then deploy the APIs to it.
That sounds good, it’s pretty easy but this has some major drawbacks:
- Gateway’s resources are shared between all the APIs. How would you manage the resource if the gateway is managing a very large traffic for multiple APIs?
- How would you manage the exposition of APIs?
- Some will say that in this scenario, gateway must be considered as a single-point-of-failure (ok, we can still have multiple API gateway instances…)
Let’s start to split API deployments
Once you get ready with a quite simple middleware deployment, you’re looking to go further on the deployment strategy.
Thanks to the experience we get from our customers at GraviteeSource, we know that the first requirement is to manage API exposition to e different target: their partners, but without having to expose existing internal services.
Some of them are also looking to manage APIs per company’s entities or per functional domain.
The biggest drawback with this strategy is that you will have to manage multiple entry-points / domains to access each of these sub-clusters, for example:
- https://api.mycompany.com (for public access)
- https://private.api.mycompany.com (for internal / private access)
- https://partners.api.mycompany.com (for partners access)
But again, Gravitee.io comes to the rescue and helps you to manage and define all the entry-points according to the sharding-tags configuration.
For sure, these entry-points will be easily accessible from the developers portal to help them to start quickly with APIs you exposed, ensuring the time-to-first-api-call.
As a side-car
Latest strategy option is to put an API Gateway in front of your API backends to ensure and apply common features without having to implement them as part of your backend (security enforcement, logging, rate-limiting, …)
This pattern is mainly coming from micro-services architecture but may be applied in many ways.
The pros are:
- All the API gateway resources are allocated for a single API, which will be really great for APIs with a (very) large traffic,
- API Backends may be written in different languages,
- API Backends code should not have to change,
- Because of the proximity, latency should be low,
- Even if the API backend does not provide extensibility, you can still add functionality at the gateway level.
But, for sure, there are also some drawbacks:
- This strategy may be overkill if your API is small
- You may have to manage side-car scalability differently than or independently from the API backends (but it’s not really hard with Gravitee and its service discovery feature / implementations).
Well! But what about my plans?
Obviously, it appears that the API is deployed on multiple shards, let’s say for an internal purpose and your partners. For sure, you can manage it by defining deployment tags at the API level, but what about the API’s plans? What if you’ve define specific plans for your partners, most probably with specific constraints (only GET method, not more than 10k requests per month, …)?
Again, Gravitee.io is still there to help you to manage also the sharding / deployment of the API’s plans to distribute them according to the consumer target. So, for example, you can base API authentication on two distinct OAuth2 or JWT plan, using two distincts authorization server or public key. And the gateway will take about the rest… Say, thanks Gravitee :)
What’s next?
In this post, we’ve covered the different options to manage deployment of your APIs and their underlying plans.
You can continue and go further with Gravitee.io to manage even more easily the way to resolve API backends / endpoints according to where the gateway is deployed, something we are calling “tenant” or “tenancy” and which can be widely used in the context of multi data-center deployments.
But, this would be the topic for an other blog post :)
If you have questions, suggestions, issues, we would be happy to help you from our Gitter channel.
