• No results found

The pains and gains of microservices: a systematic grey literature review

N/A
N/A
Protected

Academic year: 2021

Share "The pains and gains of microservices: a systematic grey literature review"

Copied!
19
0
0

Bezig met laden.... (Bekijk nu de volledige tekst)

Hele tekst

(1)

The pains and gains of microservices

Citation for published version (APA):

Soldani, J., Tamburri, D. A., & van den Heuvel, W-J. (2018). The pains and gains of microservices: a systematic

grey literature review. Journal of Systems and Software, 146, 215-232. https://doi.org/10.1016/j.jss.2018.09.082

Document license:

TAVERNE

DOI:

10.1016/j.jss.2018.09.082

Document status and date:

Published: 01/12/2018

Document Version:

Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers)

Please check the document version of this publication:

• A submitted manuscript is the version of the article upon submission and before peer-review. There can be

important differences between the submitted version and the official published version of record. People

interested in the research are advised to contact the author for the final version of the publication, or visit the

DOI to the publisher's website.

• The final author version and the galley proof are versions of the publication after peer review.

• The final published version features the final layout of the paper including the volume, issue and page

numbers.

Link to publication

General rights

Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain

• You may freely distribute the URL identifying the publication in the public portal.

If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, please follow below link for the End User Agreement:

www.tue.nl/taverne

Take down policy

If you believe that this document breaches copyright please contact us at:

openaccess@tue.nl

providing details and we will investigate your claim.

(2)

ContentslistsavailableatScienceDirect

The

Journal

of

Systems

and

Software

journalhomepage:www.elsevier.com/locate/jss

The

pains

and

gains

of

microservices:

A

Systematic

grey

literature

review

Jacopo

Soldani

a,∗

,

Damian

Andrew

Tamburri

b

,

Willem-Jan

Van

Den

Heuvel

b

a Dipartimento di Informatica, Universitá di Pisa, Pisa, Italy

b Jheronimus Academy of Data Science, TU/e, Universiteit van Tilburg, NL,the Netherlands

a

r

t

i

c

l

e

i

n

f

o

Article history: Received 7 May 2018 Revised 17 September 2018 Accepted 26 September 2018 Available online 27 September 2018

Keywords:

Microservices Microservices design Microservices development Microservices operation Systematic grey literature review Systematic literature review

a

b

s

t

r

a

c

t

Thedesign,development,andoperationofmicroservicesarepickingupmoreandmoremomentumin the IT industry.At thesame time, academic work onthe topicis atan early stage, and still onthe waytodistillingtheactual“Pains&Gains” ofmicroservicesasanarchitecturalstyle.Havingwitnessed thisgap,wesetforthtosystematicallyanalyzetheindustrialgreyliteratureonmicroservices,toidentify thetechnical/operationalpainsand gainsofthemicroservice-basedarchitecturalstyle.We concludeby discussingresearchdirectionsstemmingoutfromouranalysis.

© 2018 Elsevier Inc. All rights reserved.

1. Introduction

Microservicesaregainingmoreandmoremomentumin enter-prise IT Thönes (2015). Prominent examples are Amazon,Netflix, Spotifyand Twitter,whichare alreadydelivering their core busi-nessthroughmicroservice-basedsolutions.

Microservices were first introduced in 2014 by Lewis and Fowler in their famous blog post [S22]. They define an archi-tectural style for developing applications as suites of small and independent (micro)services. Each microservice is built around a business capability, it runs in its own process, and it commu-nicates with the other microservices in an application through lightweight mechanisms (e.g., HTTP APIs). To some extent, the microservice architectural style can be seen as a natural exten-sion of SOA (Service-Oriented Architecture ), which puts emphasis on the independent/self management of services, and on their lightweight nature(Zimmermann,2017).Microservicesareloosely coupledarchitecturalelementsthatcanbeindependentlydeployed byfullyautomatedmachinery.Suchindependentdeploymentis of-ten achievedby exploitinglightweight, container-basedplatforms (Pahletal.,2017).Assuch,microservicesofferbydesignascalable solutionforservice-orientedoperation(Fountain,2003).

Thereexistsecondarystudiesanalyzingresearchtrendson mi-croservicesintheacademia,allconcludingthatacademicresearch

Corresponding author.

E-mail address: soldani@di.unipi.it (J. Soldani).

onmicroservicesisstillinitsearlystage.Atthesametime, compa-niesare workingday-by-dayonthedesign,developmentand op-erationofmicroservices,asalsowitnessedbythehugeamountof greyliterature on the topic. We can henceobserve asort ofgap betweenacademicresearchandindustrypractices,especiallyinan efforttofigureoutwhicharethetechnical/operational“pains” and “gains” ofmicroservices.

Inthispaper,we trytofillthe abovementioned gapby com-plementingthe academicstate-of-the-arton microserviceswitha systematicanalysisoftheindustrial grey literatureonthetopic(as recommendedbyGarousietal.(2016)).Moreprecisely,weaimat identifying, taxonomically classifying, and systematically compar-ingtheexistinggreyliteratureonpainsandgainsofmicroservices, fromtheir designto their development. Weconducteda system-aticreviewof51 selectedindustrialstudies,publishedsince2014 (whenthemicroservice-based architecturalstylewasfirstdefined byLewisandFowler)tilltheveryendof2017.Followingthe guide-linesbyGarousietal.(2017)(andthosebyPetersenetal.(2008)), we first excerpted two taxonomies from the selected industrial studies,oneforthepainsofmicroservices,andonefortheirgains. We then exploited such taxonomies to classify and compare the selectedindustrialstudies,inordertodistilltheactualrecognition ofpainsandgainsofmicroservicesbytheITindustry.

Theresults ofour studyshow that thepainsof microservices are mainly dueto the intrinsiccomplexity ofmicroservice-based applications. For instance, while designing a microservice-based application, theprimary painsare determiningthe “right” granu-https://doi.org/10.1016/j.jss.2018.09.082

(3)

larity of its microservices andthe design of its security policies. Managingdistributed storage and application testing are instead theprimarypainsatdevelopmenttime.Atoperationtime,the pri-marypain of microservicesis their consumption of network and computingresources,whichisrecognizedasmuchhigherwith re-specttothatofotherarchitecturalstyles(e.g.,monoliths,SOA).

At the same time, microservices bring various, widely recog-nized gains. At design time, the primary gains of microservices those related to the exploitation of design patterns, which are widely recognized to help mitigating/solving some pains of mi-croservices.Developmentemergesbyfarasthestagegainingmost from microservices, as different microservices can be indepen-dently developedby differentdevelopers, who have all the free-domin choosing thetechnology stacksanddata storesthat best fitthe microservices they are developing.Operation isalso gain-ingfrommicroservices,whichcanbeindependentlydeployedand scaledwheneverneeded.

Oursystematicanalysisofgreyliteratureonmicroservicescan providebenefits to both researchers andpractitioners. A system-atic presentation of the industrial state-of-practice on microser-vicesprovides a bodyof knowledgeto develop newtheoriesand solutions, to analyze and experiment research implications, and toestablish futureresearch dimensions. At thesame time, itcan help practitioners to understand the currently recognized pains andgainsofmicroservices,andtheirmaturity.Thiscanhave prac-ticalvalue forpractitioners, e.g., asa startingpoint for microser-vicesexperimentationorasaguideline forday-by-day workwith microservices.

The restof this article is organizedas follows.Section 2 dis-cussesrelatedwork.Section3illustratesthemethodology,research questionsandscopeofoursystematicstudy.Section4presentsthe resultsofourstudy.Section 5discussesresultsandlimitationsof ourstudy.Section6concludes thisarticle,by discussingfindings, implicationsanddirectionsforfuturework.

2. Relatedwork

Besides the seminal paper by Sill (2016), only a handful of other efforts provideempirical evidence on effective/efficient ex-ploitationof microservices. Forinstance, Balalaie et al.(2016) il-lustrateexperiences and lessonslearned from the migration and architecturalrefactoring ofa commercial applicationto microser-vices.Hassan andBahsoon(2016) provide afirst investigationon design trade-offs, when trying to partition applications in inde-pendentmicroservices.Haselböcketal.(2017)offeranoverviewof themicroservicedesign space,by proposinga strategicmodelfor instrumentingmicroservicedesigndecisions. Erletal.(2017) and (Zimmermann, 2017) instantiateSOA notions inthe world of mi-croservices.Akey observationturningout fromabovementioned research efforts(and fromclosely relatedefforts,as well)is that academicresearch on microservices — from their design to their developmentandoperation— isstillatanearlystage.

