Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Investigating practices and challenges in microservice-based development Wang, Yingying 2019

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Notice for Google Chrome users:
If you are having trouble viewing or searching the PDF with Google Chrome, please download it here instead.

Item Metadata


24-ubc_2019_may_wang_yingying.pdf [ 446.19kB ]
JSON: 24-1.0378158.json
JSON-LD: 24-1.0378158-ld.json
RDF/XML (Pretty): 24-1.0378158-rdf.xml
RDF/JSON: 24-1.0378158-rdf.json
Turtle: 24-1.0378158-turtle.txt
N-Triples: 24-1.0378158-rdf-ntriples.txt
Original Record: 24-1.0378158-source.json
Full Text

Full Text

Investigating Practices and Challenges inMicroservice-Based DevelopmentbyYingying WangB.SE., Dalian University of Technology, China, 2015A THESIS SUBMITTED IN PARTIAL FULFILLMENTOF THE REQUIREMENTS FOR THE DEGREE OFMASTER OF APPLIED SCIENCEinTHE FACULTY OF GRADUATE AND POSTDOCTORALSTUDIES(Electrical and Computer Engineering)The University of British Columbia(Vancouver)April 2019© Yingying Wang, 2019The following individuals certify that they have read, and recommend to the Facultyof Graduate and Postdoctoral Studies for acceptance, a thesis/dissertation entitled:INVESTIGATING PRACTICES AND CHALLENGES IN MICROSERVICE-BASED DEVELOPMENTsubmitted by YINGYING WANG in partial fulfillment of the require-ments forthe degree of MASTER OF APPLIED SCIENCEin ELECTRICAL AND COMPUTER ENGINEERINGExamining Committee:JULIA RUBIN, ELECTRICAL AND COMPUTER ENGINEERINGSupervisorPHILIPPE KRUCHTEN, ELECTRICAL AND COMPUTER ENGINEERINGSupervisory Committee MemberKONSTANTIN BEZNOSOV, ELECTRICAL AND COMPUTER ENGINEERINGSupervisory Committee MemberAdditional Supervisory Committee Members:Supervisory Committee MemberSupervisory Committee MemberiiAbstractMicroservice-based architecture is a principle inspired by service-oriented ap-proaches for building complex systems as a composition of small, loosely coupledcomponents that communicate with each other using language-agnostic APIs. Thisarchitectural principle is now becoming increasingly popular in industry due to itsadvantages, such as greater software development agility and improved scalabilityof deployed applications.In this thesis, we report on a broad interview study we conducted, whichinvolved practitioners developing microservice-based applications for commercialuse for at least two years. By deliberately excluding “newcomers” and focusingthe study on “mature” teams, our goal was to collect best practices, lessons learned,and technical challenges practitioners face.Our study helps inform researchers of challenges in developing microservice-based applications, which can inspire novel software engineering methods andtechniques. The study also benefits practitioners who are interested to learn fromeach other, to borrow successful ideas, and to avoid common mistakes.iiiLay SummaryIn traditional software development processes, relatively large teams work on asingle, monolithic deployment artifact. However, such monolithic applications canevolve into a “big ball of mud”. For better scalability and development agility,practitioners start developing complex applications as a set of loosely coupled com-ponents that communicate with each other through lightweight interfaces. Such anapproach is referred to as microservice-based development and is now becomingincreasingly popular in the industry. In this thesis, we report on the results of aninterview study we conducted with industrial practitioners developing successfulmicroservice-based applications. The goal of the study is to understand the bestpractices, lessons learned, and challenges in microservice-based development. Ourstudy helps inform researchers about challenges in microservice-based develop-ment and share thoughts on possible future directions. The study also benefitspractitioners who are interested to learn from each other, to borrow successfulideas, and to avoid common mistakes when using microservices.ivPrefaceThis thesis is an original intellectual product of its author, Yingying Wang, done incollaboration with Harshavardhan Kadiyala, under the supervision of Prof. JuliaRubin. This work is covered by UBC Behavioural Research Ethics Board Number:H18-00733.Part of the work was presented as an invited talk at a Vancouver MicroservicesMeetup event, attended by around 50 practitioners. This work was also presentedat a workshop of the 28th Annual International Conference on Computer Scienceand Software Engineering (CASCON’18).vTable of ContentsAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiiLay Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivPreface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vTable of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viList of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixList of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xList of Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiAcknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiDedication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Findings Summary . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Novelty and Contribution . . . . . . . . . . . . . . . . . . . . . . 51.4 Structure of This Thesis . . . . . . . . . . . . . . . . . . . . . . . 62 Background and Related Work . . . . . . . . . . . . . . . . . . . . . 7vi2.1 Microservices and Their Characteristics . . . . . . . . . . . . . . 72.2 Claimed Advantages of Microservices . . . . . . . . . . . . . . . 92.3 Microservices vs. Collaborative Software Development . . . . . . 102.4 Existing Studies on Microservice-Based Development . . . . . . . 102.4.1 Exploratory Studies . . . . . . . . . . . . . . . . . . . . . 112.4.2 Literature Surveys . . . . . . . . . . . . . . . . . . . . . . 133 Study Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.1 Subjects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3 Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4 Ethical Considerations . . . . . . . . . . . . . . . . . . . . . . . 213.5 Threats to Validity . . . . . . . . . . . . . . . . . . . . . . . . . . 223.5.1 External Validity . . . . . . . . . . . . . . . . . . . . . . 223.5.2 Internal Validity . . . . . . . . . . . . . . . . . . . . . . . 223.5.3 Construct Validity . . . . . . . . . . . . . . . . . . . . . . 234 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.1 Microservice Granularity . . . . . . . . . . . . . . . . . . . . . . 244.2 Microservice Ownership . . . . . . . . . . . . . . . . . . . . . . 264.3 Language Diversity . . . . . . . . . . . . . . . . . . . . . . . . . 275 Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.1 Logging and Monitoring . . . . . . . . . . . . . . . . . . . . . . 295.2 Distributed Tracing . . . . . . . . . . . . . . . . . . . . . . . . . 305.3 Automating Processes . . . . . . . . . . . . . . . . . . . . . . . . 315.4 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 Code Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.1 Common Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.2 Managing API Changes . . . . . . . . . . . . . . . . . . . . . . . 356.3 Managing Variants . . . . . . . . . . . . . . . . . . . . . . . . . 37vii7 Discussion and Future Work . . . . . . . . . . . . . . . . . . . . . . 408 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45viiiList of TablesTable 3.1 Interviewee Demographics . . . . . . . . . . . . . . . . . . . . 17Table 3.2 Concept Frequency . . . . . . . . . . . . . . . . . . . . . . . . 20Table 4.1 Microservice Granularity . . . . . . . . . . . . . . . . . . . . 24Table 6.1 Common Code . . . . . . . . . . . . . . . . . . . . . . . . . . 34Table 6.2 Managing API Changes . . . . . . . . . . . . . . . . . . . . . 36Table 6.3 Managing Variants . . . . . . . . . . . . . . . . . . . . . . . . 38ixList of FiguresFigure 1.1 Popularity of Searches for the Term “Microservices” (GoogleTrends [62], March 2019) . . . . . . . . . . . . . . . . . . . 2Figure 3.1 Data Collection and Analysis Process . . . . . . . . . . . . . 18Figure 3.2 Mapping of Categories to Concepts . . . . . . . . . . . . . . 19xList of AcronymsACM Association for Computing MachineryAPI Application Program InterfaceBREB Behavioural Research Ethics BoardCD Continuous DeliveryCI Continuous IntegrationCPU Central Processing UnitDevOps Development and OperationDRY Do Not Repeat YourselfgRPC gRPC Remote Procedure CallsHTTP HyperText Transfer ProtocolIoT Internet of ThingsJAR Java ArchiveMASc Master of Applied ScienceREB Research Ethics BoardREST Representational State TransferxiRPC Remote Procedure CallSaaS Software as a ServiceSIGSOFT The Association for Computing Machinery’s Special Interest Groupon Software EngineeringSOA Service-Oriented ArchitectureUBC University of British ColumbiaxiiAcknowledgementsFirst I would like to thank all study participants for volunteering their time toparticipate in the study and sharing their experience with us. Their help and timeare much appreciated.Back to my overall master studies, I would like to express my sincere gratitudeto my supervisor, Professor Julia Rubin, for introducing me the research world,moreover, patiently supporting, guiding, and encouraging me along my studies. Ienjoy the venture a lot and look forward to continuing the expedition in the researchworld under her excellent supervision.Next, I would like to thank my committee members, Professor Philippe Kruchtenand Professor Konstantin Beznosov, for reviewing my thesis and providing con-structive comments. I also would like to thank Professor Mieszko Lis for hisinsightful feedback on shaping my defence presentation.I also want to thank my collaborator, Harshavardhan Kadiyala, as well asall my (previous and current) labmates from ReSeSS research group for all theinspiring discussions we had, their insightful feedback on my presentations, andthe invaluable support during my defence.Special thanks to my friends Sirou Zhuo, Xinwen Zhang, Lina Qiu, and WendyMa for taking care of me during the hectic deadlines, leaving a light on for meduring my late nights, and borrowing an ear for me all the time.Last but not least, I would like to express my deepest gratefulness to my parentsfor their unconditional and continuing understanding, support, and encouragement,closely and remotely, along the journey.xiiiDedicationTo my beloved parents致我亲爱的父母xivChapter 1Introduction1.1 OverviewService-oriented architecture (SOA) is an architectural approach to designingapplications around a collection of independent services. A service can be anybusiness functionality that completes an action and provides a specific result, suchas processing a customer order or compiling an inventory report. Services can bestitched together to create composite applications, providing greater functionalityto end users [48]. Service-orientation concept had received a lot of attention in early2000s [17], but lost momentum in 2009. Since 2014, the interest in service-orientedparadigms was renewed under the microservices moniker (see Figure 1.1).The term microservice was coined at a workshop of software architects nearVenice in May 2011 [65]. It described what the participants saw as a commonarchitectural style that many of them had been exploring. Yet, microservice-basedarchitecture became really popular around 2014, when Lewis and Fowler publishedtheir blog on the topic [33] and Netflix shared their expertise and lessons learnedfrom a successful transition to microservices at a Silicon Valley MicroservicesMeetup event [42]. In 2015, researchers from Gartner [32] found that 68% of orga-nizations implementing or actively investigating transition to microservices [28].Gartner also ranked microservice-based architecture as one of the top 10 strate-1Figure 1.1: Popularity of Searches for the Term “Microservices” (GoogleTrends [62], March 2019)gic technology trends for 2016, which were predicted to shape opportunities indigital business through 2020 [67]. In 2018, DZone [16], a programming andDevOps community, conducted an internal survey, which received 732 replies;nearly 50% of respondents stated that they are using microservices, and another38.7% are considering microservices [25]. The Jakarta EE 2018 survey, covering1,805 participants, reported that nearly 46% of respondents are now using microser-vices, and another 21% plan to start using microservices within one year [44].In another survey of 354 enterprises across 51 countries and 12 industries [13],63% of companies surveyed are currently using microservice-based architectures.“Famous” adopters of microservice-based architectures include Amazon, IBM,Uber, LinkedIn, Groupon, and eBay [56].At the core of microservice-based architecture is the SOA-inspired principleof building complex applications as a composition of small, loosely coupledcomponents that encapsulate individual business capabilities and communicate witheach other using language-agnostic APIs. The current popularity of microservicescan possibly be explained by a combination of several factors:2• Agile software development: Agile movement promotes frequent softwarereleases, performed by small, independent teams. However, under the “tradi-tional” software development model, teams need to synchronize on commonproduct release dates. Microservice-based architecture helps reduce cross-team coordination, allowing each team to independently deploy changes toproduction at the time appropriate for them. In a sense, it takes the alreadypopular agile development paradigm to the next level of flexibility, providingthe “architectural phase of the agile progression” [41].• Cloud: Software hosted on a cloud, a.k.a. Software as a Service (SaaS), hasbecome a popular method of software delivery. A survey involving 2,151Java Virtual Machine developers and IT professionals from Lightbend [37]reported that 31% of developers are already running most of their appli-cations in the cloud and 29% are in the process of creating a cloud-nativestrategy. The flexible pay-as-you-go offering allows developers and compa-nies to dynamically increase the number of machines when the applicationis “busy” and decrease when it is used less. Breaking large applicationsinto microservices further supports this goal because of the ability to spinup more instances of the specific “busy” microservices when needed, ratherthan scale up the entire application. Such support is ideal to further decreasethe operation costs.• Tools: The elasticity of microservices is further amplified by the availabilityof open-source tools, such as Docker container [31], which makes it possibleto deploy and duplicate each individual microservice; Prometheus [7] andGrafana [3], which provide monitoring, alerting, and visualization frame-work for analyzing the running microservices; and Kubernetes cluster man-ager [20], which facilitates automated deployment, scaling, and managementof microservices. For many organizations, availability of these tools enables(or substantially simplifies) the transition to microservices.Yet, just “jumping on the microservices trend”, expecting that the transition3itself will allow a company to achieve improvements similar to those reported byAmazon and Netflix, is a false belief [47]. “Proper” adoption of microservicesrequires several technical and organizational changes companies need to consider.The goal of this research is thus to investigate best practices, lessons learned, andcurrent challenges in employing microservice-based architectures in industry.To achieve this goal, we conducted a broad interview study, which involvedpractitioners developing microservice-based applications for several years in suc-cessful industrial companies. By deliberately excluding microservice newcomersand focusing the study on “mature” teams, we believe our work benefits practi-tioners who are interested to learn from each other, to borrow successful ideas,and to avoid common mistakes. The work also informs researchers of challengesin developing microservice-based applications, which can inspire novel softwareengineering methods and techniques.1.2 Findings SummaryIn a nutshell, our participants learned that following the “standard” advice of split-ting microservices based on business capabilities and using the most appropriateprogramming language for each microservice is not always fruitful. While theystarted with such an approach, they later had to redefine and merge microservices,e.g., because the resulting product consumed an unacceptable amount of computingresources, and also restrict the number of languages that they use, e.g.. because theend product was difficult to maintain.They also learned that an early investment in a robust infrastructure to supportautomated setup and management, extensive logging and monitoring, tracing, andmore, are some of the main factors contributing to the success of their developmentprocesses. Several practitioners indicated that while in practice they delayed settingup a solid infrastructure, they regretted such decisions in the future. They foundthat having a well-defined owner for each microservice is essential for the successof their development process, as this owner is the one to ensure the architecturalintegrity of the microservice, be the first to efficiently troubleshoot the microservice,4etc.Our study also identifies several common challenges related to managingcode of microservices, where no explicit guidelines are available as part of themicroservices “cookbooks”. These include decisions on how to deal with codeshared by several microservices, e.g., for authentication and logging, how tomanage products consisting of multiple customer offerings, and more. Eventhough solutions to these challenges might exist in the software engineering fieldin general, they are still to be studied and adapted in the particular context ofmicroservices. Our study lists different possible solutions applied by the studiedcompanies and discusses the trade-offs related to each solution.1.3 Novelty and ContributionIn the past few years, several studies focused on the process of transitioning tomicroservices [61, 22, 27, 12, 9, 10, 24, 64]. These studies identified a numberof challenges related to the transition, such as difficulties around identifying thedesired service boundaries, costs involved in setting up the infrastructure to de-ploy and monitor microservices, and the need for skilled developers to design,implement, and maintain a large distributed system.In our work, rather than focusing on the transition to microservices, we investi-gate the experience of companies that have been successfully running microservicesfor several years. Specifically, we focus on fully operational development teams ofcompanies serving the needs of their commercial customers by using microservice-based solutions.We report on best practices, lessons learned, and trade-offs we collected byconducting 21 semi-structured interviews with participants from their subjectcompanies. All of the study participants are experienced software developers, with12 years of experience on average, and all have at least two years of experiencedeveloping microservice-based applications (see Table 3.1).Our study can benefit industrial practitioners who develop such applicationsand are interested to learn from each other, to borrow successful ideas, and to5avoid common mistakes. Moreover, a description of current practices and chal-lenges practitioners face can inspire researchers and tool builders in devising novelsoftware engineering methods and techniques.To summarize, this work makes the following contributions:• It outlines the state-of-the-art in developing microservices, as described inthe literature (Chapter 2);• It describes the main characteristics of microservice-based applications andoutlines the rationale for using microservices (Chapter 2);• It identifies best practices, lessons learned, and challenges in developingmicroservices, as viewed by our study participants, in terms of architecturalconsiderations (Chapter 4), infrastructure support (Chapter 5), and codemanagement (Chapter 6);• It discusses the findings and outlines possible next steps for both researchersand practitioners (Chapter 7).1.4 Structure of This ThesisThe thesis is structured as follows:• Chapter 2 introduces the concept of microservices, describes their main ad-vantages, and reviews the related studies of microservice-based developmentpractices;• Chapter 3 describes the methodology of the study;• Chapter 4, 5, and 6 report the best practices, lessons learned, and challengesin developing microservices, as viewed by our study participants;• Chapter 7 discusses the findings of the study and possible future directionsfor microservice-based development;• Chapter 8 summarizes and concludes the study.6Chapter 2Background and Related WorkIn this chapter, we provide a brief introduction to microservices, outline theirpromises, and then discuss the related studies of microservice-based developmentpractices.2.1 Microservices and Their CharacteristicsA microservice-based approach promotes building a single application as a suite of(micro-)services1 which run in separate processes and can be deployed and scaledindependently [33]. Microservices communicate with each other – synchronouslyor asynchronously – via lightweight language-agnostic protocols, such as HTTPREST [18]. The services are split following business capabilities. Each service hasa fully automated pipeline and is independently deployable [33].As discussed by Lewis and Fowler [33], a typical microservice-based architec-ture has the following characteristics:• Componentization via services. A component is defined as a softwareunit that is independently replaceable and upgradeable. In microservice-based architectures, the primary way of componentizing the software is bybreaking it down into services. Moreover, microservice practitioners usually1We use service and microservice interchangeably.7see service decomposition as a further tool to enable application developersto control changes in their application without slowing down a change.• Smart endpoints and dumb pipes. Applications built from microservicesaim to be as decoupled and as cohesive as possible – they own their domainlogic, receive a request, apply logic as appropriate, and produce a response.The two protocols used most commonly are HTTP REST and lightweightmessaging (e.g., RabbitMQ [51]).• Decentralized data management. This includes decentralizing decisionsabout conceptual models and data storage decisions. Distributed transactionsare difficult to implement and as a consequence, microservice has explicitrecognition that consistency may only be eventual consistency.• Design for failure. Applications need to be designed to tolerate servicefailures. Any service call could fail due to unavailability of the supplier andthe client has to respond to this as gracefully as possible. Moreover, it isimportant to be able to detect the failures quickly and automatically restoreservices.• Infrastructure automation. Infrastructure automation techniques, includ-ing continuous integration (CI) and continuous delivery (CD) are used toreduce the operational complexity of building, deploying, and operatingmicroservices.• Teams organized around business capabilities. Teams developing micro-service-based applications are generally cross-functional and organizedaround business capabilities.• Products not projects. A team owns the software/product over its fulllifetime, rather than looking at the software as a set of functionalities to becompleted.8• Decentralized governance. Rather than using organizational-level guide-lines, teams can choose the languages and tools that work best for thefunctionality they want to implement.2.2 Claimed Advantages of MicroservicesIn this section, we discuss advantages of microservices from two aspects: technicaland organizational.Technical. Microservices aim at shortening the development lifecycle while im-proving the quality, availability, and scalability of applications at runtime. Fromthe development perspective, cutting one big application into small independentpieces reinforces the component abstraction, and makes it easier for the system tomaintain clear boundaries between components [21]. Developers are able to reasonabout the system without people having the opportunity to break abstractions. Inmonolithic application development, developers might “take shortcuts” and accesscode at the wrong layers, while in microservices, APIs specified in the servicecontract are the only channel for other teams to access the service.Moreover, as different microservices can be developed using different lan-guages, frameworks, and tools, developers have the freedom to choose languagesthat work best for the functionality to implement and also easily experiment withnew technology stacks on a small piece of the system, before migrating the wholeapplication.At runtime, microservices can be individually scaled by adding more instancesof only those microservices that experience increasing traffic. Moreover, while asmall change in part of the monolithic application could cause the whole deploy-ment to fail, single defective microservice would not crash the entire application,as long as the service is resilient.Organizational. Independent deployment reduces communication and coordina-tion effort needed to align on common delivery cycles. In monolith, teams haveto release everything at once, whereas microservices can be deployed in different9speed, following different timetables. The release of one microservice would notget blocked by unfinished work in another microservice. Moreover, the failuredomains of microservices are rather independent; if one microservice failed, onlythe specific team responsible for the microservice need to be notified.Developers can also focus on small parts of an application, without the needto reason about the complex dependencies and large code base. This is especiallybeneficial for junior developers and for onboarding new team members. Dealingwith legacy software also becomes easier. As the application is broken down intosmaller, replaceable pieces, they become easier to understand and upgrade.2.3 Microservices vs. Collaborative SoftwareDevelopmentMicroservice-based systems add additional complexity to “typical” collabora-tive software development. These systems are distributed, their components areloosely-coupled and communicate over the network, and are composed at runtime.Therefore, tracing the interaction between the components, identifying inter-servicefaults, and monitoring the behaviour of the entire system are more difficult.Moreover, such systems consist of multiple independent executables, allowingthe flexibility of adding new components to the system and requiring setting up thedevelopment pipeline and workflow for each such component. Thus, automation isespecially important to reduce operation cost.These properties of microservices complicate development and call for softwaredevelopment tools and practices uniquely suitable to support microservice-basedengineering, which we investigate in this thesis.2.4 Existing Studies on Microservice-BasedDevelopmentWe divide the discussion of related work on microservice-based development intoexploratory studies and literature surveys. Overall, most existing studies focused10on the process of migration to microservices. In contrast, we collected experiences,challenges, and lessons learned by organizations in the post-migration phase. Wealso included companies that did not perform any migration but built their systemsusing a microservice-based architecture from the start.2.4.1 Exploratory StudiesThe closest to ours is the study of Taibi et al., [61] who surveyed 21 practitionersfrom industry who adopted a microservice-based architecture style for at leasttwo years. The goal of that survey was to analyze the motivation as well as prosand cons of migration from monolithic to microservice-based architectures. Theauthors found that maintainability and scalability were ranked as the most importantmotivations, that the return on investment in the transition is not immediate, andthat the reduced maintenance effort in the long run is considered to compensatefor non-immediate return on investment. Unlike that work, our study does notfocus on the migration process. We also conducted in-depth interviews rather thanstructured surveys, which allowed us to identify and discuss challenges in a higherlevel of technical detail.Like Taibi et al., Francesco et al. [22] also investigated the practices andchallenges in migration to microservices. The authors did that by conducting fiveinterviews and then followed up with a questionnaire. Similar to our study, theyalso observed that finding a proper service granularity and setting up an initialinfrastructure for microservices, are some of the challenges that the developersface. Again, while that study only focused on the initial stages of a transitionto microservices, our work covered organizations in advanced adoption stages.Performing in-depth interviews with a substantially higher number of practitionersin post-migration stages led us to discover additional challenges not mentioned inearlier work, e.g., the need to redefine service granularity in resource-constrainedenvironments, issues related to variant and common code management, handlingAPI updates, and more.Zhou et al. [68] focused particularly on fault analysis and debugging of mi-11croservices. The authors interviewed 16 practitioners from 12 companies, investi-gating the fault cases these practitioners encountered in their microservice-basedsystems, their debugging practices, and practical challenges they faced when debug-ging microservices. The authors further created a benchmark microservice-basedsystem and replicated all fault cases extracted from the interviews. Then, theauthors evaluated the effectiveness of current debugging practices via an empiricalstudy. This study particularly focused on the debugging aspect of microservices,while our study is more general and it investigates practices and challenges in thedevelopment, management, and maintenance of microservices.Gouigoux et al. [27] described the lessons learned during migration frommonolith to microservices in a French company named MGDIS SA. The studyfocused on how the company determined a suitable granularity of services, andtheir deployment and orchestration strategies. Rather than one case study, wecollect practices and challenges of multiple companies developing different typesof applications. Moreover, apart from collecting the list of challenges, we makeextra efforts enumerating and comparing all emerged alternative solutions for eachsuch challenge, to help practitioners and researchers get a better view of currentoptions for addressing the challenges.Likewise, Bucchiarone et al. [12] reported on experience transitioning frommonolith to microservices in Danske Bank, showing that such transition improvedscalability. Similarly, Luz et al. [40] shared their observations on the transitionprocess of three Brazilian Government Institutions. The findings were cross-validated by surveying 13 practitioners in the studied institutions. The authorsfound that the lack of understanding on how to decompose a monolithic system intoa service and how to evaluate quality properties of a microservice are commonlyperceived as challenges in transition process. Balalaie et al. [9] also described themigration of a commercial mobile backend application to microservices, focusingon DevOps adoption practices that enabled a smooth transition for the company.Our study does not focus on the migration phase, collects best practices andchallenges from multiple companies successfully completing the migration, and12discusses development challenges in a greater level of detail.Balalaie et al. [10] reported on a set of migration and rearchitecting designpatterns that the authors empirically identified and collected from industrial-scalesoftware migration projects, such as decomposing monolith based on data owner-ship, transforming code-level dependency to service-level dependency, introducinginternal and external load balancers, and more. The authors also presented threeindependent industrial case-studies, in which they observed the recurrence of theproposed pattern, demonstrating the practical value of these patterns.Viggiato at al. [63] collected the general characteristics, advantages, and chal-lenges of microservice-based development from literature and online posts. Theauthors then conducted an online survey to confirm, in practice, if practitionersdeveloping microservices agree with the literature information. Similarly, Ghofraniand Lübke [24] also conducted an online survey with 25 practitioners who an-swered five questions related to goals and challenges in developing microservices,notations used by practitioner to describe microservices, and concerns practitionershave with using third-party libraries in their project. Our study has a broader scope;its comprehensive and open-ended nature not only allows us to discover issues notobserved by previous work, but also sheds light on concerns of organizations ofdifferent type and size.Razavian and Lago [53] explored migration activities when transitioning toSOA. The authors identified high-level activities, such as code analysis, architec-tural recovery, and business model recovery, and traced these activities to practicesdeveloped by the academic community. Our study focuses on more fine-graineddevelopment activities and investigates challenges specific to management of mi-croservices.2.4.2 Literature SurveysPahl and Jamshidi [50] and Francesco et al. [23] performed systematic mappingstudies aiming to classify research approaches to architecting microservices andproposed classification framework for categorizing, comparing, and evaluating13research work on microservices architectural solutions, methods, and techniques.Both work stated the demand for empirical studies involving practitioners to betterunderstand the state of the practice on microservices, and our work serves suchneed.Dragoni et al. [15] reviewed the history of software architecture, discussedcharacteristics of microservices, and outlined future challenges. The survey pri-marily addressed newcomers to the discipline and did not ground the discussion onany particular case study or experience.Alshuqayran et al. [1] conducted a mapping study for identifying architecturalchallenges, popular microservice architectural diagram types, and quality measure-ment in microservices architectures mentioned in the literature. Vural et al. [64]also undertook a systematic mapping study aiming to find out current trends aroundmicroservices, the motivation behind microservices research, emerging standards,and the possible research gaps. Our work is orthogonal to that as we focus onidentifying challenges of adopting microservices in industry rather than surveyingthe state-of-the-art in research.14Chapter 3Study MethodologyThis chapter describes our study methodology: the selection of subjects, theapproach to data collection and analysis, and threats to the validity of the work.3.1 SubjectsTo gain a better understanding of current practices and challenges of microservice-based development, we recruited software developers with solid experience devel-oping microservice-based applications. More precisely, our selection criteria werefor participants who:1. Have more than two years hands-on experience using microservice-basedarchitecture in industry.2. Are a member of a team that designs, develops, and deploys microservicesfor commercial use for at least two years.3. Are familiar with processes and ways of interacting with other teams workingon the same product.Such selection criteria ensure that the interviewees are experienced developersfrom organizations that use microservices in a mature way.For identifying the participants, we initially approached our network of collab-orators and colleagues. We also reached out to developers who actively participate15in various microservice-related events and meetup groups [43]. In addition, weused the LinkedIn web platform [38] to recruit developers listing microservices astheir core skills and holding active software development positions. Finally, weapplied snowballing [26], asking the interviewees to distribute a call for participa-tion in their professional networks. We interviewed each participant and stoppedrecruiting new participants when we reached data saturation [8]: we did not hearnew concerns in the last five interviews.As the result of this process, we interviewed 21 practitioners from 15 companies.Most participants hold a title of Software Engineer or Developer, Senior or PrincipalSoftware Engineer, or Software Architect. They have between 2.5 and 22 years offull-time software development experience, with a mean of 12.4 and a median of 12years. In the microservices domain, the participants have between 2 and 10 yearsof development experience, with a mean of 3.7 and a median of 3 years. They arecurrently employed in teams that are practicing microservice-based developmentbetween 2 and 15 years, with a mean of 4.6 and a median of 4 years. Notably,some of the teams developed microservice-style systems long before the term wasintroduced and popularized.The size of the teams ranges between 4 and 20 members, with a mean of 9.2 anda median of 8.5 members. The teams are responsible for 4 to 50 microservices, witha mean of 16.6 and a median of 15 microservices. They develop human resourcesapplications, retail and social media portals, enterprise resource management andcloud resource management applications, cloud infrastructure management andIoT management applications, and more. Table 3.1 also presents demographicinformation about the participants. Their ages range between 25 and 47 years, witha mean of 35.3 and a median of 35 years. One participant holds a PhD degree,four hold a Master’s level degree, and 14 hold a Bachelor’s level degree. Oneparticipant, with 20 years of experience, is entirely self-taught.16Table 3.1: Interviewee DemographicsItem ValueIndustrial Experience [years] Min=2.5; Max=22; Mean=12.4; Median=12Microservice Experience [years] Min=2; Max=10; Mean=3.7; Median=3Team Microservice Experience[years]Min=2; Max=15; Mean=4.6; Median=4Number of Microservices (Team) Min=4; Max=50; Mean=16.6; Median=15Team Size Min=4; Max=20; Mean=9.2; Median=8.5Age Min=25; Max=47; Mean=35.3; Median=35Education Level Bachelor’s=14; Master’s=5; PhD=1; Self-taught=13.2 Data CollectionThe essence of our data collection and analysis process is outlined in Figure 3.1.The study was based on semi-structured interviews with a set of open-ended ques-tions. To identify an appropriate study protocol, we performed five pilot interviewswith colleagues, friends, and student interns employed in organizations that developmicroservices. These participants were not intended to satisfy our selection criteriabut rather help us clarify, reorder, and refine the interview questions. We proceededto the main study only when the pilot interviews ran smoothly; we discarded thedata collected during the pilot study and did not include it in our data analysis.For the main study, we conducted 21 semi-structured interviews that tookaround 50 minutes each (min=26; max=90; mean=49.9; median=47 minutes,total=17.5 hours). As typical for this kind of study, the interview length was notevenly distributed. At the beginning, the interviews were substantially longer,with many follow-ups on open-ended questions. As the study progressed, werepeatedly heard similar concerns and thus the interviews became shorter. Wecollected quantitative data about the participants’ background, their project, andteam offline, which also saved time from interviews. Each interview revolvedaround three central questions:1. How, why, and when do you create new microservices?17Figure 3.1: Data Collection and Analysis Process21 InterviewsQ1Q2Q3235 Quotes (19 excluded) 10 Subcategories 3 CategoriesC3: CodeManagement33 Concepts (14 excluded) C2:ArchitectureC1:Infrastructure2. How are microservices maintained, evolved, tested, and deployed to produc-tion?3. Which of your practices work well and what you think can be improved?We followed up with subsequent questions and in-depth discussions that de-pended on the interviewees’ responses. Our goal was to identify best practices,lessons learned, and the set of challenges practitioners face when developing andmaintaining microservice-based applications.Our study team consists of three investigators in total: the author of thisthesis, the author’s supervisor, and another MASc student with microservices andqualitative studies background.The interviews were conducted in English by at least two investigators of thiswork. Four interviews were in person and the remaining ones – over the phoneor using telecommunication software, such as Skype. All but three intervieweesagreed to be recorded and the collected data was further transcribed word-by-word,only removing colloquialism such as “um”, “so”, and “you know”, and breakinglong sentences into shorter ones. The additional three interviews were summarizedduring the conversation.We shared the transcripts with each corresponding interviewee for his or herapproval or corrections. In total, we received five corrections; most of them wereminor and related to the names of companies and tools, confidentiality-relatedissues, and clarifications on the discussed topics. We applied all corrections to the18Figure 3.2: Mapping of Categories to Conceptstranscripts.3.3 Data AnalysisTo analyze the data, we used open coding – a technique from grounded theory forderiving theoretical constructs from qualitative analysis [60]. More specifically,19Table 3.2: Concept FrequencyCategory # ParticipantsArchitectureMicroservice granularity 15Microservice ownership 9Language diversity 7InfrastructureLogging and monitoring 11Distributed tracing 6Automating processes 5Tools 6Code ManagementCommon code 14Managing variants 12Managing API changes 20two of the investigators independently read the transcripts line by line and identifiedconcepts – key ideas contained in data. When looking for concepts, we searchedfor the best phrase that describes conceptually what we believe is indicated by theraw data.On a weekly basis, all investigators met to discuss the identified concepts andto refine and merge them if needed. As mentioned earlier, we proceeded withmore interviews as long as new concepts were detected, i.e., until we reached datasaturation and no new concepts emerged in the last five consecutive interviews.Such interrelated data collection and analysis process is inspired by groundedtheory and is typical for interview studies.In total, we identified 47 concepts, linked to 254 quotes. As qualitative analysisseeks to find significant concepts and explore their relationships [60], we onlyconsidered concepts that capture ideas mentioned by at least three study partici-pants, excluding from the final results 19 quotes belonging to 14 concepts. Weended up with 235 quotes and 33 concepts, as shown in Figure 3.1. We furtherabstracted concepts into ten higher-level subcategories, which we grouped into20three main categories: architectural considerations, infrastructure support, andcode management.Figure 3.2 further elaborates on these numbers, giving the detailed mapping ofcategories to concepts. Due to confidentiality issues, we cannot list the full quotes;we thus give the number of quotes for each concept.Table 3.2 lists the identified categories/subcategories and the total number ofparticipants whose quotes have contributed to these categories. As our study has aqualitative nature, all the reported numbers have informative rather than statisticalnature. As all our findings are linked to quotes extracted from the interviews,results we report are grounded on the collected data. In the rest of the manuscript,the quotes are presented in «this style».For quality control, we sent the final report summarizing our findings to allinterviewees, asking them to comment on any misinterpretations that might haveoccurred. The feedback we received shows that the study is accurate and repre-sentative: “Overall, I think this is a very strong study that accurately reflects myexperience in the industry.”3.4 Ethical ConsiderationsThe University of British Columbia (UBC) requires that research involving humanparticipants must be reviewed and approved by the UBC-affiliated Research EthicsBoard (REB) prior to data collection. Prior to the start of our data collection,we obtained an ethics approval from UBC’s REB. In the ethics application, wesummarize the intended purpose of our study, potential participants and recruitmentstrategy, informed consent process, possible conflicts of interests, data collectionstrategies, confidential data handling, etc.Before each interview session started, the participant was required to reviewour REB approved consent form and give us an informed consent to conduct thestudy; we also ask for consent for recording the interview in the consent form.213.5 Threats to ValidityFollowing the validity classification scheme described by Wohlin et al. [66], wediscuss the threats to the validity of this study from the following aspects: externalvalidity, internal validity, and construct validity.3.5.1 External ValidityExternal validity is concerned with the conditions that limit the generalization ofour findings. As in many other exploratory studies in software engineering, ourresearch is inductive in nature and thus might not generalize beyond the subjectsthat we studied. Yet, our sample is large enough and diverse enough to giveus confidence that it represents central and significant views. We intentionallyincluded in the study software developers from companies of different type and size.We also interviewed practitioners in different roles – from software developers toteam leads and managers. We believe that these measures helped to mitigate thisthreat.3.5.2 Internal ValidityThreats to internal validity can affect the causality of the results due to the influenceson the independent variable that are not acknowledged by the researchers. In ourcase, we might have misinterpreted participants’ answers or misidentified conceptand categories, introducing researcher bias to the analysis. We attempted to mitigatethis threat in two ways. First, all data analysis steps were performed independentlyby at least two investigators of the work; furthermore, all disagreements werediscussed and resolved by all investigators. Second, we shared both the “raw” datacollected during the interviews and the resulting report with the participants of thestudy for their validation. We thus believe our analysis is solid and reliable.223.5.3 Construct ValidityConstruct validity concerns whether the study builds up the correct operationalmeasures for the concept being studied. Since our goal was to understand thebest practices, lessons learned, and challenges in using microservices, we haveto approach industrial practitioners from different companies, thus we chose toconduct an interview study as it serves our goal best.23Chapter 4ArchitectureIn this chapter, we discuss architectural considerations of microservice-baseddevelopment, including concepts related to microservice granularity, ownership,and languages used.4.1 Microservice GranularityIdentifying the right granularity for a microservice is probably the most frequentquestion raised by both microservice newcomers and experienced microservicedevelopers. Table 4.1 shows different, not necessarily mutually exclusive strategiesorganizations apply, according to our study.The majority of the study participants follow the common guidelines statingthat business capabilities are the primary consideration for defining a microservice:Table 4.1: Microservice GranularityAlternatives # ParticipantsBusiness capabilities 14Data access 5Dependencies 4Team structure 3Resource consumption 324«It just does one thing and does it really well.» The size of the microservice interms of lines of code is a less important consideration: «Having a big service isnot that bad, as long as the service is cohesive and it deals with one thing.»Looking at service dependencies and grouping together functions that talk tothe same APIs leads to minimizing service-to-service communication – anotherconsideration expressed by the study participants: «The key is to have correctseparation of concerns, such that [...] the service-to-service communication isminimized. Otherwise, you just pulled in a monolith again with network trafficbetween the various systems.»Grouping together functions that need access to the same data is another well-known guideline that enforces separation of concerns. In addition, it ensures thatonly developers with the required permissions can access the appropriate data:«Machine learning has access to user data, so we want to separate it out from[other] microservices. [...] We have a couple of people who have the responsibilityand the ownership of that code.» In fact, several practitioners mentioned that teamstructure and capabilities help them decide on the microservice boundaries: «If[code] is very frontend-centric, then we will probably have teams of people whothink about web development and we will say that is a separate service. With thedata-centric thing, we might have a different group of people with different setof skills that they work on that thing.» Another participant noted: «The size of amicroservice matters only as it relates to the size of the team that can support it.[...] that matters more than just saying, ‘Well, this microservice needs to handlethese six methods only’ or something like that. It’s more about team size.»Yet, we observed multiple cases where companies that initially split their mi-croservices based on these commonly accepted guidelines had to later revisit thisdecision. The most prominent is the concern related to computing resource con-sumption, i.e., CPU, memory, and disk space. Consumption of these resourcesmight increase substantially when common libraries are duplicated in many individ-ual containers, e.g., for executing common operations, such as authentication anddatabase access, in each individual microservice. Excessive resource consumption25increases costs for companies that deploy their solutions in a pay-as-you-go cloudenvironment.Furthermore, some companies need to deploy their solutions on proprietaryhardware, their own or of their customers. When applications exceeded the hard-ware capacity allocated by the customer, companies had to merge microservices:«[Our] customers have more restricted resources. Splitting up to many microser-vices scared them away because each microservice takes a certain amount ofresources. [...] We were able to trim down more than half of the size of that originalmodule; we are still doing that today.»Closely related to resource consumption is the anticipated microservice utiliza-tion criterion: «We do not want too little traffic to a microservice. If we just servefor one particular page that is not visited frequently, we are wasting our resourcesstarting up that microservice doing nothing for most of the time.»­ Lesson learned #1: Apart from the common practice of consideringbusiness capabilities and data access when deciding on microservice granularity,developers should also consider team structure, resource consumption, andcommunication patterns between microservices.4.2 Microservice OwnershipSome of the interviewees strongly believed that having a clear owner for eachmicroservice is a necessity for functional organizations. That is in contrast to thecurrently becoming popular practice of feature-based teams that can “touch” anymicroservice when implementing a new feature.A service owner is a person or a team, who is the primary point-of-contactwhen the microservice malfunctions: «Generally what happens is that if a serviceisn’t working, that service’s owners or maintainers are informed and they are askedto look into it.» Our participants report that, apart from troubleshooting, fixingbugs, and deciding on the design and architecture of the microservice, serviceowners also need to implement new features and train trusted committers for the26service.Having service owners is important for defining clear architectures, with well-defined service responsibilities and boundaries, and reducing architectural debt [35].When changes to a microservice are proposed, the owner is responsible for assess-ing how appropriate the change is and, if not appropriate, deciding on an alternativeway to satisfy the demand: «Because there wasn’t that sense of ownership, therewasn’t continual like ‘this is the purpose of this service and it serves only thatpurpose’. It started being ‘[this service] gonna do this, and this, and this, and that’.And it did not do either of them particularly well as opposed to doing one thingreally well.»­ Lesson learned #2: Assigning owners to microservices facilitates efficienttroubleshooting and microservice architectural integrity.4.3 Language DiversityBeing polyglot is one of the most advertised advantages of microservices, as itgives developers the flexibility to choose the technology stack and languages thatwork best for their needs, as well as the ability to try new languages on smallcomponents without affecting the whole system.However, introducing many languages and frameworks may actually decreasethe overall understandability and maintainability of the system: «We said, ‘Hey,why not try using Golang? Why not try using Elixir?’ [...] so we wrote a service inthat language. But what happens then is you end up with one, maybe two peoplewho will understand it and nobody else can read the code or they struggle to readit, so it makes the service a little bit less maintainable. And nobody wants to touchit, and that is a big problem.»Introducing many languages also makes the system harder to test: «We’ve gotsome ColdFusion parts. We’ve got JS. We’ve got some Golang, we’ve got somePython. So now you’ve got all these different microservices [...] they’re usingmultiple different tools for testing and at the same time to test the entire flow from27front to the end, it’s quite difficult.»As a result, several companies we interviewed now decided to standardize theirprocesses and restrict the development for one language for each “purpose”: «Weare trying to converge on three main languages, JavaScript in the front-end, Scalafor data, and Ruby on Rails for business logic. When we are building a new service,we pick one of those three languages depending on what seems the most logical forthe problem that we are solving as well as the team that is gonna be implementingit.»Another justification for steering away from multiple languages and technolo-gies is code and knowledge sharing: «We ended up saying, ‘Yeah, we kind of do[standardize languages] just because of the shared knowledge’. You can reuseideas from one microservice to another even though all the documents say that canbe a really bad idea because it limits creativity and it limits your ability to try outnew ideas and stuff. And we are like, ‘You know what? We don’t wanna do that.We just want to have a small number of different technologies and live with it.’»­ Lesson learned #3: For practical purposes, organizations should restrictthe number of programming languages used in a microservice-based system to afew core languages: one for each high-level “purpose”.28Chapter 5InfrastructureAs microservice-based applications consist of numerous independent components,tracking their availability and performance, debugging the entire system, and usingan appropriate setup and maintenance infrastructure are critical activities, accordingto our study participants.5.1 Logging and MonitoringOne of the main criteria for a mature microservice-based development process isthe robustness of the logging and monitoring framework. Our participants reportthat, apart from service availability and the number of requests, they log input,output, and error data, response time, resource utilization, and more. Identifyingthe right granularity level for logging is not a trivial task. Not logging enoughwill cause problems when troubleshooting failures; logging too much might harmthe application performance. Several participants also stated that, when logging,particular care is needed to preserve client privacy, e.g., by obfuscating logged data.«Having metrics in place and reviewing them, making sure that they are the rightmetrics, those are all things that get reviewed by the team ahead of time before youactually launch.»Practitioners use logged info for troubleshooting, monitoring and visualizing29the overall health of the system, creating reports for customers, e.g., on the deliveredquality of service, and compliance and auditing reports. Moreover, some runstatistical analysis on the logged info, to automatically identify failures, evenbefore customers notice them, and notify the corresponding team: «Any time thatthe logs record a failure, we have tools to find out where there were a lot of failuresin this particular period of time, what percentage of failures there were, was thelatency for that call abnormal or something, did it exceed a certain threshold over acertain period of time, etc. We have a tool that would monitor those logs and sendus alarms when those thresholds were exceeded, for example, latency thresholds orsuccess thresholds.»Practitioners often regret the decision not to set up a logging and monitoringframework early as the project starts: «Probably I will focus more on logging andmonitoring, right off the bat. Because trying to retrofit monitoring and loggingonce we have all the services, is quite a bit of work.»­ Lesson learned #4: Logging and monitoring frameworks should be setup at the onset of the project. Developers should carefully review the loggedinformation, to evaluate the effect of logging on the troubleshooting, monitoring,and reporting abilities, performance of the application, and client privacy.5.2 Distributed TracingWhen locating failures, most companies follow the chain of ownership, i.e., startfrom the failing microservice and gradually track where problems are coming from.As requests often span multiple services and the call relationships betweenmicroservices get very complex, solutions like distributed tracing [55], which trackservices participating in fulfilling a request, are applied: «There have been issuesthat I have worked on which were chained through five different teams that arecompletely unrelated. And it was like, ‘okay, this is where the initial source of thisthing came from’.»Like logging and monitoring, setting up a distributed tracing framework is an30important task to do early as the project starts: «A lot of companies that start out,do not think about distributed tracing right from the get-go. They think about it asan afterthought. And distributed tracing is a lot harder to implement after the factthan it is when you start a project.»­ Lesson learned #5: To efficiently troubleshoot a microservice-basedapplication, distributed tracing should be set up at the onset of the project. It isharder to implement after the fact.5.3 Automating ProcessesBuilding infrastructure to automatically create new microservice stubs and to addnewly created microservices to the build and deployment pipeline substantiallyreduces the operation costs: «When we first started doing microservices, it actuallytook about a month or two to get all the infrastructures ready to create a newmicroservice. Now we have the ability to create a microservice in five minutes.»«The tooling is very important. There is kind of one way to create, at least, thestructure of projects for different platforms. So like, Scala microservices, they willall look about the same. They will have the same structure. They will have thesame Jenkinsfile. They will have the same format in Kubernetes, the same way toconfigure them, roughly. That is the core.»Automated pipelines also help newcomers to start using microservices: «Todaywe are working on our starter-kit for other teams to easily get on board with themicroservice-based architecture. Back to that time, we did not have a good way toeasily start up a new microservice, it involved a lot of learning curves.»Like the aforementioned infrastructures, several interviewees, especially thosefrom large companies, mentioned that an important lesson they learned is nottreating automation as an afterthought: «If we had to start microservices again, Ithink we would try to get the tooling for creating new services ready and beginstandardizing earlier. It is easy to say this in hindsight.»31­ Lesson learned #6: For large projects, automating microservices setuphelp reduce operation costs.5.4 ToolsEarly adopters of microservice-based architectures had to develop numerous propri-etary frameworks and tools, to support development, maintenance, and deploymentof microservices. Some of these tools were later contributed to open source, e.g.,Docker [31] developed by Docker Inc., Kubernetes [20] and Istio [4] by Google,and Envoy [2] by Lyft. By now, there are more than 250 tools out there to supportdevelopment and deployment of microservices, service discovery and API manage-ment at runtime, and more [19]. For smaller companies, building proprietary toolsno longer makes economic sense: «In the time that they were trying to build theirown, Kubernetes came about, and I think they realized now that they have wasteda lot of time building the toolset.»However, our study participants noticed that identifying an appropriate existingsolution takes time, which they usually lack as the development is driven bybusiness needs: «There are tools that are out or coming out that are solving alot of problems that we have. Things like gRPC, GraphQL, code generation anddocumentation, service meshes, [...], they are great at solving a lot of problems.We just do not have the time to actually move over to them.»An advisable strategy is to stick to vendor-neutral interfaces, when possi-ble, which decouples the implementation from vendors. For example, insteadof instrumenting the code to call a particular distributed tracing vendor, such asZipkin [49] or Jaeger [5], using the vendor-neutral distributed tracing frameworkOpenTracing [6] facilitates the transition between vendors.­ Lesson learned #7: When available, choose vendor-neutral interfaces toavoid vendor lock-in.32Chapter 6Code ManagementIn this chapter, we discuss considerations related to managing code of microservice-based applications. In particular, we present alternative strategies our participantsapply for dealing with code shared by multiple microservices, managing evolvingAPIs, and developing applications consisting of multiple variants serving differenttypes of customers.6.1 Common CodeSplitting an entire system into a set fully independent microservices is not realisticin practice. Virtually all study participants stated that some functionalities andcode needs to be shared between microservices. These include cross-cuttingconcerns such as logging and authentication, database access, common utilities,and more. Simply duplicating code in multiple microservices is against the “donot repeat yourself” (DRY) principle of software development [30] and will makecode unmanageable in the long run. We observed three alternative solutions formanaging common code (see Table 6.1).The most common practice participants employ to minimize code duplicationobserved is to package the common code in a shared library, which is imported atbuild time. In the simplest case, all microservices use the same latest version of the33Table 6.1: Common CodeAlternatives # ParticipantsLatest-version shared library 6Multiple-version shared library 4Standalone microservice 4library. Its downside is that a microservice cannot make independent changes tothat common code: «That is a [...] hassle because you change the common libraryand then all the services that depend on this library need to change. [...] you haveto coordinate carefully and make sure that you do not do any breaking changes.»To address this problem, several participants carefully version libraries andallow services to rely on different versions of these libraries. Such an approachcould introduce another challenge – inconsistencies and application instability:«Hopefully, we pick the right versions so that everything works because the worstthing is when you have had transitive dependencies, and their version clashes withsomething else that another library brings in. So dependency management can bepainful.»As a compromise, participants agree that new changes should always be intro-duced only in the latest version of the library. If a microservice requires a feature,it has to import the newest version of the library: «We would not support changesin the older version. We say, ‘If you are using version two and you want the newfeatures, you have to upgrade to version three first before you get new features.’Everybody has to be converged on the same mainline version.»A number of interviewees opted for wrapping common code in a standalonemicroservice. This approach simplifies procedures as no redeployment of allmicroservices that use the changed library is required: «If you put this commoncode in a JAR and then [...] there’s a bug, you have to redeploy those [microservicesthat use the JAR]. But if you have it [common code] outside [as a service], you justdeploy it once, that would be enough.» Yet, the clear disadvantage of this approachis the introduction of network delays when executing the common code, whichaffects application performance.34The other solution to the common code issue is sidecar, which has recentlyemerged from the industry. Since such a strategy was mentioned by one participantonly, we did not include it in Table 6.1. Yet, we believe that this solution is worthhighlgihting. The main idea behind sidecar resembles a sidecar attached to amotorcycle: it co-locates common code implemented as a standalone microservicewith the primary microservice, dynamically attaching it to the main container.Using sidecar helps to avoid network overhead (as it runs on the same host asthe primary microservice) and solve the deployment problem (as sidecar can beupdated independently from the primary microservice). Moreover, it provides ahomogeneous interface for services across languages: «Applications do not have toembed libraries and then encode anymore, they can use a container-based solutionthat is going to provide common functionality. And that way, if one developermakes a change to that common component, people can just pull down the latestcontainer image and run it as a sidecar. They do not need to go and get a newversion of the code to compile under their applications.»­ Lesson learned #8: Sharing common code in the form of software librariesviolates microservice independence. Such approach should be carefully managed.Participants should also experiment with the newly emerged sidecar solution.6.2 Managing API ChangesWith services, the contract with downstream customers, external or internal, isdone at the API level. Best practices for defining APIs are well captured by Postel’slaw [52]: being liberal in what you accept and conservative in what you send. Ourstudy participants make an extra effort to avoid breaking API changes, unless thoseare security-related. Breaking changes that face external customers are especiallydiscouraged: «If you break those, that’s a huge problem.» To reduce the chance ofbreaking customer code, our participants encourage customers to ignore data theydo not use: «If [the clients] receive some data that they do not need, do not breakon that, just drop it because that may be a way of introducing new changes.»35Table 6.2: Managing API ChangesAlternatives # ParticipantsDirect API calls 14Proxy 7Client library 5Message-based communication 4When a company must change an API in a way that it is no longer compatiblewith the original version, e.g., to support security features, they version the APIsup, eventually deprecating the old version without breaking it: «If we are going todelete something from the payload or we completely change the signature, we willhave to bump up the major version and create another version of the API and askpeople to move over.»API changes are typically discussed in internal or external interlocks, doc-umented, and systematically deployed. As shown in Table 6.2, a number ofinterviewed teams use direct API calls for synchronous communication betweenmicroservices. Some participants mentioned they use asynchronous message-basedcommunication within their product or across product boundaries. They mostlyrely on distributed stream-processing software, such as Apache Kafka [34] ormessage brokers, such as RabbitMQ [51]).With both direct calls and messaging, when a change is introduced, it is imple-mented by an API with a new version number. Both the old and the new versionsare deployed alongside to allow a smooth transition of the clients, and the old APIis removed when clients stop using it: «You do your first deployment on the API.You do the second deployment on the calling service. And then you do anotherdeployment on the API again to remove the old stuff.»This strategy makes the transition simple and straightforward, but requireschanges in all clients using the API. Identifying and notifying such clients isa challenging task. Various proxy solutions, e.g., API gateways [54], push thecomplexity to the server side.As breaking API changes often involve simple modifications, e.g., adding a36new input parameter to the API, a proxy can be programmed to detect old APIcalls and transform them to a new version, e.g., by adding default values to fieldsnot passed by the client, making them backward compatible before forwarding therequests to the new API version. In this way, clients stay oblivious to the actualversion they are using, as every request goes through the gateway and the gatewayjust routes the request as needed.Another solution for simplifying clients’ transition to new API versions isto provide clients with a library that wraps calls to server APIs. Client librariesare typically automatically generated, e.g., using tools such as Swagger [59].Using libraries has numerous benefits over clients making direct HTTP calls [14].First, developers can push upgrades to the clients more easily by using packagemanagement tools. The upgrade process is also simplified for the customer asthey do not need to get acquainted with the details of the changes. Finally, clientlibraries can handle low-level communication issues such as authentication withthe API server, again, reducing the burden on the customer side.­ Lesson learned #9: API breaking changes, especially those facing externalclients, are discouraged. When needed, e.g., for security upgrades, they shouldbe introduced via deprecation. APIs gateways and client libraries help tomitigate the burden of upgrades for the client.6.3 Managing VariantsManaging different customer offerings (a.k.a variants), e.g., for “free” vs. “pre-mium” customers, is yet another challenge in developing microservices. More thanhalf of our study participants need to manage variants of their products and theyreported on three common strategies for managing product variants (see Table 6.3).Feature flags are basically conditions that are passed with requests and that controldifferent paths in code. In the simplest form, these flags can identify a certaingroup of users: «It can say, ‘Oh, if you are User X, do this code’, or ‘if you arein this cohort, do this code’. We use feature flags very heavily, so we can turn on37Table 6.3: Managing VariantsAlternatives # ParticipantsSeparate deployments 5Feature flags 4Role-based access 3some code path for different people.»More robust feature flags do not condition over particular users, which is hardto scale, but rather specify high-level features: «When the feature is toggled for acustomer, it is more like a temporary thing where it is like a hack. [...] Typically,when it is a specific feature, that is something that is determined at the API leveland passed in. It is a call to the service with feature X enabled.»The biggest benefit of using feature flags is to be able to make changes on thefly at run-time. Companies also use feature flags to support blue-green deploy-ments [57] and to roll-out changes to a certain group of users: «We can say, ‘Let’spush this new feature out to 1% of our user groups, 10%, and slowly see what theresponse is over time’.»The disadvantages of feature flags are that it requires extensive managementof feature themselves and the correspondence between features and code thatimplement these features. Testing different combinations of features also becomeschallenging. Another approach for managing variants is role-based access whichprovides access to APIs based on the user role. Such an approach is typicallysupported by the API management tools and API gateways [54]. Each incomingrequest has an API key tied back to a particular API plan, and an API gatewayroutes the requests to a certain code, based on the developer-specified configuration.The main advantage of the role-based access approach compared to feature flagsis that this approach makes the primary functionality selection in the infrastructurelayer, making it possible to deny access to certain clients, instead of performingchecks in the code: «Based on the customer ID, they are allowed to use a subset ofthe service, when they try to call these other APIs that they are not supposed to,they will just get an error back.»38Finally, a few participants reported that they use separate deployments for dif-ferent customers, on the company’s or customers’ sides. In detailed interviews, thepractitioners explained that their projects started from using feature flags and othercode-level differentiation, but that complicated code management: «Previously wewere doing everything within the one microservice. [...] That became very messyvery quickly, so we ended up splitting an instance out into its own branch.»Such projects maintain different code bases for different customers: «Dedicatedand local [offerings] are different because they are for only certain customers. [...]We have a branch for the dedicated and local system; when we roll out a newfeature to the public system, they won’t get it automatically unless we pour thatfeature to the branch.»While separate branches induce the overhead of synchronizing the code bases,some practitioners opt to do that to ease the maintenance effort: «Let’s say we haveproduct v6.0, v6.1, and v6.2. We found a bug in v6.0, and need to fix the bug in allthree versions. But the bug fix that is needed in the three versions can be differentdue to compatibility issue. When fixing the bug, we need to independently fix allversions.» Such a solution might be appropriate for cases when customer offersdiverge substantially.­ Lesson learned #10: Feature flags and role-based access for managingproduct variants make it possible to maintain a single code base but complicateits maintenance. Separate deployments can be considered when variants areexpected to substantially diverge.39Chapter 7Discussion and Future WorkMicroservices are advertised as a way to speed up development, reduce commu-nication effort and dependencies, and increase performance and scalability of anapplication at runtime. Together with these benefits, there are several pitfalls andchallenges related to the adoption of microservices that warrant a discussion. Simi-lar to Chapter 2, here we discuss these challenges from two perspectives: technicaland organizational.Technical. Identifying proper service granularity is one of the concerns of multiplepractitioners. Splitting and merging microservices is a process that is performedcontinuously, long after the initial microservice topology is identified. This pro-cess should be informed not only by architectural considerations, e.g., functionaldecomposition and fan-in and fan-out metrics, but also by additional concerns suchas performance and security. Metrics and tools that help practitioners continuouslyassess and refactor their microservice-based architectures are needed.Likewise, many of the microservice technologies are built with the idea ofan open Web; introducing strict security guidelines, i.e., ensuring that networksboundaries for calls within and between applications are properly guarded, requiresmore efforts than in monolithic applications. It appears that innovation in thisarea is mostly driven by industry, e.g., the concept of a service mesh, with built-inaccess control for service-to-service communication [4, 45]. Given the increased40attack surface and distributed ownership, research on usable and robust securitymodels for microservice-based architectures will be fruitful.Performance debugging for microservice is now mostly based on metrics andlogs, and is mostly done ad hoc. Application performance management softwarefor microservices also has not gained sufficient attention in the relevant commu-nities [58, 29]. More research is needed to identify strategies for performancemonitoring of a microservice-based system under continuous software change.Maintaining different variants is another important concern for microserviceorganizations. While techniques like feature flags and segregation of functionalityby APIs are useful, they add complexity to the development processes and maketesting different combinations of features harder. Efficient management of productvariants is a research topic extensively studied by the software product line researchcommunity [36]. Adapting the techniques developed by this community to thecontext of microservices is a fruitful research direction.Organizational. Interestingly, many of our study participants believed that break-ing a system into small components makes it easier to understand. While a limitedscope indeed decreases the entrance barrier, it weakens the developers’ understand-ing of the system as a whole. Under such a model, developers, in particular, thejunior ones, are trained to believe that they should only care about a few microser-vices they directly work on. They develop the impression that it is easy(er) todebug microservices, whereas debugging a distributed system composed of multi-ple, independently managed and involving components, is in fact, a challengingtask [39, 11].In the realm of managing API changes, several of the study participants indi-cated that this process involves constant synchronization effort, e.g., daily inter-locks between the teams to propose and discuss changes, and even synchroniza-tion on deploying changes simultaneously. Even though most companies adoptmicroservice-based architectures because of the promise to decouple the teams,this synchronous communication still takes a substantial portion of the teams’ time.Tools for assessing the impact of the proposed changes as well as practices that41focus on helping teams work together better in these complex, rapidly evolvingecosystems are needed.Our study also indicates the need for a systematic analysis of the differentavailable tools for supporting microservice-based development. Several partici-pants indicated that they do not have a clear strategy in selecting an appropriatetool, out of available alternatives. More systematic criteria and a set of metrics fordescribing, evaluating, and comparing tools to each other are needed.Microservices are commonly thought of as an architectural style that emergedfrom the Agile and DevOps movements [41, 46], to solve the bottleneck of central-ized delivery, to reduce the communication effort, and to shorten build-test-deploycycles. DevOps promotes full ownership from development to production and isone of the main backbones of microservice-based architectures. Yet, for govern-ment and healthcare-related organizations that are bound by privacy laws and needspecial treatment in handling confidential data and personal data, implementingDevOps is not always straightforward. They often rely on contractors that developthe software, who do not have access to the company’s infrastructure. Regulatorycompliance products, where it is essential to produce audit trails before deployment,also complicate matters. When such organizations want to adopt microservices,they need to rethink DevOps and continuous delivery practices. We believe a morefocused study on development practices and needs of such organization is required.42Chapter 8ConclusionThis thesis reports on best practices, lessons learned, and challenging design trade-offs collected by interviewing 21 participants from companies that successfullyadopted microservice-based architectures.Our participants indicated that a clear sense of ownership, strict API man-agement, automated processes, and investment in robust logging and monitoringinfrastructure as some of the best practices they consider contributing to the successof their development processes. They learned that using a plurality of languagesand following the advice to split microservice by business functionality is notalways fruitful.Our study identified several common challenges faced by practitioners that use amicroservice-based architecture, such as identifying the proper service granularity,ways to introduce API changes, managing code shared between microservices, andmanaging multiple product variants. We reported on alternative solutions our studyparticipants employ and identified potential next steps the research communitycan take to further facilitate efficient software engineering practices in developingmicroservice-based applications. These include performance- and security-awaresolutions for managing design trade-offs, managing versions and variants, assessingthe impact of API changes, tools for performance debugging, and more.We believe this thesis can help software engineering researchers to better focus43their agenda when devising solutions for organizations that employ a microservice-based architecture and also be useful for practitioners that can learn from eachother’s experience, adopt best practices, and avoid common mistakes.44Bibliography[1] N. Alshuqayran, N. Ali, and R. Evans. A Systematic Mapping Study inMicroservice Architecture. In Proceedings of IEEE International Conferenceon Service-Oriented Computing and Applications (SOCA), pages 44–51,2016.[2] E. P. Authors. Envoy Proxy., 2019. (Lastaccessed: April 2019).[3] G. Authors. Grafana., 2019. (Last accessed: April2019).[4] I. Authors. Istio: Connect, Secure, Control, and Observe Services., 2019. (Last accessed: April 2019).[5] J. Authors. Jaeger: Open Source, End-To-End Distributed Tracing., 2018. (Last accessed: April 2019).[6] O. Authors. The OpenTracing Project., 2018.(Last accessed: April 2019).[7] P. Authors. Prometheus., 2018. (Last accessed:April 2019).[8] E. Babbie. The Practice of Social Research. Nelson Education, 2015.[9] A. Balalaie, A. Heydarnoori, and P. Jamshidi. Microservices ArchitectureEnables Devops: Migration to a Cloud-Native Architecture. IEEE Software,33(3):42–52, 2016.[10] A. Balalaie, A. Heydarnoori, P. Jamshidi, D. A. Tamburri, and T. Lynn.Microservices Migration Patterns. Software: Practice and Experience, pages1–24, 2018.45[11] I. Beschastnikh, P. Wang, Y. Brun, and M. D. Ernst. Debugging DistributedSystems. Communications of the ACM, 59(8), 2016.[12] A. Bucchiarone, N. Dragoni, S. Dustdar, S. T. Larsen, and M. Mazzara.From Monolithic to Microservices: An Experience Report from the BankingDomain. IEEE Software, 35(3):50–55, 2018.[13] Camunda. New Research Shows 63 Percent of Enterprises Are AdoptingMicroservices Architectures yet 50 Percent Are Unaware of the Impact onRevenue-Generating Business Processes., 2018. (Last accessed: April 2019).[14] G. Cloud. Client Libraries Explained.,2018. (Last accessed: April 2019).[15] N. Dragoni, S. Giallorenzo, A. L. Lafuente, M. Mazzara, F. Montesi,R. Mustafin, and L. Safina. Microservices: Yesterday, Today, and Tomorrow.Present and Ulterior Software Engineering, pages 195–216, 2017.[16] DZone. Programming & DevOps News, Tutorials & Tools., 2018. (Last accessed: April 2019).[17] J. Fenn and A. Linden. Gartner’s Hype Cycle Special Report for 2005.,2005. (Last accessed: April 2019).[18] R. T. Fielding. Architectural Styles and the Design of Network-BasedSoftware Architectures. PhD thesis, University of California, Irvine, 2000.[19] C. N. C. Foundation. CNCF Cloud Native Interactive Landscape., 2019. (Last accessed:April 2019).[20] T. L. Foundation. Kubernetes: Production-Grade Container Orchestration., 2019. (Last accessed: April 2019).46[21] M. Fowler. Microservice Trade-Offs.,2015. (Last accessed: April 2019).[22] P. D. Francesco, P. Lago, and I. Malavolta. Migrating Towards MicroserviceArchitectures: An Industrial Survey. In Proceedings of IEEE InternationalConference on Software Architecture (ICSA), pages 29–38, 2018.[23] P. D. Francesco, I. Malavolta, and P. Lago. Research on ArchitectingMicroservices: Trends, Focus, and Potential for Industrial Adoption. InProceedings of IEEE International Conference on Software Architecture(ICSA), pages 21–30, 2017.[24] J. Ghofrani and D. Lübke. Challenges of Microservices Architecture: ASurvey on the State of the Practice. In Proceedings of the 10th CentralEuropean Workshop on Services and Their Composition (ZEUS), pages 1–8,2018.[25] A. M. Glen. Microservices Priorities and Trends.,2018. (Last accessed: April 2019).[26] L. A. Goodman. Snowball Sampling. The Annals of Mathematical Statistics,32(1):148–170, 1961.[27] J.-P. Gouigoux and D. Tamzalit. From Monolith to Microservices: LessonsLearned on an Industrial Migration to a Web Oriented Architecture. InProceedings of IEEE International Conference on Software ArchitectureWorkshops (ICSAW), pages 62–65, 2017.[28] C. Green. Agile Development is Ideally Suited for Microservices., 2017. (Last accessed: April 2019).[29] R. Heinrich, A. van Hoorn, H. Knoche, F. Li, L. E. Lwakatare, C. Pahl,S. Schulte, and J. Wettinger. Performance Engineering for Microservices:Research Challenges and Directions. In Companion Proceedings of the 8thACM/SPEC on International Conference on Performance Engineering(ICPE), pages 223–226, 2017.47[30] A. Hunt and D. Thomas. The Pragmatic Programmer: From Journeyman toMaster. Addison-Wesley Longman Publishing, 1999.[31] D. Inc. Docker: Build, Manage and Secure Your Apps Anywhere. Your Way., 2019. (Last accessed: April 2019).[32] G. Inc. Gartner: the World’s Leading Research and Advisory Company., 2018. (Last accessed: April 2019).[33] M. F. James Lewis. Microservices: A Definition of This New ArchitecturalTerm.,2014. (Last accessed: April 2019).[34] A. Kafka. Apache Kafka: A Distributed Streaming Platform., 2017. (Last accessed: April 2019).[35] P. Kruchten, R. L. Nord, and I. Ozkaya. Technical Debt: from Metaphor toTheory and Practice. IEEE Software, 29(6):18–21, 2012.[36] W. U. Lab. SPLC: Systems and Software Product Line Conference., 2018. (Last accessed: April 2019).[37] Lightbend. Enterprise Development Trends 2016., 2016. (Last accessed: April2019).[38] Linkedin. Linkedin., 2018. (Last accessed:April 2019).[39] X. Liu, Z. Guo, X. Wang, F. Chen, X. Lian, J. Tang, M. Wu, M. F. Kaashoek,and Z. Zhang. D3S: Debugging Deployed Distributed Systems. InProceedings of USENIX Symposium on Networked Systems Design andImplementation (NSDI), pages 423–437, 2008.[40] W. Luz, E. Agilar, M. C. de Oliveira, C. E. R. de Melo, G. Pinto, andR. Bonifácio. An Experience Report on the Adoption of Microservices inThree Brazilian Government Institutions. In Proceedings of BrazilianSymposium on Software Engineering (SBES), pages 32–41, 2018.48[41] M. McLarty. Microservice Architecture is Agile Software Architecture., 2016. (Lastaccessed: April 2019).[42] Meetup. Microservices: A Definition of This New Architectural Term., 2014.(Last accessed: April 2019).[43] Meetup. Meetup: We Are What We Do., 2018.(Last accessed: April 2019).[44] M. Milinkovich. Jakarta EE Developer Survey., 2018.(Last accessed: April 2019).[45] W. Morgan. The History of the Service Mesh., 2018. (Last accessed:April 2019).[46] MuleSoft. Microservices and DevOps: Better Together., 2018. (Last accessed: April 2019).[47] I. Nadareishvili, R. Mitra, M. McLarty, and M. Amundsen. MicroserviceArchitecture: Aligning Principles, Practices, and Culture. O’Reilly Media,2016.[48] E. Newcomer and G. Lomow. Understanding SOA with Web Services.Addison-Wesley, 2005.[49] Openzipkin. Zipkin: A Distributed Tracing System.,2019. (Last accessed: April 2019).[50] C. Pahl and P. Jamshidi. Microservices: A Systematic Mapping Study. InProceedings of the International Conference on Cloud Computing andServices Science (CLOSER), pages 137–146, 2016.[51] Pivotal. RabbitMQ., 2018. (Last accessed:April 2019).49[52] J. Postel. DoD Standard Transmission Control Protocol. RFC, 761:1–88,1980.[53] M. Razavian and P. Lago. A Survey of SOA Migration in Industry. InProceedings of IEEE International Conference on Service-OrientedComputing (ICSOC), pages 618–626, 2011.[54] C. Richardson. API Gateway Pattern., 2018. (Lastaccessed: April 2019).[55] C. Richardson. Pattern: Distributed Tracing., 2018. (Lastaccessed: April 2019).[56] C. Richardson. Who is Using Microservices?,2018. (Last accessed: April 2019).[57] C. Rossi, E. Shibley, S. Su, K. Beck, T. Savor, and M. Stumm. ContinuousDeployment of Mobile Software at Facebook (Showcase). In Proceedings ofthe ACM SIGSOFT International Symposium on Foundations of SoftwareEngineering (FSE), pages 12–23, 2016.[58] V. Seifermann. Application Performance Monitoring in Microservice-BasedSystems. Bachelor’s thesis, Institute of Software Technology ReliableSoftware Systems, University of Stuttgart, 2017.[59] S. Software. Swagger: The Best APIs are Built with Swagger Tools., 2019. (Last accessed: April 2019).[60] A. Strauss and J. Corbin. Basics of Qualitative Research: Techniques andProcedures for Developing Grounded Theory. Thousand Oaks, CA: Sage,1998.[61] D. Taibi, V. Lenarduzzi, and C. Pahl. Processes, Motivations, and Issues forMigrating to Microservices Architectures: An Empirical Investigation. IEEECloud Computing, 4(5):22–32, 2017.[62] G. Trends. Google Trends., 2018. (Lastaccessed: April 2019).50[63] M. Viggiato, R. Terra, H. Rocha, M. T. Valente, and E. Figueiredo.Microservices in Practice: A Survey Study. In Brazilian Workshop onSoftware Visualization, Evolution and Maintenance (VEM), pages 1–8, 2018.[64] H. Vural, M. Koyuncu, and S. Guney. A Systematic Literature Review onMicroservices. In Proceedings of International Conference onComputational Science and Its Applications (ICCSA), pages 203–217, 2017.[65] Wikipedia. Microservices., 2019. (Last accessed:April 2019).[66] C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson, B. Regnell, and A. Wesslén.Experimentation in Software Engineering. Springer Science & BusinessMedia, 2012.[67] V. Woods. Gartner Identifies the Top 10 Strategic Technology Trends for2016.,2015. (Last accessed: April 2019).[68] X. Zhou, X. Peng, T. Xie, J. Sun, C. Ji, W. Li, and D. Ding. Fault Analysisand Debugging of Microservice Systems: Industrial Survey, BenchmarkSystem, and Empirical Study. IEEE Transactions on Software Engineering,14(8):1–18, 2018.51


Citation Scheme:


Citations by CSL (citeproc-js)

Usage Statistics



Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            async >
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:


Related Items