Service mesh use cases (2020)
lucperkins.dev
Service mesh use cases (2020)
1–10 of 50 posts
Re: Service mesh use cases (2020)
#2Article is from 2020. Please add to title.
Re: Service mesh use cases (2020)
#3Thanks for this.
I have never deployed a service mesh or used one but I am designing something similar at the code layer. It is designed to route between server components. That is, at the architecture between threads in a multithreaded system.
The problem I want to solve is that I want architecture to be trivially easy to change with minimal code changes. This is the promise and allure of enterprise service buses and messaging queues and probably Spring.
I have managed RabbitMQ and I didn't enjoy it.
If I want a system that can scale up and down and that multiples of any system object can be introduced or removed without drastic rewrites.
I would like to decouple bottleneck from code and turn it into runtime configuration.
My understanding of things such as Traefik and istio is that they are frustrating to set up.
Specifically I am working on designing interthread communication patterns for multithreaded software.
How do you design an architecture that is easy to change, scales and is flexible?
I am thinking of a message routing definition format that is extremely flexible and allows any topology to be created.
https://github.com/samsquire/ideas4#526-multiplexing-setting...
I think there is application of the same pattern to the network layer too.
Each communication event has associated with it an environment of keyvalues that look similar to this:
petsserver1
container1
thread3
socket5
user563
ingestionthread1
In other words: changing the RabbitMQ routing settings doesn't change the architecture of your software. You need to change the architecture of the software to match the routing configuration. But what if you changed the routing configuration and the application architecture changed to match?
Re: Service mesh use cases (2020)
#4Now 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.
Re: Service mesh use cases (2020)
#5I’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?
Re: Service mesh use cases (2020)
#6Thanks for this. I have never deployed a service mesh or used one but I am designing something similar at the code layer. It is designed to route between server components. That is, at the architecture between threads in a multithreaded system. The problem I want to solve is that I want architecture to be trivially easy to change with minimal code changes. This is the promise and allure of enterprise service buses an…
>> But what if you changed the routing configuration and the application architecture changed to match?
If there were 3 ways to categorise scaling (there’s more than this in reality) then they might be vertical, horizontal then distributed.
You’re describing an architecture that’s in the horizontal scaling world view.
You’re not in vertical because you’re using higher powered (but slower) strategies like active routing for comms between components where in vertical you’d have configurable queues but no routing layer.
You’re not in distributed scaling mode because your routing is assuming consistent latency and consistent bandwidth behaviours.
I don’t think one architecture to rule them all is a solvable problem. I’d heartily and very gratefully welcome being proven wrong on this.
Re: Service mesh use cases (2020)
#7Now 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
Re: Service mesh use cases (2020)
#8I’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?
Many of the use cases described in the post are solved by service meshes.
So, in my opinion, the questions are introspective:
- “Do I have enough context to know what problem those solutions are solving, and to at least appreciate the problem space to understand why someone may solve it like this?”
- “Do I have or perceive those problem to impact my infrastructure/applications?”
- “Does the solution offered by the use cases described appeal to me?”
If yes at the end, then one potential implementation is a service mesh.
A lot of these are solved out-of-the-box with Hashicorp’s Nomad/Consul/Vault pairing, for example!
Re: Service mesh use cases (2020)
#9Thanks for this. I have never deployed a service mesh or used one but I am designing something similar at the code layer. It is designed to route between server components. That is, at the architecture between threads in a multithreaded system. The problem I want to solve is that I want architecture to be trivially easy to change with minimal code changes. This is the promise and allure of enterprise service buses an…
>> But what if you changed the routing configuration and the application architecture changed to match? If there were 3 ways to categorise scaling (there’s more than this in reality) then they might be vertical, horizontal then distributed. You’re describing an architecture that’s in the horizontal scaling world view. You’re not in vertical because you’re using higher powered (but slower) strategies like active routi…
Thanks for your comment. It's definitely food for thought.
You remind me of fallacies of distributed computing by mentioning consistent latency and bandwidth.
https://en.m.wikipedia.org/wiki/Fallacies_of_distributed_com...
I'm still at the design stage.
Those architectures you describe, I am hoping there is a representation that can describe many architectures. There's probably architecture's I am yet to think of that are unrepresentable with my format.
Going from 1 to N or removing, adding a layer should be automatable. That's my hope anyway.
I want everything to wire itself automatically.
I am trying to come up with a data structure that can represent architecture.
I am trying to do what inversion of control containers do per request but for architecture. In Inversion of control containers you specify a scope of an object that is instantiated for a scope such as for a request or for a session. I want that for architecture.
Re: Service mesh use cases (2020)
#10Earlier quoted context omitted.
>> But what if you changed the routing configuration and the application architecture changed to match? If there were 3 ways to categorise scaling (there’s more than this in reality) then they might be vertical, horizontal then distributed. You’re describing an architecture that’s in the horizontal scaling world view. You’re not in vertical because you’re using higher powered (but slower) strategies like active routi…
Thanks for your comment. It's definitely food for thought. You remind me of fallacies of distributed computing by mentioning consistent latency and bandwidth. https://en.m.wikipedia.org/wiki/Fallacies_of_distributed_com... I'm still at the design stage. Those architectures you describe, I am hoping there is a representation that can describe many architectures. There's probably architecture's I am yet to think of tha…
it’s such a fundamental problem space and with such a rich diversity of possible solutions that at a minimum you’re going to create something seriously useful for a subset of types of application. But it’d be transformational for computing if you cracked the whole problem. I hope you do.
I do like your idea of outsourcing the wiring (an error prone, detail heavy task) away from humans.