Microservice Architecture (MSA) is a rising trend emerging from the enterprise world. This architectural style is defined by Lewis and Fowler ^[1] as “an approach to developing a single application as a suite of small services, each running in its own process and communicating using lightweight mechanisms, often an HTTP resource API”.

MSAs are particularly suitable for cloud infrastructures as they greatly benefit from the elasticity and rapid provisioning of resources ^[2], but  also for the modernization of legacy systems ^[3].

According to the survey published by the Eclipse Foundation, in 2018 (2018 Jakarta EE Developer Survey Report—https://jakarta.ee/documents/insights/2018-jakarta-ee-developer-survey.pdf (accessed on 13 October 2021)), about 46% of organizations developed their applications in the form of microservices. A survey performed in 2019 (2019 Jakarta EE Developer Survey Report—https://jakarta.ee/documents/insights/2019-jakarta-ee-developer-survey.pdf (accessed on 13 October 2021)), again by the Eclipse Foundation, shows that MSA is the leading architecture for implementing Java in the cloud.

Although evidence shows an increase of distributed systems developed in the form of MSA, studies presented in ^[3][4][5] show that it is still problematic to find skilled developers familiar with microservices. Microservice developers need to familiarize themselves with the variety of technologies and tools in a timely manner. Furthermore, supporting polyglot programming may require additional tooling, processes, and knowledge ^[6]. Being polyglot is an important characteristic of MSA as it gives developers the flexibility to choose the technology stack and languages that work best for their needs. However, introducing many languages and frameworks may actually decrease the overall understandability and maintainability of the system. As shown by Wang et al. ^[7], some organizations already regulate language diversity by restricting the number of programming languages used in a microservice-based system to a few core languages. While this decreases the problems of understandability and maintainability, a study performed by Baškarada et al. ^[4] shows that the opportunity to use heterogeneous technology stacks was singled out by most interviewees as one of the most significant drivers for MSA adoption.

Due to the higher complexity of MSA, migration of the monolithic legacy system to MSA can cause high development costs. The empirical study performed by Lenarduzzi et al. ^[8] shows that the technical debt of microservices grows 90% slower than in the corresponding monolithic legacy system. Lenarduzzi et al. ^[8] also recommend companies define a set of service templates as a way to ease the development of new microservices, but also not to delay important architectural decision making, as this will cause more effort in the future. Having service templates helps, but developers are still required to manually introduce the necessary changes to create a new microservice or to update the existing microservices to comply with architectural changes.

Documenting MSA properly can also be a challenge. Frequent changes in the architecture often lead to wrong and out-of-date architecture models ^[9]. In addition, communication relationships between microservices and the specific APIs through which they communicate are often missing from such models ^[9]. With the highly decentralized development and design of microservices, it becomes challenging to maintain a centralized reference of the architectural design ^[10][11]. Due to this, the system’s architecture deviates from the original design over time.

2. Comparison of MSA with Other Architectural Styles

The terms architecture and architecture description are introduced by ISO/IEC/IEEE 42010:2011 standard ^[12]. An architecture description expresses an architecture of a system-of-interest ^[12]. 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 ^[12]. 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. Gorski ^[13] 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 ^[14]. Both MSA and SOA are generally distributed architectures and also lend themselves to more loosely coupled and modular applications ^[14]. 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 ^[14]. Although MSA and SOA both rely on services as the main architecture component, they vary greatly in terms of service characteristics ^[14]. 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 nonfunctional 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 ^[14]. 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 ^[14]. 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) ^[15]. 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 ^[14]. 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 ^[14]. The term service orchestration refers to the coordination of multiple services through a centralized mediator, whereas service choreography lacks the mediator ^[14]. Implementation of service coordination is a non-trivial and error-prone task. However, there are several tools that allow developers to automate this process ^[16][17]. As a result of this approach, microservices are responsible for interaction with others ^[18]. Of course, one can still utilize orchestration; however, this is not a typical approach ^[18]. 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 ^[14]. 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 Li et al. in ^[19]. The order of service tasks execution is determined by a service scheduling ^[20]. 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 ^[20]. 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 ^[21]. 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 ^[22]. However, large monolithic applications suffer from the following problems ^[15]: 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 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 ^[15]. 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 a limited time ^[23].
• Independence: Each microservice in MSA is operationally independent of others and communicates with other microservices through their published interfaces ^[23]. This has several benefits: (i) microservices are independently deployed, (ii) the new version of microservice can co-exist with the old version, and the microservices that use the old microservice can be gradually modified to use the new microservice ^[15], (iii) changes in one microservice do not require the reboot of the whole system, and (iv) scaling MSA implies deploying or disposing of instances of microservices with respect to their load ^[24].

3. MSA Design Patterns

