The Service Mesh in the Microservices World - DZone Microservices

The software industry has come a long journey and throughout this journey, Software Architecture has evolved a lot. Starting with 1-tier (Single-node), 2-tier (Client/ Server), 3-tier, and Distributed are some of the Software Architectural patterns we saw in this journey.

The Problem

The majority of software companies are moving from Monolithic architecture to Microservices architecture, and Microservices architecture is taking over the software industry day-by-day. While monolithic architecture has many benefits, it also has so many shortcomings when catering to modern software development needs. With those shortcomings of monolithic architecture, it is very difficult to meet the demand of the modern-world software requirements and as a result, microservices architecture is taking control of the software development aggressively. The Microservices architecture enables us to deploy our applications more frequently, independently, and reliably meeting modern-day software application development requirements.

#microservice architecture #istio #microservice best practices #linkerd #microservice communication #microservice design #envoy proxy #kubernetes architecture #api gateways #service mesh architecture

What is GEEK

Buddha Community

The Service Mesh in the Microservices World - DZone Microservices

The Service Mesh in the Microservices World - DZone Microservices

The software industry has come a long journey and throughout this journey, Software Architecture has evolved a lot. Starting with 1-tier (Single-node), 2-tier (Client/ Server), 3-tier, and Distributed are some of the Software Architectural patterns we saw in this journey.

The Problem

The majority of software companies are moving from Monolithic architecture to Microservices architecture, and Microservices architecture is taking over the software industry day-by-day. While monolithic architecture has many benefits, it also has so many shortcomings when catering to modern software development needs. With those shortcomings of monolithic architecture, it is very difficult to meet the demand of the modern-world software requirements and as a result, microservices architecture is taking control of the software development aggressively. The Microservices architecture enables us to deploy our applications more frequently, independently, and reliably meeting modern-day software application development requirements.

#microservice architecture #istio #microservice best practices #linkerd #microservice communication #microservice design #envoy proxy #kubernetes architecture #api gateways #service mesh architecture

Roberta  Ward

Roberta Ward

1598169240

From Service Mess to Service Mesh

Introduction

Over the last 10 years, the rapid adoption of microservices architecture has resulted in enterprises with hundreds or (sometimes even thousands) of services. With the growth of containerization technologies like Docker and Kubernetes, microservice patterns have seen the strongest growth; resulting in a complex dependency matrix between these micro-services. For teams to monitor, support, and to maintain these services is becoming a challenge so most enterprises have invested in some kind of microservices management tool.

This article will explore some of the common aspects of microservice management. Then we’ll take a closer look at the centralized gateway pattern, as well as its limitations (most enterprises have started with or currently still use this pattern). Then we will look into a new pattern called “Service Mesh” which has gained a lot of attention in the last 3–4 years. Often this pattern is also referred to as the “Side Car Proxy”. So lets get started!

Micro-Services Management

As enterprises start building more and more microservices, it’s becoming clear that some of the aspects of microservices are common across all microservices. So it makes sense to provide a common platform for managing these common aspects. Below are some of the key common aspects:

Service Registration and Discovery: A commonplace to register, document, search and discover microservices

Service Version Management: Ability to run multiple versions of a microservice.

**Authentication and Authorization: **Handle authentication and authorization including Mutual TLS (MTLS) between services.

Service Observability: Ability to monitor end to end traffic between services, response times, and quickly identify failures and bottlenecks.

**Rate Limiting: **Define threshold limits that traffic services can handle.

Circuit Breaker: Ability to configure and introduce a circuit breaker in case of failure scenarios (to avoid flooding downstream services with requests).

**Retry Logic: **Ability to configure and introduce retry logic dynamically in services.

So it’s a good idea to build these concerns as part of a common framework or service management tool. As a result, micro-service development teams don’t have to build these aspects in the service itself.

#service-mesh #istio-service-mesh #microservices #gateway-service #envoy-proxy

Deploy a Microservice into Istio service mesh

Before going to deploy the service into istio let’s first understand what is service mesh.

The service mesh is a dedicated infrastructure layer for handling service to service communication.

Basically, it’s a way to control how different micro services deployed on Kubernetes will manage secure communication and traffic between them with lots of cross-cutting concerns like logging, security, etc.

Istio service mesh comes with lot’s of feature like –

  • circuit-breaking
  • load balancing
  • service discovery
  • number of retries

we will not talk about the feature here, Let’s jump over to how we can deploy here so we categories the deployment process in 3 phases.

  • Download and install Istio on cluster
  • Deploy the micro-service
  • Setup the Gateway

Download and install Istio on cluster

For downloading the latest version we can refer to the release page. Just download the tar.gz file and unzip it. In the directory, we will find istioctl client which we can use

  • To customise the configuration of service mesh istio
  • Retrieve the information about proxy configuration …

Now set the istioctl client to your machine path and for installation we need to choose the configuration profile. There are a set of configuration profiles, we are going to use a demo profile which enables the components according to default settings.

use the following command for installing the demo configuration profile.

istioctl install --set profile=demo

As we know, istio automatically injects Envoy sidecar proxies using mutating webhook admission controllers when we deploy services in a particular namespace. To enable this feature we need to enable the istio-injection in a particular namespace where we will deploy the application.

kubectl label namespace default istio-injection=enabled

