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
The Service Mesh: What Engineers Need to Know
61–66 of 66 posts
Re: The Service Mesh: What Engineers Need to Know
#62Earlier 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?
Re: The Service Mesh: What Engineers Need to Know
#63Earlier 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.
Re: The Service Mesh: What Engineers Need to Know
#64One 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…
Re: The Service Mesh: What Engineers Need to Know
#65As someone who's familiar with the API gateway pattern, is it fair to say this is just another API gateway for internal services? Seems like it is but its also described in an extremely convoluted way with 'control planes' and such.
Re: The Service Mesh: What Engineers Need to Know
#66I'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…