Theearlystage ofacademicresearchonmicroservicesalso im-pactsonsurveysonthestate-of-the-artorstate-of-practiceon mi-croservices.State-of-the-artsurveysfocusonclassifyingand com-paringtheexistingresearchbodyonmicroservices(includingsome nonpeer-reviewedcontent),inordertodeterminethematurityof research onmicroservices, andonestablishing the research chal-lengesemerging fromthe analyzed literature. Concrete examples arethesystematicanalysesprovidedbyDiFrancescoetal.(2017), by Pahland Jamshidi (2016) and by Vural etal. (2017). Theyall concludethat academic research on microservices is still imma-ture,byalsooutliningvariousresearchdirections.

State-of-practiceanalysesareinsteadyettobeprovided,as(to thebest ofourknowledge)theonlyavailableeffortsarethoseby Ghofrani and Lübke (2018) and by Taibi and Lenarduzzi (2018).

GhofraniandLübke(2018)provideapreliminaryanalysison state-of-practice on microservices, based on an online survey (with 3 questions, answered by 25 interviewed practitioners). The re-sultspresentedbyGhofraniandLübke(2018)provideahigh-level overview of industry-oriented challengeson microservices, with-outdelvingintothedetailsoftheiractualpainsandthegains.Our study instead aims at providing a deeper analysis on which are the technical/operational painsand gainsof microservices recog-nized by industrialresearchersandpractitioners working day-by-daywithmicroservices.

Taibi and Lenarduzzi (2018) illustrate 11 microservice-specific badpractices,resultingfrominterviewsofdevelopersexperienced withmicroservice-basedsystems.Such badpracticesare reflected bysomeofthepainsthatweidentifyinourstudy,whoseobjective ishoweverdifferentfromthatbyTaibi andLenarduzzi.Insteadof tryingtoidentifybadpractices byconductinginterviews,ouraim is to elicitthe main technical/operational painsandgains of mi-croservices by systematically analysing the grey literature on the topic.

Insummary,we perceive asortofgap betweenthe industrial understanding andstate-of-practice on microservices andthe re-latedacademicliterature on thetopic. The keymotivation ofour study is to try to fill this gap, by eliciting the current state-of-practiceon microservicesthrougha systematicgreyliterature re-view.

3. Researchdesign

Amajorintrinsicdifficultyofourstudyisournecessaryreliance overwhat iscalled grey literature (Garousi etal., 2016), intended as materials and research produced by organizations outside of the traditional commercial or academic publishing and distribu-tion channels. Common grey literature publication types include reports(annual,research, technical,project,etc.), workingpapers, governmentdocuments,whitepapers,videosandevaluations.On theone hand,theuseofgreyliteratureisrisky sincethereis of-ten little orno scientific factual representationof data or analy-sespresented ingreyliterature itself (FaraceandSchöpfel,2010). On the other hand, a growing interest around using grey litera-tureforsoftwareengineeringpractitioner benefitaswell as com-bining itto determine thestate of theartand practicearound a topicisgaininga considerableinterest inmanyfields(Faraceand Schöpfel,2010;Stempfhuberetal.,2008),includingsoftware engi-neering(Garousietal.,2016).

For the scope of this study, and in an effort to maximize its validity, we followeda systematic approach based onthat by Petersenetal.(2008)forconductingsystematicliteraturereviews in software engineering. More precisely, following the guidelines by Garousi et al. (2017), we varied the standard approach by Petersenetal.(2008)asfollows:

Weexploitedgeneralwebsearchenginesforsearchingforgrey literature(insteadofindexingdatabases).

Weemployed “saturation” asstoppingcriteria(i.e.,westopped oursearchwhennonewrelevantresults/conceptswere emerg-ingfromsearchresults).

We combined inclusion/exclusion criteria with quality assess-mentcontrolfactors.

We fixed the type of relevant grey literature to blog post, whitepapers,industrialmagazinesandvideos.

We hereafteroutline thesystematicapproach wefollowed, by startingfromproblemdefinitionandbyalsodescribing the trian-gulationandinter-raterreliabilityassessmenttrials weranto en-forcethevalidityofourfindings.

(4)

Fig. 1. Strings employed for searching the technical/operational (a) pains and (b) gains of microservices. In both cases, “* ” matches lexically related terms (e.g., plurals, verb conjugations).

3.1. Research problem definition and research questions

The problemwe aim to address istwofold.On the one hand, we aimtoelicitpains, gains,bestpractices,andfallacies over us-ingmicroservicesinpractice,bylookingatthereportedfailureand successexperimentsdirectlyfromtheindustrialliterature.This in-formation can haveclearpractical value since other practitioners canusetheresultscapturedinthismanuscriptasastartingpoint formicroservicesexperimentationintheirownpractice.

Onthe other hand,we aimto elicit thegaps, limitations,and practical directions experimented up to thispoint. This can help researchers investigating microservices, who can start from our findings toproceedintheir researchfromabasisofsynergywith industry itself (as we believe that the results captured in this manuscriptareonesuchbasisofsynergy).

Stemmingfromtheaboveresearchproblems,weformulatethe followingresearchquestions:

Q1 How much evidence of microservices experimentation from in- dustry is available online? We aim to provide a high-level overview of the involvement of industrial researchers and practitioners in microservices, by analyzing how much in-dustrial studies have been published in the recent past (i.e.,sincethebeginningof2014tilltheendof2017),aswell the typesofcontributions, thesources ofpublications, and theircontents.

Q2 What are the technical and operational “pains” of microser- vices? We aim to elicit the technical and operational dif-ficulties intrinsic to the design, development and opera-tionofmicroservice-basedapplications,whichindustrial re-searchers/practitioners havebeen experimenting in the re-centpast.

Q3 What are the technical and operational “gains” of microser- vices? We aim to elicit the technical and operational ben-efits that are provided by microservices, which industrial researchers/practitionershavebeen appreciatingduringthe design, development and operation of microservice-based applications.

3.2. Search for industrial studies

As recommended by Garousi et al. (2017), industrial stud-ies can be identified by exploiting search strings on search engines (e.g., Google, Bing). Following the guidelines provided by Petersen et al. (2008), we identified the search string by structuring them guided by our research questions. More pre-cisely, we defined the search strings based on the PICO terms of our question (Kitchenham and Charters, 2007), by exploiting only the terms Population and Intervention . The keywords were taken from each aspect of a research question. Differently from Petersen et al. (2008), we did not restrict our focus to specific outcomes or experimental designs in our study, as we wished to have a broader overview ofthe industrial state-of-practice on microservices. By restricting ourselves to certain types of stud-ies,wecouldhaveobtainedabiased/incompleteanalysis,assome sub-topics might have been over-/under-represented for certain typesofstudy.The aboveexplaineddifferenceisalsoreflectedby

thestrings we employed forsearching forthe painsof microser-vices (Fig.1.(a)) and forsearching for the gainsof microservices (Fig.1.(b)).

We exploited the above indicated search strings to look for industrial studies(e.g., blogposts, whitepapers,industry-oriented magazines, videos) that were published since the beginning of 2014 (when microservices were first proposed by Lewis and Fowler) until the end of 2017. The search engines we employed areGoogle(primary),Bing,DuckDuckGo,Yahoo!andWebopedia. Since engines look forsearch strings over the whole pages they index,our searchresultedin ahighnumberofirrelevant studies, whichwere furtherrefined with a secondary search andmanual screening,basedontheinclusion/exclusioncriteriaandcontrol fac-torsdiscussedinthefollowingsection.

3.3. Sample selection & control factors

Table1outlinestheinclusionandexclusioncriteriaadoptedin oursampleselection.Theinclusioncriteria(i 1 − i4 )weredesigned tofocusexplicitlyonthekindofpracticalgreyliteraturethat iden-tifies the design,development andoperation principlescurrently deemed efficientinindustry based ontheir direct application. At thesame time, theexclusion criteriapermit disqualifyingstudies thatdonotofferthenecessarydesign/implementationdetails(e 1 ), thatrefertononfactualorunquantifiableevidence(e 2 and e 3 ),and thatdonotdiscussthelimitationsandpracticalimpactforthe pro-posedsolutionsoroutlinedissues(e 4 and e 5 ).Anindustrialstudy istobe selectedifitsatisfies all theinclusion criteria,while itis tobeexcludedifitsatisfiesatleastoneoftheexclusioncriteria.

