Enterprises are implementing API-centric architectures to transition to microservices and Kubernetes. I’ve always wondered how fast the change was taking place and when.

As I began planning my activities at the Index conference in San Francisco, I was reading through the open community meetings and I see Kubernetes, OpenAPI, Istio, and Node.js as some of the communities listed.

This got me thinking more deeply about the central role that API architecture plays in all these groups and how new API technologies open the path for large enterprises to move to new architectures using containers and API servers. API architecture may not be as interesting as Kubernetes and microservices. But implementing technology and processes to create, test, and document APIs lays the foundation for a scalable IT organization that can manage a microservices architecture.

APIs and Site Reliability

Modern cloud applications are highly services-driven and leverage APIs extensively including a wide range of external APIs. This is a key part of the shift from monolithic architectures to microservices.

The implications of that change from an operational perspective are significant. Four “golden signals” of monitoring, championed by the Google site reliability engineering (SRE) team and the larger web-scale SRE community, are seen as the most fundamental metrics for tracking service health and performance. They are latency, traffic, errors, and saturation. They are the foundation of service-level observability for large-scale production applications. These golden signals ultimately help measure end-user experience, service abandonment and impact on business.

Microservices

Microservices are small, simple services that are accessed using the HTTP protocol through APIs. They are reusable and can be updated and provisioned independent of other services. Older architectures are based on monolithic applications, which are larger units that are tied together. The main problem with monolithic applications is that a change to one area may force a change in many other areas.

Microservices allow developers to work on individual components independently. This enables an easier move to DevOps and Continuous Delivery (CD). Many large enterprises want to get the benefits of lower downtime and higher responsiveness that DevOps and CD brings, but how do they actually move to something like Kubernetes, Docker, and a microservice architecture?

API Standards

The Open API Initiative (OAI) is a fairly new open specification group run under The Linux Foundation umbrella. Its primary mission is to promote a standard specification for API definition. Founding members included 3Scale, Apigee, Capital One, Google, IBM, Intuit, Microsoft, PayPal, and Restlet. If you aren’t actively involved in API architectures, you may be wondering why there’s a need for a standard API specification.

In the last few years, there’s been an increase in tools to create, test, manage, and document APIs. The OpenAPI Spec (OAS) was created to enable different tools to work together, ultimately supporting the creation of API architectures that are more robust and easily managed.

APIs are Foundation for Scale

While a sweeping change to Kubernetes and containers is an exciting project for many IT professionals, the reality is that many projects get stalled in the pilot phase. Switching off of an existing enterprise architecture to Kubernetes is a big deal and the ROI may be difficult to calculate during the proposal phase.

Although API architecture is not as exciting as diving straight into Kubernetes and microservices, implementing technology and process to create, test, and document APIs will lay the foundation for a scalable IT organization that can manage a microservices architecture. Kubernetes.io publishes all APIs in the OpenAPI specification. The Kubernetes service publishes OpenAPI specs and ships with OpenAPI UI tools.

Benefits of an OpenAPI Specification

According to March Gardiner in his Google Next ‘17 presentation, API Design and What’s new with Open API?, the following are benefits of embracing and OpenAPI specification:

• Document generation
• Code generation
• API service configuration
• API authoring and creation

Summary

A new architecture requires a new foundation. Scalable connections between services require standardization of API specifications and management processes. Open standards and open source projects are at the forefront of the change. Even when attending a large enterprise technology conference like Index, I’m going to pay special attention to open source and open standards communities like Kubernetes, OAI, and Docker. That’s where the action is.