The system must be divided into modules that provide interfaces. Access to other modules is only possible through these interfaces. Therefore modules must not directly depend on implementation details of other modules, e.g. the internal data representation in a database. The rest of the principles define how modules might be implemented.
- The system must have two clearly separated levels of architectural decisions:
- The Macro Architecture comprises decisions that cover all modules. All further principles are part of the Macro Architecture.
- The Micro Architecture considers decisions which may be taken individually for each module.
Modules must be implemented as separate processes, containers, or virtual machines to maximize independence and enable a separation between Macro and Micro Architecture.
The choice of integration and communication options must be limited and standardized for the system. The integration might be done with synchronous or asynchronous communication, and/or on the UI level. Communication must use a limited set of protocols like RESTful HTTP or messaging. It might make sense to use just one protocol for each integration option.
Metadata, e.g. for authentication, must be standardized. Otherwise the user would need to log in to each microservices. This might be done using e.g. a token that is transferred with each call / request. Other examples might include a trace id to track a call and its dependent calls through the microservices.
Each module must have its own independent continuous delivery pipeline. Tests are part of the continuous delivery pipeline so the modules must be tested independently.
Operations should be standardized. This includes configuration, deployment, log analysis, tracing, monitoring, and alerting. There might be exceptions from the standard if a module has very specific requirements.
Standards for operations, integration, or communication should be enforced on the interface level. For example, the communication protocol and data structures could be standardized to a specific JSON payload format exchanged using HTTP, but every module should be free to use a different REST library/implementation.
- Modules must be resilient. They must compensate unavailable modules or communication problems. They must be able to cope with unexpected shutdowns without losing data or state. It must be possible to move them to other runtime environments (hosts, networks, config etc).
Comentários
Enviar um comentário