Inadditiontotheinclusion/exclusioncriteriainTable1,to en-surethe quality ofthe selected grey literature, we selected only thoseindustrialstudiesthatweresatisfyingfouradditionalcontrol factors:

Practical experience → A studyis to be selected only if it is writtenbypractitionerswith5+experienceinservice-oriented design,developmentandoperation,orifitreferstoestablished microservicessolutionswith2+yearsofoperation.

Industrial case-study Astudyistobeselectedonlyifitrefers toatleast1industrialcase-studywhereaquantifiablenumber ofmicroservicesareoperated.

Heterogeneity → Theselected studiesreflectatleast5top in-dustrial domains and markets where microservices were suc-cessfullyapplied.

Implementation quantity → The selectedstudiesrefer to/show implementationdetailsforthebenefitsandpitfalltheydiscuss, sothatotherresearchersandpractitionerscanusethemin ac-tion.

Thecontrolfactors practical experience, industrial case-study and implementation quantity were checked against each single study, whereas the control factor heterogeneity waschecked against the overallsetofindustrialstudiestobeselected1.

1 The information for checking the inclusion/exclusion criteria and the control factors was excerpted from the selected industrial studies themselves, from the au- thors’ LinkedIn pages, and from the website/portfolio of the company where each selected industrial study was carried out.

(5)

Table 1

Inclusion and exclusion criteria for sample selection.

Inclusion i1 ) The study discusses the industrial application of microservices.

i2 ) The study discusses the benefits or shortcomings of microservice design, development or operation.

i3 ) The study reports on direct experiences, opinions or practices on microservices by educated practitioners.

i4 ) The study refers to a practical case-study of design, development or operation of microservices.

Exclusion e1 ) The study does not offer details on design or implementation of microservices.

e2 ) The study is not referred to industrial cases or other factual evidence.

e3 ) The benefits or pitfalls of microservices are not justified/quantified by the study.

e4 ) The study does not provide scope and limitations of proposed solutions/patterns.

e5 ) The study does not offer evidence of a practitioner perspective.

Attheendofourscreening,51industrialstudieswereselected based on the inclusion/exclusion criteria and on the additional control factors.The complete list of selected industrialstudies is providedinAppendixA.

3.4. Analysis & inter-Rater reliability assessment

To attainthe findings discussed inSection 4 we adopted the-maticcoding(BuderandCreß,2003).Theselectedsampleof arti-clesweresubjecttoannotationandlabelingwiththegoalof iden-tifying themesemerging fromthe analyzed text. This process of analysiswas executed in parallel over two 50% splits of the en-tire dataset, to ensure avoidance of observer bias. The coders of thetwosplits (i.e.,thefirst twoauthorsof thisstudy) werethen inverted and an inter-rater evaluation was enacted between the twoemerginglistsofthemes.Toevaluateinter-raterreliability,we adoptedthewidelyknownandadoptedKrippendorff

α

coefficient (orK

α

),whichmeasurestheagreementbetweentwoorderedlists ofcodesapplied aspartof contentanalysis(Krippendorff,2004). Aspartofourevaluation,K

α

wasappliedtwice.

We first applied the evaluation coefficient to measure the agreement between the two emerging lists of codes by the two independentobserverswhoindividuallycoded100%ofthedataset in2rounds. TheresultofapplyingK

α

tomeasuretheagreement betweenthesetwolistsamountedto0.76,slightlylower thanthe typicalreferencescore of0.80(i.e.,80% agreement). Adiscussion and analysis of disagreement points revealed misalignment be-tween thedepth of the codingstrategy, which wassubsequently addressed. Thismodification broughtthe agreementbetweenthe emerginglistsofcodestoK

α

=0.81.

K

α

wasthenappliedagaintotriangulatethe0.81scoreforthe final list of themes with its identical counterpart, coded by the third authorof thispaper, who re-coded the entiredataset with thefinal coding strategy. The agreement betweenthe final list A (obtainedbythefirst2authors)andafinallistB(obtainedbythe thirdauthor)wasevaluatedtoK

α

=0.92.

3.5. Replication package

To encouragerepeatabilityof ourapproach andverifiability of ourfindings, results, anddiscussion points, a replication package isfreelyavailableonGitHub2Thereplicationpackagecontainsthe intermediary artifacts andthe final results of our study. The se-lectedindustrial studiescan insteadbe freely accessedonline,by followingthebibliographicinformationreportedinAppendixA.

4. Results

In this section we analyze the selected grey literature under three different perspectives, aligned with the research questions Q 1 , Q 2 and Q 3 . We first provide a general overview of the se-lected industrial studies (Section 4.1). We then analyze in detail

2https://www.tinyurl.com/microservices-study .

Fig. 2. Distribution of selected industrial studies (a) by year and (b) by contribution type.

the pains andgains of microservice-based applications emerging from the selected grey literature (Sections 4.2 and 4.3, respec-tively).Wefinallyprovideasummaryofthefindingsofour analy-sis(Section4.4).

4.1. Overview of the selected grey literature

Inorder toaddress Q 1 ,we herebyprovidean overviewofthe selected studies [S1]-[S51] based on generic aspects, i.e., when andwheretheywere published,inwhichformat, andwhichwas their content. Table 2 shows how we classified [S1]-[S51] based ontheirpublicationyear,theirsource(i.e., ad-hoc blog maintained byexperts, community ofpractitioners, company website, industry-oriented magazine ,orindustrial summit ), thetype ofcontribution (i.e., blog post , industrial whitepaper ,or video ), andtheir contents (description of patterns or best practices, experience report , or dis-cussion of pros/cons of microservices). The table also shows the companies andindustrialsettings(i.e., product, case study or con- sulting )wheretheselectedindustrialstudieswerecarriedout.

Fig.2illustratesthedistributionoftheselectedstudiesbyyear andtypeofcontribution.Whilethedistributionofselectedstudies bycontributiontypedoesnotprovideanyparticularinsight,their distributionbyyearshowsthattheamountofindustrial contribu-tionsonmicroservicesisyearlyincreasing since2014.Thissignals thatmicroservicesaresteadilygainingattentionintheITindustry since2014,whenJamesLewisandMartinFowlergaverisetothe microservice-basedarchitecturalstylewiththeirfamous blogpost [S22].

Fig.3insteadillustratesthedistributionoftheselectedstudies by source and contents. We can observe that the selected stud-ies aremainly takenfromcommunity portalsandcompany web-sites,wherepractitionersandresearchersaremainlysharingtheir best practices, describing microservices-related patterns or just discussingadvantagesanddisadvantagesofadopting microservice-based solutions. The above clearlywitnesses the interests of the IT industryinmicroservices,intheir painsandgains,andinbest practices andpatternsthat canbe exploitedtobetter leverageof microservices.

Theaboveisevenmoreevident ifwerestrict thevisualization totheselectedstudiesthatwerepublishedlastyear(Fig.4),where

(6)

Table 2

Classification of the selected industrial studies based on year of publication, type of contribution, source, contents, reference company and industrial setting.

