How to select an API Management Platform for your business — part III
How to select a future-proof API Management platform for your business
Introduction
This is the third and final part of the article series we wrote on selecting an API Management for your business. You can find the first two parts of this tutorial in the below links.
In this article, we are discussing how to make the solution future-proof and ready for cloud evolution and the features that are required to make it happen. At the end of this chapter, we will provide a guide on selecting the best possible API Management platform for your business considering technical and non-technical aspects.
How to make your API platform cloud-native?
Now we have discussed expanding our API platform to wider audiences through the developer portal and API federation. What’s next? Next in-line is what everyone is talking about. Making it future-proof and cloud-native or cloud-ready. We didn’t want to jump into the cloud bandwagon at the beginning since APIs and cloud-native are 2 separate things and to understand the value of APIs, you do not necessarily need to talk about cloud-native concepts. But we cannot let it go if we are designing our API platform to be future-proof.
The layman’s definition of the word cloud-native is “to reap the benefits of the cloud”. At a high level, cloud computing offers you the capabilities like
- High availability — available across the globe
- Elasticity — can scale up and down as and when necessary
- Scalability — expand to global scales
- Cost savings — pay as you go
There are many other aspects, but we can consider these as the basic advantages of the cloud. Let’s see how we can align our API platform to reap the benefits of the cloud. There is an entirely different set of advantages offered by container platforms and microservices architecture which is not mentioned here. Once you have the platform designed for the cloud, you can consider gaining those advantages also through the same.
One of the fundamental aspects of scalability and maintainability is modular architecture. If you have all the functionality baked into a single monolithic application, scaling becomes much harder. The concepts like microservices architecture have come up to address the problems which are surfaced with this monolithic architecture. Once the functional components are divided into compatible yet independent modules, the deployment becomes much more flexible. Let’s see how to define a cloud-native architecture for your API platform.
The above figure captures several aspects which we have not yet discussed and hence the steep jump from the previous figure to this one. Let’s start with what we have discussed before the figure which is the modular architecture. Prior to this point, we considered the API gateway as a one-component and the API developer portal as a separate component. In this diagram, we have separated the security part of the API gateway into a separate component called API key management so that security-related requirements can be handled independently.
Also, we have introduced 2 additional modules for API analytics and API development. API analytics component is good to have feature if you want to analyze the API usage and many other parameters and take decisions based on that. API development component is the component where API developers will interact when building the APIs. This can be a GUI-based interface or a fully automated process that bounds to a source code management system and a build pipeline like Jenkins.
The other key addition of this figure is the separation of internal and external gateways so that those APIs don’t impact each other during the execution (runtime). In addition to that separation, there is a hexagon in those components that describes a micro gateway that can be used in certain use cases where you need to deploy one or a selected set of APIs in an isolated runtime that can work independently from any other component. Again, the micro gateway is good to have components in your API platform.
Finally, all these components are embossed with the docker logo to depict that these components can be deployed in a cloud-native platform like docker. The selection of the underlying infrastructure layer is totally up to the respective organization. The above architecture matches well with any of the
- On-premise (physical/VM)
- IaaS (VM based)
- Containerized
- Kubernetes
infrastructure mentioned above.
Non-functional requirements of an API Management Platform
Up to this point, we mainly discussed the functional capabilities of the platform that we are going to build. There are a few non-functional requirements also to be considered when selecting the right vendor for your need.
Supported deployment options
Organizations change their strategies more frequently than ever before. The choice of deployment model is key when selecting a vendor for any application within the enterprise. There are 3 main deployment choices available in the industry for application deployments.
- Self-managed deployment (on-premise, on-IaaS)
- Vendor-managed deployment (SaaS, private-IaaS)
- Hybrid deployment (vendor managed + self-managed)
Let’s discuss in detail what these deployment models offer to the users.
Self-managed deployment
This is the traditional on-premise deployment model where the users need to manage the deployment of the API Management platform by themselves with support from the vendor. The vendors provide support through ticketing systems like JIRA with different SLAs for different types of issues (incident, queries, development, etc.). With the popularity of IaaS providers like AWS, Azure, and GCP, more and more people started deploying these products on those platforms. Even that sort of deployment on a cloud platform is considered self-managed if the user is managing the deployment-related activities like patching, updating, upgrading, and monitoring. This option is suitable for organizations having dedicated IT teams with enough resources to manage these deployments. With the usage of proper automation and monitoring tools, most of these management activities can be offloaded to systems. But that requires a significant effort to build such an infrastructure. One advantage of this approach is that the system has the highest level of flexibility in terms of customizations that are required for the specific customer.
Vendor-managed deployment
This is the option with the least management overhead. In this option, the vendor who offers the product takes care of the management of the deployment. In most cases, these solutions are provided as SaaS (Software as a Service) or PaaS (Platform as a Service) on the cloud. The users have to work with the solution architects from the vendor to identify the components and their respective sizes required for the project through capacity planning exercises. Then the vendor will provide the required services on their cloud platform and give the users with access to those services. In most of the vendors, these services are running as multi-tenant, shared infrastructure with each user getting logically separated deployment.
One drawback with this approach is that the flexibility in terms of customization is very limited since this is a shared infrastructure. As a solution to that problem, some vendors offer the option of providing a fully managed, private cloud deployment for users who are willing to pay some extra bucks. The deployment will be a dedicated one for the user on a given cloud platform (IaaS) and the vendor will take care of the maintenance and management aspects.
Hybrid deployment
This deployment model is designed to provide the best of both worlds in terms of flexibility and the management of the infrastructure. In this model, the vendor is managing the “control plane” or “management plane” related components that do not need to stay close to the user’s systems. As an example, the API gateway is a component that needs to sit close to backend systems but the developer portal does not need to do the same. In such a case, the API gateway will be deployed in a customer-managed infrastructure (on-premise, IaaS) while the developer portal is deployed in a vendor-managed cloud environment. This model comes with a certain set of challenges as well. Integration from vendor deployment to user deployment needs to be set up in a proper manner and given the platform resides in 2 places, debugging issues can be difficult at certain times. But those challenges come with the price of flexibility and performance (latency) gains that users could achieve with this approach.
Each organization has its preferred ways of managing the IT systems and based on that preference, users can select a platform that supports that particular deployment model. One thing to consider here is that, if the platform is designed in a modular manner where functional components can be deployed independently, any of the mentioned deployment models are possible and future changes of directions can be accommodated.
Developer Experience
The next big thing that we should consider when selecting an API Management platform is the developer experience with the platform. If the developers within your organization prefer using low-code, UI-driven API development and governance, selecting a platform that comes with such a UI (e.g. publisher) or an IDE (offline or cloud) would help to deliver applications effectively.
But if your organization is comprised of developers who love to automate the processes with minimal UI interactions through CICD pipelines, then the platform should support these requirements through
- Product APIs
- CLI tools
- Kubernetes operators
- Deployment resources for Docker, Helm, Ansible, Puppet
It is critical to select a platform that aligns with the level of experience and the skill set that is available in the organization or has plans to hire. In most cases, we could find engineers who can wear different hats based on the need of the company. But it is good to select a platform that most of your engineers are comfortable with than asking them to adapt to the new platform.
Total Cost of Ownership (TCO) and Return on Investment (ROI)
Last but not least, it is essential to consider the financial aspect of the project on top of all the other aspects such as features, deployment, and user experience. It is essential to understand the broader picture of TCO and ROI before taking any decision on the final vendor.
Total Cost of Ownership (TCO)
This is the cost associated with not only purchasing the licenses but also managing the solution for a given time period (e.g. 3 years or 5 years). This includes
- Licensing cost for production and pre-production usage
- Infrastructure cost (If doing an on-premise or hybrid)
- Learning curve
- Managed services cost (associated with private deployments)
- Availability of skilled resources
- Consultancy services cost
Some factors such as the learning curve and the availability of skilled resources are not directly quantifiable. But considering those aspects also important in making the selection.
Return on Investment (ROI)
The other side of the cost metrics is the return on investment which is not possible to measure at the beginning. But with the KPIs we discussed in the first part of this series, we can measure the return on investment as time goes by. At the initial stages, we could consider the aspects such as
- Time to market (production)
- Reusability
- Operational savings
to measure the ROI of the platform.
Selection guidelines
Now is a good time to share a set of guidelines on selecting the right API Management Platform for your business.
- Look out for required functional capabilities such as security, monitoring, OAS, Swagger, SOAP, REST
- Developer experience and productivity (UI driven development, CLI tools)
- Features to engage with external application developers to the platform (Developer portal)
- Deployment choices (on-premises, SaaS, hybrid)
- Integration with existing solutions such as IAM vendors for security
- TCO and ROI over 3 to 5 years
- Support for cloud-native architecture and future road map
- Quality of enterprise support and SLAs
Summary
If you have read this far, you may be wondering what is the API management platform you are going to select? Even though the topic of the article suggests a selection process, the final decision on a particular vendor always in the hands of the respective organization. In this article, we covered the fundamental requirements of an API platform and how that can be scaled within an organization to reach out to more customers and then make it future-proof. In terms of vendor selection, here is a list of vendors that fits into the above-mentioned requirements.
Happy API Management !!!
