AWS App Mesh – Service Mesh for Microservices on AWS | Hacker News Reader

AWS App Mesh – Service Mesh for Microservices on AWS

aws.amazon.com

91 pointsgreyskull33 comments

I am looking forwards to digging in to this a bit more and figuring out how this compares to Istio. I am guessing integration with AWS services such as X-ray and Cloudwatch/logs are the selling point. Still, I am a bit weary about configuring things that run inside your Kubernetes cluster through amazon apis, and not k8s resources. However, you could easily create a custom resource for this. Maybe that is to come? EKS is still young and they are yet to figure a lot of things out, from what i've seen, the roadmap is promising though. I have been working with it a lot, kops still wins for small/medium workloads in production, but I doubt for much longer.

shubha from AWS here, we built App Mesh to enable customers to use microservices in any compute service in AWS - be it ECS, Fargate, EKS or even directly on EC2. You configure capabilities using APIs and App Mesh configures Envoy proxies deployed with your pods.

IS it Istio? Someone on Twitter mentioned it uses the same ports and MIGHT just be Istio...

The ports that are common are the envoy ports. In the roadmap it's mentioned that support for istio mixer is planned implying that mixer isn't supported now which, if it was istio, it would be.

the blog post says it's envoy

(App Mesh SDE)

We chose to use some common configuration for deploying Envoy to drive consistency there, but App Mesh itself is a custom control plane for managing Envoy.

I wonder if this integrates with AWS Certificate Manager to provision HTTPS certificates so that traffic can be end-to-end encrypted. That's one of the reasons I've stuck to Application Load Balancers in front of services instead of using ECS/Route53 service discovery.

Not yet. On the roadmap. Leave us your inputs https://github.com/awslabs/aws-app-mesh-examples/issues/33

Does App Mesh mirror how amazon internally communicates between the services they build at all?

Would this be suitable for an actor-based system (where we want to think of each actor as a routeable microservice)?

Assuming your actors use queues, as they traditionally would, I don't think so. You don't really need service mesh if your communication is a queue, right?

I was wondering more about orchestration of the actors... something needs to be responsible for spawning them onto machines and something needs to be responsible for tracking where they are or where their queues are. I love MSFT Orleans but I'd love even more something that fit easier into a conventional node.js and docker kind of world (C# is great but when I look at adoption curves Typescript seems to be growing fast while C# seems to be at best holding steady)

Aws step functions? That's their solution for tracking long running state.

Good timing since Envoy just became a graduated project at CNCF.io

https://blog.envoyproxy.io/envoy-graduates-a6f71879852e

like Istio?

It rather looks that way, although it seems like it requires more explicit configuration.

Perhaps you can help me out. I'm wondering where Istio (and other meshes) fit into the picture when deploying to k8s. The Itsio docs mention it is deployed as a side car, but is that within each pod? And are Service objects still required?

Here is my mental model of a traditional deployment (EKS):

Service[Type: LoadBalancer] -> Deployment[Pod]

How does Itsio fit into this scenario, or what does it replace?

Generally traffic is defined as north/south (into and out of the datacenter) or east/west (between servers in the datacenter).

Istio is for east/west traffic within your K8S cluster, designed to connect your services together by moving all the network traffic through the Envoy proxy. It is usually done by wrapping your deployments with an extra sidecar pod (automatically using K8S APIs) that intercepts all the networking to other services and pods. You would still use a load balancer or ingress to route external traffic into the cluster, although there are options like Heptio Contour that also use Envoy for this.

This provides a single data and control plane to centralize all network reliability, security, service discovery, and monitoring.

GP asked about Service objects though. k8s natively provides name resolution, traffic routing and load balancing to your defined service objects. So what does Envoy do for me that k8s does not do itself?

things like layer 7 control, you can say - "don't allow HTTP GET on /supersecret". Also, Isito is gRPC aware

This brings about a major problem with centralized route management, though, in that you then must build all of your access controls around URLs rather than deeper business logic.

Istio offers much more, but as far as anything but coarse-grained "this service will never need to talk to this other service" access control, I'd still much rather write the logic in the code where it has access to a lot more domain knowledge.

if you want just simple layer 4 ACLs among the services, I recommend just using NetworkPolicies[1] of k8s.

Personally, I think that Istio is overly complex but then so is k8s :)

[1] https://kubernetes.io/docs/concepts/services-networking/netw...

More protocol support, retries, rate-limits, circuit-breakers, traffic mirroring, better load-balancing, faster proxy performance, complex routing, fine-grained security policies with pluggable authentication, and in-depth monitoring with integrated tracing.

Smaller clusters or services don't need it. The docs overview page is worth a read: https://istio.io/docs/concepts/what-is-istio/

Thanks! I was wondering if mesh effectively replaces services and why, and you've answered that.

The service mesh landscape will be updated soon - https://layer5.io/landscape

Just wonder how this could connect with Fargate and possibly support scale-down to zero with power of firecracker?

You can use app mesh with fargate services, support coming by GA

Sounds similar to Consul, which has a similar architecture.

AWS is totally killing it this week. This is like the 10th major release I've seen since monday.

Well, it’s Re:Invent this week (AWS’ major annual conference), so this is fairly typical. Expect another handful or so of announcements tomorrow during Werner Vogel’s keynote as well.

Doh. duh.

Happens every time at re:Invent

More cool stuff you probably don't need whatsoever.

Reply on news.ycombinator.com