The Service Mesh: What Engineers Need to Know
servicemesh.io
The Service Mesh: What Engineers Need to Know
1–10 of 66 posts
Re: The Service Mesh: What Engineers Need to Know
#2How many transactions per second before you need all that stuff? If you're not in the top 100 sites, it seems unnecessary.
Re: The Service Mesh: What Engineers Need to Know
#3How many transactions per second before you need all that stuff? If you're not in the top 100 sites, it seems unnecessary.
For us it's an easy way to get Microsegmentation for our services which is a huge boon to our security posture.
Re: The Service Mesh: What Engineers Need to Know
#4My favorite use of this kind of system is to manage tls and acls. The service itself can be extremely dumb and just expose a unix socket.
The 10:1 ratio of microservices to developer sounds like hell though that's just too much to reason about.
Re: The Service Mesh: What Engineers Need to Know
#5As 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
#6As 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.
Not really. API gateways are typically single-point-deployment proxies, designed to create a coherent public interface out of a disparate group of services. An API gateway change is almost always going to be a PR for the application team.
Service meshes are proxies deployed alongside all the services, and used as much by devops (and potentially security) as by the application developers.
Re: The Service Mesh: What Engineers Need to Know
#7How many transactions per second before you need all that stuff? If you're not in the top 100 sites, it seems unnecessary.
It's not as much about load as it is about complexity; it starts to make sense when you hit some threshold number of internal services, regardless of the amount of traffic you're doing. You use a service mesh to factor out network policy and observability from your services into a common layer.
Re: The Service Mesh: What Engineers Need to Know
#8I'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.
Re: The Service Mesh: What Engineers Need to Know
#9Good article - I must admit I’m vaguely familiar with the concept and this read certainly gave me some new insights.
One meta call out on the writing - I read and scrolled at least 30% through the page on my iPhone until the author explained why I should care about a service mesh I.e. what problems it tries to simplify or solve.
It seems to me there are some strong use cases here, but it’s only worth your while if you’re operating at sufficient scale.
For instance, if my team at some FAANG scale company is responsible for vending the library that provides TLS or log rotation or , and it requires some non trivial on boarding and operational cost, migrating to this kind of architecture longer term where these concerns are handled out of the box may be beneficial.
Still - it doesn’t mean the service owners are off the hook. They still need to tune their retry logic, or confirm the proxy is configured to call the correct endpoints (let say my service is a client of another service B and for us, B has a dedicated fleet because of our traffic patterns). This is an abstraction. Abstractions have cost.
Trust but verify.
The trap people fall into is, “Here’s a new technology or concept. Let’s all flock to it without considering the costs.”
Re: The Service Mesh: What Engineers Need to Know
#10As 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.
The service mesh is a bit different from an API gateway -- in it's current most popular implementations (linkerd[0] & Istio[1]), there are basically small programs that run next to each individual instance of the programs you want to run. Linkerd has been around for a while and IMO there weren't that many companies that were at a scale where they needed it (I didn't see it deployed that often), but it's basically that same concept, but on a more granular level -- if you delegate all your requests to some intermediary, then the intermediaries can deal with the messy logic and tracing so your program doesn't have to.
A better way to describe is "smart pipes, dumb programs". Imagine that all your circuit-breaking/retry/etc robustness logic was moved into another process that happened to be running right next to the program actually doing the work.
You can have both an API gateway and a service mesh deployment -- for example Kong's Service Mesh[2] works this way. They're saying stuff like "inject gateway functionality in your service", but that only make sense if you sent literally every request (whether intra-service or to/from the outside world) through the gateway. Maybe that's how some people used Kong but I don't think everyone thought of API gateways as a place to send every single request through. You'll have a Kong API gateway at the edge and the kong proxies (little programs that you send all your requests through) next to every compute workload.
[0]: https://linkerd.io/
[1]: https://istio.io/