The Service Mesh: What Engineers Need to Know • Hacker News Board

Re: The Service Mesh: What Engineers Need to Know

#51

Post by Bombthecat » Mon, Nov 25, 2019, 6:51 AM UTC

phlakaton wrote: post #34

ajessup wrote: 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…

I was going to say re: "How is this different from an API Gateway?" – this was a lot harder a question for me to get my head around than William suggests, _because_ API Gateway vendors, I'm sure quite intentionally, have been positioning their stuff as service mesh solutions or alternatives, not as service mesh complements.

Yeah... And they still do. I work in the api management field (vendors / software)

And I think it is more akin to have an aircraft carrier and the protection fleet of smaller ships..

You have your big api gateway with management, billing, governance (for B2b, b2c, b2b2c) and your service mesh.

Re: The Service Mesh: What Engineers Need to Know

#52

Post by Bombthecat » Mon, Nov 25, 2019, 6:55 AM UTC

jonahx wrote: post #43

taneq wrote: post #25

Earlier quoted context omitted.

Network-over-network is just another Inner Platform Effect.

Wonderful term. I've been aware of the phenomenon for a while but not its name. Link for others: https://en.wikipedia.org/wiki/Inner-platform_effect

Oh wow! I had a customer who was really bad at it. All! there Software was effected by it in one way or another.

Now I have a name for that at least :)

Re: The Service Mesh: What Engineers Need to Know

#53

Post by Bombthecat » Mon, Nov 25, 2019, 6:57 AM UTC

snupples wrote: post #40

lycidas wrote: post #36

At my company, we were migrating all our apps to a kubernetes + istio platform over the past couple of months and my advice is this - don't use a service mesh unless you really, really need to. We initially choose istio because it seemed to satisfy all our requirements and more - mTLS, sidecar authz, etc - but configuring it turned out to be a huge pain. Things like crafting a non-superadmin pod security policy for i…

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…

Yeah, most people / projects can live with just kong for example.

Re: The Service Mesh: What Engineers Need to Know

#54

Post by vidar » Mon, Nov 25, 2019, 7:45 AM UTC

streetcat1 wrote: post #26

ajessup wrote: 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 a good overview. However, I think that the reason that we see a lot of service variations is because the core tech - namely - Envoy, contains all the "hard" tech (the data plane) while creating a "service mesh", basically comes down to creating a management layer on top of it. Another intresting note is that Google did NOT recede control over Istio to CNCF.

And it will hopefully cost them dearly, to have a single provider control such a core piece is deeply wrong.

Re: The Service Mesh: What Engineers Need to Know

#55

Post by golover721 » Mon, Nov 25, 2019, 7:54 AM UTC

While nobody ever seems to want to hear it, the vast majority of companies utilizing service meshes and k8s are wasting huge amounts of time and money on things they don’t need.

Unfortunately these technologies are at peak hype so everyone seems to be implementing them for their small to medium crud apps. But get very sensitive if you try and point it out.

Re: The Service Mesh: What Engineers Need to Know

#56

Post by fcoelho » Mon, Nov 25, 2019, 8:52 AM UTC

reilly3000 wrote: post #8

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

Re: The Service Mesh: What Engineers Need to Know

#57

Post by reissbaker » Mon, Nov 25, 2019, 10:05 AM UTC

Opinionated read, but interesting. That being said, Linkerd wasn't the first service mesh — SmartStack predates it by three years. [1] Although they didn't use the (then-nonexistent) "service mesh" term at the time, it pioneered the concept of userspace TCP proxies configured by a control plane management daemon. I doubt the Linkerd folks are unaware of it, so it was a surprising omission.

[1]: https://medium.com/airbnb-engineering/smartstack-service-dis...

Re: The Service Mesh: What Engineers Need to Know

#58

Post by koffiezet » Mon, Nov 25, 2019, 2:08 PM UTC

cpitman wrote: post #50

thom wrote: post #29

Earlier quoted context omitted.

What is the threshold above which a service needs to exist at all, over a module in an existing codebase?

The point at which you have multiple teams working on the same codebase, and their velocity is suffering from communication overhead and missteps.

A few remarks:

* Codebase should be defined as 'the platform'. where one team will most likely never look at the code of other team's microservices. * this communication problems and overhead start the moment you go from 2 to 3 or more teams. * the term 'team' in this context should be interpreted very broadly. One dev working alone on a microservice should be considered "a team".

Also, things mentioned in the article: you don't want to implement TLS, circuit breakers, retries, ... in every single microservice. Keep them as simple as possible. Adding stuff like that creates bloat very quickly.

Re: The Service Mesh: What Engineers Need to Know

#59

Post by bogomipz » Mon, Nov 25, 2019, 2:18 PM UTC

snupples wrote: post #40

lycidas wrote: post #36

At my company, we were migrating all our apps to a kubernetes + istio platform over the past couple of months and my advice is this - don't use a service mesh unless you really, really need to. We initially choose istio because it seemed to satisfy all our requirements and more - mTLS, sidecar authz, etc - but configuring it turned out to be a huge pain. Things like crafting a non-superadmin pod security policy for i…

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

#60

Post by ajessup » Mon, Nov 25, 2019, 3:27 PM UTC

jensneuse wrote: post #46

ajessup wrote: 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…

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.