Make Java microservices resilient with Istio  

Enable your Java microservices with advanced resiliency and fault tolerance leveraging Istio

Last updated | By Tommy Li, Animesh Singh

Description

Twelve-factor apps make a strong case for designing and implementing your microservices for failure. What that means is with the proliferation of microservices, failure is inevitable, and applications should be fault-tolerant. Istio, a service mesh, can help make your microservices resilient without changing application code.

Overview

Building and packaging microservices is one part of the story. Given that a highly salable and distributed microservices deployment is going to face failures at different layers, how do we make these microservices resilient and fault-tolerant? How do we enforce policy decisions, such as fine-grained access control and rate limits? How do we enable timeouts/retries, health checks, etc.? Even though some language-specific frameworks address these issues, the implementation is often framework- or language-specific. If the underlying framework or language changes, the resiliency features need to be reimplemented or ported over. And in some cases, applications also have the responsibility of implementing the code and configuration required for resiliency and fault-tolerance. A service-mesh architecture attempts to resolve these issues by extracting the common resiliency features needed by a microservices framework away from the applications and frameworks and into the platform itself. Istio provides an easy way to create this service mesh. In this developer journey, we demonstrate how to build, deploy, and connect your Java™ MicroProfile microservices, leveraging Istio service mesh. We then show how to configure and use circuit breakers, timeouts/retries, rate limits, and other advanced resiliency features from Istio without changing the application code.

Flow

  1. In this step, the user deploys a Java application that is configured to run in a Kubernetes Cluster. The application, MicroProfile, is composed of five microservices. The application is written in Angular and Java. The ‘Vote’ microservice has two versions. V1 stores its data locally, and V2 stores its data with the Cloudant® database. The user ensures that the Istio service mesh control plane is running on Kubernetes.
  2. To enable the application to use Istio features, the user injects Istio envoys on the application. Envoys are deployed as sidecars on each microservice. Injecting Envoy into a microservice means that the Envoy sidecar would manage the incoming and outgoing calls for the service. The user also creates ingress to enable ingress traffic from Istio ingress.
  3. The user now configures advanced Istio features for the MicroProfile and creates a circuit breaker for the Cloudant database. We specify maximum active connections to Cloudant and maximum pending requests. If we sent more than the allowed maximum requests at once to Cloudant, it will have pending requests up to the specified threshold and deny additional requests until the pending ones process.
  4. Another circuit breaker that can be used is based on the health of the instances in a load-balancing pool. User creates a load-balancing pool with two instances of Cloudant, then uses a circuit breaker to detect and eject an instance when no longer healthy.
  5. User creates a timeout and retries rule for the ‘Vote’ microservice connection to Cloudant. This rule times out responses that take more than the allowed response-time threshold. User also applies retries rule by telling Istio how many retries he wants and what the timeout should be for retry. The user creates a fault injection on Cloudant database to simulate the failure situation and verify the timeout and retries rule works properly.

Related Blogs

CloudNativeCon and KubeCon are coming to Copenhagen!

With May just around the corner, mark your calendars for an exciting event, CloudNativeCon/KubeCon, in Denmark’s capital city of Copenhagen. Many of us in the Cloud Native community already visited this beautiful city for DockerCon EU last year and we’re excited to be able to take in all of the wonderful sites again this year....

Continue reading CloudNativeCon and KubeCon are coming to Copenhagen!

Live analytics with an event store fed from Java and analyzed in Jupyter Notebook

Event-driven analytics requires a data management system that can scale to allow a high rate of incoming events while optimizing to allow immediate analytics. IBM Db2 Event Store extends Apache Spark to provide accelerated queries and lightning fast inserts. This code pattern is a simple introduction to get you started with event-driven analytics. You can...

Continue reading Live analytics with an event store fed from Java and analyzed in Jupyter Notebook

Related Links