DevOps & Microservices. Part 4: Service Mesh and Serverless

4 min readNov 3, 2018

Part 4 of the series, check part 3 first. In this post I quickly explain what service mesh and Serverless is.

Service Mesh

Currently it is very common for organizations to have thousands of micro services running on containers and managed by Kubernetes in a fully automated and resilient environment. As the complexity increases, even using the Spring Cloud capabilities becomes complex since each service needs to deal with errors, failures, latency, health checks, etc. This logic is duplicated on every service. Kubernetes introduced health checks and automatic recovery but services still need to implement circuit breaker patterns, service discovery, API management, encryption, SSL management, ACLs, etc.

Service Mesh such Istio were introduced to overcome this problem and allow developers to focus on pure development by automating the service to service communication complexity. A service mesh is the connective tissue between your services that adds additional capabilities like traffic control, service discovery, load balancing, resilience, observability, security, and so on. A service mesh allows applications to offload these capabilities from application level libraries and allow developers to focus on differentiating business logic.

OpenShift already supports Istio. There are other alternatives to Istio but Istio is gaining popularity thanks to Google support. The basic idea behind service mesh is that each container will have a companion (side card) that will handle the service to service to service communication.

Istio provides all the necessary components for distributed tracing, monitoring and API management. It also incorporates several add ons such Prometheus, Grafana and service graphs. For hands on experience see this. Some of the things that Istio provides are: ACL, SSL management, dark launch, canary deployments, error injections, stress testing, circuit breakers, advanced routing, error management, etc.