After defining Bounded Contexts and having done Strategic Domain-Driven Design phase, we are ready to talk about some technical details of our Microservice environment. Since we are all professionals, we decided to log our decisions about architecture and infrastructure. We have split our system into independent mini-systems, so we don’t need to stick to one architecture or programming language, because all those pieces will communicate with a standard HTTP protocol. Some ADR files are available in the Lab, so make sure you go through them carefully.
Other Decisions
Every IT system out there is made of thousands of decisions. Requirements, algorithms, ui mechanics, even brand colors. All these aspects were discussed, and at some point someone decided, which way the project should go. Can you imagine that your team actually writes them all down? If so, then probably they would do nothing but justifying their technical choices, instead actually implementing them. The conclusion? Don’t be overambitious, because you may stuck in talking about the system instead providing a real value.
Decisions About The Tutorial
App Containers
To keep our Microservices nice and separated, we run them as an independent containers under Docker’s supervision. The Load Balancing is handled by the Caddy Server. It was chosen, because it provides a simple, yet robust configuration options. Setting up the reverse proxy this way is a piece of cake.
Communication Between Services
There are two ways our Services can communicate:
- requesting data via HTTP endpoints, it happens only when some Service needs a particular data from another Service
- obtaining data via Events, which are emitted by Services via Message Broker
The first method requires additional configuration, because requesting service must be authorized somehow. Generally, the private network creates a secure and safe environment, but there may be situation when we don’t want some Services talk to another ones. The second way doesn’t require implementing any authorization mechanisms on a Service level, because it only needs access to the Message Broker. Producing messages takes place behind Service’s authorization system, that’s why we can assume that if message was sent, it was meant to be published.
Storage And Persistence
To store the data, we will use PostgreSQL, which is implementation of the SQL database. This RDBMS will help us to keep our data safely and consistently. If you feel you could you some extra tutorial about this technology, do not hesitate to visit dedicated lessons on this subject. The second storage engine is Redis. This key-value store, will help us with non-critical data like user sessions or cached, pre-calculated structures. Redis must be considered non-persistent, because it usually doesn’t store any data on the hard drive. Every time Redis is restarted or turned-off, the data that resides in RAM will be deleted.
Deployment And Production
At the end of every development process, there is a deployment phase, which will build and run our applications in the production environment. It can be placed in many cloud environments, but here we will use the most popular provider, which is Amazon Web Services (AWS). AWS provides a great service called Elastic Container Service that will be the last stage of exposing our system to the end users.