This page details the current architectural design of the entire system, if this changes, this page should reflect those changes (and specify why those changes where made).

Table of Contents

Microservice architecture

General architecture

A general solid, project-independent, documentation of the microservice architecture can be found here: http://microservices.io/patterns/microservices.html

OMS architecture

Of course our project's architectural structure is an implementation of an abstract design and therefore has some differences, implementation choices and/or nuances.

Docker is used as a distribution tool, it's swarm-features enable us to run the system on a cluster transparently
The core microservice is somewhat of an artifact from the past: It still has some of the more monolithic aspects of it in place (as of writing).
- The core microservice contains the frontend as well.
All 'normal' microservices are very loosely coupled by 'the 3 inter-service communication services'
- Information on how to correctly setup a new microservice to be used by these services can be found where???
Inter-service communication services:
- Docker provides a loadbalanced DNS that resolves the service name to a container instance and is activated in every container. (http://omscore → IP)
- Traefik is a proxy for external requests and redirects requests to a microservice instance according to proxying rules (defined in the docker-compose.yml) and an internal loadbalancing-mechanism
- Registry provides security tokens for microservices, as well as adding category-labels (based on docker-compose.yml)
Diagrams:
- Since all the microservices are loosely coupled a table suffices, this can be found on the Microservice overview page.
- Explanation and diagrams of the inter-service communication can be found on the Microservice communicatino page.

The diagram on the right is an attempt at visualizing the architecture.

Architectural Challenges

Challenges related to the architecture: challenges as a result from the architecture that arise through implementation / development. For the project related challenges see the project plan.

Deployment

The single most challenging aspect of having a (micro)service oriented architecture is the impact it has on development, deployment and testing: It gets a lot more complicated. For now this is solved by making use of docker and vagrant, but this should be kept in mind for the future.

Data consistency

As mentioned on the microservice pattern page, achieving data consistency between multiple services that are together part of a single request (edit) can prove to be troublesome, as each have their own database and can run into their own errors.

Suggested is an event driven approach, although currently there is probably not anything in place for this.

Collaboration

Having multiple independent microservices can make it easier to develop a microserivce (as well as assigning a team per microservice), eventually these independent services need to work together for the system to function. To this end clear standards should be set, both in terms of workflow (see project plan) and implementation.

Implementation standards:

Standardized Microservice Requirements

Differences to older designs

Name	Date	Design
Core independent	2017	With the addition of traefik and the registry there is no longer a real 'core' module. Some artifacts of the previous design remain.
Monolithic core	< 2017	The older design, while also deemed as having a microservice architecture, was in reality more of a hybrid: It had a more monolithic core combined with several microservices that could be plugged in. The current design is more enterprise level with more in-dependability between services while lessening the monolithic nature of the core microservice.

Future considerations

Split frontend from core
Which cross-cutting concerns should be anticipated on by introducing standardization requirements?
1. So far: authentication, permissions
2. To standardize: Data and Objects model
  1. Achieving data consistency
  2. Allow extending existing Objects (adding new fields to it)

Discussion

Points that should/could be discussed about the architectural design can be noted down here until resolved. Discussion on these should place take in a dedicated discussion issue on JIRA (GENERAL).

Should we revert back to the monolithic core design?
1. Since it seems to be working now, this would probably not benefit the system and project a lot.
Should the core be renamed?
1. It is not really the monolithic core it once was planned to be anymore
Investigate the redundancy between Docker DNS / Traefik / Registry
1. Docker DNS is automatically gained by using docker
2. Traefik seems to only provide extra the external url to docker container, is this worth the overhead?
3. Registry seems to pretty much only add categories, is this necessary?

Design