# Developing Microservice-Based Applications Using the Silvera Domain-Specific Language
## 2 Related Work
### Comparison of MSA with Other Architectural Styles
For this reason, a microservice and its associated data represent a single unit with minimal dependencies, which facilitates maintenance and deployment of the microservice (i.e., microservice can be changed and redeployed without affecting the rest of the system). Multiple services can be composed together as a new service. This process is known as _service composition_. Service composition implies the existence of _service coordination_. For service coordination, MSA focuses on service choreography, whereas SOA relies on both service choreography and service orchestration [16]. The term _service orchestration_ refers to the coordination of multiple services through a centralized mediator, whereas _service choreography_ lacks the mediator [16]. Implementation of service coordination is a non-trivial and error-prone task. However, there are several tools that allow developers to automate this process [18; 19]. As a result of this approach, microservices are responsible for interaction with others [20]. Of course, one can still utilize orchestration; however, this is not a typical approach [20]. Due to the mentioned differences, systems built on SOA tend to be slower than microservices and require more time and effort to develop, test, deploy, and maintain [16]. In addition, a service composition should be efficient with minimal execution time and energy consumption. An approach for execution time and energy efficient service composition is presented by [PERSON] et al. in [21]. The order of service tasks execution is determined by a _service scheduling_[22]. Resource allocation is another important process that affects the performance. The goal of resource allocation is to select resources for component instances and determine the number of component instances needed to meet performance and reliability requirements [22]. Usually, microservices have more components with less functionality that require fewer resources. MSA also differs from Monolithic Architecture (MA). In MA, components rely on the sharing of resources of the same machine (memory, databases, or files) and are therefore not independently executable [23]. Monolithic applications are usually internally split into multiple services and/or components, but they are all deployed as a single solution. Unless the application is becoming too big, monolithic applications are easier to develop [24]. However, large monolithic applications suffer from the following problems [17]: they are difficult to maintain and evolve, it is hard to add or update libraries due to _dependency hell_, change in only one module requires rebooting the whole application, etc. Microservices \begin{table}
\begin{tabular}{l l l} \hline \hline \multicolumn{1}{c}{**Architectural Style**} & **Service Taxonomy** & **Service Ownership** \\ \hline \multirow{2}{*}{MSA} & Functional services & Application development teams \\ \cline{2-3}  & Infrastructure services & Application development teams \\ \hline \multirow{4}{*}{SOA} & Business services & Business users. \\ \cline{2-3}  & Enterprise services & Shared services team orchitects. \\ \cline{1-1} \cline{2-3}  & Application services & Application development teams. \\ \cline{1-1} \cline{2-3}  & Infrastructure services & Application development teams or infrastructure services teams. \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Comparison of service characteristics in MSA and SOA. succeed in mitigating these problems and are gaining in popularity due to the following characteristics:  
* _Size_: Because microservices implement a limited amount of functionalities, their code bases are small which limits the scope of a bug [17]. The small size also provides benefits in terms of service maintainability and extendability. A small service can be easily modified or rebuilt from scratch with limited resources and in limited time [25]. * _Independence_: Each microservice in MSA is operationally independent of others and communicates with other microservices through their published interfaces [25].