Study Year Contribution type Source Content Company Industrial setting [S1] 2015 Whitepaper Community Patterns Asurion Case study [S2] 2014 Whitepaper Community Pros/cons C4Media Consulting [S3] 2015 Blog post Company Pros/cons IGATE Case study [S4] 2016 Whitepaper Magazine Exp. report Comparethemarket Case [S5] [S5] 2017 Whitepaper Company Pros/cons Chakray Consulting [S6] 2017 Video Summit Pros/cons nearForm Consulting [S7] 2016 Video Summit Exp. report SimplicityItself Case study [S8] 2015 Video Company Pros/cons Dev2 Technologies Case study [S9] 2016 Whitepaper Community Patterns HCL Technologies Case study [S10] 2016 Blog post Ad-hoc blog Best practices JDriven Case study [S11] 2016 Whitepaper Magazine Patterns Techworld Consulting [S12] 2017 Video Summit Exp. report Netflix Case study [S13] 2015 Blog post Company Pros/cons ThoughtWorks Consulting [S14] 2016 Whitepaper Community Best practices Navica Consulting [S15] 2016 Whitepaper Community Patterns DynaTrace Case study [S16] 2015 Blog post Ad-hoc blog Pros/cons Spreadshirt Case study [S17] 2017 Blog post Company Best practices LogicRoom Case study [S18] 2014 Whitepaper Community Best practices Microsoft Case study [S19] 2016 Whitepaper Community Patterns WSO2 Case study [S20] 2017 Blog post Community Pros/cons SAP Case study [S21] 2015 Blog post Ad-hoc blog Best practices Tyro Payments Case study [S22] 2014 bBog post Company Patterns ThoughtWorks Consulting [S23] 2015 Whitepaper Community Best practices Pivotal Product [S24] 2015 Blog post Company Pros/cons MadeTech Consulting [S25] 2017 Whitepaper Magazine Best practices Nginx Product [S26] 2015 Blog post Company Exp. report Netflix Product [S27] 2017 Whitepaper Company Patterns Micro Consulting [S28] 2017 Video Summit Exp. report Speedment Case study [S29] 2015 Blog post Company Best practices Smartbear Consulting [S30] 2015 Video Company Pros/cons Sam Newman Consulting [S31] 2017 Whitepaper Community Pros/cons Apiumhub Consulting [S32] 2017 Blog post Company Patterns Valtech Consulting [S33] 2016 Whitepaper Community Best practices Avi Networks Consulting [S34] 2015 Blog post Company Best practices Neotys Consulting [S35] 2014 Blog post Ad-hoc blog Patterns Eventuate Case study [S36] 2014 Blog post Ad-hoc blog Patterns Eventuate Case study [S37] 2014 Blog post Ad-hoc blog Patterns Eventuate Case study [S38] 2016 Whitepaper Company Best practices Nginx Product [S39] 2014 Video Summit Patterns Pivotal Case study [S40] 2017 Blog post Company Pros/cons Oracle Consulting [S41] 2017 Video Company Pros/cons ThoughtWorks Consulting [S42] 2017 Video Summit Pros/cons ThoughtWorks Consulting [S43] 2016 Whitepaper company Best practices FacileLogin Case study [S44] 2014 Video Summit Pros/cons Netflix Case study [S45] 2017 Blog post Company Best practices Coding Sans Case study [S46] 2017 Whitepaper Community Best practices ServisBOT Consulting [S47] 2017 Whitepaper Community Pros/cons Nirmata Consulting [S48] 2017 Whitepaper company Patterns Microsoft Product [S49] 2017 Whitepaper Company Exp. report Microsoft Case study [S50] 2014 Blog post Community Best practices Contino consulting [S51] 2016 Blog post Community Pros/cons AND Digital Consulting

Fig. 3. Distribution of selected industrial studies (a) by source and (b) by contents.

companies are involved inthe majority ofthe contributions, and wherethecontributionsare mainlyfocusedonthepros andcons ofmicroservices, andonthe bestpractices andpatternsthat can beexploitedtobetterleverageofmicroservices.

Fig. 4. Distribution of selected industrial studies (a) by source and (b) by contents (restricted to the studies published in 2017).

Finally,Fig.5plotsthedistributionoftheselectedstudiesby in-dustrialsetting.Whilethedistributionovertheperiod2014–2017 (Fig. 5(a)) does not provide any particular insight, it is

(7)

interest-Table 3

A taxonomy for pains of microservices.

Stage Concern Pain

Design Architecture API Versioning, Communication heterogeneity, Service contracts, Service dimensioning, Size/complexity Security Access control, Centralised support, CI/CD, Endpoint proliferation, Human errors, Size/complexity Development Microservices Microservice separation, Overhead

Storage Data consistency, Distributed transactions, Heterogeneity, Query complexity Testing Integration testing, Performance testing, Size/complexity

Operation Management Cascading failures, Operational complexity, Service coordination, Service location Monitoring Logging, Problem location, Size/complexity

Resource consumption Compute, Network

Fig. 5. Distribution of selected industrial studies by industrial setting (a) over the period 2014–2017, and (b) restricted to the studies published in 2017.

ing to note that the industrial studies published in 2017 mainly focused on consulting. If we cross this data with the facts that microservicesgainedmomentum,andthatthetechnologyaround microserviceshasmatured(Jamshidietal.,2018),wecanconclude thatITcompaniesstartedfocusingonincreasingtheirconsultancy portfolioonmicroservices.

4.2. Microservices pains

We hereby introduce a taxonomy forclassifying the pains of microservices.Wealsoshow howweexploitedsuchtaxonomyto analyse currentindustrial perspectives on the pains of microser-vices.

4.2.1. A taxonomy for pains of microservices

Table 3 illustrates a taxonomy for the pains of microservices. Weobtainedsuch taxonomy byfollowing theguidelines for con-ducting systematic reviews in software engineering proposed by Petersenetal.(2008):

We first established the stages , by aligning Q 2 with common stepsofthelifecycleofsoftware(i.e.,design,developmentand operation).

We then identified the concerns by performing a firstscan of the selected studies, which wasfocused on Q 2 to ensure the validityofthetaxonomy.

Theconcreteterms(i.e.,the pains )wereexcerpteddirectlyfrom theselectedstudies,andtheyweremanuallyorganizedintothe abovementionedsub-classes.

As we anticipatedinSection 3,theobtainedtaxonomy under-gonevariousiterationsamongtheauthorsofthisstudy,anditwas submitted for validation to external experts from two organiza-tionslocatedintwo differentcountries.Thishasresultedinsome correctionsandamendmentstothefirstversion ofthetaxonomy, whichresultedinthetaxonomydisplayedinTable3.

4.2.2. Pains in the selected industrial studies

Table4showstheclassificationofallselectedindustrialstudies basedonthetaxonomyforpainsofmicroservicesintroduced ear-lier.The table provides a first overviewof the coverage of pains

Fig. 6. Coverage of the concerns in the taxonomy for pains of microservices. The size of each bubble is directly proportional to the number of selected industrial studies discussing a pain pertaining to the corresponding concern.

over the selected studies, despite (due to reasons of readability and space) it only captures the classification over the concerns listedinthetaxonomyofpains3Suchcoverageisalsodisplayedin Fig.6,fromwhichitisclearthatthemainconcernsarethedesign ofmicroservice-based architectures, thedistributedand heteroge-neous storage hampering the work of developers, and the man-agement and monitoring of operating instances of microservice-basedapplications.Security,testingandresourceconsumptionare alsonotableconcerns,whiletheconcretedevelopmentofeach mi-croserviceisnotsignificantlyperceivedasproblematic.

Wehereby discussin detailthenotable concernslisted above, stage by stage. We shall display the occurrences ofthe painsof eachconcerninasortedtable,andwewillcomparetheirweights4 byexploiting%-basedpiecharts.

Designstage.AccordingtoFig.6,themainconcernduringthe designofmicroservice-basedapplicationsistheirarchitecture.This is also witnessed by the yearly coverage of design-related con-cerns (Fig.7). Therecognitionofpainspertainingtothe architec-tureofmicroservice-based applicationis steadilyincreasing since 2014, anditkeepshigherwith respectto thatof security-related pains.

The coverage of the concretepains dueto the architecture of microservice-basedapplicationsarelistedinFig.8,whichalso dis-plays their weights in the selected industrial studies. The figure highlights what one can obviouslyexpect, namely that industrial researchers and practitioners are mostly pained by the size and complexityofthearchitecturesobtainedwhen designing applica-tionaccordingtothemicroservice-basedarchitecturalstyle.

3 The detailed classification, displaying each occurrence of each pain, is publicly available in the replication package (see Section 3.5 ).

4 We will measure the weight of a pain as the percentage of its occurrences among all occurrences of all pains pertaining to its same concern. This is analogous to what done by Pahl et al. (2017) to measure weights while classifying studies on cloud container technologies.

(8)

Table 4

Classification of the selected studies based on the concerns listed in the taxonomy for pains of microservices.

Design Development Operation Design Development Operation

Arc. Sec. Mic. Sto. Tes. Man. Mon. Res. Arc. Sec. Mic. Sto. Tes. Man. Mon. Res.

