API Gateway Identity Crisis – are they replaced by service mesh? | Hacker News Reader

API Gateway Identity Crisis – are they replaced by service mesh?

medium.com

113 pointscloudytoday20 comments

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.

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?

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.

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 love this article https://twitter.com/sytses/status/1163503057444855808

An API gateway can mean API Management, Cluster ingress, an API Gateway pattern, or a Service mesh.

API Management will still be needed, even with a service mesh. And I don’t think the article author thinks they will be replaced.

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.

The answer is no.

The service mesh still has ingress needs. North / South.

Internally the service mesh has interconnectivity communication needs. East / West.

You will still need a gateway / load balancer.

So what about istio Gateway?

What would you like to know about it specifically?

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.

Of open source tools, Envoy Proxy also does this.

Envoy is the data plane and lots of the newer API gateways and service meshes are built on it but it still needs a control plane (aka 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.

It’s a tradeoff, to be sure.

I wonder who pays for all the handwringing about Api gateways on medium...

haha, isn't it obvious? They gotta have something for the product marketing teams to do throughout the year, after all!

There also seems to be significant overlap with load balancers, as they add API gateway type features.

That all 3 spaces converge seems inevitable.

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.

Reply on news.ycombinator.com