# Developing Microservice-Based Applications Using the Silvera Domain-Specific Language
## 2 Related Work  
### Comparison of MSA with Other Architectural Styles  
The terms _architecture_ and _architecture description_ are introduced by ISO/IEC/IEEE 42010:2011 standard [14]. An _architecture description_ expresses an architecture of a system-of-interest [14]. _Architecture_ encompasses fundamental concepts or properties of a system in its environment embodied in its elements and relationships and in the principles of its design and evolution [14]. Architecture descriptions are used by software teams to improve communication and cooperation among stakeholders, enabling them to work in a comprehended and coherent manner. An architecture description comprises architecture views and models. [PERSON] [15] presents the software architecture model 1+5 that encompasses various architectural views for modeling business processes, describing use cases and their realizations, interaction and contract agreements between services, and deployment. MSA is a _service-based architecture_, just like Service-Oriented Architecture (SOA). Even though MSA and SOA represent very different architectural styles, they share many characteristics. Services are a primary architecture component used to implement and perform business and nonbusiness functionality in both MSA and SOA [16]. Both MSA and SOA are generally distributed architectures and also lend themselves to more loosely coupled and modular applications [16]. Furthermore, the implementation of a service is hidden behind its publicly available API. Due to this, the implementation of a service can be entirely changed without affecting the rest of the system as long as the API changes are backward compatible [16]. Although MSA and SOA both rely on services as the main architecture component, they vary greatly in terms of service characteristics [16]. Differences are shown in service taxonomy (i.e., how services are classified within an architecture), service ownership, and service granularity. As shown in Table 1, microservices have limited service taxonomy. There are only two service types: _functional services_ and _infrastructure services_. Functional services implement specific business operations or functions, whereas infrastructure services implement non-functional tasks such as authentication, authorization, auditing, logging, and monitoring. In MSA, infrastructure services are not exposed to the outside world and are only available internally to other services [16]. On the other hand, in SOA, there are four types of services. _Business services_ are abstract, coarse-grained services that define core business operations. These services are devoid of implementation details and usually only contain information about a service name and expected inputs and outputs. _Enterprise services_ are concrete,coarse-grained services that implement the functionality defined by the business services. These services are generalized and shared across the organization [16]. _Enterprise services_ can contain business functionality, but usually, they rely on application and infrastructure services. _Application services_ are fine-grained services that are bound to a specific application context. They provide functionality not found in the enterprise services. _Infrastructure_ services implement the same tasks as in MSA. In addition, there is a significant difference in service ownership as development teams are responsible for full support and development of a service throughout its life cycle (also known as the \"you build, you run it\" principle) [17]. Microservices are small, fine-grained services (hence \"micro\"), whereas services in SOA range in size from very small to large enterprise services. MSA and SOA also differ with regard to data sharing and service coordination. In the case of data sharing, MSA promotes a style where microservices share as little data as possible, whereas SOA promotes the diametrically opposed concept of sharing as much data as possible [16].