Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS App Mesh – Service Mesh for Microservices on AWS

aws.amazon.com

Post reply on HN
Print view View original

21–30 of 36 posts

Re: AWS App Mesh – Service Mesh for Microservices on AWS

#21

Post by kronin »

burtonator wrote: post #20
willejs wrote: post #13

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? EK…

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.

Re: AWS App Mesh – Service Mesh for Microservices on AWS

#22

Post by querulous »

burtonator wrote: post #20
willejs wrote: post #13

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? EK…

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

the blog post says it's envoy

Re: AWS App Mesh – Service Mesh for Microservices on AWS

#23

Post by andrewstuart2 »

gauravphoenix wrote: post #11
jeremyjh wrote: post #9

Earlier quoted context omitted.

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.

Re: AWS App Mesh – Service Mesh for Microservices on AWS

#25

Post by dastbe »

burtonator wrote: post #20
willejs wrote: post #13

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? EK…

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

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

Re: AWS App Mesh – Service Mesh for Microservices on AWS

#26

Post by jelling »

yodon wrote: post #19
staticassertion wrote: post #12

Earlier quoted context omitted.

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 fa…

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

Re: AWS App Mesh – Service Mesh for Microservices on AWS

#28

Post by gauravphoenix »

andrewstuart2 wrote: post #23
gauravphoenix wrote: post #11

Earlier quoted context omitted.

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 knowle…

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

Re: AWS App Mesh – Service Mesh for Microservices on AWS

#30

Post by paulannesley »

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.
Post reply on HN