CC BY
35
DOI: 10.15514/ISPRAS-2023-35(1)-4
Microservice Deployment
V.M. Niño-Martínez, ORCID: 0000-0002-8436-1430 <ninomtz.victor@gmail.com> J.O. Ocharán-Hernández, ORCID: 0000-0002-2598-1445 <jocharan@uv.mx> X. Limón, ORCID: 0000-0003-4654-636X <hlimon@uv.mx> J.C. Pérez-Arriaga, ORCID: 0000-0003-2354-2462 <juaperez@uv.mx>
University of Veracruz, Xalapa, Veracruz, 91020, Mexico
Abstract. Modem software development requires agile methods to deploy and scale increasingly demanded distributed systems. Practitioners have adopted the microservices architecture to cope with the challenges posed by modern software demands. However, the adoption and deployment of this architecture also creates technical and organizational challenges, potentially slowing down the development and operation teams, which require more time and effort to implement a quality deployment process that allows them to constantly release new features to production. The adoption of a DevOps culture, along with its practices and tools, alleviates some of these new challenges. In this paper we propose a guide for the deployment of systems with a microservices architecture, considering the practices of a DevOps culture, providing practitioners with a base path to start implementing the necessary platform for this architecture. We conducted this work following the Design Science Research Methodology for Information Systems (DSRM). In this way, we identified the problem, and also defined the solution objectives through the execution of a Systematic Literature Mapping and a Gray Literature Review, having as a result the proposed guide. This work can be summarized as follows: (I) Identification of practices and technologies that support the deployment of microservices. (II) Identification of recommendations, challenges, and best practices for the deployment process. (III) Modeling of the microservices deployment process using SPEM. (IV) Integration of the knowledge in a guide to deploy microservices by adopting DevOps practices.
Keywords: agile methods; microservices architecture; deployment; DevOps; Systematic Literature Mapping; Gray Literature Review
For citation: Niño-Martínez V.M., Ocharán-Hernández J.O., Limón X., Pérez-Arriaga J.C. Microservice Deployment. Trudy ISP RAN/Proc. ISP RAS, vol. 35, issue 1, 2023. pp. 57-72. DOI: 10.15514/ISPRAS-2023-35(1)-4
Развертывание микросервисов
В.М. Ниньо-Мартинес, ORCID: 0000-0002-8436-1430 <ninomtz.victor@gmail.com> Х.О. Очаран-Эрнандес, ORCID: 0000-0002-2598-1445 <jocharan@uv.mx> К. Лимон, ORCID: 0000-0003-4654-636X <hlimon@uv.mx> Х.К. Перес-Арриага, ORCID: 0000-0003-2354-2462 <juaperez@uv.mx>
Университет Веракруса, 91020, Мексика, Веракрус, Халапа
Аннотация. Современная разработка программного обеспечения требует гибких методов для развертывания и масштабирования все более востребованных распределенных систем. Практики применяют архитектуру микросервисов, чтобы справиться с проблемами, связанными с современными требованиями к программному обеспечению. Однако использование этой архитектуры также создает технические и организационные проблемы, потенциально замедляя работу групп разработки и
эксплуатации, которым требуется больше времени и усилий для реализации качественного процесса развертывания, позволяющего им постоянно выпускать новые функции в рабочую среду. Принятие культуры DevOps вместе с ее методами и инструментами смягчает некоторые из этих новых проблем. В этой статье мы предлагаем руководство по развертыванию систем с микросервисной архитектурой с позиции культуры DevOps, предоставляющей практикам путь к началц внедрения необходимой платформы для этой архитектуры. Мы провели эту работу в соответствии с Методологией исследований в области проектирования информационных систем. Таким образом, мы определили проблему, а также определили цели решения путем выполнения систематического обзора литературы, включая серую литературу. Эту работу можно резюмировать следующим образом: (I) определение методов и технологий, поддерживающих развертывание микросервисов; (II) определение рекомендаций, проблем и лучших практик для процесса развертывания; (III) моделирование процесса развертывания микросервисов с помощью; (IV) интеграция знаний в руководство по развертыванию микросервисов с применением практики DevOps.
Ключевые слова: гибкие методы; микросервисная архитектура; развертывание; DevOps; систематический обзор литературы; обзор серой литературы
Для цитирования: Ниньо-Мартинес В.М., Очаран-Эрнандес Х.О., Лимон К., Перес-Арриага Х.К. Развертывание микросервисов. Труды ИСП РАН, том 35, вып. 1, 2023 г., стр. 57-72. DOI: 10.15514/ISPRAS-2023-35(1 )-4
1. Introduction
In the 1990s, the popularization of the World Wide Web (WWW) and the subsequent dot-com gold rush introduced the world to software as a service (SaaS), leading to entire industries built on this SaaS model. This motivated the development of applications that required more resources, making them more complex to develop, maintain and deploy. Nowadays, enterprise systems need to transfer information with other systems, internal or external to the organization, even at a global scale. Companies such as Amazon, Netflix [1], Uber [2], LinkedIn [3] and, SoundCloud [4], among others, found the need to migrate to a software architecture that allows them to undertake the complexity and constant need of evolution of their systems. To this end, they chose to adopt a Microservices Architecture (MSA). Not only have these large companies migrated to an mSa, but small and medium-sized companies have also done so, all of them seeking the benefits that this architecture brings, such as scalability, heterogeneity, and extensibility, among others.
A MSA is an approach to developing a distributed system as a set of small services. Each of these services runs in its process and communicates using lightweight mechanisms, like an HTTP resource API [5]. One of the characteristics that make this architecture different is the granularity of the services, which must be small and highly cohesive. Microservices adopt the single responsibility principle approach, which states "Gather together the things that change for the same reasons, separate those things that change for different reasons" [6], focusing the service boundaries on the business boundaries, in this way, preventing services from growing too large as well as the difficulties that this may introduce. The key benefits that microservices architecture offers over conventional architectural patterns are: the heterogeneity of technologies, fault tolerance, agile deployment, scalability, alignment with organizational structure, replaceability, and agile development of business functionality [7, 8].
Software deployment is a stage of the software development life cycle in which a system is put into operation and transition issues are resolved [9]. Deployment combines two closely related concepts, the first one is the deployment process, which consists of a series of steps that must be executed by the developers or those in charge of managing the system infrastructure to put the software into a production environment, and the second is the deployment architecture, which defines the structure of the software execution environment [10]. An application is only useful when deployed to users. Mature deployment practices are crucial to building reliable and stable microservices.
Unlike a monolithic system, optimized for a single-use case, microservices deployment practices need to scale to multiple services; it is possible to have tens or hundreds of microservices, written in different programming languages and frameworks. Each microservice is a small application with a specific process and architecture, which operators and developers need to deploy in production. If operators and developers are not able to quickly and reliably deploy microservices, then the added development speed gained from microservices would be useless. Therefore, a mature deployment process and automated deployments are essential for developing microservices at scale. When migrating from a monolithic approach to deploy microservices, the main challenges are the familiarization with the variety of technologies and tools, the automation of the process, and the implementation of a pipeline to continuously deploy [11]. In addition, among the most important challenges related to the deployment of this type of architecture are: 1) maintaining stability for a large volume of releases and component changes; 2) avoiding coupling between components, leading to dependencies in the build or release times; 3) managing changes in the service API, as changes could negatively affect the clients; and 4) removing and updating production services [12]. The practices found in DevOps aid to alleviate the mentioned challenges, these practices include: Continuous Integration (CI), Continuous Delivery (CD), Configuration Management (CM), and monitoring, among others. The implementation of these practices generates new challenges regarding: communication and coordination between teams; lack of investment in costs; lack of experience and skills; conflict management; design and code dependencies between components; implementation and release of software to customers [13].
To help developers and people in charge of creating a stable infrastructure to deploy microservices, we decided to elaborate a guide for the deployment of microservices-based systems, considering DevOps culture practices. The goal of the guide is to reduce the effort associated with creating an ecosystem for the microservices architecture. The guide integrates different organizational technical decisions, technologies, and tools successfully used by organizations, as well as the associated DevOps practices. The guide helps all related parties in the process of adopting a microservices architecture.
In order to create the guide, we followed the Design Science Research Methodology (DSRM) methodology[14], consisting of six phases. We have already completed the following phases: identification of practices, technologies, tools, activities, and recommendations for the deployment of microservices, through a previous work [15] consisting of a systematic mapping of the literature and a review of gray literature; classification and grouping of the information found; MSA process adoption modeling; and the selection and integration of related activities according to the adoption process. With these phases covered, it is possible to have a first version of the microservices deployment guide, leaving the demonstration and evaluation as future work. This paper is organized as follows. Section 2 gives an overview of some studies focused on the deployment of microservices and the adoption of DevOps practices. Section 3 presents the followed method to develop our microservices deployment guide, based on the DSRM methodology [14]. Section 4 describes the proposed deployment guide and its structure. Finally, Section 5 features the conclusion and future work.
2. Research Method
We followed the Design Science Research Methodology (DSRM) [14], establishing the recognition and legitimization of aims, processes, and investigation outputs, and helping researchers to present their work according to a common framework. The methodology incorporates principles, practices, and procedures required to carry out such research, meeting three objectives: consistency with prior literature, providing a nominal process model for doing Design Science (DS) research, and providing a mental model for presenting and evaluating DS research. Several studies have used this methodology to develop artifacts and validate its process, for example [16, 17]. DSRM includes six
steps: problem identification and motivation, the definition of the objectives, design, and development, demonstration, evaluation, and communication. We detail these phases in the following subsections.
2.1 Problem identification and motivation
For the identification of the problem related to microservices deployment and its importance, we performed a preliminary literature review. The concepts and topics analyzed were the microservice architecture style; advantages and drawbacks of its use; processes to deploy microservices; aspects that affect the deployment; and DevOps culture and its practices.
One of the main challenges we found, is the familiarization with the variety of technologies and tools, as well as the automation and implementation of a pipeline to deploy continuously [11]. Moreover, the implementation of practices such as Continuous Integration (CI), Continuous Delivery (CD), Configuration Management (CM), and monitoring; bring new challenges, such as communication and coordination between teams; lack of investment in costs; lack of experience and skills; conflict management; design and code dependencies between components; challenges in the implementation and release of software to customers [13, 18].
With our literature review, we developed a cause-effect diagram to reflect the factors that impact the deployment of microservices and convert it into a challenging process. Figure 1 shows the cause-effect diagram.
Fig. 1. Cause-effect diagram of a microservice deployment
2.2 Design the objectives for a Solution
Once we identified the problems, we concluded that a guide to deploy a microservice architecture could help to solve the problems. To know the state of the art, and the possible solutions, we performed a Systematic Mapping Study and A Gray Literature Review, both with the aim to identify practices, processes, technologies, recommendations, and lessons learned and reported by practitioners.
2.2.1 Systematic Mapping Study
We conducted the study following the guidelines of Kitchenham, Budgen, and Brereton [19], the guidelines describe a process to perform the mapping in Software Engineering. The objective of a mapping study is to survey the available knowledge about a topic. It is possible to synthesize information by categorization, identify "clusters" of studies that could form the basis of a fuller
review, and also identify "gaps", indicating the need for more primary studies. We executed the mapping study in three main phases: planning, conduction, and results report. Some activities carried out within these phases were: a preliminary literature review; definition of the research questions and search keywords; database selection; inclusion, and exclusion criteria; methods for the data extraction and analysis.
Planning
Research questions: Derived from the objective of the work, we formulated four research questions (RQ). The questions compiled the state of the art, showing us the techniques and technologies that researches, and practitioners use to deploy microservices, along with the related DevOps practices. The RQs and their motivation are shown in Table 1.
Table 1. Research Questions and Motivation
Questions Motivation
RQ-1: What DevOps practices and approaches support the deployment of Microservices? Identify the practices and approaches used in the DevOps culture and classify the technologies needed for each practice
RQ-2: What technologies do DevOps practices use to deploy Microservices? It is important to identify the technologies that are used in each DevOps practice, to understand which are the most suitable for a given situation
RQ-2: What technologies do DevOps practices use to deploy Microservices? It is important to identify the technologies that are used in each DevOps practice, to understand which are the most suitable for a given situation
RQ-3: What challenges does the literature report regarding the adoption of DevOps practices in the deployment of microservices? Many problems can emerge in the implementation of the practices and this question aims to know what they are and how often they are reported.
RQ-4: What lessons does the literature report for successful microservices deployment? This question aims to identify the processes, best practices, and recommendations that practitioners implemented in the deployment of their systems and serve as a guide for those in the same situation.
Research process: We performed a preliminary literature review, identifying a series of articles that helped us to define a set of keywords representing the main concepts around the research questions and, some of their related concepts. In the end, we decided to run an automated search for selecting primary studies. We constructed a base string with the search terms identified, refined, and validated using the Recall and Precision techniques. The generated string is the following:
(microservices OR "microservice architecture" OR micro-services OR "architecting microservices") AND (DevOps OR development OR operations OR "continuous integration " OR CI OR "continuous deployment" OR "continuous delivery" OR CD OR migration OR automation OR tools OR adoption OR monitoring OR cloud). Table 2. Selected Electronic Databases
Database Link
IEEE Xplore Digital https //ieeexplore.ieee.org
Elsevier Science Direct https //www. sciencedirect.com
Springer Link https //link.springer.com
Wiley Online Library https //onlinelibrary. wiley .com
ACM Digital Library https //dl.acm.org
Table 2 shows the selected databases that to conduct the search. We chose these databases because they compile the most significant number of works related to Software Engineering. In addition, in a previous manual review, we found results in the mentioned sources. ACM Digital Library and Elsevier Science Direct repositories have some considerations in their search engines, so we adjusted the search string. Due to the large number of results obtained in ACM, we decided to search only using the title as the indexer. In the Wiley repository, we used the exact string as in Science Direct, because, in the first tests, we observed that it performed better. We present the search string of each
database in Table 3. We only covered the last five years in the study, in these years the topics of DevOps and Microservices had more relevance in research articles. We have also observed in these years an increase in popularity of the topics of interest, and therefore it is of relevance for the study. We defined a list of inclusion and exclusion criteria for the studies, presented in Table 4.
Table 3. String Adjusted to each database
Source String
ACM Digital Library [microservice* OR "microservice architecture" OR "architecting microservices"] AND [DevOps OR development OR operations OR "continuous integration" OR CI OR "continuous deployment" OR "continuous delivery" OR CD OR migration]
Elsevier Science Direct (microservice OR "microservice architecture") AND (devops OR development OR operations OR "continuous integration" OR "continuous deployment" OR "continuous delivery" OR migration)
Springer Link (devops OR development OR operations OR "continuous integration" OR "continuous deployment" OR "continuous delivery" OR migration)
Wiley Online Library (devops OR development OR operations OR "continuous integration" OR "continuous deployment" OR "continuous delivery" OR migration)
Table 4. Inclusion and Exclusion Criteria
Database Link
IC-1: Studies published between 2015 and 2020. EC-1: It is an abstract, workshop, opinion article, presentations, book chapters, or conference notes.
CI-2: Articles written in English EC-2: The study does not focus on Microservices and DevOps process deployment
IC-3: The title and abstract contain information indicating that the full text could answer at least one research question. EC-3: The study is an earlier version of more recent work
IC-4: The full text answers at least one research question
Data extraction: We defined a template to extract the necessary information from each article to answer the research questions. Data D1-D10 contains the general information of each study, and data D11-D16 helped to extract qualitative data that answers the research questions. We used a spreadsheet to collect the information.
Data synthesis: For information synthesis, we used the meta-aggregation method [20]. The synthesis brings together the study findings, communicated as themes, metaphors, categories, or concepts; and grouped by further aggregation based on similarity of meaning [20]. This method helped us to identify lessons learned, common mistakes and understand why the literature reports certain technologies a higher number of times. Moreover, with the information classified and grouped, its analysis becomes a more straightforward process.
Conduction
We conducted the selection process in three stages, implementing the inclusion and exclusion of the strings in the different sources, and using the filters provided by each of them, the CI-1 and CI-2 criteria corresponding to the years of publication and their language were applied. In addition, in databases such as Science Direct, Springer Link, and ACM Digital Library, we used filters to only include research articles and not book chapters or lecture notes, thus applying the execution criteria CI-3 as well as the exclusion criteria CE-1 and CE-2. In the third stage, we read the full text, and the inclusion and exclusion criteria CI-4, and CE-3 were applied. Figure 2 shows the results after applying the inclusion and exclusion criteria by stage and database. At the end of the third stage, we obtained a total of 21 primary studies.
Fig. 2. Selection process
Data extraction and analysis: Once we selected the primary studies, we created a spreadsheet in which each column presents the to be extracted data. We performed a complete reading of each article, highlighting the information that answered the research questions and capturing this information in the spreadsheet; we performed this process for each of the primary studies selected. With the extracted information, we proceeded to apply the meta-aggregation method. This method has three main steps: (I) Identify and assemble findings from all included studies; (II) Aggregate well-founded and explicit findings; (III) Synthesis of findings implications. We also captured the findings in a spreadsheet, and with all the findings identified, we iteratively created categories and grouped findings on them.
Fig. 3. Meta-aggregation classification
Results
Meta-aggregation results: After the application of the method, we extracted classified 43 findings into seven categories. These categories were grouped into three synthesized findings Considerations for Deployment Microservices, Precautions when Deploying Microservices, and Deployment Technologies. Figure 3 shows the associations between categories.
Microservices deployment requirements: In this category, we identified requirements that practitioners, from their experience in the area, considered necessary for a successful microservices deployment. We found that architectural support is crucial for the adoption of DevOps practices, as well as having a mature operations team, to allow continuous deployment of numerous microservices. Furthermore, developers need to consider microservices' backward compatibility, and microservices upgrading with minimum effort and application downtime. Flexible and maintainable delivery systems support these needs.
Characteristics of DevOps practices: We grouped in this category, requirements, tips, and lessons learned by practitioners when implementing DevOps practices as well as deployment pipelines. The practitioners agree that pipelines are one of the key parts in the deployment of microservices because without good construction of pipelines, long wait times for releases and builds occur. To prevent it, it is necessary to apply DevOps principles in building CI/CD pipelines, automation is paramount to successful deployment.
Microservices deployment challenges: The findings related to this category are challenges those practitioners identified when adopting a microservices-based architecture. One of the challenges identified is the release of a new version of a microservice, because one or more microservices may depend on it. In addition, when adopting this architecture, there is a great effort in the context of new tools and frameworks. Microservices configuration is essential to achieve the expected results.
Challenges of DevOps practices: In this category, we grouped a set of challenges related to practices and technologies related to DevOps practices. The constant updating of tools and libraries makes development difficult, as well as the lack of tools for specific tasks that developers need to automate. For example, monitoring has several challenges such as lack of commercial options, lack of standardization, and lack of faster learning curves.
Characteristics of building technologies: Technologies are an important part of software deployment and construction; therefore, it is an aspect that practitioners pay particular attention to. In this category, we gathered characteristics mentioned by practitioners for these technologies. Some examples are integration servers such as Jenkins, GitLab CI, and Travis CI. Also, as part of the findings of the category, we made a comparison and characteristics of usage of each technology. Characteristics of containerization technologies: The use of containerization technologies, such as Docker, is one of the characteristics that popularized the microservices architecture. Many studies recommend the use of this technology, contrasting the advantages with respect to virtual machines. Deploying microservices using containers takes significantly less time than using virtual machines. The use of containers makes deployment a simple, fast, and platform-independent process. The mentioned benefits come from the fact that developers can automate the construction and provisioning of containers using scripts.
Characteristics of orchestration technologies: As a result of the wide adoption of containerization technologies, solutions for their orchestration have emerged. Technologies such as Kubernetes, Docker Swarm, and Docker-compose, among others, provide practitioners with various deployment benefits. This category presents a comparison in terms effectiveness of these technologies, and also compiles the experiences that developers had with their adoption. Kubernetes for container orchestration is the most suitable method for deploying microservices when the application demands high availability and scalability, however when it comes to security Kubernetes and Docker Swarm do not provide complete isolation between deployed containers, which introduces security issues.
Fig. 4. Practices mentioned by study
Answers to research questions: What DevOps practices and approaches support the deployment of Microservices? The studies mentioned the DevOps practices of Continuous Integration (CI), Continuous Delivery (CD), Continuous Deployment and Monitoring. However, some studies did not directly mention the use of DevOps practices but used the processes and activities of these practices. Figure 4 shows the practices reported and related articles. It is worth noting that some studies mentioned more than one practice.
Fig. 5. Technologies reported by the studies
What technologies do DevOps practices use to deploy Microservices? We found several technologies for the construction and deployment of microservices. Figure 5 presents the ten most frequently reported technologies.
Studies mentioned Docker, a containerization technology, 16 times. The literature compares containers with other similar technologies such as Virtual Machines (VM), and in each comparison, the studies concluded that the former provided more significant benefits. The literature also highlights DockerHub as a repository for container images.
Another important technology is Jenkins, a building technology used in CI/CD practices, mentioned in the literature eight times. In contrast, the literature only mentions once Circle CI and Travis-CI, which are similar to Jenkins.
Among deployment and orchestration technologies, the literature mentions Kubernetes, Dockercompose, and Docker Swarm. Kubernetes was the most used because it provides significant benefits in systems with many microservices. Finally, the literature also mentions GitHub and Gitlab four and three times, respectively.
What challenges does the literature report regarding the adoption of DevOps practices in the deployment of microservices?
Publishing and upgrading microservices: Updating and publishing a new microservice version is a significant challenge, developers have to be careful since a microservice may depend on many others [21]. In addition, service discovery is a challenging aspect affected by upgrading a new version of a microservice and deploying it [22].
Technologies and tools requiredfor building and deploying microservices: Developers make a great effort to adopt new tools and frameworks for each practice that they implement [23]. It is crucial to choose the right tools to protect the DevOps approach; otherwise, the rollback or tool change is very costly in time and effort [24]. Developers must perform careful initial configuration of the tools as this will allow correct automation [25]. Constant updates of libraries and tools make development and maintenance difficult.
Monitoring of a microservices architecture: The challenges that practitioners must face are the lack of commercial monitoring options, lack of standardization, and lack of faster learning curves [26]. What lessons does the literature report for successful microservices deployment? We grouped the lessons learned into two main topics: Solid architectural foundations and Attention to DevOps principles.
Solid architectural baseline: A long and scalable system requires a good architectural foundation that supports DevOps [27]. Every change in the architecture imposes new requirements on the delivery system and the implementation of new components and technologies [28]. Backward compatibility between microservices, separation of domains, and responsibilities for each service helps to prevent cross-configuration and keep services running smoothly.
Attention to DevOps principles: Applying DevOps principles in building CI/CD pipelines makes them leaner and more robust. Principles such as automation in all processes (integration, testing, deployment, analysis, and monitoring) are key to ensuring system reliability [29]. Good design and implementation of deployment pipelines allow rapid error detection [24]. Maintenance and updating of pipelines should take priority over code development. When problems arise, it is important to centralize error handling, in order to reduce the work of developers and operators. System monitoring should be flexible and scalable.
2.2.2 Gray literature review
We conducted a gray literature review to complement the mapping findings. For the review, we considered books, and electronic resources focused on the topics of DevOps, microservices deployment, and associated technologies. We searched the resources using the search engines Google Scholar, Google Books, and Google. We used these three since we aimed to have as much information as possible. In addition, we applied the snowballing method [30], which consists of searching for the material cited or referenced in the mapping articles. The steps carried out for the 66
selection of the resources were as follows: For the selection of books, the process consisted of reading the table of contents, and the chapters that corresponded to the deployment of microservices or some DevOps practice related to microservices. For the selection of electronic resources such as company blogs, standards, and technical documentation, we read the content to determine if it would be useful. We investigated each of the resources to answer the research questions formulated in the MSL, or at least to find information that contributes to the findings.
Once we identified the resources, we continued with the reading of the most relevant aspects. Following a process similar to the meta-aggregation method used in the mapping, we identified important ideas or findings, and classify them according to their type. Among the types identified are deployment patterns, principles, practices, advantages, and disadvantages of technologies and resources.
2.3 Design and Development
In the design and development phase, we performed a series of activities, these activities consisted of grouping and classifying the information obtained from the white and gray literature reviews. We focus on the implementation modeling process of a microservices architecture, aiming to provide an order to the set of tasks and activities that we identified in previous phases. Finally, using the modeling and the information obtained, we integrated the microservices deployment guide, which we structured according to the modeling phases, having as content the related activities in each phase.
2.4 Demonstration and Evaluation
The demonstration aims to use the artifact to solve one or more instances of the problem. To achieve it, the authors propose certain approaches such as experimentation, simulation, case study, or other appropriate activity. Once performed the demonstration is needed to observe and measure how well the artifact supports a solution to the problem. However, given the complexity, the amount of time, personnel, and resources involved in building a microservices architecture large enough to be applied as a case study, as well as the number of case studies that would be needed to have deterministic results, it was decided not to include this phase in the scope of this work. For the evaluation of the guide, we decided to use another approach and analyze the evaluation method that best suits our problem, so far, we are considering using the work of Garousi et al. [31] and focusing on the evaluation of quality for technical software documents, thus the application of the evaluation is planned as future work.
2.5 Communication
As a part of the communication phase, we communicated the importance of the problem through the paper publication Microservice Deployment: A Systematic Mapping Study [15]. For the artifact communication, its utility, and effectiveness we present the current paper, and we are developing a website to publish the guide so it could be accessible for the practitioners.
3. Proposed Deployment Guide
The guide works as a path where practitioners can identify their starting point and gradually adopt practices and strategies for microservices deployment. The guide includes practices, patterns [32], technologies, and tips found in the literature. The guide organizes possible decisions according to the phases of the microservices deployment process. Organizations interested in adopting the MSA can follow the guide, in this way, the person in charge of design or deployment can consult the practices and strategies recommended for each specific phase. The intention of showing the decisions in a modular way is that the managers can consult the parts they need, without the need to
read the whole guide, or if practitioners have already managed to adopt some practices, they can find additional information that allows them to improve their current process. We used SPEM 2.0 (Software & Systems Process Engineering Metamodel) for the modeling of the guide, it is a standard for defining software processes. SPEM uses the UML (Unified Modeling Language) notation, which provides components that allow the standardized representation of methods, life cycles, roles, activities, tasks, and work products used in Software Engineering. The main process consists of three phases. Each phase can have different iterations, an iteration is a set of activities performed iteratively, and each activity has one or many tasks needed to complete the activity. Due to the time involved in having a platform that supports the microservices architecture, practitioners can perform all these activities iteratively and incrementally as the project develops, thus adding value to the deployment process as the project and its needs grow. The first phase corresponds to the architectural design, separating the problem domain, identifying the required microservices, the communication style between them, and the deployment method for orchestrating the microservices. The second phase presents the preparation of the development environment for each microservice; the related activities in the construction; integration and delivery of each service; and finally, the strategies for delivery and observability of the microservices in the production environment. The third and last phase, covers microservice construction, following the design and platform created in the previous phases. The following is a description of the sections that make up the guide as well as the related activities and tasks.
3.1 Deployment design
This section of the guide covers the design and deployment planning iteration, which has four main activities for those responsible for the design and implementation of the system. Each activity has an output that serves as input for the next task, the first activity is the selection of the deployment strategy, followed by the selection of technologies, and finally, the last two activities, possibly executed in parallel, corresponding to the design of configurable services, and the design of observable services can.
The activities described in this section contain the following information: Name, Roles in charge, Description, List of identified methods or patterns, and Recommendations. Each identified pattern has the following properties: Characteristics, Advantages, Disadvantages, and Technology.
3.2 Configuration management and development environment
This section encompasses the Iteration Delivery Environment Preparation activity for the preparation of the deployment pipeline. This activity is very important since it is the basis that will allow the implementation of a deployment pipeline, the person in charge of the deployment has the task of implementing a set of practices and technologies that allow the control of the changes made in the service's code, as well as the automation of the processes for the construction of services. The activities implemented are the Implementation of version control, Establishment of development guidelines, Implementation of patterns for source code branch management, implementation of unit tests, and automation of the build and test processes.
3.3 Deployment pipeline
This section of the guide presents DevOps activities related to Continuous Integration and Continuous Delivery practices. The section incorporates two activities from the iteration phase of the deployment pipeline: the preparation of the built environment, and the preparation of the delivery environment. These activities are fundamental to constantly building and releasing microservices, a key aspect of successfully implementing MSA. The section features recommendations, technologies, and features for each task. The first activity corresponds to the practice of Continuous
Integration, this activity concerns the implementation of a continuous integration system; automation of the compilation process; implementation of unit and acceptance tenting; implementation of code analysis and generation of binaries; and packaging artifacts. The second activity, focused on the Continuous Delivery practice, concerns the tasks of environment configuration; implementation of smoke tests; implementation of manual tests; acceptance or performance tests; and deployment and release to a production environment.
3.4 Infrastructure management and System observability
This section presents the tasks that correspond to DevOps culture practices, such as Infrastructure as Code and GitOps. Here we present the description of these practices, the description of the existing technologies, as well as good practices found in the literature for their correct implementation. In addition, the last section presents the practices we found in the literature to achieve adequate observability of the services deployed in a production environment.
4. Conclusion and Future Work
This paper presented the current results of a project to build a deployment guide for applications with a microservices architectural style. To this end, we conducted a systematic mapping study to identify the practices, tools, technologies, activities, and recommendations used in microservices deployment, we also complemented the information found with a gray literature review. We integrated into the guide all the elements and models found.
As for future work, we plan to perform the evaluation phase of the DSRM methodology. This phase is for analyzing the guide and related artifacts, to know if they meet the intended objectives. To perform the evaluation of the guide we intend to use the work of Garousi et al. [31] for the evaluation of the use and quality of software technical documentation.
The present version of the artifact does not cover organizational aspects of the DevOps culture. To obtain the benefits of a DevOps culture, organizations not only have to adopt technologies and practices, but they also have to adopt an organizational and cultural base, driven by the highest levels of the organization. Therefore, as future work, the guide will incorporate the organization of effective teams for microservices deployment. In this way, the work would bring additional value to organizations and to all those who seek to adopt a DevOps culture.
References / Список литературы
[1] Mauro T. Adopting Microservices at Netflix: Lessons for Architectural Design. NGINX Blog, 2015. Available at: https://www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/, accessed May 10, 2021.
[2] Reinhold E. Rewriting Uber Engineering: The Opportunities Microservices Provide. Uber Engineering Blog. Available at: https://eng.uber.com/building-tincup-microservice-implementation/, accessed May 10, 2021.
[3] Ihde S., Parikh K. From a Monolith to Microservices + REST: the Evolution of Linkedln's Service Architecture. Mar. 2015. Available at: https://www.infoq.com/presentations/linkedin-microservices-urn/, accessed Mar. 22, 2022)
[4] Calcado P. Building Products at SoundCloud —Part I: Dealing with the Monolith. SoundCloud Backstage Blog, Jun. 11, 2014. Available at: https://developers.soundcloud.com/blog/building-products-at-soundcloud-part-1-dealing-with-the-monolith, accessed Mar. 22, 2022.
[5] Lewis J., Fowler M. Microservices. Mar. 25, 2014. Available at: https://martinfowler.com/articles/microservices.html, accessed Nov. 16, 2021.
[6] Martin R.C. The Single Responsibility Principle. Clean Coder Blog, May 08, 2014. Available at: https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html, accessed Jan. 26, 2022.
[7] Newman S. Building Microservices: Designing Fine-Grained Systems. O'Reilly Media, 2015, 280 p.
[S] lndrasiri K., Siriwardena P. Microservices for the Enterprise: Designing, Developing, and Deploying. Apress, 201S, 441 p.
[9] lEEE Standard for DevOps: Building Reliable and Secure Systems lncluding Application Build, Package, and Deployment: lEEE Standard 2675-2021.
[10] Richardson C. Microservices Patterns: with examples in Java. Manning, 201S, 520 p.
[11] Fritzsch J., Bogner J. et al. Microservices Migration in lndustry: lntentions, Strategies, and Challenges. ln Proc. of the lEEE lnternational Conference on Software Maintenance and Evolution (lCSME), 2019, pp. 4S1-490.
[12] Bruce M., Pereira P.A. Microservices in action. Manning, 201S, 392 p.
[13] Shahin M., Ali Babar M., Zhu L. Continuous lntegration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices. lEEE Access, vol. 5, 2017, pp. 3909-3943.
[14] Peffers K., Tuunanen T. et al. A Design Science Research Methodology for lnformation Systems Research. Journal of Management lnformation Systems, vol. 24, issue 3, 2007, pp. 45-77.
[15] Niño-Martínez V.M., Ocharán-Hernández J.O. et al. Microservices Deployment: A Systematic Mapping Study. ln Proc. of the 9th lnternational Conference in Software Engineering Research and lnnovation (CONISOFT), 2021, pp. 24-33.
[16] Hyvärinen H., Risius M., Friis G. A Blockchain-Based Approach Towards Overcoming Financial Fraud in Public Sector Services. Business & Information Systems Engineering, vol. 59, issue 6, 2017, pp. 441456.
[17] Tello-Rodríguez M., Ocharán-Hernández J.O. et al. A Design Guide for Usable Web APIs. Programming and Computer Software, vol. 46, issue S, 2020, pp. 5S4-593 / Тельо-Родригес M., Очаран-Эрнандес Х.О., Перес-Арриага Х.К., Лимон К., Санчес-Гарсия А.Х. Путеводитель по проектированию удобных Web-API. Труды ИСП РАН, том 33, вып. 1, 2021 г., стр. 173-1SS. DOl: 10.15514/lSPRAS-2021-33(1)-12.
[1S] Chen L. Continuous Delivery: Overcoming adoption challenges. Journal of Systems and Software, vol. 12S, 2017, pp. 72-S6.
[19] Kitchenham B., Budgen D., Brereton P. Evidence-Based Software Engineering and Systematic Reviews. Chapman and Hall/CRC, 2015, 399 p.
[20] Pearson A., Robertson-Malt S., Rittenmeyer L. Synthesizing Qualitative Evidence. Lippincott Williams & Wilkins, 2011, S0 p.
[21] Kargar M.J., Hanifizade A. Automation of regression test in microservice architecture. ln Proc. of the International Conference on Web Research (1CWR), 201S, pp. 133-137.
[22] Singh V., Peddoju S.K. Container-based microservice architecture for cloud applications. ln Proc. of the International Conference on Computing, Communication and Automation (ICCCA), 2017, pp. S47-S52.
[23] Richter D., Konrad M. et al. Highly-Available Applications on Unreliable Infrastructure: Microservice Architectures in Practice. ln Proc. of the lEEE lnternational Conference on Software Quality, Reliability and Security Companion (QRS-C), 2017, pp. 130-137.
[24] Soenen T., Van Rossem S. et al. Insights from SONATA: Implementing and integrating a microservice-based NFV service platform with a DevOps methodology. ln Proc. of the 1EEE/IFIP Network Operations and Management Symposium, 201S, pp. 1-6.
[25] Fan C.Y., Ma S.P. Migrating Monolithic Mobile Application to Microservice Architecture: An Experiment Report. ln Proc. of the lEEE lnternational Conference on Al & Mobile Services (AlMS), 2017, pp. 109-112.
[26] Tamburri D.A., Miglierina M., Di Nitto E. Cloud applications monitoring: An industrial study. lnformation and Software Technology, vol. 127, 2020, article no. 106376, 2S p.
[27] Chen H.M., Kazman R. et al. Architectural Support for DevOps in a Neo-Metropolis BDaaS Platform. ln Proc. of the lEEE 34th Symposium on Reliable Distributed Systems Workshop (SRDSW), 2015, pp. 2530.
[2S] Steffens A., Lichter H., Döring J.S. Designing a next-generation continuous software delivery system: Concepts and architecture. ln Proc. of the 4th lnternational Workshop on Rapid Continuous Software Engineering, 201S, pp. 1-7.
[29] Hasselbring W., Steinacker G. Microservice architectures for scalability, agility and reliability in ecommerce. lEEE lnternational Conference on Software Architecture Workshops (ICSAW), 2017, pp. 243246.
[30] Wohlin C. Guidelines for snowballing in systematic literature studies and a replication in software engineering, ln Proceedings of the lSth lnternational Conference on Evaluation and Assessment in Software Engineering, 2014, article no. 3S, 10 p.
[31] Garousi G., Garousi V. et al. Evaluating Usage and Quality of Technical Software Documentation: An Empirical Study. In Proc. of the 17th International Conference on Evaluation and Assessment in Software Engineering, 2013, pp. 24-35.
[32] Valdivia J.A., Lora-González A. et al. Patterns related to microservice architecture: a multivocal literature review. Programming and Computer Software, vol. 46, issue 8, 2020, pp. 594-608 / Вальдивия Х.А., Лора-Гонсалес А. и др. Паттерны микросервисной архитектуры: многопрофильный обзор литературы. Труды ИСП РАН, том 33, вып. 1, 2021 г., стр. 81-96. DOI: 10.15514/ISPRAS-2021-33(1)-4.
Information about authors / Информация об авторах
Victor M. NIÑO-MARTÍNEZ, Software Engineer Student. Research interests: Software Engineering, Software Architecture, and DevOps.
Виктор М. НИНЬО-МАРТИНЕС, студент-программист. Область научных интересов: разработка программного обеспечения, архитектура программного обеспечения и DevOps. Jorge Octavio OCHARÁN-HERNANDEZ, Doctor in Computing Sciences, Professor at the School of Statistics and Informatics. Research interests: software engineering, software architecture, requirements engineering, API design
Хорхе Октавио ОЧАРАН-ЭРНАНДЕС, кандидат компьютерных наук, профессор факультета статистики и информатики. Область научных интересов: разработка программного обеспечения, архитектура программного обеспечения, разработка требований, разработкаAPI.
Xavier LIMÓN, Doctor of Artificial Intelligence, Associate Professor of the Statistics and Informatics Faculty. Research interests: Distributed Systems, Software Architectures, Multi-agent systems, Machine Learning.
Ксавье ЛИМОН, кандидат наук в области искусственного интеллекта, доцент факультета статистики и информатики. Область научных интересов: распределенные системы, архитектуры программного обеспечения, многоагентные системы, машинное обучение.
Juan Carlos PÉREZ-ARRIAGA, Master in Computer Science, Software Developer. Research interests include software architecture, software engineering, software metrics, software tools, software quality.
Хуан Карлос ПЕРЕС-АРРИАГА, магистр компьютерных наук, разработчик программного обеспечения. Область научных интересов: архитектура программного обеспечения, инженерия программного обеспечения, показатели программного обеспечения, программные инструменты, качество программного обеспечения.
