Microservices and 12-factor applications solved a lot of issues with monolithic applications, but as mentioned in my previous post, as the number of these microservices continues to grow, new challenges arise, such as service discovery, routing, and failure handling. Let’s dive into how to leverage Istio to make your application fault-tolerant and resilient. How do we introduce health checks, timeouts, retries, and ensure request buffering or reliable communication among microservices? Some of these features are built in the microservices framework, but they are often language-specific, or you have to accommodate for it in your application code. How do we introduce it without changing the code? Service-mesh architecture attempts to resolve these issues. Istio provides an easy way to create this service mesh by deploying a control plane and injecting sidecar containers alongside your microservice. Istio adds fault-tolerance to your application without any changes to code. Some resiliency features it supports are:
  • Circuit breakers
  • Control connection pool size and request load
  • Health checks
  • Retries/Timeouts
Circuit breakers Circuit breaking is a critical component of distributed systems. When we apply a circuit breaker to an entity, and if failures reach a certain threshold, subsequent calls to that entity should automatically fail without applying additional pressure on the failed entity and paying for communication costs. If done right, there should be a fallback for that entity that handles the response for failure. It’s nearly always better to fail quickly and apply back-pressure downstream as soon as possible. Envoy enforces circuit-breaking limits at the network level, as opposed to having to configure and code each application independently. Control connection pool size and request load Istio can also be used to specify maximum active connections to a microservice or maximum pending requests. We can set destination microservice maximum connections to X and maximum pending requests to Y. Thus, if we sent more than X+Y requests at once to the microservice, it will have Y pending requests and deny any additional requests until the pending requests are processed. Health checks Istio can perform health checks against a load-balancing pool. A microservice in a load-balancing pool can have multiple deployed instances, and Istio distributes traffic across those instances. If some of those instances are broken, Istio can perform health checks and eject any broken instance in your load-balancing pool to avoid any further failure. Timeouts and retries Istio allows you to create route rules for your destination microservices where you can specify the timeout and retry policies. For example, you can create a route rule if your microservice does not respond within n seconds. Once applied, this rule will time out all the responses that take more than n seconds in the destination service. You also can apply the retries rule by telling Istio how many retries you want if a particular microservices is not reachable and what the timeout should be for your retry. So if at first attempt, your destination microservice is not reachable in n seconds, you can tell Istio to do m number of retries and also increase the timeout for retries beyond n. Give it a try In our new “Make your Java microservices resilient with Istio” journey, we show how you can deploy a Java™ MicroProfile microservices application leveraging Istio capabilities to introduce resiliency. MicroProfile is an open source baseline platform definition that optimizes the Java EE for microservices architecture. You’ll learn how Istio resiliency features – health checks, timeouts, retries – ensure request buffering or reliable communication between microservices can be enabled without requiring changes to the microservice code. We’ve also integrated the journey with the IBM Bluemix® DevOps toolchain to provide one-click deployment for anyone who wants to try it out quickly. Please check out the journey, extend it, and send us your feedback. As with every IBM Code journey, all pull requests are welcome.

Join The Discussion

Your email address will not be published. Required fields are marked *