Microservices specialize in specific business related features. These services should be small applications highly specialized in business rules; however, when trying to connect them with each other, dependencies and detailed configurations are required. These changes don’t correspond to the business, but rather to architecture and networking.
As usual, to get this connectivity between services, It’s necessary to know their address in the network of each service – also known as IP based communication – bearing in mind the network topology, communication protocols, and credentials exchange to guarantee the identity and secure communication between them, just to mention a few important considerations.
All right, let’s just say we already have this connectivity.
Now we have to guarantee a high availability and fault tolerance in our services, maybe clustering some services and using load balancers for distributing the networking traffic, and adding health-check monitoring and usage metrics in the platform.
All this to achieve communication between our services.
Now we could think of adding additional services (application as a service), some of them in external networks or clouds with different protocols, security policies or service levels (SLA), etc.
What I want to highlight is the need for better configuration, monitoring and management of connections between services. This is how the pattern Service Mesh comes onto the scene; it’s considered a dedicated software infrastructure to manage communication between microservices.
A Service Mesh incorporates the pattern of Sidecar proxy to decouple the connectivity complexity from our services. A sidecar is an application installed and running in the same container, a virtual machine or environment where the application runs while getting direct communication; being the sidecar responsible for connectivity, monitoring and security to other services, it gives an identity for each service known as an identity-based authorization.
Sidecars are responsible for solving communication and security between our services, becoming a network of interconnected sidecars known as a Data Plane, which gives us these features:
- enforces retries / circuit breaking
- enables certificate generation
- orchestrates mutual TLS connections
These Sidecars are controlled by a Control Plane, where security policies and permissions between services are grouped – now known as Intentions – in addition to getting the metrics and traffic distribution. Some features that a Control Plane provides are:
- provides service discovery
- manages service communication authorization
- handles routing
So far, we have seen what is a service mesh and some useful terms related, but how can we start implementing a service mesh solution? What sort of proxy could be convenient for sidecar? Which deployment techniques can we use to reduce downtime and risk for new releases?
As a DigitalOnUs’ key partner, Hashicorp has solutions that allow us to answer the questions above. It provides our infrastructure, and allows us to connect and run it for any application.
A brief overview of Hashicorp’s technologies, we have Terraform being a infrastructure as code tool which has a high-level language for infrastructure provisioning, providing the ability to define our infrastructure requirements and execute it in any public, private or hybrid cloud.
Vault, another in the Hashicorp family of products, allows us to handle all aspects of privacy, authentication, access control, and other considerations to keep our applications protected.
We already have infrastructure and security; now we need to run applications to solve the business requirements. Using Nomad, we can manage the deployments or releases of our services. It supports a large number of containers, virtual machines or any other environment necessary to run our applications.
Finally, we have Consul, being a great implementation of Service Mesh, providing all the advantages of this pattern plus the flexibility of configuration, administration, and monitoring through a user interface, specialized in solving the following needs:
- Discovery: Services must be able to find each other.
- Configuration: Services must accept runtime configuration from a central source.
- Segmentation: Service communication must be authorized and encrypted.
Consul has a control plane called Consul Connect which allows us to connect multiple services securely through different public or private clouds such as AWS, Azure, GCP as others.
Through its declarative language, Consul facilitates the creation of a sidecar linked to each of our services running from the same environment as our application, forming the Data Plane described at the beginning.
Both data and control planes are managed by Consul, creating a centralized catalog of nodes and services; with this we can discover and connect all the provided services for our business without configuring the networking details, just knowing their identity. When the communication is achieved the exchange of credentials is carried out, before performing any Intention, the permissions are verified between the services.
Now, imagine we want to release a new version of our service with a minimal impact on our business. Consul allows us to apply several deployment techniques, distributing the traffic between services; this can be done by defining the percentage of traffic or through headers defined in the request. Among other deployment techniques that allow us to maintain high availability of our services, Consul can check the availability of service through its health check endpoint, and in case of presenting a failure in the service, it can redirect traffic to an alternate service that allows maintaining the operation of our system.
Another useful one of Consul’s features is traffic monitoring capacity throughout our infrastructure, identifying usage peaks in the network, bottlenecks and potential problems in advance to apply preventive actions.
I invite you to check the references for more details about the concepts, terms and technologies mentioned in this article, in the following links you can find very interesting conferences about Service Mesh and Hashicorp technologies that you can use in your future implementations.
- HashiCorp Solutions Engineer Stephen Wilson gives one of the clearest introductions to service mesh: https://www.hashicorp.com/resources/demystifying-service-mesh
- Developer Advocate Nic Jackson gives in-depth demos of Consul’s key service mesh features : https: //www.hashicorp.com/resources/consul-service-mesh-deep-dive
- Official Hashicorp articles
- https://www.hashicorp.com/products/consul/service-mesh
- https://www.hashicorp.com/products / consul
- https://www.hashicorp.com/blog/consul-1-2-service-mesh/
- https://www.hashicorp.com/resources/smart-networking-with-service-mesh
- https: // www .hashicorp.com / resources / service-mesh-microservices-networking
- Hashicorp tools
- Hashicorp Terraform: https://www.terraform.io
- Hashicorp Vault: https://www.vaultproject.io
- Hashicorp Nomad: https://nomadproject.io
- Hashicorp Consul: https://www.consul.io
- Consul Connect: https://www.consul.io/docs/connect/index.html
- Hashicorp learning center:
- Circuit breaker: https://martinfowler.com/bliki/CircuitBreaker.html
