Using Weave Scope to explore Microservices Communication and Service Mesh (OpenShift and Istio)

If you are working with ESB, Message Brokers, BPMS, SOA or Microservices, you will notice that you are solving the same problems of Standalone Applications but in different way, because all of them are different kind of Distributed Application. Those problems are:

  • Users Management, Authentication and Authorisation
  • Logging, Debugging, Monitoring and Alerting
  • Clustering, High Availability, Load Balancing, etc…

What is a Service Mesh?

It’s other type of Distributed Application where the Services, or Microservices or APIs, are being interconnected.

api-mesh-security-2-weave-scope

Service Mesh on Containerised and Orchestrated Platform

Generally a Service Mesh, based on the Microservices and/or APIs, is deployed by using multiple containers hosted and orchestrated for Kubernetes. In this scenario, we need to face new challenges such as ephemeral infrastructure, zero trust network, network segmentation or adopting new methodologies to test, to monitor, to deploy, to operate, etc. That’s we are calling DevOps.

Deployment Container Patterns

Like to EIP (Enterprise Integration Patterns) and Software Design Patterns, the Deployment of Service Mesh in a Containerised Platform also has Patterns. Google, Microsoft, Netflix, etc. recommend to use some patterns to implement solutions for the problems stated above.
For example, Google explains very well 3 patterns:

  • Sidecar Pattern
  • Ambassador Pattern
  • Adapter Pattern

All of them support the building of the Service Mesh based on Containers. For further details read this paper:

Design patterns for container-based distributed systems. By Brendan Burns and David Oppenheimer

What is Istio?

Extracted from Istio.io:

Istio is an open platform that provides a uniform way to connect, manage, and secure microservices. Istio supports managing traffic flows between microservices, enforcing access policies, and aggregating telemetry data, all without requiring changes to the microservice code. Istio gives you:

  • Automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic
  • Fine-grained control of traffic behavior with rich routing rules, retries, failovers, and fault injection.
  • A pluggable policy layer and configuration API supporting access controls, rate limits and quotas.
  • Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress.
  • Secure service-to-service authentication with strong identity assertions between services in a cluster.

istio-architecture

Why use Istio?

Extracted from Istio.io:

Istio addresses many of the challenges faced by developers and operators as monolithic applications transition towards a distributed microservice architecture. The term service mesh is often used to describe the network of microservices that make up such applications and the interactions between them. As a service mesh grows in size and complexity, it can become harder to understand and manage. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring, and often more complex operational requirements such as A/B testing, canary releases, rate limiting, access control, and end-to-end authentication.

Istio provides a complete solution to satisfy the diverse requirements of microservice applications by providing behavioral insights and operational control over the service mesh as a whole. It provides a number of key capabilities uniformly across a network of services:

  • Traffic Management. Control the flow of traffic and API calls between services, make calls more reliable, and make the network more robust in the face of adverse conditions.
  • Observability. Gain understanding of the dependencies between services and the nature and flow of traffic between them, providing the ability to quickly identify issues.
  • Policy Enforcement. Apply organizational policy to the interaction between services, ensure access policies are enforced and resources are fairly distributed among consumers. Policy changes are made by configuring the mesh, not by changing application code.
  • Service Identity and Security. Provide services in the mesh with a verifiable identity and provide the ability to protect service traffic as it flows over networks of varying degrees of trustability.

Get a container-based Service Mesh with Istio

I’ve created 3 Ansible Roles to get easily a minimalist OpenShift Cluster (by using Minishift), Weave Scope (https://github.com/weaveworks/scope), Istio and BookInfo Application (API and Microservices on containers) to understand what challenges we have to face. The 3 Ansible Role are:

  1. Minishift Ansible Role
    To get OpenShift Cluster in a VM by using Minishift
  2. Weave Scope Ansible Role
    To deploy Weave Scope Application in an OpenShift running locally
  3. Istio Ansible Role
    To deploy and configure Istio in OpenShift running locally, to deploy BookInfo Application and inject sidecar proxies(Envoy Proxy)

I have also created some examples so that you can have an environment where you can test and try quickly with all this.

Weave Scope Application will play a important role here, because It will allow us to monitor, visualise, troubleshot and manage easily whole the container-based Service Mesh.

Once completed the step-by-step guide, you will get next:

Hope this helps!.
Regards.

@Chilcano

Tagged with: , , , , , , ,
Posted in DevOps, Microservices, PaaS, Security

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Archives
%d bloggers like this: