## 6 Discussion  
The microservices-based approach succeeds at pointing out the boundaries between different components. A software architect or even developer would have few or no problems identifying what the functionalities offered by a service are. Thus, the separation of concern was defined by properly designing the services' responsibilities. Additionally, fault tolerance represents another advantage. Architectural loose coupling of the microservice containers allows their replacement and restart without negatively impacting the other services. The poorly engineered services are easily replaceable during development, while the rest of the application continued to operate as expected. Deploying changes can be as easy as pushing a commit to the master branch if Kubernetes is set up to check for newer versions of the Docker images automatically. Another advantage comes from reusability. The authentication service could easily be used in a different application without further modifications. Implied data are also isolated at the database level and can be used or backed up independently. Containerization means that the services can be easily deployed using commercial cloud infrastructures, as well. Adding features might prove to be simpler than working with monolithic applications while requiring only the development of a new microservice instead of modifying the existing ones and taking the risk of introducing new bugs. Moreover, the web interface can be multiple-sided, covering different components of the ecosystem that manage data readings, end clients, smart meters, and so on. Under normal circumstances, each team that develops a microservice should be responsible for the entire developed microservices-based architecture. This approach is also recommended for complex applications. Microservices-based architectures are better suited for complex applications, which require a high degree of flexibility and scalability. Indeed, it is often recommended to start with a monolithic structure and consequently break it up into microservices only when and if the need arises. Designing a system around microservices might prove to be a more difficult architectural task than designing standard applications. New and exciting technologies, such as containers and orchestration layers, help the design, development, and deployment processes. Multiple token-based standards were developed, such as OAuth, OpenID Connect, and JSON Web Token. The token-based authentication models cover the two main phases of the service requests, namely, the initial authentication and also the refresh (update) of the token. According to the architectural considerations and principles introduced in this paper, the services are separated, and they can be easily replaced when updated libraries are published, or new versions of security token standards are made available. Identity providers may be represented by self-developed services, which manage their own credential databases and tokens, or they can be open-source identity stores, such as Okta, Keycloak, LDAP, or a combination of these. Their use is wrapped into customized services, or their own RESTful API can be used in order to secure the respective microservices-based architectures. Web redirect mechanisms are used to forward system requests to the authentication service using secure communication channels. There exists a large pool of client types that are connected to microservices-based architectures, such as other services, phones, IoT devices, browsers, etc. Some of the clientsare owned by particular organizations, while other clients are represented by external entities. Limited access to external clients must be granted through firewalls. Each type of client must be able to access the identity service in order to retrieve the needed token or to access the application functionalities. The access rights to a group of microservices cannot always be granted through a reverse proxy microservice. The trusted network is difficult to isolate.