[S1] [S27] [S2] [S28] [S3] [S29] [S4] [S30] [S5] [S31] [S6] [S32] [S7] [S33] [S8] [S34] [S9] [S35] [S10] [S36] [S11] [S37] [S12] [S38] [S13] [S39] [S14] [S40] [S15] [S41] [S16] [S42] [S17] [S43] [S18] [S44] [S19] [S45] [S20] [S46] [S21] [S47] [S22] [S48] [S23] [S49] [S24] [S50] [S25] [S51] [S26]

Fig. 7. Yearly evolution of the coverage of the concerns pertaining to the design stage.

Fig. 8. Weights and occurrences of the pains pertaining to the architecture concern during the design stage.

Servicedimensioningisalsosignificantly recognizedasapain, with16oftheselectedindustrialstudiesrecognizingdifficultiesin determininghowmuch“micro” amicroserviceshouldbe.Allsuch studiesagreethatitisoftendifficulttoidentifythebusiness capa-bility/boundedcontext that should be assignedto each microser-vice, asthe boundaries among different capabilities/contexts are usuallynotthatsharp.

Anotherobservationworthdoingisaboutthepainsdueto ex-ploitingprogrammableAPIstoallowmicroservicesto intercommu-nicate. The group composed by the pains API versioning and ser- vice contracts is also significantly covered by the selected indus-trialstudies.Since communicationsamongmicroservicesisbased

Fig. 9. Weights and occurrences of the pains pertaining to security during the de- sign stage.

on APIs, the API provided by a microservice becomes a sort of contractbetweensuchmicroservicesandthoseconsumingitsAPI. Suchakindofcontractsshouldnotbe violated,ifwewish to al-lowmicroservicestocontinuetointercommunicate.Thisofcourse impacts onthe versioningof theAPIsprovided by microservices, hencepainingthedesignofmicroservice-basedarchitectures.

Fig.9insteaddisplaystheweightsandoccurrencesofthepains related to securing a microservice-based application. Other than the intrinsic complexity of securing microservice-based architec-tures(obviously dueto their size andcomplexity),the most rec-ognized pains concerning security are due to the access control andtothe endpointproliferation. Accesscontrol isrecognized as critical in 8 out of the selected industrial studies, all pointing out that the microservices in an architecture should be able to quicklyand consistently ascertainthe provenance and authentic-ityofarequest.The industrialstudies alsoagreethat thisis cur-rentlyfar frombeingeasy,mainly becauseofthe distributed na-tureofmicroservice-basedarchitectures,andsincetheir microser-vicesevolveasynchronously.Thepainsduetocontrollingaccesses inmicroservice-based architecturescould be mitigated if design-erswouldbeprovided withtoolssupportinga consistent, decen-tralizedaccesscontrol.However,ashighlightedby[S46]and[S23], thisiscurrentlynotthecase,asexistingtoolsprovideacentralized supportforsecuringmicroservices.

(9)

Fig. 10. Yearly evolution of the coverage of the concerns pertaining to the develop- ment stage.

Fig. 11. Weights and occurrences of the pains pertaining to storage during the de- velopment stage.

Endpoint proliferationisduetopartitioningofarchitecturesin suitesofindependent microservices.The attack surfacein mono-lithsorservice-oriented architectureswaslimitedtofew isolated servers. Microservice-based architectures instead require to open alotmoreports,to exposemoreAPIsandtodistribute authenti-cationandaccesscontrol(asalreadydiscussedabove).Theattack surfaceishencemuchmoreextended,andthisisthemainreason whyendpointproliferationissignificantlyrecognizedasapainby industrialresearchersandpractitioners.

Development stage. The selected industrial studies recog-nizestorage andtesting assignificant concerns while developing microservice-based applications. The same does not hold forthe developmentofthemicroservicesformingan applications(Fig.6). Giventhe above, we hereby focus on the concrete pains dueto storageandtestingconcerns.Theyearlycoverage ofsuchpainsis displayedinFig.10.The recognitionofbothstorage-and testing-relatedpainsoverall increasedfrom2014 to 2017,even ifwitha non-monotonicbehaviour.It isworth observing thatthe recogni-tionofstorage-relatedpainsstarteddecreasingin2017,whilethat oftesting-relatedpainsexperiencedan increasepeak inthesame year.Ifwecrossthisdatawiththetechnologywavesillustratedby Jamshidietal.(2018),wecanobservethatthetechnologyfor man-aging storage in microservice-based applicationis maturing, and thisresultedinstartingtoreduce storage-related painsfor devel-opersofmicroservices.Atthe sametime,themore microservices arewidespreading, themoredevelopers arepained bytheir test-ing[S6].

ThepainsduetostorageconcernsarelistedinFig.11,together withtheirweightsandoccurrencesintheselectedindustrial stud-ies.Fromthefigureitisclearhowstorage-relatedpainsarecaused bythedistributednatureofstorageinmicroservice-based applica-tions. 21 ofthe selected industrial studies highlightthat, by dis-tributingthestorageoverthevariousmicroservicesformingan ap-plication,itbecomesapain toensuredataconsistency. Theyalso highlighthoweventual consistencymayhelpmitigatingthispain, evenifitisnoteasytoensure.Eventualconsistencymayalsonot beaviableoptioninsomecases,especiallywhenconsistencymust beensuredonsensitivedata.

Operating withdistributed data storesis another pain signifi-cantlyrecognized by industrialresearchers andpractitioners. The

Fig. 12. Weights and occurrences of the pains pertaining to testing during the de- velopment stage.

Fig. 13. Yearly evolution of the coverage of the concerns pertaining to the operation stage.

intrinsiccomplexityinimplementingtransactionsoverdistributed datastoresispointedoutin18oftheselectedindustrialstudies.9 ofthemalsohighlightthecomplexityofbuildingqueries combin-ingdatastoredindistributedandheterogeneousdatastores.

Fig.12insteadillustratestheweightsandoccurrencesrelatedto theconcernoftestingwhiledevelopingmicroservice-based appli-cations.Thefigurehighlightshowperformancetestingisbyfarthe mostchallengingpainamongthoserelatedtotesting microservice-basedapplications.Asdiscussedin[S34]and[S6],a microservice-based application is partitioned in a huge number of indepen-dentlyevolvingservices,andthismakesitchallengingtomeasure the performances of each of them and of the application itself. This especially holds when testers wish to measure user experi-ence through the user interface of a microservice-based applica-tion.

Operationstage.AsshownbyFig.6,all threeconcernsofthe operation stage are recognized as significant by the selected in-dustrial studies, withmanagement andmonitoring beingslightly more covered than resource consumption. This can be observed alsoinFig.13,whichplotstheyearlycoverageofoperation-related concerns in the period 2014–2017. The recognition of pains re-lated to the management and monitoring increased in 2016 (if compared withthat in 2014),while it kept stable from2016 on. Therecognitionofpainsrelatedtoresourceconsumptionfollowed the opposite behaviour, as it decreased from 2014 to 2016, by then experiencingan increase peakfrom2016 to2017. Thelatter meansthatresourceconsumptionbecameafirst-classconcernfor theindustrial researchersandpractitioners authoringthe selecte-dindustrial studies, andthis may be due to the widespread and day-by-day work with microservice-based applications and tools (Jamshidietal.,2018).

The concrete pains due to the management of microservice-basedapplications,their weightsandoccurrencesaredisplayedin Fig.14. The figurehighlights how theintrinsic complexityof op-erating applications composed by distributed and heterogeneous microservices is the main challenge in the scope of managing microservice-basedapplications.

The above mentioned complexity is partly explained by the three other pains significantly discussed by the industrial re-searchersandpractitioners authoringtheselectedindustrial

(10)

stud-Fig. 14. Weights and occurrences of the pains pertaining to management during the operation stage.

Fig. 15. Weights and occurrences of the pains pertaining to monitoring during the operation stage.

Fig. 16. Weights and occurrences of the pains pertaining to resource consumption during the operation stage.

ies.Thepartitioningofanapplicationinmicroservicescanchange overtime,aswellasthenumberofreplicasofamicroserviceand theiractual locations(i.e.,thehostswherethey aredeployed,and the ports on which they are listening). This makes it challeng-ingtolocateandcoordinatethemicroservicesformingan applica-tion.Additionally,ifnotproperly isolated,afailure ina microser-vices may causethe failure of another, andso on. Handling cas-cading failureis henceanother factorhamperingtheoperationof microservice-basedapplications.

