Commit eeb10747 authored by Arthur Del Esposte's avatar Arthur Del Esposte 🤘🏻
Browse files

Add design principles

parent 02ede929
......@@ -8,12 +8,11 @@ provided by the InterSCity Platform.
* [Overview](#overview)
* [Microservices view](#microservices-view)
* [Deployment view](#deployment-view)
* [Design constraints and guidelines](#design-constraints-and-guidelines)
* [Design principles](#design-principles)
* [Security](#security)
* [Roadmap](#roadmap)
* [API](#api)
* [Service discovery](#service-discovery)
* [Messaging](#messaging)
* [API Gateway](#api-gateway)
## Overview
......@@ -153,13 +152,38 @@ Both *Resource Discovery* and *Resource Viewer* request the *Resource Catalog*
API to get static data about resources (3). They also request historical and
real-time data to *Data Collector* microservice (4).
TODO: CONTINUE HERE
## Deployment view
> Comming soon
## Design constraints and guidelines
## Design principles
* **Modularity via Services** - Microservice architectures achieve
modularity through single-purpose, small services that communicate
through lightweight mechanisms to achieve a common goal.
* **Distributed Models and Data** - With microservices, each service has its
own database and models, which may evolve independently of external services.
We encorage decentralized data management and the possibility to use different
technologies that best fit each microservice context.
* **Decentralized Evolution** - Microservices must be autonomous,
providing well-defined boundaries and communication APIs so that they can
evolve and be maintained independently. Moreover, this principle ensures
that each service may implement its functionalities using the most appropriate
technology, provoking positive technology heterogeneity. Each microservice
may scale independently using different strategies. Finally, this design
principle should reflect on the configuration and deployment procedures,
which may be performed independently as well.
* **Reuse of Open Source Projects** - We must always give preference to
the use of existing robust open source tools, libraries, and frameworks
instead of implementing components from scratch.
* **Asynchronous versus Synchronous** - Although most services provide
RESTful APIs, they must implement asynchronous messaging as much
as possible to avoid blocking in synchronous request-reply interactions.
* **Stateless Services** - Microservices should be as stateless as possible
to enable any service instance to respond to any request,
facilitating load distribution and elasticity.
Thus, the design of microservices should separate state data, such as context
and session data, to be managed by an external component whenever possible.
> Comming soon
......@@ -197,17 +221,6 @@ system to support dynamic service discovery. These are some options:
* [SERF by HashiCorp](https://www.serf.io/)
* [SkyDNS](https://github.com/skynetservices/skydns)
### Messaging
Some of the synchronous communication between services may be redesigned to be
support asynchronous messaging. These are some open source options:
* [Mist](https://github.com/nanopack/mist)
* [Apache Kafka](http://kafka.apache.org/)
* [RabbitMQ](https://www.rabbitmq.com/)
* [Mosquitto by Eclipse](https://mosquitto.org/)
### API Gateway
The [API Gateway design pattern](http://microservices.io/patterns/apigateway.html)
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment