4 ms·

Could someone explain this in plain english?

by pbreit 10y ago

tyingq 10y ago
I think the real driver is being "elastic". Renting infrastructure is really expensive if you can't ramp it up and down as demand changes. So, if you're elastic, you now need some dynamic way of finding the various services...they are spinning up and shutting down all the time, so you can't have a static list of IP's and ports. So, some framework that maps questions like "what host and port should I use to connect to the pricing service" is desirable. There can be many instances of that service for scale, and when new ones spin up, they are added to the directory. When existing ones fail, or are purposefully shutdown, they are removed. This is more complex than a normal load balancer, as it has to handle service-to-service connections versus just client connections. And the number of instances of each service is highly dynamic, based on load.
peterwwillis 10y ago
It's a message bus with a new name.
- tyingq 10y ago
  A (usually) synchronous one. Like rmi or corba or dcom.
moondev 10y ago
It's basically a configurable proxy for communication between services. Kubernetes has the concept of "services" which allow you to declare a dns name for service discovery, but it's fairly barebones. By using linkerd, you manage and configure various things like load-balancing strategies, retry-windows, circuit breaking etc etc. Instead of doing these things with a library inside the application like hysterix, you move it to it's own layer. This also has the benefit of being code agnostic, so you can leverage the same service concepts for any type of app. You can also run linkerd outside of kubernetes.
- nwmcsween 10y ago
  Ok so why not DNS-sd with service monitoring to balance, etc?
  - moondev 10y ago
    That's what this does and more. What you described are techniques. Linkered is an implementation. From https://blog.buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/ https://blog.buoyant.io/2017/04/25/whats-a-service-mesh-and-... Linkerd applies dynamic routing rules to determine which service the requester intended. Should the request be routed to a service in production or in staging? To a service in a local datacenter or one in the cloud? To the most recent version of a service that’s being tested or to an older one that’s been vetted in production? All of these routing rules are dynamically configurable, and can be applied both globally and for arbitrary slices of traffic. Having found the correct destination, Linkerd retrieves the corresponding pool of instances from the relevant service discovery endpoint, of which there may be several. If this information diverges from what Linkerd has observed in practice, Linkerd makes a decision about which source of information to trust. Linkerd chooses the instance most likely to return a fast response based on a variety of factors, including its observed latency for recent requests. Linkerd attempts to send the request to the instance, recording the latency and response type of the result. If the instance is down, unresponsive, or fails to process the request, Linkerd retries the request on another instance (but only if it knows the request is idempotent). If an instance is consistently returning errors, Linkerd evicts it from the load balancing pool, to be periodically retried later (for example, an instance may be undergoing a transient failure). If the deadline for the request has elapsed, Linkerd proactively fails the request rather than adding load with further retries. Linkerd captures every aspect of the above behavior in the form of metrics and distributed tracing, which are emitted to a centralized metrics system.
drdrey 10y ago
The context for things like Linkerd or Hystrix is server infrastructures that are made of multiple services. For instance you may be working on a public facing service that exposes a search functionality, and your downstream services could be things like the authentication service, the search service, and the logging service. Let's say you have authenticated a request and need to submit it to the search service. Instead of opening a socket to a particular IP address, you use the service mesh to send the request to 'service=search' on your behalf. The service mesh keeps an up-to-date list of instances that implement the search service in the background, picks one of them to send the request to and gives you the response. In addition to managing the pool of servers, it can do a few fancy things: * have connections primed and ready to go before you had to make the request * balance the load between instances, potentially based on their latencies and error rates * handle timeouts and retries against different instances * fail requests without making the remote call if the error rate of the downstream service is too high (circuit breaking) * expose metrics about request volume, error rates and latencies

Could someone explain this in plain english?

by pbreit 10y ago

Could someone explain this in plain english?

I think the real driver is being "elastic". Renting infrastructure is really expensive if you can't ramp it up and down as demand changes. So, if you're elastic, you now need some dynamic way of finding the various services...they are spinning up and shutting down all the time, so you can't have a static list of IP's and ports. So, some framework that maps questions like "what host and port should I use to connect to the pricing service" is desirable. There can be many instances of that service for scale, and when new ones spin up, they are added to the directory. When existing ones fail, or are purposefully shutdown, they are removed. This is more complex than a normal load balancer, as it has to handle service-to-service connections versus just client connections. And the number of instances of each service is highly dynamic, based on load.

peterwwillis 10y ago

It's a message bus with a new name.

tyingq 10y ago
A (usually) synchronous one. Like rmi or corba or dcom.

moondev 10y ago

It's basically a configurable proxy for communication between services. Kubernetes has the concept of "services" which allow you to declare a dns name for service discovery, but it's fairly barebones. By using linkerd, you manage and configure various things like load-balancing strategies, retry-windows, circuit breaking etc etc. Instead of doing these things with a library inside the application like hysterix, you move it to it's own layer. This also has the benefit of being code agnostic, so you can leverage the same service concepts for any type of app. You can also run linkerd outside of kubernetes.

nwmcsween 10y ago
Ok so why not DNS-sd with service monitoring to balance, etc?
- moondev 10y ago
  That's what this does and more. What you described are techniques. Linkered is an implementation. From https://blog.buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/ https://blog.buoyant.io/2017/04/25/whats-a-service-mesh-and-... Linkerd applies dynamic routing rules to determine which service the requester intended. Should the request be routed to a service in production or in staging? To a service in a local datacenter or one in the cloud? To the most recent version of a service that’s being tested or to an older one that’s been vetted in production? All of these routing rules are dynamically configurable, and can be applied both globally and for arbitrary slices of traffic. Having found the correct destination, Linkerd retrieves the corresponding pool of instances from the relevant service discovery endpoint, of which there may be several. If this information diverges from what Linkerd has observed in practice, Linkerd makes a decision about which source of information to trust. Linkerd chooses the instance most likely to return a fast response based on a variety of factors, including its observed latency for recent requests. Linkerd attempts to send the request to the instance, recording the latency and response type of the result. If the instance is down, unresponsive, or fails to process the request, Linkerd retries the request on another instance (but only if it knows the request is idempotent). If an instance is consistently returning errors, Linkerd evicts it from the load balancing pool, to be periodically retried later (for example, an instance may be undergoing a transient failure). If the deadline for the request has elapsed, Linkerd proactively fails the request rather than adding load with further retries. Linkerd captures every aspect of the above behavior in the form of metrics and distributed tracing, which are emitted to a centralized metrics system.

drdrey 10y ago

The context for things like Linkerd or Hystrix is server infrastructures that are made of multiple services. For instance you may be working on a public facing service that exposes a search functionality, and your downstream services could be things like the authentication service, the search service, and the logging service. Let's say you have authenticated a request and need to submit it to the search service. Instead of opening a socket to a particular IP address, you use the service mesh to send the request to 'service=search' on your behalf. The service mesh keeps an up-to-date list of instances that implement the search service in the background, picks one of them to send the request to and gives you the response. In addition to managing the pool of servers, it can do a few fancy things: * have connections primed and ready to go before you had to make the request * balance the load between instances, potentially based on their latencies and error rates * handle timeouts and retries against different instances * fail requests without making the remote call if the error rate of the downstream service is too high (circuit breaking) * expose metrics about request volume, error rates and latencies