Comment by samsquire | Hacker News Reader

Comment by samsquire | Hacker News Reader

Thanks 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

These can be used to route to keyspace ranges (such as particular users to tenant shards or load balance) to other components. For example users1-1000 are handled by petsserver1 and socket5 is associated with thread3.

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?

>> 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.

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.

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.

I'd say most of these patterns are supported by NATS, it can do pub/sub but actually also has excellent support for RPC and in the latest iteration it also has a KV store baked in. I've been using it for a few pet projects so far and it has never been the weakest link.

I keep hearing about NATS but I am yet to use it leisurely or for work.

Thanks for the recommendation :-)

Reply on news.ycombinator.com