3 ms·

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 faci

by revel 7y ago

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.

hinkley 7y ago
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?
- paulddraper 7y ago
  High availability, sure. 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.
donavanm 7y ago
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.

by revel 7y ago

hinkley 7y ago

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?

paulddraper 7y ago
High availability, sure. 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.

donavanm 7y ago

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.