Architectural analysis of Susanne Kaiser presentation, The Journey to Microservices from a Startup Perspective.
Just Social is an application that fully integrates collaboration and communication in organizations by providing functionalities for social network, document sharing, task management and real-time collaboration.
The developer stakeholders want to evolve and change the system in a timely manner, modifiability quality, in order to achieve a time to market quality. This business quality is raised by the Just Social business managers, which are also relevant architectural stakeholders.
The presentation can be described according to two different perspectives: the architectural steps taken to migrate from a monolith to a microservices architecture; and the qualities of the system that are provided by the microservices architecture. To have a more concrete idea on how these two perspectives differ we compare two modifiability scenarios, one for each perspective.
Considering the quality of modifiability a scenario that describes the architectural migration is
- Source of Stimulus: Developers
- Stimulus: Extract web interface for a microservice from the monolith
- Environment: Design time
- Artifacts: Just Social (Monolith)
- Response: The modification is made, tested and deployed, minimizing the number of errors
- Response Measure: Amount of time to make the modification, number of errors, preservation of the original behaviour of the system (concrete values not specified in the presentation)
- Tactic: Increase semantic coherence, because it increases the coherence of the web interface, and encapsulate, because the access to business logic in the monolith is done through a REST API
On the other hand, a modifiability scenario that highlights the advantage of using a microservices architecture
- Source of Stimulus: Developers
- Stimulus: Add a new feature
- Environment: Design time
- Artifacts: Just Social
- Response: The modification is made, tested and deployed requiring reduced coordination between the different team members
- Response Measure: Amount of time to make the modification, number of errors such that it can be done from a time to market business perspective (concrete values not specified in the presentation)
- Tactic: Increase semantic coherence, because the system is split in a set of independent responsibilities
Therefore, the first scenario artifact is the monolith and the scenario states the quality of modifiability, change the architecture and while reducing the number of possible errors, whereas the second scenario artifact is the microservices system and highlights the reduced impact the add of a feature has on other microservices.
Following this distinction, and in what concerns the migration perspective, two similar modifiability scenarios can be written for the migration of, respectively, the business logic and the data storage. An additional quality involved in the migration process is interoperability between what remains of the monolith and the microservices that were extracted. The need for interoperability is due to the fact that some of the business logic that remains in the monolith is coupled with the business logic that migrated to the new microservice.
- Source of Stimulus: Monolith
- Stimulus: Monolith business logic requires the business logic that migrates to the microservice
- Environment: Known prior to runtime
- Artifacts: Monolith and microservice
- Response: The business logic in the microservice is processed on behalf of the monolith
- Response Measure: The information is correctly processed
- Tactic: Tailor interface
The architectural solution implies the definition of a REST API in the microservice that is accessed by the monolith business logic.
In the other hand, the other qualities that were addressed in the presentation associated with the microservices system were: usability and security.
A scenario for the usability quality is
- Source of Stimulus: End user
- Stimulus: End user uses the system while continuous feature amendments occur
- Environment: Runtime
- Artifacts: Just Social
- Response: The system is intuitive to use and the number of errors are minimal
- Response Measure: Number of errors (concrete values not specified in the presentation)
- Tactic: There isn’t an architectural solution, because by modularizing the user interfaces they are changed less frequently, it may occur only when the microservice is changed
The relevant aspect of this scenario is that there isn’t a usability architectural solution to achieve better usability, it was, actually, a side-effect of the modularization, resulting from the decomposition into microservices.
The security quality was addressed in term of authorization, as described in the following scenario
- Stimulus: Unauthorized attempts to access a domain object
- Environment: Fully operational
- Artifacts: Domain object which is contained in a microservice
- Response: The domain object is protected from anauthorized access
- Response Measure: The system is not compromised
- Tactic: Authorize actors
As a consequence, they implemented a decentralized authorization mechanism, where authorization data is kept together with the domain data. However, this architectural solution has two drawbacks, (1) the degradation of performance for changes to the authorization data, because the authorization of a request needs to use the authorization data of domain objects which belong to different microservices, which result in an communication overhead between them in order to synchronize the replicated authorization data, and (2) the increase on the modifiability cost, because the authorization logic is implemented at every microservice and whenever it changes it is necessary to change it in all microservices which results in tight coupling between microservices. Considering (1) and (2) as scenarios, the solution uses two tactics, reduce overhead by not replicating the authorization data, and increase semantic coherence by centralizing the authorization mechanism. After this architectural change they got an overhead in the communication over the network for authorization verification and the centralized solution became a single point of failure. Note, however, that a passive redundancy tactic can be applied for the second issue.
There wasn’t described any impact of downgrading to eventual consistency.