> The appeal of App Mesh for us was initially around using it to facilitate canary deployments. AWS Code Deploy does a nice job with Blue / Green deployments and that may suffice for us, but it doesn't support canary for Fargate. Is that enough reason to add the additional complexity in our stack? Not sure, looking for input.
Maybe you should write a script for this? It sounds like you're about to take on a lot of complexity for just the ability to do canary deployments when you could probably hack up a script in a day or two.
> We want to implement OIDC on the edge for some services, but App Mesh doesn't support that yet as other meshes like Ambassador, Gloo, and Istio seem to. Since App Mesh doesn't really act as a front-proxy on AWS, we'll still be using ALB to handle auth which is fine, I think. I get mixed messages about the need for JWT validation, but if so, that would need to be implemented in the app level with ALB fronting it.
JWTs are only required for client-side identity tokens (you can use opaque ids and other kinds of stuff for backends) -- it seems like you're also at the same time looking for something to take authentication off your hands? App Mesh doesn't do that AFAIK, it's only the service<->service communication that it's trying to solve.
I think it might be a good idea to make a concise need of what you're trying to accomplish here, it seems kind of over the place. From what I can tell it's:
- Ability to do Canary deployments
- The ability to shape traffic to services (?)
- Observability, with access logging
- AuthN via OIDC at the edge
A lot of meshes do the above list of things, but the question of whether it's worth adopting one just to get the pieces you don't have already (which is only #2 really, assuming you scripted up #1), is a harder question.
> Namespaces: In order to identify the versions of services for routing, you need independent virtual nodes and routes in a virtual router. You can reuse the DNS names or use cloudmap names with metadata to identify the versions/virtual nodes.
> OIDC at ingress - App Mesh does not do this yet, ALB / API Gateway is needed for this. App Mesh has this on the roadmap.
> Resources - You can reach the app mesh team with specific questions at the App Mesh roadmap Github and we can help
Maybe you should write a script for this? It sounds like you're about to take on a lot of complexity for just the ability to do canary deployments when you could probably hack up a script in a day or two.
> We want to implement OIDC on the edge for some services, but App Mesh doesn't support that yet as other meshes like Ambassador, Gloo, and Istio seem to. Since App Mesh doesn't really act as a front-proxy on AWS, we'll still be using ALB to handle auth which is fine, I think. I get mixed messages about the need for JWT validation, but if so, that would need to be implemented in the app level with ALB fronting it.
JWTs are only required for client-side identity tokens (you can use opaque ids and other kinds of stuff for backends) -- it seems like you're also at the same time looking for something to take authentication off your hands? App Mesh doesn't do that AFAIK, it's only the service<->service communication that it's trying to solve.
I think it might be a good idea to make a concise need of what you're trying to accomplish here, it seems kind of over the place. From what I can tell it's:
- Ability to do Canary deployments
- The ability to shape traffic to services (?)
- Observability, with access logging
- AuthN via OIDC at the edge
A lot of meshes do the above list of things, but the question of whether it's worth adopting one just to get the pieces you don't have already (which is only #2 really, assuming you scripted up #1), is a harder question.