Thanks for your feedback!
EDIT
Architecture and Operation
Sensedia Service Mesh is our solution for microservice management. It abstracts network problems arising with the communication between services and allows users to apply traffic rules, security policies, and service version deployment quickly and easily. It also offers observability features, with visualisation of telemetry and tracing data, all through a low-code and intuitive graphical interface.
This page provides a summary of its architecture and operation. On the following pages, you can read about how to use every feature of Sensedia Service Mesh and get the most out of them.
Concepts
In order to understand what Sensedia is offering, it’s important to have an idea of the concepts behind service meshes and the problems they seek to solve.
Microservice architecture and service meshes
Microservice architecture postulates the development of applications not as a unified whole — the so-called monolith, which is built and implemented in one go. Instead, applications comprised of microservices form a distributed system, divided into many smaller parts that usually talk to each other via HTTP.
This allows each microservice to be developed individually, under the responsibility of a small development team — with freedom to choose the technologies and programming languages to be used — and implemented autonomously, which facilitates the maintenance of the application as a whole.
Like any architectural style, however, microservices raise specific problems that must be addressed holistically if you want to take full advantage of their enormous benefits.
For the most part, these problems come from the communication between services, particularly regarding discovery, routing and security rules. In a nutshell, the big issue is defining how the services will "know" which other components are part of the same application, with which other services it can communicate directly, and which actions are allowed within that network.
Service meshes are used to solve these very network issues. They are an infrastructure layer that provides central control for a distributed system. With them, it’s possible to define, in a declarative way, the behaviour of the network, the identity of the nodes and the traffic flow through policies.[1]
In addition to managing applications already developed as microservices, service meshes are a great option when you want to modernise monolithic applications without having to reprogram them, either by creating a microservice front to access the application and increase its functionality through new services, or by defining opportunities for breaking the monolith into smaller parts. In other words, service meshes help to manage and integrate legacy systems.
Sensedia Service Mesh
Sensedia Service Mesh allows the creation of traffic and security policies for a group of microservices with central control (and that group is what is called a mesh). The entire system is observable and generates graphics for you to observe your applications.
At the same time, it integrates fully with Sensedia API Platform, which handles North-South traffic (that is, in and out of meshes), while Sensedia Service Mesh controls East-West traffic, i.e., the communication between services.
Its biggest advantage is that all this can be done through an intuitive graphical interface, which facilitates the work of development and operations teams, but which also supports configurations by kubectl, taking advantage of users’ experience with the command line.
Architecture
Our product was developed on top of Istio and runs on Kubernetes.
We abstract Istio’s features, allowing access to them via a graphical interface, adds user management, and integrates with tracing and metrics tools that would need third-party applications to run if you were working directly with Istio.
This abstraction also enables a straightforward integration of Sensedia API Platform features with the Istio implementation.
Operation
This diagram represents, in a simplified way, how Sensedia Service Mesh works.
Sensedia API Platform exposes services through APIs, the API Gateway accepts traffic from outside and distributes it into the system — North-South traffic (in and out of a mesh). From there, Sensedia Mesh takes care of East-West traffic, i.e., between services.
The control centre configures service proxies with the policies inserted using the Sensedia Service Mesh interface. These policies combine security rules (with distribution of certificates throughout the system), service discovery and traffic routing. The system is observable through headers that follow the OpenTracing specification and are propagated with the communication between services. These headers feed metrics graphs and tracing compilations.
In addition to these management and visualization features, Istio’s traffic discovery and routing system allows you to deploy different versions of a service at the same time. With this, you can easily create canary releases, defining rules to separate traffic from one version to another of the product, either by percentage of requests or by headers. It’s also possible to test new versions of services without impacting ongoing traffic, by directing part of the requests handled by a service to another version of it, which will not have to respond to the request (an action called traffic shadowing).
1. Calcote, Lee; Butcher, Zack. Istio Up & Running: using a service mesh to connect, secure, control, and observe. Sebastopool: O’Reilly, 2020.
Share your suggestions with us!
Click here and then [+ Submit idea]