This image has an empty alt attribute; its file name is image.png

Deploy the micro-service

Now let’s deploy the sample application by applying the following yaml file.

apiVersion: v1
kind: Service
metadata:
  name: sample
  namespace: default
  labels:
    app: sample
spec:
  selector:
    app: sample
  ports:
    - name: http
      port: 8081
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sample
      version: 'v1'
  template:
    metadata:
      labels:
        app: sample
        version: 'v1'
    spec:
      initContainers:
        - name: init-ds
          image: busybox:latest
          command:
            - '/bin/sh'
            - '-c'
            - |
              while true
              do
                if [ $? -eq 0 ]; then
                  echo "DB is UP"
                  break
                fi
                echo "DB is not yet reachable;sleep for 10s before retry"
                sleep 10
              done
      containers:
        - name: sample-app
          image: lokesh/bundle123:latest
          imagePullPolicy: Always
          env:
            - name: SPRING_PROFILES_ACTIVE
              value: prod
            - name: SPRING_SLEUTH_PROPAGATION_KEYS
              value: 'x-request-id,x-ot-span-context'
            - name: JAVA_OPTS
              value: ' -Xmx256m -Xms256m'
          resources:
            requests:
              memory: '256Mi'
              cpu: '50m'
            limits:
              memory: '512Mi'
              cpu: '1'
          ports:
            - name: http
              containerPort: 8081
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sample
spec:
  hosts:
    - "*"
  gateways:
    - sample-gateway
  http:
    - match:
        - uri:
            exact: /getStudents
        - uri:
            exact: /accounts/create
        - uri:
            exact: /istio/auth
        - uri:
            prefix: /getTeacher
      route:
        - destination:
            host: sample
            port:
              number: 8081

#devops #microservices #scala #tech blogs #deploy microservice #istio #service mesh

Brain  Crist

Brain Crist

1600117200

Deploying Citrix ADC with Service Mesh on Rancher

Introduction

As a network of microservices changes and grows, the interactions between them can be difficult to manage and understand. That’s why it’s handy to have a service mesh as a separate infrastructure layer. A service mesh is an approach to solving microservices at scale. It handles routing and terminating traffic, monitoring and tracing, service delivery and routing, load balancing, circuit breaking and mutual authentication. A service mesh takes these components and makes them part of the underlying infrastructure layer, eliminating the need for developers to write specific code to enable these capabilities.

Istio is a popular open-source service mesh that is built into the Rancher Kubernetes management platform. This integration allows developers to focus on their business logic and leave the rest to Kubernetes and Istio.

Citrix ADC is a comprehensive application delivery and load balancing solution for monolithic and microservices-based applications. Its advanced traffic management capabilities enhance application performance and provide comprehensive security. Citrix ADC integrates with Istio as an ingress gateway to the service mesh environment and as a sidecar proxy to control inter-microservice communication. This integration allows you to tightly secure and optimize traffic into and within your microservice-based application environment. Citrix ADC’s Ingress deployment is configured as a load balancer for your Kubernetes services. As a sidecar proxy, Citrix ADC handles service-to-service communication and makes this communication reliable, secure, observable, and manageable.

#service mesh #rancher #istio service mesh #microservices and containers

Lindsey  Koepp

Lindsey Koepp

1597685580

Service Mesh Comparison: Istio vs Linkerd - DZone Microservices

From the latest CNCF annual survey, it is pretty clear that a lot of people are showing high interest in service mesh in their project and many are already using in Production. Nearly 69% are evaluating Istio, and 64% are evaluating Linkerd. You might not know that Linkerd was the first service mesh in the market but Istio made the service meshes more popular. Both projects are cutting edge and very competitive, makes a tough choice to select one. In this blog post, we will learn about Istio and Linkerd architecture, their moving parts, and compare their offerings to help you make an informed decision.

Introduction To Service Mesh

Over the past few years, Microservices architecture has become a more popular style in designing software applications. In this architecture, we breakdown the application into independently deployable services. The services are usually lightweight, polyglot in nature, and often managed by various functional teams. This architecture style works well until a certain point when the number of these services becomes higher, difficult to manage and they are not simple anymore. This leads to challenges in managing various aspects like security, network traffic control, and observability. A **service mesh **helps address these challenges.

The term **service mesh **is used to describe the network of microservices that make up such applications and the interactions between them. As the number of services grows in size and complexity, it becomes harder to scale and manage. A service typically offers service discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh also often has more complex operational requirements, like A/B testing, canary rollouts, rate limiting, access control, and end-to-end authentication. A service mesh provides an easy way to create a network of services with load balancing, service-to-service authentication, monitoring, and more, with few or no code changes in service code.

Let’s go through the architecture of Istio and Linkerd. Note that both projects are evolving fast and this article is based on Istio version 1.6 and Linkerd version 2.7.

Istio

Istio is an open-source platform that provides a complete solution as service mesh providing a uniform way to secure, connect, and monitor microservices. It is backed by industry leaders like IBM, Google, and Lyft. Istio is one of the most popular and complete solutions with advanced offerings suitable for all sizes of enterprises. It is a first-class citizen of Kubernetes and designed as a modular platform-independent system. For a quick demo of Istio, please refer to our previous post.

#microservices #kubernetes #istio #service mesh #linkerd