This is an interesting article but there's a dichotomy here that isn't discussed that I think is important. Part of the appeal of an API gateway is that it facilitates bolting on solutions to a ton of common crosscutting concerns that show up between external-to-internal callers. Purely internal-internal system communication isn't quite the same and the set of concerns that affects each is different. Authentication and authorization are not necessarily concerns for system internal calls, for instance, neither is endpoint stability (at least, not in the same way). This article blurs the line between the two.
Strongly disagree that “internal” interfaces have lesser access control or (to a degree) stability concerns. Any successful system will, sooner rather than later, have the same concerns as those “public” use cases.
Coming from inside AWS the fact that we build on the same primitives customers is an advantage. When my service calls EC2 APIs its with the same IAM Principals, Policies, and evaluation that EC2 uses to authorize any other request. Similarly inside my service different components or microservices have their own Principals, and can define access capabilities just as we expect customers to do. That means we’ll find sharp edges or gaps; but those drive improvements for us that solve the same problems our customers will get to sooner or later.
I’m not so sure we won’t be talking about endpoint stability in five to eight years. Once we’ve figured out how to get high abailability at the ingress, why not extend that down the stack?
Why do I need circuit breakers but the guy calling my service doesn’t?
By "stability" I think the parent meant interface stability.
For external access I may need to support the same data formats and schemes for years, but it hardly makes sense for you to have that same burden of API stability on internal systems that you could refactor with less effort.
It's the same article. I think there is a misconception that mesh will replace gateways but as mentioned in earlier comments...it's really two different types of traffic patterns with north/south and east/west so we'll need both.
A feature not mentioned is translating between HTTP/REST to other protocols. GCP Endpoints (https://cloud.google.com/endpoints/) has this functionality for gRPC and gRPC-web (additional proxy on top of gRPC). I'd love to learn about similar features on AWS's API Gateway.
You should think more about: api management (as selling API to someone) and as a security enforcement point to make sure some rules are applied, always!
Those simple api gateways are replaced or will be replaced, that's probably true.
I’m trying to convince my team to move some stats to the ingress server to reduce duplicate effort going forward, and also just to have apples to apples comparison for some metrics.
We spend a lot of time trying to remove choke points from our code but the fact is is that when you need to enforce policy, the checkpoint is the only place you can safely put it.
I’ve only recently begun my Kubernetes voyage of self study and knowledge acquisition (as it’s becoming more of a demand in job requirements so I’ve begun studying) so pardon the ignorance, though that’s what motivates the question:
Is k8s an indicator of that convergence happening or do I misunderstand this tooling?
The rise of microservices and k8s (or other container orchestration) has brought about the need for more advanced API management.
It used to be that most people got by with physical servers, or maybe EC2 instances. Everything was relatively static and so configuring the networking was doable by hand. You also could handle things like authentication at the application layer just fine.
As you introduce more services and make things less static by using k8s, you introduce the need for more configuration, more service discovery, etc. Things like authentication and documentation need to be moved up to the API Gateway layer for consistency across the myriad of services people are now running.
I think the convergence is more of a sign of of the ecosystem around containers maturing and realizing that really these things are related and we need all of them so let's put them all together.
> One thing to note: we want to be careful not to allow any business logic into this layer.
I can’t agree. But I also include operational concerns under the umbrella of “business logic”, and the only examples I can think of where I would break that rule with relish relate to ops. From audit trails to security.