Fig.15 displaystheweights andoccurrencesofthe pains per-tainingtomonitoringmicroservice-basedapplications.Similarlyto the case of management, the primary challenge is the intrinsic complexityofmonitoringanapplicationcomposedbyahuge num-berdynamicallyevolving,heterogeneousmicroservices.

Accordingtotheindustrialresearchersandpractitioners author-ingtheselectedindustrialstudies,suchacomplexityispartlydue to other two significantly discussed pains, i.e., logging and prob- lem location . 12 of the selected industrial studies point out the painsduetohandlinga hugenumberofdistributedlogs,one for eachmicroserviceforminganapplication.This,alongwiththe dis-tributednatureofmicroservice-basedapplication,makesithardto identifythesourceofanissueinanapplication, asdiscussedin9 oftheselectedindustrialstudies.

Fig. 16 illustrates the weights of the pains related to the re-sources consumedby amicroservice-based application, duringits operation stage. An increase in resource consumption (with re-spect to monolithic/service-oriented applications) is significantly recognizedbytheselectedindustrialstudies.7outoftheselected industrial studies highlight how the higher number of running services requires an increased amount of runtime environments,

Fig. 17. Coverage of the concerns in the taxonomy for gains of microservices. The size of each bubble is directly proportional to the number of selected industrial studies discussing a gain pertaining to the corresponding concern.

whichinturnresultsinanincreasedconsumptionofcompute re-sources.

Theincreasedconsumptionofnetworkresourcesemergestobe by farmore challenging. 17out ofthe selected industrialstudies highlightthat,sincethemicroservicesinanapplication intercom-municate through remote API invocations, applications generate a much higher network traffic withrespect to monoliths (where modulesinteractthroughin-memorycalls)orservice-based appli-cations(composedby alowernumberofservices,hencereducing theamountofremoteAPIinvocations).

4.3. Microservices gains

Inthissection,we firstpresenta taxonomyforclassifyingthe gainsofmicroservices,andwethenillustratehowweexploitedit toanalysecurrentperpectivesofindustrialresearchersand practi-tionersonthegainsofmicroservices.

4.3.1. A taxonomy for gains of microservices

Weherebypresentataxonomyforclassifyinggainsof microser-vices(Table5).Itcanbehelpfultoanalysethecurrentstateofthe artonmicroservicesin theIT industry,aswellasto identify po-tentialtrendsandresearchdirections.Theproposedtaxonomyfor gainsof microserviceswas obtainedwithan approach similar to thatfordeterminingthetaxonomyforpains(Section4.2.1).

Theobtainedtaxonomyundergonevariousiterationsamongthe authorsofthisstudy,anditwasalsosubmittedtoexternalexperts fromtwodifferentresearchinstitutions.Thisresultedinsome cor-rectionsandamendmentstothefirstversionofthetaxonomy,and thefinal outcomeisthetaxonomydisplayedinTable5.Thelatter was then validated through the inter-rater reliability assessment describedinSection3.4.

4.3.2. Gains in the selected industrial studies

Weclassifiedtheselectedindustrialstudiesbasedonthe taxon-omyforgainsofmicroservices(Table5).Theobtainedclassification is displayedin Table 6. Due to reasons ofreadability andspace, thetable only capturesthe classificationover the concernslisted inthetaxonomy ofgains5 Itstill provides afirst overviewofthe coverageofgainsovertheselectedstudies,whichisevenmore ev-identinthebubbleplotinFig.17.Thefigureclearlyhighlightshow biggestgainscomefromarchitecture concerns,fromthe exploita-tion of design patterns, from the development of microservices,

5 The detailed classification, displaying each occurrence of each gain, is publicly available in the replication package (see Sect. 3.5 ).

(11)

Table 5

A classification framework for gains of microservices. Stage Concern Gain

Design Architecture Bounded contexts, Cloud native, Decentralised governance, Fault tolerance, Flexibility Design patterns API gateway, Circuit breaker, Database per service, Message broker, Service discovery Security Automation, Fine-grained policies, Firewalling, Isolation, Layering

Development Microservices CI/CD, Loose coupling, Reusability, Service size, Technology freedom Storage Data persistence, Data isolation, Microservice-orientation Testing Automation, Rollback, Unit testing, Updates

Operation Deployment Containerisation, Independency, Reliability, Speed Management Fault isolation, Scalability, Updateability

Table 6

Classification of the selected studies based on the concerns listed in the taxonomy for gains of microservices.

Design Development Operation Design Development Operation

Arc. Des. Sec. Mic. Sto. Tes. Dep. Man. Arc. Des. Sec. Mic. Sto. Tes. Dep. Man.

[S1] [S27] [S2] [S28] [S3] [S29] [S4] [S30] [S5] [S31] [S6] [S32] [S7] [S33] [S8] [S34] [S9] [S35] [S10] [S36] [S11] [S37] [S12] [S38] [S13] [S39] [S14] [S40] [S15] [S41] [S16] [S42] [S17] [S43] [S18] [S44] [S19] [S45] [S20] [S46] [S21] [S47] [S22] [S48] [S23] [S49] [S24] [S50] [S25] [S51] [S26]

andfromapplicationpeculiaritiessimplifyingtheir actual deploy-mentandmanagement. Security designandstorage implementa-tionalsoprovidenotablegains,whileapplicationtestingisnot sig-nificantlyimpactingontheadvantagesofdeveloping microservice-basedapplications.

In the following, we provide details on the notable concerns highlighted above. We shall proceed concern-wise, by listing the occurrences of gains in sorted tables, and by comparing their weightsthrough%-basedpiecharts.

Designstage.Themainsourcesofgainsduringthedesignstage are the architecture peculiarities and the exploitation of design patterns(Fig.17).ThiscanbeobservedalsoinFig.18,whichshows the evolution of the coverage of design concerns in the period 2014–2017.Thefigure alsoshowsthattheinterests forgains per-tainingtothearchitectureconcernissteadilyincreasing,whilethat fordesignpatternsinstead keepsstable. The samedoesnot hold forsecurity-relatedgains,which(afteraperiodofslightincrease) arestartingtoloosetheirappealfortheindustrialresearchersand practitionersauthoringtheselectedindustrialstudies.

The concrete gains due to microservice-based architectures, their weights and occurrences in the selected industrial studies areillustrated inFig. 19.Bounded contexts (which are an intrin-sicpeculiarityofmicroservice-based architectures) emergeasthe primary architecturalgain, with 24out of the selectedindustrial studieshighlightingtheirbenefits.Thenotionofboundedcontexts comes from (Evans, 2003), and it makes microservices

selfcon-Fig. 18. Yearly evolution of the coverage of the concerns pertaining to the design stage.

tained. A microservicecan be analysed, understood andupdated without knowing anything about the internals of the other mi-croservices inan architecture. Thisimpacts on the governanceof anapplication,whichcanbedecentralisedbyassigningthe gover-nanceofmicroservicestodifferentgroups(aspointedoutby7out ofthe24studiesdiscussingthebenefitsofboundedcontexts).

Industrial researchers and practitioners are also highlighting that microservice-basedarchitecturesare faulttolerantby design, thatmicroservicescanbeflexiblyaddedandremovedfroman ar-chitecture,andthatmicroservice-basedarchitecturesarecloud na-tive.Faulttoleranceandcloudnativenessofmicroservice-based ar-chitectures are two of the main reasons why the IT industry is

(12)

Fig. 19. Weights and occurrences of the gains pertaining to the architecture con- cern during the design stage.

Fig. 20. Weights and occurrences of the gains pertaining to design patterns during the design stage.

Fig. 21. Weights and occurrences of the gains pertaining to security during the de- sign stage.

strongly interestedin them, with Netflix being one of the most prominentexamples[S26],[S12].

