Adeptia Connect (AC) is an enterprise-class application that is designed for reliable, scalable, and secure operations in mission-critical use cases. Large organizations such as many Fortune 500 companies rely on Adeptia Connect to handle important data exchanges with external customers and partners as well as within internal systems and applications.
Adeptia Connect version 4.0 is a cloud-native application with microservice architecture. It uses Docker to containerize different microservices and uses Kubernetes for container orchestration and management. The application provides the following advantages:
The Application Architecture diagram for Adeptia Connect is shown below.
Adeptia Connect has two ways to communicate over the public internet using REST over https and SOAP (Refer to blue arrows in the diagram).
Browser client : User will access Adeptia Connect using web interface in browser. Any user request from this UI is routed via webapp-gateway to portal microservice and web-runner microservice. This is a synchronous communication using REST over https.
API Client: A user can access API published on Adeptia Connect using API client. The request is routed via api-gateway to rest-api or soap-api microservice depending on whether the API uses REST (HTTPS) or SOAP protocol.
The inter-service communication happens in two ways – Synchronous using REST over https (Refer to green arrows in the diagram) and Asynchronous using RabbitMQ Message broker.
There are two types of data in Adeptia Connect that require persistence (Refer to the dotted arrows in the diagram).
Individual microservice in AC 4.0 are scalable and can scale up or down based on their respective scalability criteria and threshold.
All other Microservices are scalable based on the CPU and Memory utilization percentage. Autoscaler spins up a new pod if the CPU or Memory utilization of the pod increases beyond the threshold value. This threshold value can be configured in values.yaml by changing the value for the environment variables targetCPUUtilizationPercentage and targetMemoryUtilizationPercentage under autoscaling section of the microservice.
|The listener and license microservices have only one replica set (single instance) each.|
An application that is architected, built, and run to be perfectly scalable in every way still faces scalability challenges if its dependencies cannot scale with it. Ensuring that all dependencies will scale with a microservice’s expected growth is essential for building production-ready services.
As you scale microservices in the Adeptia application, you need to ensure that the underlying database is scalable and performant. With an increase in the number of microservices and the incoming requests, the interaction with the database increases. Therefore, the database shall be able to handle the surge in the requests by allowing more concurrent active connections and be able to return the results promptly.
Similarly, with an increase in the number of microservices, the application interaction with the shared volume provisioned in the Kubernetes cluster through PV/PVC increases. As you scale the microservices in the Adeptia application, you need to ensure that the shared volume(PV/PVC) is sized to a correct value and configured for high performance for I/O intensive workloads.
Fault tolerance is the capability that enables the application to continue operating properly in the event of the failure of some of its components. Adeptia Connect application provides fault tolerance capability using Circuit Breaker and Timeout.
Any REST Https call from one service to another via gateway implements Timeout mechanism. If it takes longer than the configured timeout to respond to a REST Https call, the call is treated as failed.
Circuit Breaker prevents the cascading effect of a malfunctioned microservice to other healthy microservices and provides fault-tolerance capability to the application architecture.
In AC4, the circuit breaking is implemented using the following three components of the application.
How Circuit Breaker works
With the help of the circuit breaker the Webapp Gateway/API Gateway/RabbitMQ is able to make or break the communication with a failed microservice. To determine whether a microservice is up or not, the Webapp Gateway/API Gateway/RabbitMQ allows 20 consecutive requests to the microservice – if the response to all the twenty requests fails, it instructs the circuit breaker to open the circuit and thereby break the communication.
After the circuit remains open for 60 seconds, the Webapp Gateway/API Gateway/RabbitMQ once again allows a few requests (in this case, five) to check whether the faulty microservice has started responding or not. In such a condition the circuit breaker is said to be in half-open state.