Cloud native architecture is built upon four pillars: rapid release cycles, architectural flexibility, packaged delivery, and continuous deployment. These traits have enabled organisations to design and deploy hundreds to thousands of solutions across the world. These solutions expose external and/or internal APIs to support the automation needs of their customers, partners, and workforce.
However, API management in a cloud native world is not without its challenges. We are going to look at five of these challenges and find ways to address each one.
1. Multiple architectural styles that require differing API management needs
The traditional monolithic or n-tier architectural styles expose a single API surface area, managing all of the details behind-the-scenes. With each new release, the API gateway must be updated to be in sync with the latest operations and authorisation rules.
Since release cycles for these architectural styles are all-or-nothing, the gateway configuration updates are applied at deploy time. Releases are often automated with tools such as Ansible or Puppet. All north-south traffic (i.e. traffic from API consumers) is managed by the gateway.
Microservices stand in contrast to a monolithic architecture through the use of small, self-contained services that deliver one or a few capabilities. Microservices are independent of one another but may be combined to produce highly-complex solutions.
Since microservices are distributed components, each service has an independent release cycle. API gateway configuration has to be managed per-component rather than across the entire solution. This makes the automation process even more important, as release and rollback processes must be careful not to negatively impact other services. If we fail to isolate the release process for each component we will end up with a big-bang release of a distributed monolith – much like we saw in the SOA days a decade ago.
Additionally, there are additional network concerns with microservices. Not only does north-south traffic need to be properly managed, but so does the east-west traffic between the components. Propagation of authorisation details is essential as well to ensure that a service understands how to properly apply data access and entitlement rules.
If our architecture was one style, it would be much easier to manage. However, cloud native solutions often involve in-house, third-party, and legacy systems. Your API routing rules, authorisation, and data entitlements have to play nice in this kind of environment. Having an API gateway solution robust enough to handle these variety of architectural styles is critical.
2. New API styles beyond REST are emerging that demand more from API management
For REST-based APIs, each operation (or a group of operations) is registered and protected by an API gateway using a specific path or path prefix. This ensures that only authorised consuming apps are allowed access. Operations that work with sensitive data can be further protected as a result of this operation-based approach through entitlements and sanitised for logging purposes. It is important to note that an API gateway’s ability to enforce each operation is driven by the layered architecture of HTTP, which allows for middleware to be inserted transparently between the consuming application and the API.
However, new API styles are emerging that are introducing additional challenges to API management, including GraphQL and gRPC.
GraphQL is designed to return shallow or deeply nested data structures within a single HTTP request. It is a common choice for shaping the response of data from an API within the UI of web and mobile-based apps. Since GraphQL uses a single HTTP-based endpoint, API gateways are often unable to apply management techniques such as rate limiting, role-based access, reporting, and analytics of a GraphQL-based API beyond monitoring the single GraphQL query endpoint.
To protect GraphQL-based APIs, custom code must be written that parses all incoming requests. This code must:
- Determine the type of query or mutation being performed by the client2
- Assert resource-level RBAC for any/all resources within the query, and
- Apply any restrictions prior to processing the request
It is also important to recognise that reporting will be more challenging for GraphQL queries, since the code itself will need to interpret and log the specific queries being requested.
gRPC is emerging as a popular choice for network APIs between services. It is built upon HTTP/2 and offers bi-directional streaming support. Since HTTP/1 assumes short-lived connections and doesn’t natively support streaming, API gateways must be able to handle proxying calls that may exist for a longer period of time. Additionally, gRPC uses HTTP/2 primarily for tunneling of the protocol and therefore makes it more challenging to manage when using service-to-service calls. The addition of a service mesh is often required to help manage authorisation and routing needs for gRPC-based APIs – unless your API gateway is able to manage gRPC calls.
3. The introduction of Kubernetes and multi-cloud to manage API traffic
Kubernetes is an orchestration layer over multiple hosts, responsible for managing compute, network, and storage infrastructure on behalf of user workloads. Kubernetes has been called a ‘platform of platforms’, as it is a building block for container-based infrastructure.
Kubernetes has a few key concepts that we must understand when it comes to API management:
- A Kubernetes pod is the smallest and simplest unit in the Kubernetes model that one can create or deploy. A pod encapsulates one or many application containers and also includes: storage resources and a unique network IP
- A Kubernetes service is an abstraction which defines a logical set of pods and a policy by which to access them.
- Kubernetes load balancers distribute traffic by port, allowing any kind of traffic (HTTP, TCP, UDP, Websockets, etc) to be distributed across pods managed by the service. They are often provisioned using a reverse-proxy solution such as nginx, HAProxy, or a cloud-native resource from your cloud provider
- A Kubernetes ingress typically routes HTTP traffic and may offer TLS termination for secure HTTPS communication. Traffic routing is controlled by rules defined on the ingress resource, including options such as routing traffic to a single service, applying a fanout strategy to multiple services based on a URL path element, or name based (for virtual routing of multiple hosts)
While traditional API gateways are able to route incoming traffic into a Kubernetes cluster, having the option of a Kubernetes ingress affords more flexibility and avoids the need to construct workarounds or customised deployments to make them fit into a Kubernetes-based infrastructure.
4. The growth of API portfolios and API governance
An organisation’s API portfolio is a digital reflection of their capabilities and day-to-day business practices. As your API program expands, it is important to manage it effectively. This includes partitioning the portfolio based on capability domains (e.g., customer accounts, orders, and inventory for an eCommerce platform). It is also important to segment your API surface area based on the target audience to limit exposure of sensitive data and operations (e.g. partners, internal APIs, and public APIs).
Organisations should also develop a clear process for adding new APIs into the portfolio, API consumers will have an easier time finding the APIs they need. Manage your URL paths through the use of prefixes or other naming conventions. The URL paths for your API are like real estate for developers.
A properly executed API portfolio ensures teams across the organisation can contribute to the overall portfolio. Selecting an API gateway that enables you to effectively manage your API surface area will contribute to an effective cloud native API management approach.
5. Multi-cloud API management
Organisations today are finding that multiple cloud regions, and even multiple cloud vendors, are necessary. Reasons for incorporating multiple cloud vendors include:
- Catering to customer demand to avoid or use specific cloud provider(s)
- Accessing data centres in regions not provided for by your primary cloud provider
- Managing costs and resources more effectively by taking advantage of reduced costs or specialised offerings not available with other vendors
- Increasing performance and resiliency from outages in a specific region or across an entire provider
- Addressing data sovereignty, data residency, and data localisation concerns
No matter the reason, supporting a multi-cloud strategy requires evaluating your API management approach. This includes finding an API management solution that is capable of working in a multi-cloud, multi-region configuration while ensuring a centralised control plane that ensures all instances of the API are in sync with the latest authorisation and routing rules.
For more insight into the challenges of multi-cloud API management, take a look at the Cloud Native API Management whitepaper.