Thecoverage ofdesignpatternsisinsteaddisplayedinFig.20. The design pattern database per service is the most discussed in the selected industrial studies, with 20 out of them highlighting that eachmicroserviceshould beequippedwithitsown database (ifitneedsapersistentstorage,ofcourse). API gateway and circuit breakers are also significantly covered. 16 of the selected studies explain how the API gateway design pattern permits decoupling the clients ofa microservice-based applicationfrom its internals, while 12 studies discuss how circuit breakers can help mitigat-ing issues dueto failures (such as cascadingfailures, one of the pains displayed in Fig. 14). Service discovery and message brokers arealsodiscussed,tomitigatethepainsofservicelocationand ser-vicecoordination,andtoallowasynchronousservice intercommu-nications, respectively. More generally, 30of the selected studies were discussing atleastone ofthe above listedpatterns, byalso showinghowdesignersexploitthemtomitigatesomeofthepains discussed inSection4.2.Thishighlightsthe importanceofdesign patterns,andtheneed foradditionalpatternsallowing tofurther mitigatethepainsofmicroservice-basedarchitectures[S37].

Microservice-based architectures are also bringing some security-related gains, whose coverage in the selected industrial studiesisdisplayedinFig.21.Firewallingemergesastheprimary gain, with9oftheselectedindustrial studiesdiscussing howAPI gatewayscansimplifyitinmicroservice-basedarchitectures.

Othergainsworthmentioningareduetothesupportoflayered andfine-grainedsecurity policies.By defining hierarchical group-ings of the microservices forming an architecture, designers can applydifferentlygrainedsecuritypoliciestothedifferentlayersin a hierarchy. The partitioning of applications into small,

indepen-Fig. 22. Yearly evolution of the coverage of the concerns pertaining to the develop- ment stage.

Fig. 23. Weights and occurrences of the gains pertaining to the concrete develop- ment of microservices.

dent microservicesalso simplifies the design of automated secu-rity policiesand itfavours a better isolationamongthe different componentsinan application(withrespectto monolithic/service-orientedarchitectures).

Development stage.According to Fig. 17, the developmentof microservices is the main source of gains in microservice-based architectures. This is also witnessed by the yearly coverage of development-related concerns (Fig. 22). The recognition of gains pertainingtothedevelopmentofmicroservicesissteadily increas-ingsince 2014, anditkeepsmuch higherwithrespect tothat of thegainspertainingtostorage.

The coverage of the concrete gains due to the development ofmicroservicesis displayedin Fig.23,which alsodisplaystheir weights in the selected industrial studies. The loose coupling (whichallowstoindependentlydevelopthemicroservicesforming anapplication)andthefreedom inchoosing thetechnologystack forimplementingeachmicroservicesarethemostattractivegains. Theyare strictlyrelated toone another, andtheir groupingisby farmorecoveredwithrespecttotheothergainspertainingtothe developmentofmicroservices.

Anothersignificant gain emergingfromthe selectedindustrial studiesisrelatedtoCI/CD,aDevOpspracticeenablingthe contin-uousreleaseofupdatedversionsofasoftware(Nygard,2007). As pointedout by15oftheselectedindustrialstudies,microservices nativelysupportCI/CD.Thelattercanbedirectlyoperatedon mi-croservices,henceallowingtocontinuously andindependently re-leaseupdatedversionsofthemicroservicesforminganapplication. The actual size of microservicesand their reusability are also discussedintheselectedindustrialstudies.Asreusability is pecu-liartomanyservice-basedarchitecturalstyle,itismoreinteresting to commenton how the actual size of microservicesimpacts on their development. Microservices focus on doing one thing well, andtheir business logic turn out to be small and self-contained [S31]. 14 of the selected studies highlight how this makes them quick to develop and easy to understand for new personnel as-signedtotheirdevelopmentandmaintenance.

Microserviceshave alsosome positive impact onstorage con-cerns(Fig.17).Thecoverageofthestorage-relatedgainsinthe se-lected industrialstudies isreported inFig.24.The only gain sig-nificantlycoveredisthatrelatedtothemicroserviceorientationof

(13)

Fig. 24. Weights and occurrences of the gains pertaining to storage during the de- velopment stage.

Fig. 25. Yearly evolution of the coverage of the concerns pertaining to the operation stage.

Fig. 26. Weights and occurrences of the gains pertaining to deployment during the operation stage.

storage.15oftheselectedindustrialstudiesindeedhighlightthat, whenamicroservicemustbe equippedwitha backenddatabase, its developer can freely choose the database type (e.g., SQL or NoSQL)and how to structure the data in it. This is because the only serviceaccessing to such databasewill be the microservice sheis developing(following the database per service design pat-tern).

Operation stage. As shown by Fig. 17, microservices provide significant benefits also during the operation stage. The recog-nition of gains pertaining to the deployment and management of microservices is steadily increasing since 2014 (Fig. 25). By crossing this data with the technology waves highlighted by Jamshidietal.(2018),wecanobservethatthemoretechnologyfor supportingmicroservicesisgettingmature,themoremicroservice becomeattractiveforthegainstheybringwhilebeingoperated.

The coverage and weights of the gains pertaining to the de-ploymentof microservices are illustrated in Fig.26. The primary gainisindependency.19oftheselectedindustrialstudieshighlight thatmicroservicescanbedeployedandundeployedindependently fromonetoanother.Microservicesaredesignedanddevelopedto beself-contained ina boundedcontext. Evenifa microserviceis exploiting(atruntime)somefunctionalitiesprovidedbyother mi-croservices,itcanbedeployedwithoutrequiringtheiravailability. Oncerunning,ifoneoftherequiredmicroservicesisnotavailable (becauseithasnotbeendeployedyet,orbecauseitfailed),the de-ployedmicroservicecontinuetoberunning,evenifpartlyworking [S31].

Fig. 27. Weights and occurrences of the gains pertaining to management during the operation stage.

Othersignificantgainsarerelatedtocontainerisationandspeed of deployment. Containers (and Docker, in particular) emerge as the natural way of packaging and shipping microservices, hence fostering the build of portable, cloud-based deployments. This, alongwiththefact thatmicroservicesare smallsized, makes mi-croservicesveryfasttogetupandrunning.

Fig.27 instead displaysthe coverage andweights ofthegains that microservices bring to the operation ofthe management of applications. The figure clearly shows tha scalability emerges as the primary gain for the industrial researchers andpractitioners authoringthe selectedstudies. 31of theselected industrial stud-ies indeedhighlighthow microserviceapplicationsnaturally sup-port thehorizontalscaling oftheir microservices,aswell ashow microservicesscalequicklyandreactively(alsothankstotheir in-dependenceandspeedofdeployment).

Faultisolationandupdateabiltyarealsosignificantlyrecognised asgainspertainingtothemanagement ofmicroservice-based ap-plications.14oftheselectedstudiespointoutthatthepartitioning ofapplicationinboundedmicroservicessimplifiestheoperationof faultisolation,alsothankstotheexploitationofthedesignpattern calledcircuitbreaker(discussedearlier).14oftheselectedstudies insteadpointoutthat,thankstotheindependenceamongthe mi-croservicesinanapplication,liveupgradesandliveupdatescanbe appliedto arunningmicroservice,without requiringto touchthe othermicroservicesofanapplication.

4.4. Summary

Since2014, when JamesLewisandMartinFowler gaverise to the microservice-based architecturalstyle withtheir famous blog post [S22],microservices are steadilyattracting increasing atten-tionby theITindustry.Thisissupported bythe trendsdiscussed inSection4.1,whichansweredtoour Q 1 byillustratinghow com-munitiesofpractitionersandITcompaniesaremoreandmore in-volved inindustrialresearchon microservices.The growing inter-estinmicroservicesbytheITindustryisevenmoreevidentifwe focusonthecontributionspublishedlastyear,whosevastmajority wasdirectlyprovidedbyITcompanies.

The contents presentedinthe selected industrialstudies span from discussing advantages and disadvantages of microservices, to proposing designpatterns andsharing bestpractices to better leverage ofmicroservices.This is inline withourresearch ques-tions Q 2 and Q 3 ,whichwereansweredinSections4.2and4.3, re-spectively.Inthefollowing,we reportthemainfindings resulting fromthe analysisoftheselected industrial studies,based onour taxonomies forpainsandgainsof microservices(Tables 3and5, respectively).

4.4.1. Summary of pains

The pains of microservice-based applications are mainly due to their intrinsic complexity.As recognized by almost all the se-lected industrial studies, the design,the development and/or the operation of microservice-based applications is hampered by the

(14)

