4 ms·

I'm going to sound like an old man but... What amuses me about this is back in the day everyone thought the Mach guys were crazy for thinking things like netwo

I'm going to sound like an old man but... What amuses me about this is back in the day everyone thought the Mach guys were crazy for thinking things like network routing and IPC services be implemented in user space... and others mocked the OSI model's 7 layers as overly complex (e.g. RFC3439's "layering considered harmful"). Now we've moved all our network services onto a layer 7 protocol (HTTP), and we've discovered we need to reinvent layers we skipped over on top of it. We're doing it all in user space with comparatively new and untested application logic, somehow forgetting that this can be done far more efficiently and scalably with established and far more sophisticated networking tools... if only we'd give up on this silly notion that everything must go over HTTP.

skywhopper 7y ago
You aren't wrong about the trend of solving the same problems over and over at higher points in the stack. But you missed the mark on responding to this article and the Service Mesh pattern, which usually operates at a lower network layer. In fact, if anything, the trend in microservices architecture is away from HTTP and back towards binary protocols over TCP (but, in this case, proxied via authenticated mTLS connections managed by an external service, but which also operate over TCP).
taneq 7y ago
Network-over-network is just another Inner Platform Effect.
- jonahx 7y ago
  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 https://en.wikipedia.org/wiki/Inner-platform_effect
  - Bombthecat 7y ago
    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 :)
jayd16 7y ago
I think this is a bad take, especially saying HTTP is the reason. Its not. The real reason is we want stateless connections and load balancing and because of TLS we want to keep our handshakes warm too. We also want our retries to work at the application layer too so lower layers would at least have to understand chunks of a connection larger than a packet can fail even if all the packets were acked successfully... _and_ a completely different machine should receive that chunk instead. We want all that for free and we don't want to pay for hardware. Http/2 is the only close to this and you still need app layer retries.

skywhopper 7y ago

You aren't wrong about the trend of solving the same problems over and over at higher points in the stack. But you missed the mark on responding to this article and the Service Mesh pattern, which usually operates at a lower network layer. In fact, if anything, the trend in microservices architecture is away from HTTP and back towards binary protocols over TCP (but, in this case, proxied via authenticated mTLS connections managed by an external service, but which also operate over TCP).

taneq 7y ago

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

jonahx 7y ago
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 https://en.wikipedia.org/wiki/Inner-platform_effect
- Bombthecat 7y ago
  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 :)

jayd16 7y ago

I think this is a bad take, especially saying HTTP is the reason. Its not. The real reason is we want stateless connections and load balancing and because of TLS we want to keep our handshakes warm too. We also want our retries to work at the application layer too so lower layers would at least have to understand chunks of a connection larger than a packet can fail even if all the packets were acked successfully... _and_ a completely different machine should receive that chunk instead. We want all that for free and we don't want to pay for hardware. Http/2 is the only close to this and you still need app layer retries.