Abstract

Presenting a series of articles that provides an overview of Istio Service Mesh, why should we use, its capabilities, how to setup and how to enable Istio service mesh for microservice style architecture based application.

Introduction

In cloud era, many organizations are starting journey towards adopting microservice architecture to enable organizations to grow fast, where & when needed. This article has been divided into multiple parts.

In part 1 of series, we will touch upon key challenges in traditional (monolithic) architecture and microservice style architecture to start with.

However, the intent of this article is to cover usage of Istio service mesh. It is also assumed that reader of this article is having basic knowledge on microservices and Kubernetes.

In later series, we will be focusing what is Service Mesh, why do need to use Istio Service Mesh and benefits of Istio service mesh like how Istio helps developer, operators, monitoring features, etc.

Challenges in monolithic architecture
The some of the key challenges organization are facing today and wanted to address,

• Long cycles – build, test, release
• Architecture is hard to maintain and evolve
• Struck with technology/software stack or framework
• Long time to add new features
• Low scalability
• Low reuse and high maintenance effort and cost

Due to these issues, organizations are started adopting microservice style architecture. Let’s have look on how microservice style architecture addresses these issues and what challenges it brings.

Microservices

Microservices is an architecture style, in which large complex software applications are composed of one or more services.

The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. — James Lewis and Martin Fowler

• Microservice can be deployed independently of one another and are loosely coupled. Each of these microservices focuses on completing one task only and does that one task well. In all cases, that one task represents a small business capability.
• Microservices can be developed in any programming language.
• Microservices communicate with each other using language-neutral application programming interfaces (APIs) such as Representational State Transfer (REST).
• Microservices also have a bounded context. They don’t need to know anything about underlying implementation or architecture of other microservices.

Benefits of Microservices

The key features are,

• Small, focused and easy to understand – enable to respond to customer needs more rapidly
• Loose coupled – enables frequent and rapid deployment as zero coordination necessary for the deployment with other microservices.
• Technology agnostic – enables to adapt technology faster or use existing skills or use most optimal language.
• Easy to scale development – teams organize around different business requirements and manage their own services.
• Easy to deploy new versions of services frequently – services can be deployed, scaled and managed independently.
• Improved fault tolerance and isolation – separation of concerns minimizes the impact of issues in one service from another.
• Improved speed of execution – teams deliver on business requirements faster by developing, deploying and managing microservices independently.

These features help to address business needs like time to market, scalability, rapid change, etc. however microservices style architecture comes with few operational challenges.

Challenges in Microservices Style Architecture

As mentioned in previous section, microservices style architecture approach has a lot of benefits, but it also brings complexity. Before a service getting to production, the following points should be considered or reviewed,

• how to provide services discovery and request routing between different microservices
• how to control and secure access to the application and to individual microservices
• how to efficiently scale up (and down) microservices while maintaining connectivity and overall application resiliency
• how to collect and send logging and monitoring data for later consumption
• how to enable DevOps functions, such as Canary deployments, A/B testing and gradual rollouts or roll-backs

Traditionally, most of the above listed functionality had to be developed/incorporated by every new application team, with support codified into the different microservices. While this may be an achievable for a single application and source base, as applications grow more complex and microservices are implemented using different languages and runtimes, the work becomes tedious and open to error.

References