fact that the business logic in such applications is heavily dis-tributedovermanyindependentandasynchronouslyevolving mi-croservices.Thisgeneratesvarious design,developmentand oper-ationalchallenges,whicharerecappedbelow.

Atdesigntime,theprimarypainofthedesignof microservice-based applications is the dimensioning of services. It is indeed often difficult to determine the partitioning of an application in boundedcontexts,astheboundariesamongthedifferentbusiness capabilities ofan application areusually not sharp.The fact that intercommunications are purely basedon remote API invocations isalsocreatingconcretepains.TheAPIprovidedbyamicroservice becomesasortofcontractbetweensuchmicroserviceandthe mi-croservicesconsumingitsAPI.Thisdirectlyimpactsonthe version-ingofAPIs,asnewAPIversionmustalwaysberetro-compatibleto avoidviolatingthecontractsamongmicroservices,henceallowing themtocontinuetointercommunicate.

Securityisalsogeneratingpainsatdesign-time,mainlydueto accesscontrolandendpointproliferations.Accesscontrolisoneof themain challenges, asthe designofmicroservice-based applica-tion should allow to the microservices formingan applicationto quickly andconsistently ascertain the provenanceand authentic-ityof arequest (which isfar frombeingeasy duetothe heavily distributed nature of microservice-based applications). Addition-ally,endpointsproliferateinmicroservice-basedapplications,asall theirmicroservicesareexposingremotelyaccessibleAPIsexposed. Theattacksurfacetobesecuredishencemuchlargerwithrespect toclassicalmonolithic/service-orientedapplications.

At development time, the primary pains come from storage-relatedissues.Bydistributingthestorageoverthemany microser-vicesforminganapplication,itbecomeschallengingtoensuredata consistency.Eventualconsistencyisanoptiontomitigatethispain, even ifnot always viableand not easy to implementtoo.At the sametime,theheavydistributionofdatamakesitchallengingalso to implementdistributedtransaction,andevento querythedata (alsobecauseoftheheterogeneityofthedatastorestobequeried). Testingisalsopainingthejobofdevelopers.Microservice-based applicationpartitiontheirbusinesslogicoverindependently evolv-ing services,andthismakesitchallengingtomeasurethe perfor-mancesoftheapplicationitself.Thisespeciallyholdswhen devel-opers are required to test theuser experienceof a microservice-basedapplication[S34].

Theoperationofmicroservice-basedapplicationsisalsopained bytheirdistributedanddynamicnature.Microservicescanflexibly be added orremoved froman application, they can be scaled in andout, orthey canbe migratedfromone hosttoanother. This, along withthe huge number of microservices forming an appli-cation,makesitchallengingtolocateandcoordinatetheconcrete instancesofthemicroservicesinanapplication.Additionally,ifnot properlyisolated,afailinginstanceofamicroservicecangenerate acascadeoffailureinthemicroserviceinstancesdependingonit.

At thesame time,the distributionof theinstances ofthe mi-croservices in an application, results in the distribution of their logs. Delving through many distributed logs is of course a pain, especiallywhenthe operatorsofamicroservice-basedapplication are requiredto identifythe reasons/problemcausing an issuein suchapplication.

The primary pain during the operation of microservice-based applicationsis howevergivenby theirresource consumption.The require to run more services with respect to monolithic and service-based application, which require more runtime environ-ments tobe distributed,andwhichinteractbased onremote API invocations.Thisincreasestheirconsumptionofcomputeand net-workresources,withthelatterbeingtheprimaryworryofthe in-dustrialresearchersandpractitionersauthoringtheselected stud-ies.

4.4.2. Summary of gains

The primary gains of microservices are due to peculiar prop-erties of microservice-based architectures, to design patterns al-lowingtobetter exploit them,tothe easeof developmentofthe microservicesinan application,andtothepossibilityof indepen-dently deploying and managingthe microservices in an applica-tion.

Consider the design of microservice-based architectures. De-spiteidentifying thepartitioningof applicationsin bounded con-texts is not easy, microservices actually gain from the bounded-nessof their context.Amicroserviceis self-contained,andit can be analyzed, understood andupdated without knowing anything aboutthe restofthearchitectureit ispartof.Thispositively im-pactson thegovernance ofapplications,which canbe decentral-izedbyassigningthegovernanceofdifferentmicroservicesto dif-ferent groups. Additionally, bounded contexts enforce fault toler-ancebydesign,andtheypermitflexiblyaddingandremoving mi-croservicestoandfromanarchitecture.Theresultingarchitectures arealsocloud-native,astheir boundedcontexts/microservicescan beindependentlymanagedoverdifferentcloudplatforms.

Themostlyrecognized gainsatdesign-time arehoweverthose relatedto theexploitation of designpatterns. Thedesign pattern database per service permits enforcing the independence among microservices,by equipping each microservicewith its own data store (if needed). API gateway s permit decoupling the clients of a microservice-based application from its internals, while circuit breakers and service discovery tomitigate thepainsrelatedto the failureandservicecoordination/locationofmicroservices.The im-portanceof design patternsfor mitigatingthe painsof microser-vicesisalsoexplicitlyhighlightedbyRichardson[S37].

Thedistributednature ofmicroservicescan alsoprovidesome security-related gains, even the pains it brings are more signif-icantly recognized in the selected grey literature. Microservice-based architecture indeed naturally support the possibility of defininghierarchicalsecuritypolicies,withdifferentlygrained se-curity policiesassociated withdifferentlevels in ahierarchy. De-signpatternsalsohelpsecuringmicroservices,withtheAPI gate-way emerging as the most prominent example, asit thoroughly simplifiesfirewallingmicroservice-basedarchitectures.

Development emerges by far as the stage gaining most from microservices.Inthisperspective,themostimportantgains recog-nizedbytheindustrialresearchersandpractitionersauthoringthe selected studies are the loose coupling among the microservices inanapplication(whichpermitsindependentlydevelopingthem), thefreedominchoosingthetechnologystackfordevelopinga mi-croservice,andthepossibilityofchoosingthedatastorethat best suitstheneedsofamicroservice.

Other important gains come from the ease of use of DevOps techniquesinmicroservice-basedapplications,andfromtheactual sizeofthemicroservicesforminganapplication.Ontheonehand, CI/CDcan be directlyoperated on each microserviceinan appli-cation, henceallowing to continuously releaseupdated/upgraded versionsof such microservice, independently fromthe rest ofan application. On the other hand,microservices focus on doing on thingandondoingitwell,withabusinesslogicthatturnsoutto besmallandself-contained[S31].Thismakesitquicktheir devel-opment,aswellastheirunderstandingbynewpersonnelassigned totheirdevelopmentandmaintenance.

Finally, consider the operation of microservice-based applica-tions.Thepossibilityofindependentlydeployingthemicroservices inanapplicationisrecognizedasoneofthemostimportantgains duetomicroservices.Amicroservicecanindeedbedeployed with-outrequiringtheavailability ofothermicroservices,evenifit ex-ploitstheirfunctionalities atruntime.Oncerunning,ifone ofthe requiredmicroservicesisnotavailable(becauseithasnotbeen de-ployed yet, orbecause it failed), the deployedmicroservice

Referenties

GERELATEERDE DOCUMENTEN

Figure 7 shows the average number of service discovery messages sent and received per node for a network of 100 nodes, depending on the percentage of moving nodes.. We represent

het publiek, oud en jong, onwetend en ingewijd, het hele jaar door gemakkelijk getuige kan zijn van wat in de loop der seizoenen, te be- ginnen met 1 januari en te eindi- gen met

Although, a substantial body of academic research exists on the adoption and implementation of technology, a review of the practical recommendations regarding institutional

However, “We are just beginning to understand the complexities of how and why different perceptions of relationships may impact […] the exchange.” (Cogliser et al.,

The development of the user participation theory could benefit if, besides the more widely presented views of physicians and nurses ((end-) users) in the user participation

Findings – Based on the classification framework a number of key findings emerged: studies on monetary incentives primarily applied an economical theory; the large majority of

Independent variables Organizational characteristics Digital innovation embeddedness Type of Innovation Managerial characteristics Knowledge management Capabilities

Since the descriptive analysis in the previous chapter identified ‘crowdsourcing’ as the most frequently studied topic within the research field of open innovation, we will