Live data from Hacker News

The Service Mesh: What Engineers Need to Know

servicemesh.io

61–66 of 66 posts

Re: The Service Mesh: What Engineers Need to Know

#61
post #56

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

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

Great news, thanks for sharing!

Re: The Service Mesh: What Engineers Need to Know

#62

Earlier quoted context omitted.

I would go as far as to say I think the vast majority of people don't need a specialized service mesh. We unfortunately started with Linkerd and it actually is the cause of most reliability/troubleshooting issues. I don't think lack of complexity is actually a good selling point for it, because it's inherently more complex that not using a service mesh. Istio may appear more complex but that's because it has a superi…

>"We unfortunately started with Linkerd and it actually is the cause of most reliability/troubleshooting issues" Would you mind elaborating on what those Linkerd issue are/were that were effecting reliability and troubleshooting?

I'm also curious about this (author here btw). The majority of people we see coming to Linkerd today are coming from Istio. They get the service mesh value props, but want Linkerd's simplicity and lower operational overhead. Would love some more details, especially GitHub issues.

Re: The Service Mesh: What Engineers Need to Know

#63
post #60

Earlier quoted context omitted.

I don't get the part on API gateways. Gateways are north south most of the time while a sm is east west. They can work together perfectly fine and don't even have to be integrated.

Supporting North/South is how they have traditionally been marketed, but not how they are actually used much of the time. Inside enterprise they are often used as an internal "service catalog" and are effectively a shim providing discovery and consistency over a bunch of fairly scoped internal services.

This is blatantly false. Service catalogs are the worst functions of gateways.

Re: The Service Mesh: What Engineers Need to Know

#64
post #24

One reason for the explosive interest in service mesh over the last 24 months that this article glosses over is that it's deeply threatening to a range of existing industries, that are now responding. Most immediately to API gateways (eg. Apigee, Kong, Mulesoft), which provide similar value to SM (in providing centralized control and auditing of an organization's East-West service traffic) but implemented differently…

This is so far from the truth. It’s simply another deployment method. One of many that an enterprise will try. That’s why. As simple as that.

Re: The Service Mesh: What Engineers Need to Know

#66

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

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

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