Need of Design Standards for Cross Cutting Concerns in Microservices Architecture

Cross cutting concerns are technical requirements that are commonly applicable for all the features of a software. These are requirements typically the development team wouldn’t expect to see in a Business nor Technical requirements for a specific service feature list.

If there’s one area where Monolithic applications have an advantage of, it is the code reuse for Cross Cutting Concerns is present. They can be be shared centrally in Monolithic through single instances of libraries or frameworks.

In Microservices architecture, these cross cutting concerns are either applied or copied across to every Microservice, which brings maintainability overhead and result in chaotic architecture. There are Microservices-based application architectures where they try to make a standalone service for Cross Cutting Concerns like logging, which is called externally over the network via an API call. The result is unpleasant, crude implementation, latency overhead, and it introduces new forms of challenges. It is not recommended to create standalone cross cutting concerns related Microservice/s.

Solutions that address Cross Cutting Concerns cannot be shared in Microservices architecture doesn’t mean we should ignore it in MicroServices Architecture, instead a kind of rule book explaining how the cross cutting concerns should be addressed uniformly across all Microservices should be created. For disparate development Agile team setup, sets of standards should be followed to avoid different ways of implementations by different teams for the same generic concerns. During sprints, cross cutting concerns should be default task cards for every service. Upon beta-version code completion, code reviewers that aren’t abreast to the functionality of the service would tend to focus on sets of standards such as Cross Cutting Concerns, along with code style and naming conventions.

Here is the list of primary Cross Cutting Concerns.

• Configuration lookups. These are shared configurations, placeholders and lookups — these have different contexts on various technical angles. Standards needs to be set on how this should be implemented. Example concerns for this are: file and directory separation for credential values, dynamic values, communication session related parameters, whether to localise a parameter or not.
• Logging, notification and alert. Configuration settings of the logging framework, then notification and/or alert logics (eg. send email or SMS) based on log level — WARN, ERROR, FATAL. For investigation purposes, implementation of logging should ideally have conventions to help with tracing and transaction querying.
• Exception handling. Strategies and standards to implement before terminating the session/message in an event of an exception. In native Object Oriented exception handling has different types: checked, unchecked, irrecoverable error.
• Monitoring and Performance. Pro active Health Check frameworks to be defined, and in some cases benchmarking performance utilities to provide throughput metrics.
• Audit tracing and correlation. For end to end tracing of transactions with external vertical system as part of the consideration. A strategy is needed to have a traceable form of ‘reference number’, an ID that maps the entire lifecycle of the payload message including external interactions with another microservice.
• Authentication and Authorization. Repeatable security related standards that needs to be abstracted due to a number of services will be implementing similar authentication and/or authorization mechanism.