Cross-Cutting Concern Patterns

Topic: Software Design                                                                                  Level: Intermediate

Cross-Cutting Concern Patterns - What?

A concern that is applicable throughout the application of microservices that supplies a generic unified characterisation of functionality

1. External Configuration

Application services often need to define configuration information related to database connectivity, logging, timeouts, port configs, external endpoints, queue connection properties, management endpoints etc., that would co-exist with the packaged/shipped application for deployment. Such configuration management setup introduces sophistication when there is a change in a configuration property, the associated application has to be recompiled, repackaged and redeployed leading to downtime and coordination overheads.

Additionally violating the DRY (Don't Repeat Yourself) principle if multiple services use the same configuration properties brings about a cascade of change management.

Abstracting away the configuration properties from the service to a centralized location provisioning for data sharing, instantaneous change control, definitions per deployment environment (dev, qa, staging, production) and one-place administration to enforce the application-wide policies to the services of the application utilising pre-defined configuration setup (enabling service-level overrides to the inherited properties).

The annoyance of recompilation, repackage and redeployments when there is a config property modification is now rectified, where the application admin performs the change to the externalized store, the updated configs are now refreshed to the service interface cascading the modified properties to the consuming service, all on the fly.

2. Service Discovery

In the microservices world for an application, there can be N-associated microservices coordinating with each other to facilitate the holistic application business use case. The services concerned might be residing in their own virtualized or containerized environment characterising by the number of available instances and their location details changing dynamically (based on auto-scaling/load balancing policies defined by which we are constantly destroying and distributing new instances of services).

A strategy by which the client services can identify and interact with each distributed service appropriately without going rogue/redundant in its request flow, via a registry that maintains the archives of services available (by assigned network paths for identification and redirection).

The Service Registry fosters service discovery by permitting the services to be enlisted during its startup. The registered services periodically transmit heartbeats on their availability to the registry and the registry provides information about the service, its available zone and port identity that is required to be invoked via HTTP REST, gRPC, GraphQL API call by another service that is requesting for.

1. Client-Side Service Discovery - the Service Consumer is responsible for determining the network locations of available service instances and load balancing requests between them. The client queries the Service Register. Then the client uses a load-balancing algorithm to choose one of the available service instances and performs a request.
2. Server-Side Service Discovery - uses an intermediary that acts as a Load Balancer. The client makes a request to a service via a load balancer that acts as an orchestrator. The load balancer queries the Service Registry and routes each request to an available service instance.

1. Multiple instances of the same service are registered in the registry.
2. Any service trying to communicate with another service looks up the service registry with the service name and discovers the intended location route for contact.
3. With the retrieved details, the service is now able to interact with the other service.

3. Circuit Breaker

When one service collaborates with another service there is always a case where the invoked service might not be able to facilitate the response for the given request that might arise due to timeouts, processing errors, database downtime, resource unavailability, etc., In such a situation, the parent service eventually errors out as well since the problem manifestation got propagated from the child on to the parent service creating a cascade of failures.

To deter the series of failures, the parent service should invoke the child service wrapped by a proxy, that determines the number of failures and trips the request flow once the predefined threshold is breached, and any requests that are made during the timeout period are made to fail immediately. After the timeout expires the circuit breaker allows a limited number of test requests to pass through. If those requests succeed the circuit breaker resumes normal operation. Otherwise, if there is a failure the timeout period begins again.

4. Blue-Green Deployment

Resilient fault-tolerant service availability with potentially zero downtime during deployments can be realistic by following a blue-green deployment strategy, where blue corresponds to the older version of the service and green corresponds to the latest version.

The idea is to place both the legacy and the newer versions of the service instance adjacent and direct request traffic by switching between the blue (legacy) and green (newer) versions. 

When the green environment reaches its stability the bluer instances can be retired as all the requests are handled by the green instances. However, if there is a spike in the failures the requests can be automatically re-routed to the blue instances mitigating the complete collapse.

Instantaneous feedback-based traffic routing amongst the legacy and newer services enables seamless deployment and incremental service adaptions.

Image source: https://semaphoreci.com/blog/blue-green-deployment

References

1. https://www.baeldung.com/cs/service-discovery-microservices
2. https://microservices.io/patterns/server-side-discovery.html
3. https://dzone.com/articles/service-discovery-in-a-microservices-architecture
4. https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/
5. https://learn.microsoft.com/en-us/azure/architecture/patterns/external-configuration-store
6. https://dzone.com/articles/microservices-externalized-configuration
7. https://microservices.io/patterns/reliability/circuit-breaker.html
8. https://martinfowler.com/bliki/CircuitBreaker.html
9. https://spring.io/guides/gs/cloud-circuit-breaker/
10. https://semaphoreci.com/blog/blue-green-deployment
11. https://www.redhat.com/en/topics/devops/what-is-blue-green-deployment#overview
12. https://martinfowler.com/bliki/BlueGreenDeployment.html

---

Disclaimer: 
This is a personal blog. Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated. Any views or opinions are not intended to malign any religion, ethnic group, club, organization, company, or individual. All content provided on this blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The owner will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this information.
Downloadable Files and Images
Any downloadable file, including but not limited to pdfs, docs, jpegs, pngs, is provided at the user’s own risk. The owner will not be liable for any losses, injuries, or damages resulting from a corrupted or damaged file.

• Comments are welcome. However, the blog owner reserves the right to edit or delete any comments submitted to this blog without notice due to :
• Comments deemed to be spam or questionable spam.
• Comments including profanity.
• Comments containing language or concepts that could be deemed offensive.
• Comments containing hate speech, credible threats, or direct attacks on an individual or group.

The blog owner is not responsible for the content in the comments.
This blog disclaimer is subject to change at any time.