Christian Posta’s API Gateways are going through an identity crisis on the Solo.io blog is an older essay that still reads as current, because the confusion it sorts out never went away. It separates three things that all get called an API gateway: the gateway behind API management, which exists for exposing “existing, curated, APIs that we want to share with others but share them on our terms”; the cluster ingress controller that guards what traffic enters a Kubernetes cluster; and the API gateway pattern, a backend-for-frontends that curates many services into one API for a class of consumer. Service mesh, it argues, does not replace any of them. It handles east-west traffic transparently at L7, while API gateways “live above the service mesh and with the applications (L8?).”
There are no numbers to audit here, just a taxonomy and a warning. The warning is the line worth keeping: keep business logic out of the management layer, because shared gateway infrastructure “has the tendency to re-create the ‘all-knowing, all-being’ (think Enterprise Service Bus) governance gate.” The product list has aged, since Gloo is now Kgateway Enterprise and Solo’s newest work is agentgateway for LLM, MCP, and A2A traffic, but the three-way split holds up. It is also the frame for reading what Solo itself exposes.
On the Solo.io provider page, all 15 API pages belong to the first identity. They are the Gloo Portal Server, the self-service side of API management the essay describes: the Solo.io API Products API for the curated catalog, the Solo.io Subscriptions API for signing up to plans, the Solo.io API Keys API and Solo.io OAUTH Credentials API for the security flows, and the Solo.io Teams API for who is allowed to consume what. Ingress and the gateway pattern are configured declaratively through Kubernetes resources, which is why they do not appear here as REST surfaces, and the catalog does not pretend otherwise.
The Kin Score is 60.4, strong band, carried by developer ergonomics at 78.6, discoverability at 76.7, and contract quality at 65.2, with access clarity at 50.0 and contract governance at 28.0. Agent Readiness is 34.8, agent-ready, with the MCP server, agent skills, and error semantics lit and the well-known catalog, delegated identity, protected resource metadata, and dynamic client registration dark. The essay asked readers to put each gateway at the level where it adds value. Measured from outside, Solo is legible at exactly one of the three levels it describes, and the governance facet is the weakest thing about the management API it does publish.