Microservices as an Evolutionary Architecture of Component-Based Development: A Think-aloud Study
MMicroservices as an Evolutionary Architecture ofComponent-Based Development:A Think-aloud Study
Reza M. Parizi (cid:63)
Department of Software Engineering and Game DevelopmentKennesaw State University, Marietta, GA 30060, USA [email protected]
Abstract.
Microservices become a fast growing and popular architec-tural style based on service-oriented development. One of the major ad-vantages using component-based approaches is to support reuse. In thispaper, we present a study of microservices and how these systems arerelated to the traditional abstract models of component-based systems.This research focuses on the core properties of microservices includingtheir scalability, availability and resilience, consistency, coupling and co-hesion, and data storage capability, while highlighting their limitationsand challenges in relation to components. To support our study, we in-vestigated the existing literature and provided potential directions andinteresting points in this growing field of research. As a result, using mi-croservices as components is promising and would be a good mechanismfor building applications that were used to be built with component-based approaches.
Keywords:
Microservices, Component-based development, Reusability,Architecture, Services, CBSD.
Microservices are the new rising architecture in the enterprise market, andmainly adopted by massively deployed applications such as Netflix, eBay, Ama-zon and even Uber [1]. Microservice has similarity with component-based de-velopment (CBD) on objectives which is to create a large complex architecturefrom existing small reusable elements by assembling and replacing interoperableparts [2]. The CBD (or often CBSD) idea was first introduced by Douglas McIl-roy [3] and it was intended to use components in the commercial production.Since after, many researches on CBD were conducted within last 20 years [4],[5]. The definition of microservice goes an architectural pattern for developmentof distributed applications that builds an application as a collection of looselycoupled services or smaller independent components that implement businesscapability [6]. Microservices communicate with lightweight mechanisms, often (cid:63)
Corresponding author. Tel: +1-470-578-2118; Fax: +1-470-578-9219. a r X i v : . [ c s . S E ] M a y Reza M. Parizi an HTTP resource API. As the demand for complex applications are increasing,driven with frequent changes in technology stack, developmental practices haveevolved from the traditional ”monolithic” architecture, which is all developed allin one piece, to a more fine-grained distributed architecture, most recently ad-vocated by microservices. Benefits of microservices over monolithic architectureare scalability and reusability, as well as efficiency for the most part.Over the past two decades, industry needs have driven software architecturein various directions from client-server, service-oriented architecture (SOA) tomicroservices. As the technologies (e.g., CORBA, OSGi, Sun JavaBeans or En-terprise JavaBeans components) and traditional practices of CBSD are gettingless popular and demanding, it makes more sense to study whether microservicescould be used as components to surrogate these practices as promised. Inspiredby this, the goal of this research paper is to explain microservices in the field ofcomponent-based software development (CBSD), analyzing their related prop-erties to provide an overview of the topic and to lay a first-step basis for futureresearch in the CBSD.The rest of the paper is organized as follows. Section 2 gives an overviewthe related work. Section 3 contains the research design and synthesis of results.Sections 4 discusses briefly the main observations with respect to research ques-tions, and outlines future directions. Finally, Section 5 summarizes concludingremarks.
In this part, we overview the most current and existing researches around mi-croservices architectures whose aims have been directed to assessing and evalu-ating works in the field.Francesco et al. conducted a meta-study research on architecting microser-vices [1]. Their research focuses on (i) the publication trends of research studiesabout architecting microservices (ii) the focus of research on architecting mi-croservices, and (iii) the potential for industrial adoption of existing research onarchitecting microservices. They searched over 300 papers and selected 71 pri-marily studies. They concluded architecture analysis emerges as the most popu-lar architecting activity and research scope, but supports for proper architectingof microservices are still immature.Alshuqayran et al. performed a systematic mapping study on microservicearchitecture [7]. They selected 33 articles published in between 2014 to 2016.Their study focuses on (i) the architectural challenges faced by microservice-based systems, (ii) the architectural diagrams used for representing them, and(iii) the involved quality requirements. Their research is somewhat similar in thetechniques we used, however their research questions were different than ours.Shadija et al. carried out a research on understanding of microservices [6].In their research, they approached by comparing microservices architecture withservice-oriented architecture that identified key characteristics that will assistdevelopers to choose the most suitable approach. They concluded that SOAPSer- unning title 3 vice is a communication layer on top of the business logic of an application whilea microservice is a service-oriented architectural style for the application.Sampaio et al. conducted a research on supporting microservice evolution[8]. In this research, they outlined checking for upgrade consistency, identify-ing architectural improvements and evaluating changing deployment trade-offs.In their article, they concluded that microservices can perform a flexible andscalable approach of distributed business logic.Most recently, Cerny et al. [9] proposed a comprehensive survey-nature studycontextualizing the main concepts behind both SOA and microservices. In thiswork, the authors explained the key differences between these two architecturesand their features, and presented research and industry viewpoints and chal-lenges on adoption of microservices compared to SOA.In summary, our study of literature (including the aforementioned works)reveals that the concept of CBSD has not been discussed in the current literaturerelated to microservices, which is the main center of discussion in this research.
The main objective of this study is to explain microservices in the field ofcomponent-based software development (CBSD), analyzing their related prop-erties to provide an overview of the topic and to lay a first-step basis for futureresearch in the CBSD. As a result, the main research question addressing thiswork is: can microservices be used as components in massively deployed and com-plex applications?
Since microservices can intuitively be used broadly for terms,we specify certain key features of microservices and discuss their relevance.
To support the main research question mentioned above, we formulated the fol-lowing research questions to drive the study:RQ1. What are the main motivations to study microservices in CBSD?RQ2. What are the limitations of microservices in this field?RQ3. What should be the future research in this field?
Reza M. Parizi
Delving into Micro-Deployments, we assume that the term can roughly equateto broad-ranging updates to small services, in that minor updates done on anear-constant rate of development are distributed among a broad range of end-users. Furthering this definition, we can elaborate on the topic by looking at anexample of such, in this case, the app Uber, developed by Uber Technologies Inc.and their deployment of micro-updates to their app and servers. They ”developedMicro Deploy (known as Deploy for short), as in-house deployment system thatbuilds, upgrades, and rolls back services at Uber” [10].
In this section, we examine the core properties of microservices, and discuss howthey could be related to CBSD with respect to the selected studies.
Microservices for Expansive Scale.
When we look at an expansive scaleregarding DD, what are we looking for? We assume that we want to see a micro-deployment reach a broad range of deployment hits, but still maintain a balanceof usage. In [8], we can see that ”important feature of microservices is theirability to scale in/out by removing or creating microservices replicas as necessary.This causes the microservices instances to have a short lifetime, inducing furtherdynamism and complexity”. They also go into detail on an example wherein theysplit a microservice into two components so that their underutilized servicesof the duo do not get replicated needlessly. We can then determine that anexpansive scale is relevant to hosting and removing instances of the microservicesas needed. unning title 5
Microservices for Expansive Domain.
An expansive domain is ever im-portant for a microservice due to the desire for microservice providers to profitfrom hosting it. There are pros and cons to this: a larger domain means moreincome, more hits, but also means more traffic and more end-user issues. In [6],they remark upon the microservice’s end goal: business capability. They furtheradd that such domains like the medical or Internet infrastructure are domainsto always consider.
Microservices for Expansive Release Schedules.
Furthering the research,an expansive release schedule is also desired. More updates mean more function-ality, less issues, and more knowledge of what users want and approve of in yourupdates. However, this also poses issues in development, as more developers arepushed to make deadlines rushed, releases frequent, and can impose other issueson end-users like reaching data-caps or possible server outages.Continuous development starts first with continuous integration that letsdevelopers integrate their work with others work early and regularly. Typically,microservices are deployed using virtualization which is very cost ineffective andcreates overhead [13]. A possible solution to this by using containers that isolatesand manages overhead much better than virtualizationAnother method that has been researched is using cloud microservice tothat of deploying a monolithic web application. Deployment for the microservicetypically requires configuration with the application and services. New versionsof microservices could easily break dependent services which made service ver-sioning very important. Coordination between microservice teams is vital topreventing problem from occurring. The infrastructure cost for the microservicedeployment compared to monolithic deployment is cheaper than the monolithicapplication but still has its own problems as previously mentioned.
In traditional CBSD, instantiation and parallelism of several instances ofone component is not literally supported, or it is challenging due to limited sup-port from most languages. Thus, the scalability, domain-expansive friendly, andshorter release features of microservices can enhance the way the componentswere used in CBSD (a more distributed CBSD), and more legit reasons to usemicroservices as components.
The CAP Theorem.
The CAP Theorem was first described by Eric Brewerin 1998. The basis for the CAP Theorem is that a distributed system can onlyguarantee two of the following three concerns: Consistency, Availability, andPartition tolerance [11].
Consistency:
Gilbert and Lynch [11] describe consistency as ”the propertythat each server returns the right response to each request.” By that definition,a system is consistent when all of the nodes can always agree on the sameset of data across each partition. To guarantee consistency, one must sacrificeavailability. This sacrifice exists because consistency requires an invested partyto wait to give other invested parties the opportunity to finish posting answersif they are already doing so. This generally manifests itself as locking, which
Reza M. Parizi works well on a local machine. The more distributed a system, the more costlythe communication; this means that locking has a greater impact on systemperformance and is thus less desirable.
Availability:
Gilbert and Lynch describe availability as ”the property thateach request eventually receives a response” [11]. It is often important to ensurea service can always provide a response, and it may be more and more impor-tant concern than consistency. Often this manifest itself in the form of messagequeueing and possibly even event-sourcing. The focus of systems that prioritizeavailability is often to always be able to eventually get the correct answer, butto never turn down clients or make them wait when the data is still in flux.
Partition Tolerance:
Gilbert and Lynch describe partition tolerance as ”com-munication among the servers is unreliable, and the servers can be partitionedinto multiple groups that cannot communicate with one another” [11]. Thiscomes down to a form of reliability for the data in the sense that all the datamust eventually converge to a point of consistency. In distributed systems, this isconsidered a requirement. It is therefore appropriate to conclude that partitiontolerance is always a given, leaving an existing tradeoff between consistency andavailability. This tradeoff is often decided on a per-problem basis and must becarefully considered at each design decision.
Microservices basically provides more availability than components in CBSD,while in terms of consistency, components could deliver more benefits over mi-croservices due to each component provides a firm module boundary. While therecould be a trade-off between availability and consistency, using microservies ascomponents in more complex and user-centric applications would be still moreprefered. The reason is the importance of resiliency and high availability of mi-croservices in modern software applications.
Cohesion and Coupling.
One of the major advantages of microservices is theirtendency to create system with more cohesion and a lower degree of coupling.Heffner argues microservices are inherently cohesive and uncoupled because sys-tems that do not fit this description are not microservices. He says that ”a unit’ssize fits with the microservices concept if it is highly cohesive, with loose couplingto other units” [12].
Cohesion:
According to Heffner, ”high cohesion is achieved by keeping to-gether in one unit the things that change together” [12]. A microservice mustbe a cohesive unit for it to be reasonably managed. If changes frequently requiremost services in the system to be changed, then a microservices pattern will onlyslow down production.
Coupling:
Hefner describes how ”low coupling is achieved by designing soas to maximize the degree to which unit A’s implementation can change with-out affecting the design or implementation of other units that refer to unit A”[12]. This is especially useful for a microservice because of its need to be ”hot-swappable”: if a service is to be replaced with a new one, it is important otherservices working around this service are not inherently dependent only on thatservice to function correctly. unning title 7
Microservices are less coupled than components. As pointed out by Fowler[13], using services as components would lead to a more explicit remote callmechanism. The reason is that most supporting languages in CBSD do not havea good strategy for defining an explicit Published Interface. Frequently, it’s onlydocumentation and discipline that prevents clients breaking a component’s en-capsulation, leading to overly-tight coupling between components.
Data Storing Strategies
Having each service be its own component allowsdevelopers more freedom in choosing ways to store their data. In this part,we discuss the various data storing applications and when to use each one inmicroservices domains. There are many various databases available today. Themain categories now are SQL, NoSQL, and most recently NewSQL.Using a traditional SQL database will allow to organize data neatly intotables. The advantage of this method is that everything will be neatly structured,but it takes time to develop. A recent issue with traditional table SQL databasesis with scalability.A NoSQL database is different from the traditional SQL databases. It wasspecifically made with the idea of having multiple devices allowing access to thedata. One of NoSQL’s advantages is that is non-relational, and this means thatthere are no tables. Most NoSQL databases are open source. One disadvantagehowever is that there is no standardization. Each NoSQL database has its ownquery language.NewSQL databases are fairly new and they combine features of both NoSQLand SQL, a new kind of Cloud database. They are ”relational databases, sup-porting sharding, automatic replication, and distributed transaction processing”[14]. A few examples of this are NuoDB, CockroachDB, VoltDB, and Clustrix,and most importantly Google Cloud Spanner.Spanner is a globally, synchronized distributed database by Google. Spannerwas made to be very scalable, and is designed to scale up to millions of machines[15]. One advantage of Spanner is that it is available as part of the GoogleCloud platform. The biggest advantage that spanner adds is the feature of highavailability by allowing clients to replicate their data across continents. This isdone by having global committing timestamps to transactions. This feature isaccomplished by using an atomic clock. Google created the TrueTime API [18]which uses atomic clocks and GPS receivers in each spanner data center to keeptime consistent between its servers. One big disadvantage of this system howeveris in the latencies, a critical concern with distributed databases.Attested to this disadvantage, Bulanov [16] performed an evaluation basedon Yahoo! Cloud Serving Benchmark (YCSB) [17]. In this study, three databasesincluding NuoDB, CockroachDB, and Google Cloud Spanner were compared. Forthe experiment, they ran the YCSB Spanner tests on Google Cloud for CloudSpanner, while benchmarks for CockroachDB and NuoDB resided on bare metalin their lab using 32GB, 4 core SuperMicros with 10G network.
Reza M. Parizi
In YCSB tests, there are a number of workloads named from A to E. Inshort, the workloads can be described as follows:A - Heavy update (50% read, 50% update)B - Mostly read (95% read, 5% update)C - Read-only (100% read)D - Read the latest inserted (90% read, 10% insert)E - Scan the latest inserted (90% read, 10% insert)F - Read-modify-write (50% read, 50% update)For each of the workloads, the application load (number of threads ran byYCSB application) was varied, and so was database capacity (number of nodesbetween 1 and 3). Multiple runs were executed, then the latencies numbers acrossall runs for each database were gathered. Fig. 1 and Fig. 2 show the results.
Fig. 1.
Latency experienced by the applications for READs
The graph in Fig.1 measures average latency experienced by the applicationfor READs during periods of peak throughput. As it can be seen from the figure,NuoDB’s latency numbers were significantly lower than latency for Google Span-ner and CockroachDB (minimal latency is ideal for the best user experience).The graph in Fig. 2 measures average latency experienced by the applica-tion for UPDATEs and INSERTs during periods of peak throughput. Note thatWorkload C was not represented here as it is a READ-only workload. As it canbe seen from the figure, this was another area where NuoDB outperformed otherdatabases.
As mentioned, having each microservice be its own component allows develop-ers more freedom in choosing ways to store their data, satisfying a more purpose- unning title 9
Fig. 2.
Latency experienced by the applications for UPDATEs and INSERTs fit technology stack practice. Additionally, microservices seem more technicallyin line with new data storage technologies, thus they could be used as effectivecomponents in terms of data storage supporting capability.
In addition to results presented in Section 3, we discuss briefly the main observa-tions with respect to research questions, and outline a few directions and pointsfor further research in this section.
RQ1. What are the main motivations to study microservices in CBSD?
Microservices have become an effective means to design systems that can ac-commodate an expansive scale, an expansive domain, or a rapid release schedule,while keep a high degree of reusability. The demands of software systems todayoften expect one or many of these concerns to be met, making microservices arelevant tool for the design of component-based software systems. Particularlyits scalability, which CBSD is severely lacking in it, is considered ideal whenthe system must enable support for a range of devices and platforms, includingWeb, Mobile, IoT, wearables, or simply when the users are not sure what kindof devices they will need to support in the future. There exists a myriad numberof deployment and operation mechanisms centered around microservices. Inno-vation is near constant, as more are being added to the microservices’ list daily(more efficient techniques and tools are on the rise)
RQ2. What are the limitations of microservices in this field?
A microservice is a service that completes a business objective and it onlyhandles that one specific function and uses messages as a way to communicatewith each other. A microservice has to be independent leading to high cohesionand low coupling. The work in [19] provides benchmark requirements. Even when the authors compared their benchmarks with software repositories, it showedthat there is no consensus on all the requirements of what makes a microserviceand its architecture, posing a serious adoption limitation for users and clients.On a more specific level, the limiting factors that microservices provide are:The first being that they use a distributed system that increases modularitybut also causes performance issues as remote calls are often slow and producehorrible latency. Another problem is its reliability to which remote calls can failand need to be handled in a certain way. Consistency becomes a problem (asexplained in the CAP theorem) when microservices need to update it may needmultiple resources to do so.Though these limitations might come at a price, but the amazing possibilitiesthat microservices offer as components should be considered as factors related todecisions to adopt this architectural style, and how the likelihood of its utilizationcan be beneficial in a context-by-context basis.
RQ3. What should be the future research in this field?
Implementation of a microservice-based system as components is still a dif-ficult ordeal that requires a great deal of coordination, planning, and expertise.Since this field is still a new frontier, design patterns and best practices are stilllargely up for debate. Development of microservices could benefit greatly fromthe greater establishment and standardization of these concepts.As another observation, we noticed is how few empirical studies have beenconducted in microservices domain (and literally none for investigation of mi-croservices as components) and how many cannot even be reproduced. Indepen-dent replication of interesting studies supported by valid meta-analysis is a goodway to start. Software service engineering is not any area like physics or medicinewhere researchers vie to be first with some new idea, extending and improvinga useful idea is valuable.
With the rise in popularity of microservices and a shift from large monolithicapplications to small independent services, we believe that component-basedsoftware engineering will pick up on this. Much of the concepts of one are veryinterconnected with the other such as using a service that allows users access toa system. Service-oriented architecture (SOA) represents a good bridge betweenthe two as a service that is being called on could be made by a collection ofmicroservices. We approached this study with research question: can microser-vices be used as components in massively deployed and complex applications?We investigated the existing literature and reviewed a sample of the techniquesand methods from selected researches, analyzing the core properties of microser-vices including scalability, consistency, availability, coupling and cohesion, anddata storage technologies. As a general result, we conclude that using microser-vices as components is promising and would be a good mechanism for buildingapplications that were used to be built with component-based approaches. unning title 11
We hope this work can be useful in the process of building a more communityspirit to study CBSD from a new perspective, since microservices field is evolvingand potentially has much to offer to revive component-based approaches.