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

Service mesh use cases (2020)

lucperkins.dev

Post reply on HN
Print view View original

31–40 of 50 posts

Re: Service mesh use cases (2020)

#31

Post by jspdown »

jpdb wrote: post #18
tyingq wrote: post #15

Earlier quoted context omitted.

I suspect if a Service Mesh is ultimately shown to have broad value, one will make it's way into the K8S core. To me, it's a fairly big decision to layer something that's complex in it's own right on top of something else that's also complex.

> I suspect if a Service Mesh is ultimately shown to have broad value, one will make it's way into the K8S core I'm not so sure. I suspect it'll follow the same roadmap as Gateway API, which it already kind of is with the Service Mesh Interface ( https://smi-spec.io/ )

Indeed, all major Service Meshes solution for Kubernetes implements (at least some part) the SMI specification. There is a group composed of these players working actively on making such spec a standard.

Understanding these few CRDs give great insights on what do expect from a Service mesh and how thinks are typically articulated.

Re: Service mesh use cases (2020)

#32

Post by jrockway »

Scubabear68 wrote: post #5

I’ve only read about Service Mesh, my impression was that it seems to add an awful lot of processes and complexity just to make developer’s lives slightly easier. Maybe I’m wrong but it almost feels like busy work for DevOps. Is my first impression wrong? Is this the right way to architect systems in some use cases, and if so what are they?

It's a "big company" thing. In my opinion, the best way to add mTLS to your stack is to just adjust your application code to verify the certificate on the other end of the connection. But if the "dev team" has the mandate "add features X, Y, and Z", and the "devops team" has the mandate "implement mTLS by the end of Q1", you can see why "bolt on a bunch of sidecars" becomes the selected solution. The two teams don't have to talk with each other, but they both accomplish their goals. The cost is less understanding, debuggability, and the cost of the service mesh product. But, from both teams' perspective, it looks like the best option.

I'm not a big fan of this approach; the two teams need to have a meeting and need to have a shared goal to implement the business's selected security requirements together. But sometimes fixing the org is too hard, so there is a Plan B.

Re: Service mesh use cases (2020)

#33

Post by jspdown »

zidad wrote: post #7
NovemberWhiskey wrote: post #4

Now imagine you have something that has the complexity and change volume of a distributed control plane bringing together load-balancing, service advertisement, public key infrastructure, and software defined networking, and then try to imagine running it at the same reliability as your DNS. Also: proxies, proxies everywhere, as far as the eye can see.

And in addition to that, all of those immediately becoming the same centralized single point of failure. What could possibly go wrong (on high load)? ;p

In most implementations this is not the case. Service Meshes tend to either follow a sidecar or a DaemonSet approach. You don't have a single proxy, people usually complain about the exact opposite.

Re: Service mesh use cases (2020)

#35

Post by jspdown »

jcq3 wrote: post #23

I thought service mesh main use case was to reduce time to production delivery, allowing hotfixes to be much more reactive. Am I totally wrong?

It's not about fast delivery, at least not in this way. Arguably if you need mTLS, traffic shaping, cross service observability, service discovery... Then yes, it's much faster to use an existing solution than built it yourself. But it won't make you hot fixes shipped faster.

Service Mesh is nothing new. People tend to call it differently back then. The key features it bring are: - Traffic shaping: mirroring, canary, blue-green... - Cross service observability - End to end encryption - Service discovery

Re: Service mesh use cases (2020)

#36

Post by [deleted] »

jagged-chisel wrote: post #11
Scubabear68 wrote: post #5

I’ve only read about Service Mesh, my impression was that it seems to add an awful lot of processes and complexity just to make developer’s lives slightly easier. Maybe I’m wrong but it almost feels like busy work for DevOps. Is my first impression wrong? Is this the right way to architect systems in some use cases, and if so what are they?

Most of my programming peers want to focus on solving product-related problems rather than authe, authn, tls config, failover, throttling, discovery… We want to automate everything not related to the code we want to write. Service meshes sound like a good way to do that.

[deleted]

Re: Service mesh use cases (2020)

#37

Post by peteradio »

emptysea wrote: post #27
peteradio wrote: post #22

Earlier quoted context omitted.

If you can convince your business folks to run shit on the command-line then there is basically no need for services ever. I know it sounds insane but its how it was done in the old days and there really is only a false barrier to doing it again.

Place I worked had support staff copy-pasting mongo queries from google docs -- worked in the early days but eventually you have to start building an admin interface for more complicated processes When it was just mongo installs are easy since they only needed a mongo desktop client

Terminal can handle auth.

Re: Service mesh use cases (2020)

#38

Post by bushbaba »

kevan wrote: post #17
Scubabear68 wrote: post #5

I’ve only read about Service Mesh, my impression was that it seems to add an awful lot of processes and complexity just to make developer’s lives slightly easier. Maybe I’m wrong but it almost feels like busy work for DevOps. Is my first impression wrong? Is this the right way to architect systems in some use cases, and if so what are they?

>slightly easier As a company grows sooner or later most of these features become pretty desirable from an operations perspective. Feature developers likely don't and shouldn't need to care. It probably starts with things like Auth and basic load balancing. As the company grows to dozens of teams and services then you'll start feeling pain around service discovery and wish you didn't need to implement yet another cus…

Some of the functionality you mentioned above is possible without a service mesh.

Re: Service mesh use cases (2020)

#39

Post by davewritescode »

kevan wrote: post #17
Scubabear68 wrote: post #5

I’ve only read about Service Mesh, my impression was that it seems to add an awful lot of processes and complexity just to make developer’s lives slightly easier. Maybe I’m wrong but it almost feels like busy work for DevOps. Is my first impression wrong? Is this the right way to architect systems in some use cases, and if so what are they?

>slightly easier As a company grows sooner or later most of these features become pretty desirable from an operations perspective. Feature developers likely don't and shouldn't need to care. It probably starts with things like Auth and basic load balancing. As the company grows to dozens of teams and services then you'll start feeling pain around service discovery and wish you didn't need to implement yet another cus…

We’re the process of moving all of our services over to a service mesh and while the growing pains are definitely there, the payoff is huge.

Even aside from a lot of the more hyped up features of service mesh, the biggest thing Istio solves is tls everywhere and cloud agnostic workload identity. All of our pods get new tls certs every 24 hours and nobody needs an API key to call anything.

Our security team is thrilled that applications running with an Istio sidecar literally have way to leak credentials. There’s no API keys to accidentally log. Once we have databases setup to support mTLS authentication, we won’t need database passwords anymore.

Re: Service mesh use cases (2020)

#40

Post by davewritescode »

jrockway wrote: post #32
Scubabear68 wrote: post #5

I’ve only read about Service Mesh, my impression was that it seems to add an awful lot of processes and complexity just to make developer’s lives slightly easier. Maybe I’m wrong but it almost feels like busy work for DevOps. Is my first impression wrong? Is this the right way to architect systems in some use cases, and if so what are they?

It's a "big company" thing. In my opinion, the best way to add mTLS to your stack is to just adjust your application code to verify the certificate on the other end of the connection. But if the "dev team" has the mandate "add features X, Y, and Z", and the "devops team" has the mandate "implement mTLS by the end of Q1", you can see why "bolt on a bunch of sidecars" becomes the selected solution. The two teams don't…

I very much disagree the sentiment that adding mTLS is just “verifying the certificate on the other end of the connection”. You ignore the process of distribution and rotation of certificates which is non-trivial to implement application side.
Post reply on HN