Microservices

While implementing microservices or upgrading a given legacy system it is crucial to provide backwards-compatibility. This can be easily achieved by using portability layers, which abstracts service usage. By using configuration parameters it is also possible to switch between the given implementations during service invocations. Therefore introducting this layer for microservices is a good practice while upgrading legacy applications:

While adopting a microservices architecture to a given system, the following points should be considered:

• Operational concerns are considered during requirements specification
• The overarching structure of the system should be a collection of small, independent services
• Each services should be distrustful of both clients and other required services
• Team roles have been defined and are understood
• Services are required to be registred with a local registry/load balancer
• Services must renew their registration periodically
• Services must provide SLA for their clients
• Services should aim to be stateless and be treated as transient
• If a service has to maintain state, it should be maintained in external persistent storage
• Services ahve alternatives in case a service they depend on fails
• Services have defensive checks to intercept erroneous input from clients and output from other services
• Use of external services, environmental information, and third-party software and libraries are localized (i.e they require passage through a module specific to that external service, environment information, or external software or library)

Dependendability

Microservices face three sources for dependability problems:

• Inter-Team coordination
  This can be resolved by:
  • Defensive programming through input verification and a rich collection of exceptions
  • Integrate end-to-end testing, e.g. Consumer Driven Contract (CDC)
• Correctness of environments
  This can be resolved by:
  • Service initialization shall verify the expected environment
  • Service initialization shall verify configuration parameter consistency (see Infrastructure-as-Code paradigm)
• Possibility of service-instance failure
  ​This can be resolved by:
  • Once a call failed, a second call shall be triggered
  • Provide fall-back in case of service failures

Modifiability

Microservices must be designed modifiable to make changes easy and reduce ripple effects. This can be done by encapsulate the affected portions of a likely change or the interfactions that might cause ripple effects of a change. There are some examples for such changes:

• Environment within which a service executes
  This is the case for the deployment pipeline, where a service moves through environments for testing until the go-live on production.
• State of other services with which your service interacts
  Service semantics and interfaces can change due to development activities, therefore they can be considered as treat all communication with external services as likely to change.
• Version of third-party software and libraries
  External software, where you do not have source code access, can change arbitrarily sometimes in ways that are disruptive for your service.

Feature Toggle

Feature Toggles can be used for dynamical control of new features. Thy provide a functionality to enable and disable those. Implemented within Service Registries they can be leveraged as powerfull tools to configure new services globally. Feature Toggles typically are implemented using if-statements, e.g.:

if (Feature_Toggle) then    new code  else    old codeend;

Configuration Parameters

Configuration parameters are externally setable variables, which change the behavior of a system. The amount of configuration parameters must be cept at a manageable level, as they tend to result in a complex connection between each configuration and require a higher integration and dependency of skilled resources to manage them. Typical use-cases are:

• Language of application
• Location of data files
• Thread Pool sizes
• CSV adjustments
• Feature Toggles
• Environment Configuration

Configuration parameters for environment configuration should be kept synchron across all stages of the deployment pipeline, while other parameters, such as amount of instances of a application, can be kept separate. Some parameters must be kept confidential, such as database password for productive environments.