A design pattern is a reusable solution for a problem that occurs in a specific context. Richardson ^[25] proposes a taxonomy and describes design patterns used in MSA. In the rest of the paper, design patterns from the following categories will be considered: Deployment patterns, Communication patterns, External API patterns, Reliability patterns, and Service Discovery patterns. Each of the previously mentioned categories can contain multiple different design patterns, as shown in Table 2. Deployment patterns provide a solution to the problem of packaging and deploying microservices. Patterns such as Single Instance Per Host, Multiple Instances Per Host, Single Instance Per Container, and Serverless are all deployment patterns. In the case of the Single Instance Per Host and the Multiple Instances Per Host, a Host can be either a physical or a virtual machine (VM). The most popular deployment pattern, both in industry and academia, is the Single Instance Per Container, followed by the Single Instance Per Host, where a host is a VM ^[26]. There are several reasons why containers are preferred over VMs ^[26]: (i) creating and launching container images are often very fast, (ii) the same physical server can hold more containers than VMs due to their size, and (iii) more than one container can use a single operating system, which in turn reduces the overhead of licensing costs compared to the VM. Microservices must handle requests from external clients, but often they must collaborate to perform a certain task. The role of Communication patterns is to provide a solution for a problem of communication between the parts of the system. The most prevalent communication patterns in microservice-based systems are Remote Procedure Call (RPC) and Messaging. With RPC, microservices can communicate either in a synchronous or asynchronous manner, whereas with Messaging the communication is always asynchronous. According to Aksakalli et al. ^[26], it is not possible to determine the most popular communication pattern, since the selected pattern can change over time as the system evolves. How microservices will establish a connection is further described by Service Discovery patterns. The Service Registry pattern ensures the existence of a service registry, which represents a database that contains the data model of available microservices deployed in the platform ^[27]. A service registry is a critical part of the system and must be highly available. The responsibility for registering or unregistering a microservice within a service registry can be put either on the microservice itself (Self-Registration) pattern or the third party (Third-Party) pattern. Similarly, the responsibility for discovering a microservice can be either on the client side (Client-Side Discover) pattern or on the server side (Server-Side Discovery) pattern. External API patterns describe exactly how external clients will communicate with microservices. An API Gateway provides a single entry point for all external clients. To avoid a single point of failure, multiple instances of an API gateway are usually deployed ^[26]. Additionally, a separate API gateway can be provided for each kind of client (web app, mobile, etc.). This variation of an API Gateway pattern is a Back-End for Front-End pattern. Microservices are built to fail ^[28]. The solution for the problem of preventing the microservice failure to cascade to other microservices is provided by a Reliability pattern named Circuit Breaker.

4. Existing MSA fFrameworks

In tThis section, we w will briefly describe current state-of-the-art tools for describing the architecture of distributed systems based on microservices.

MAGMA (Maven Archetype for Generating Microservice Architectures) is a tool that is based on the Maven build management system. It aims at accelerating the development of microservices architectures (MSA) by generating infrastructure code that is: (i) specifically

configured for the target application domain; (ii) directly runnable; (iii) extensible with user-defined templates ^[29].

AjiL is a tool for creating and describing MSAs based on the Eclipse Modeling Framework (EMF) (Eclipse Modeling Framework—https://www.eclipse.org/modeling/emf/ (accessed on 10 January 2021)). AjiL comprises a graphical editor and a template-based code generator. The generator converts existing AjiL diagrams into runnable MSA, based upon Java and the Spring framework ^[30].

TheArchitect is a rule-based system used for generating serverless microservices ^[31]. MSAs in TheArchitect are created by providing system requirements into TheArchitect’s input wizard. The obtained information is processed by the predefined set of models afterward. These models are subsequently analyzed by the code generator, which produces the application code. MicroBuilder is a tool for generating REST-based (REST–Representational State Transfer) microservices ^[32]. It consists of two modules: MicroDSL and MicroGenerator. MicroDSL is a domain-specific language (DSL) used to describe the architecture of the microservices. MicroGenerator uses the MicroDSL specifications to generate Java applications based on the Spring framework. JHipster (JHipster — https://www.jhipster.tech/ (accessed on 13 July 2022))is a tool for generating, developing, and deploying web applications and MSAs. MSAs in JHipster are modeled by using the JHipster domain language (JDL). Modeling of microservices in JDL can be performed quickly due to its user-friendly syntax. JDL specifications are transformed automatically into runnable Java applications by the JHipster code generator. LEMMA (Language Ecosystem for Modeling Microservice Architecture) ^[33] is a set of Eclipse-based modeling languages and model transformations for developing MSA . These languages provide different modeling viewpoints for different roles in a microservice development team . By . By introducing explicit modeling viewpoints, LEMMA decomposes the system into smaller, more specialized parts. Because  of this, each role is presented only with the information relaevant for that role . Just like AjiL, LEMMA is also based on the Eclipse  ecosystem. Jolie is a service-oriented programming language ^[34]. A service, in Jolie, is composed of two parts: behavior and deployment. A behavior part defines the implementation of the service’s functionalities, whereas the deployment part defines the necessary information for establishing communication links between services. The Jolie interpreter is implemented in Java, and it comes with a Java API to interact with it. Silvera is a declarative language developed for the domain of microservice software architecture development ^[35]. The language is designed in a way that directly implements design patterns related to the domain of MSA. Silvera is a lightweight language. Because of this, it can be used in any text editor. The simple textual notation also enables easier collaboration through version control systems. Silvera supports an arbitrary number of programming languages and their versions. Various implementations of microservices, API gateways, service registries, and message brokers can also be supported easily. This allows developers to use the best tool for the job and also supports experimentation. Silvera uses microservice-tailored metrics to evaluate the architecture of the designed system. Silvera comes with a small number of dependencies and is available at the Python Package Index (Python Package Index—https://pypi.org/ (accessed on 18 January 2022)). Results of the Silvera evaluation study show that participants, on average, implemented the task ∼124% faster when using Silvera than when implementing the same task manually . In addition,  50% of the participants had a task completion of 100% when using Silvera, as opposed to 33.33% with the manual approach.