3 ms·

I'm evaluating using AWS App Mesh at the moment. We're a really small team so we're choosing Fargate vs Kubernetes- mainly because we don't have need of nodes n

I'm evaluating using AWS App Mesh at the moment. We're a really small team so we're choosing Fargate vs Kubernetes- mainly because we don't have need of nodes nor want to deal with them. 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. Also, much of the documentation is focused on K8s. I'm murky on how to implement an internal namespace for routing. Most of what I've seen is like myenv.myservice.svc.cluster.local but its not clear to me that using that pattern is needed in the context of Fargate. Consistent observability is valuable, but again Fargate can do that pretty well- it just doesn't mandate access logging so that would be left to the app itself. 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. Can anybody help me find resources to sort this out? I've been through the `color-teller` example time and time again, but it still leaves lots of open questions about how to structure a larger project and handle deployments effectively.

hardwaresofton 7y ago
> 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.
- shubha-aws 7y ago
  > 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
fcoelho 7y ago
On canary deployments, if you can wait a bit to make a decision, CodeDeploy should have canary deployments available soon-ish: https://github.com/aws/containers-roadmap/issues/229 https://github.com/aws/containers-roadmap/issues/229
- reilly3000 7y ago
  Great news, thanks for sharing!

hardwaresofton 7y ago

> 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.

shubha-aws 7y ago
> 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

fcoelho 7y ago

On canary deployments, if you can wait a bit to make a decision, CodeDeploy should have canary deployments available soon-ish: https://github.com/aws/containers-roadmap/issues/229 https://github.com/aws/containers-roadmap/issues/229

reilly3000 7y ago
Great news, thanks for sharing!