Not All Superheroes Monitor APIs. Here Is Why They Should
If architecture is the art and technique of designing and building, then API architecture is akin to constructing a digital fabric to connect end users and application services together to bring digital experiences to life. It’s the blueprint for an information superhighway composed of on-ramps for ingress where users enter an interconnected turnpike for service-to-service communication.
With this high level of connectivity comes inherent complexity, making management and monitoring a challenge and potentially increasing the risk of compromised security. The good news is that there are well-established building blocks to help you crawl and walk before you eventually run your evolved API-based system: namely, containers and the de facto container-orchestration platform, Kubernetes, which bring the information superhighway of microservices across hybrid and multicloud infrastructure to life — with a little help from a superhero tool belt.
Key architectural considerations for managing and monitoring API-based systems include performance, observability, API life cycle and security. These factors are often intertwined; for example, poor performance can result in poor customer conversion, and a lax API life-cycle policy may increase the risk of a security incident that exploits weaknesses in authentication. Fortunately, there are key metrics that can be tracked and best practices that can be employed during design and maintenance to ensure the performance, observability, visibility and security stars align.
| Performance | Observability | Lifecycle | Security |
| Latency | Customer conversion | Feature flagging | Encryption |
| Networking hops | Revenue per hour | Release modeling | Authentication |
| Redundancy | Stream starts per second | Release strategies | Authorization |
What Goes into Your API Superhero Tool Belt?
Now back to that superhero tool belt. The API life cycle is incredibly important because evolving into API-based systems does not end with design and deployment. Architecture is a continuous journey. API architecture, in particular, is decentralized, so it is critical to ensure interoperability at every step of the way, from configuring and enabling new features at a code level to monitoring metrics to confirm performance and reliability SLAs are being met.
Traffic management is also critical for managing and monitoring APIs and serves as an opportunity to use traffic routing to model releases. This includes control of traffic originating externally from end users and traffic originating internally from services that need to be brokered across the system.
These distinct traffic patterns are characterized as north-south (ingress flow) and east-west (service-to-service flow). Remember the information superhighway?
The methods and tools used to manage and monitor these traffic flows vary, with tradeoffs and considerations that influence architectural decisions for greenfield and replatformed apps. Fortunately, there is broad consensus with respect to the right tools to manage and monitor north-south and east-west traffic flows. As detailed in the following tables, your decision about which tool to use will often be based on the calculus between complexity and business value.
| North-South Traffic | Description | Key Considerations | |
| Ingress routing | Directs consumer API requests from an external origin (web browser or mobile app) to an internal backend application. | Provides a mechanism for directing traffic from a URL to a backend system with high reliability, observability and security. | |
| 1: | Reverse proxy | A type of proxy server that typically sits behind the firewall in a private network and securely routes client requests to the appropriate backend server. | A simple solution when there are deterministic traffic patterns (often to a single backend service). |
| 2: | Load balancer/ADC | Provides intelligent traffic management, security and optimization for complex environments that require high performance and reliability. | A more operationally complex solution to manage dynamic traffic patterns involving multiple backend services and associated SSL/TLS configurations, large (media-rich) data payloads and requests needing granular traffic management due to varying priority and/or security requirements. |
| 3: | API gateways | A critical part of any modern technology stack, typically sitting at the network edge and acting as a management tool to broker communication into and across a collection of backend services. | As the number of API consumers and providers increase, API gateways are often the most scalable, maintainable and secure option, as they often provide service discovery, authorization, rate limiting and logging capabilities. Given their rich feature set, API gateways come with an inherent level of complexity. |
| East-West Traffic | Description | Key Considerations | |
| Service mesh | A technology for routing, observing and securing traffic for service-to-service communication. | When there are complex, cross-functional requirements, for example, services that use different programming languages or technology stacks, a service mesh is most likely the optimal solution. | |
| 1: | Sidecar proxy | A general-purpose pattern that is typically implemented using a proxy within a service mesh to extend or enhance functionality in a loosely coupled fashion. Service-to-service traffic within Kubernetes clusters is routed via sidecar proxies. | A simple solution that supports the addition of a number of capabilities to an application without using language-specific libraries or other techniques; however, context for gleaned insights may require language support or a shim. |
| 2: | Proxyless gRPC | Networking abstractions provided in language-specific libraries included in each service to act as the data plane within the service mesh. | A more comprehensive solution with insights that are easy to propagate and that should be considered if an API-based system is standardized on gRPC (until support for REST is provided). |
| 3: | eBPF | A technology that allows custom programs to run sandboxed in the kernel in response to operating system events, including the arrival of network packets. | An elegant, language-agnostic solution that requires kernel program updates and patching — potentially introducing security risks as applications interact directly with the operating system via syscalls. |
What’s Next?
Observability goes hand in hand with security across all aspects of an API-based system.
After deploying the right tools to manage and monitor APIs, it is imperative to secure them so that legacy apps can be successfully replatformed for the cloud while keeping risk in check. Since security comes down to risk, we encourage you to explore a threat modeling case study and read more on the risk of not securing external APIs in chapter six of the free O’Reilly e-book, “Mastering API Architecture.”
