A

Seminar Report
On

Microservice Architecture

Submitted in partial fulfilment of the requirements for the award of degree of

Bachelor of Technology

by
Rupali Chawla
(CE-4117-2K16)

Department of Computer Engineering

J. C. BOSE UNIVERSITY OF SCIENCE & TECHNOLOGY, YMCA

FARIDABAD-121006

May 2019
 CANDIDATE’S DECLARATION

I hereby certify that the work which is being presented in this seminar report titled
“Microservice Architecture” in fulfilment of the requirement for the degree of Bachelor of
Technology and submitted to “J. C. Bose University of Science and Technology, YMCA,
Faridabad”, is an authentic record of my own work carried out under the supervision of
Dr.Anuradha.

The work contained in this report has not been submitted to any other University or Institute
for the award of any other degree or diploma by me.

Rupali Chawla
(CE-4117-2K16)

ii
 LIST OF FIGURES

Figure Page No.

Fig. 1 Microservice Architecture 2

Fig. 2 Monolithic Architecture 6

Fig. 3 An e-commerce App built using Monolithic Architecture 10

Fig. 4 An e-commerce App built using Monolithic Architecture 11

iii
 TABLE OF CONTENTS

S. No. Content Page No.

1. INTRODUCTION 1
2. HISTORY 3
3. MONOLITHIC ARCHITECTURE 5
4. MONOLITHIC VS MICROSERVICE 7
ARCHITECTURE
5. MONOLITHIC VS MICROSERVICE FOR E- 9
COMMERCE APP
6. ADVANTAGES 12
7. CASE STUDY 14
8. DISADVANTAGES 19
9. FUTURE SCOPE 21
10. REFERENCES 23

iv
 Chapter No. 1

INTRODUCTION
 INTRODUCTION

A microservices architecture consists of a collection of small, autonomous services. Each

service is self-contained and should implement a single business capability. Here are some of
the defining characteristics of microservices:

 In a microservices architecture, services are small, independent, and loosely coupled.

 A microservice is small enough that a single small team of developers can write and
maintain it.
 Services can be deployed independently. A team can update an existing service without
rebuilding and redeploying the entire application.
 Services are responsible for persisting their own data or external state. This differs from
the traditional model, where a separate data layer handles data persistence.
 Services communicate with each other by using well-defined APIs. Internal
implementation details of each service are hidden from other services.
 Services don't need to share the same technology stack, libraries, or frameworks.

2
Chapter No. 2

HISTORY
 HISTORY

A workshop of software architects held near Venice in May 2011 used the term
"microservice" to describe what the participants saw as a common architectural style that
many of them had been recently exploring[citation needed]. In May 2012, the same group
decided on "microservices" as the most appropriate name. James Lewis presented some
of those ideas as a case study in March 2012 at 33rd Degree in Kraków in Micro services
- Java, the Unix Way [19], as did Fred George.about the same time. Adrian Cockcroft at
Netflix, describing this approach as "fine grained SOA", pioneered the style at web scale,
as did many of the others mentioned in this article - Joe Walnes, Dan North, Evan
Bottcher and Graham Tackley
Dr. Peter Rodgers introduced the term "Micro-Web-Services" during a presentation at
the Web Services Edge conference in 2005. On slide #4 of the conference presentation,
he states that "Software components are Micro-Web-Services". Juval Löwy had similar
precursor ideas about classes being granular services, as the next evolution
of Microsoft architecture. "Services are composed using Unix-like
pipelines (the Web meets Unix = true loose-coupling). Services can call services
(+multiple language run-times). Complex service-assemblies are abstracted behind
simple URI interfaces. Any service, at any granularity, can be exposed." He described
how a well-designed service platform "applies the underlying architectural principles of
the Web and Web services together with Unix-like scheduling and pipelines to provide
radical flexibility and improved simplicity by providing a platform to apply service-
oriented architecture throughout your application environment". The design, which
originated in a research project at Hewlett Packard Labs, aims to make code less brittle
and to make large-scale, complex software systems robust to change. To make "Micro-
Web-Services" work, one has to question and analyze the foundations of architectural
styles (such as SOA) and the role of messaging between software components in order
to arrive at a new general computing abstraction.[28] In this case, one can think
of resource-oriented computing (ROC) as a generalized form of the Web abstraction. If
in the Unix abstraction "everything is a file", in ROC, everything is a "Micro-Web-
Service". It can contain information, code or the results of computations so that a service
can be either a consumer or producer in a symmetrical and evolving architecture.

Microservices is a specialization of an implementation approach for service-oriented

architectures (SOA) used to build flexible, independently deployable software
systems.[10] The microservices approach is a first realisation of SOA that followed the
introduction of DevOps and is becoming more popular for building continuously
deployed systems.

4
 Chapter No. 3

MONOLITHIC ARCHITECTURE
 MONOLITHIC ARCHITECTURE

Monolithic architecture is the traditional unified model for the design of a software program.

Monolithic, in this context, means composed all in one piece. Monolithic software is
designed to be self-contained; components of the program are interconnected and
interdependent rather than loosely coupled as is the case with modular software programs. In
a tightly-coupled architecture, each component and its associated components must be
present in order for code to be executed or compiled.

Furthermore, if any program component must be updated, the whole application has to be
rewritten, whereas in a modular application, any separate module (such as a microservice)
can be changed without affecting other parts of the program. Modular architectures reduce
the risk that a change made within one element will create unanticipated changes within other
elements, because modules are relatively independent. Modular programs also lend
themselves to iterative processes more readily than monolithic programs.

However, there are benefits to monolithic architectures as well. Monolithic

programs typically have better throughput than modular approaches, such as the microservice
architecture (MSA) and they can be easier to test and debug because, with fewer elements
there are fewer variables that come into play.

6
 Chapter No. 4

MONOLITHIC VS MICROSERVICE
ARCHITECTURE
 MONOLITHIC VS MICROSERVICE ARCHITECTURE

 Fault Isolation

Since all services in a microservice architecture are independent of each other, any halt in a
process will keep rest of the processes unaffected. For example, a memory leak in one service
will only affect that single service.

 Technology Commitment

With microservices architecture, developers have the advantage of using different

technologies (languages, frameworks, and OS) to build an application. This eliminates
dependency and long-term commitment with a single technology stack.

 Application Scaling

Once the codebase of an application reaches a certain size, it is a good practice to divide the
development team to handle specific functional areas. For example, a UI team, an inventory
management team, a product management team etc. In microservices architecture, all these
services are developed as separate modules. Thus, teams can be divided to work
independently, which helps them to change and update production, making it easy to scale
application.

With a monolithic architecture, developers have a challenge in scaling. Since there is a single
codebase accommodating all services, teams cannot work on different modules,
independentlyContinuous Development and Deployment

 Code Management

The size of a monolithic codebase is huge. The large monolithic codebase is difficult for
developers to understand and manage, especially those who are new to the team. This, as a
result, can slow down the development process. Microservices codebase, on the other hand, is
divided into a group of small codes and thus is managed easily, compared to a monolithic
application.

8
 Chapter No. 5

MONOLITHIC VS MICROSERVICE FOR

E-COMMERCE APP
 MONOLITHIC VS MICROSERVICE FOR E-COMMERCE APP
Microservice Architecture for building a scalable, robust e-commerce app.

Example: An eCommerce App built using Microservices Architecture

The example demonstrates how to build an eCommerce application using microservices

architecture, powered by Consule, Docker, Spring, React.JS, MongoDB, Redis and more.
The above example includes functional microservices (Product catalog, cart microservice)
and infrastructure microservices (global configuration microservice, Service Registration &
Discovery microservice) only. These microservices are deployed independently and are
organized around business capabilities.

10
Example: An eCommerce App built using Monolithic Architecture

The same eCommerce application when built using monolithic architecture has all the
services tightly-coupled, uses limited technology stack and have a single database. Such an
architecture brings a number of challenges as the application scales.

11
Chapter No. 6

ADVANTAGES
 ADVANTAGES

#1 Accelerate turnaround:

Each microservice is designed to address a single concern. Moreover, the services are
partitioned along functional boundaries and deployed inside containers. This means,
developers have to deal with less complicated databases and significantly lower
dependencies, resulting in higher agility and ease of deployment. Another advantage is that
microservices are easier to tweak as well as update

#2 Improve fault isolation and resolution:

With microservices, developers know exactly where to look for problems. Failure of a single
module can be easily isolated and resolved, without the larger applications being affected. In
monolithic applications, failure of a single function or component can pull down the entire
application. Even a single line code change in monolithic architectures would require
redeployment of the whole application.

#3 Enable on-demand flexibility and scalability:

Consumer demands and preferences change at warp speed today. Take new user registration
and existing user login functionalities on an eCommerce portal, for instance. Due to a
particularly successful marketing acquisition campaign, the portal may see a temporary surge
in new user registrations. If the application is built on microservices architecture, it would be
significantly easier for the company to scale that one functionality separately, without having
to scale the entire application and waste time and resources..

#4 Make change less expensive:

Traditional service-oriented architectures are typically based on shared infrastructure –if

developers have to change implementation details in one service/component, they have to
consider the inadvertent side effects it will cause to other services. Shared resources design
encapsulates a great deal of physical coupling, where each service shares a monolithic
database, an object-relational mapping layer, and other implementation
elements. Microservices, on the other hand, strive for integration coupling, without any
physical coupling. The result is both – encapsulated behavior as well as ease of operational
change

#5 Unleash innovation:

Because microservices make change less expensive, they enable innovation at the scale and
agility needed to survive the digital disruption. Eg- Netflix.
13
Chapter No. 7

CASE STUDY
 CASE STUDY: AMAZON

“If you go back to 2001,” stated Amazon AWS senior manager for product

management Rob Brigham, “the Amazon.com retail website was a large

architectural monolith.”

Brigham was addressing a mostly well-attended main stage at Amazon’s re:Invent 2015
conference in Las Vegas Wednesday. His accompanying slide showed a certain well-
recognized “2001” monolith, this time towering next to a brilliant Washington mountain lake,
probably someplace nearby. And he was snickering just a bit at the cleverness of either
Amazon’s historical timing, or his own.

Brigham brought up the subject of the software development lifecycle (SDLC) as the fabric
of a development team — specifically, as the substance that, when dealing with a monolithic
application such as Amazon.com faced in 2001, kept developers apart from each other and
separated the team from its ultimate goal. Their truly revolutionary approach to resolving this
issue became one of the prototypes (NASA’s Nebula project being one of the others) that led
to the creation of cloud computing.

Brigham told the story of Amazon’s engineering group, which in 2000 had the unenviable
task of reconciling the in-process changes from hundreds of developers, resolving all the
conflicts between them, merging them into a single version, and producing a master version
that waits on the queue to be moved into production. “Even when you have that big, large,
new version,” he said, “it still adds a lot of overhead on this delivery pipeline. That whole,
new code base needs to be rebuilt. All of the test cases need to be re-run, to make sure there
have been no rushes. And then you need to take that entire application, and deploy it all to
your full production fleet.”

Amazon’s approach is not to get rid of the pipeline, but to simplify it. The company’s
continuous deployment tools — CodeDeploy, CodePipeline and CodeCommit — are built
around truly cloud-native web applications where the various segments of that pipeline can
be scripted and automated. Rob Brigham said both the architectural and logistical changes

15
that Amazon made, beginning at the turn of the century, directly led to the tools it now offers
to development teams.

At the time of their creation, these single-purpose functions seemed simple enough to
accomplish. But imagine the hundreds of development teams, some comprised of dozens of
developers at that time (instead of the more comfortable “two-pizza” size of no more than
eight), whose simple-enough, single-purpose functions had to be merged together week after
week … and later, month after month, as the fabric of the SDLC became bigger and bulkier.

The solution to the single-purpose function problem was the creation of a rule, to be adhered
to by developers, that functions could only communicate with the rest of the world through
their own web service APIs. “This enabled us to create a very highly decoupled architecture,”
said Brigham, “where these services could iterate independently from each other without any
coordination between those services, as long as they adhered to that standard web service
interface.”

The decoupling of services enabled the creation of one of the first automated deployment
systems, and the prototype for much of what Amazon offers customers today —
appropriately named “Apollo.” It helped introduce the pipeline model to the culture of
Amazon, and it is probably here in the session that Brigham judiciously applied some
discretionary editing, because that process could not have been simple.

“We still noticed that it took a long time for a code change to go from a developer check-in,
to be running in production where customers could use it,” he related. “So being a data-
driven company, we did a study on that. And we measured the amount of time it took a code
change to make its way through that deployment lifecycle, across a number of teams. When
we added up that data, and looked at the results, and saw the average time it took, we were
frankly embarrassed. It was on the order of weeks.”

Brigham’s talk led to a demo of CodePipeline at work, which included inline scripting of
events that take place in the deployment pipeline, and integration with private repositories on
Amazon as well as GitHub. Amazon took care at this point to show that it was avoiding the
tack of locking development shops into an Amazon-branded way of doing things, contrary
to what some outside its partner ecosystem have alleged.

16
 CASE STUDY: NETFLIX

Netflix is one of the earliest adopters of microservices, a term that didn't even exist when

Netflix began moving away from its monolith. Today, the Netflix application is powered by

an architecture featuring an API Gateway that handles about two billion API edge requests

every day which are handled by approximately 500+ microservices. Netflix has been so

successful with its architecture, that the company has open sourced a great deal of its

platform including the technologies powering its microservices.

Netflix Moves to the Cloud

Netflix began moving from a monolithic to AWS cloud-based microservices architecture in

2009, long before the term microservices even existed. In 2010, Netflix began moving

customer facing pieces of the website to AWS including account sign up, movie selections,

TV selections, metadata, and device configuration. By the end of 2010, the entire customer

facing website had been moved to AWS. By December 2011, Netflix had successfully moved

to the cloud, breaking up their monolith into hundreds of fine-grained microservices.

Reasons for the Move

There were a number of reasons Netflix made the decision to move from a monolithic

datacenter to a cloud-based microservices architecture. The primary reasons for the move

however, had to do with availability, scale, and speed. Back in 2008, when Netflix was still

operating as a monolith, a single missing semi semicolon brought down the entire Netflix

website for several hours. Monoliths tend to become spaghetti code with various components

linked together and tightly coupled together. A well-designed microservices architecture

allows for better availability.

17
Another reason for the move to a cloud-based microservices architecture had to do with scale.

Thousands of server instances can be commissioned simultaneously if needed to meet

increased demand for services. The microservices architecture allowed Netflix to greatly

speed up development and deployment of its platform and services. The company was able to

build and test global services on a large scale without impacting the current system and they

could quickly rollback if there were problems.

There Were a Few Problems

While the Netflix platform is one of the best examples of a modern cloud-based

microservices architecture, the move from monolith to microservices was not without some

problems. In April 2011, there was an outage in AWS US-East that brought down several

popular websites hosted on AWS. While Netflix did not experience any large external

outages because of the The company has since automated much of the process, so that

failures of this nature are handled without requiring a lot of manual intervention by Netflix

engineers.

Netflix Provides Open Source Software

Netflix has been so successful moving to a cloud-based microservices architecture, that the

company has open sourced many of the tools and components used to build it.

18
 Chapter No. 8

DISADVANTAGES
 DISADVANTAGES

Disadvantage #1: Microservices Are More Complex

The biggest disadvantage of a microservices architecture is its increased complexity over a
monolithic application. The complexity of a microservices based application is directly
correlated with the number of services involved. Existing tools are not designed to work with
service dependencies.. Increase in language and frameworks can cause the application to
become hard to maintain. As each service has its own database, transaction management and
data consistency can become a nightmare. Each service has to be testing and monitored
increasing demand for automation. The initial refactoring of a monolithic application can be
exceedingly complex for large enterprise applications.

Disadvantage #2: Microservices Require Cultural Changes

A microservices initiative will require a cultural shift in organizations seeking to adopt them.
They require a mature agile and DevOps culture. With a microservices based application,
teams need to be enabled to manage the entire lifecycle of a service. This often requires
migrating competencies and decision-making from managers and architects to individual
teams. This change in hierarchy can be difficult for some people within the organization to
accept. Therefore, ensuring experienced members and upper management have bought into
the initiative is an important first step. Also, communication between individuals and teams
becomes much more challenging as teams may not always have visibility of the big picture
and how individual services must work with each other to create a usable application.

Disadvantage #3: Microservices Are More Expensive

Among other microservice disadvantages in its architecture is growing costs. Services will
need to communicate with each other, resulting in a lot of remote calls. These remote calls
result in higher costs associated with network latency and processing than with traditional
architectures. Developers will want to put forth their best efforts in order to reduce the
number of calls. Another driver of increased cost is a higher resource demand as each service
will require its own runtime environment and CPU.

Disadvantage #4: Microservices Pose Security Challenges

Compare a monolithic application to microservices and you will see microservices can pose
enormous security challenges due to the increases in inter-service communication over the
network. All of these interactions create an opportunity to outside entities to gain access to
the system.
 Chapter No. 9

FUTURE SCOPE
 FUTURE SCOPE

Microservices is an umbrella term that covers a range of things—the most notable and
obvious of which is containers. Containers, driven primarily by the rise of Docker, are now
embraced and supported across a variety of operating systems and cloud platforms. The next
step in the microservices evolution, however, is to eliminate those dependencies
completely—or at least most of them—and move to serverless applications that run more or
less natively in the cloud.
Al Hilwa, program director of software development research for IDC- “Microservices are
typically developed with modern elastic and often stateless back-end architectures, but that
does not mean they are automatically scalable. Architects have to take special care to make
sure that centralized services or databases are also designed to be scalable. Microservices also
put a lot of pressure on APIs highlighting the importance of strong API management
technology in the software stack being employed.”

There has been a proliferation recently of services aimed at taking microservices to the next
level and supporting a serverless application ecosystem. Amazon’s AWS Lambda and API
Gateway, Google Cloud Functions, and Azure Container Service (ACS) are all built on the
premise of providing a generic layer capable of running a container orchestration solution.

Some refer to serverless computing as “NoOps” because it essentially eliminates the

operational infrastructure aspect of DevOps. “Developers follow the fire-and-forget paradigm
where they upload individual code snippets that are hooked to a variety of events at runtime,”
explains a Forbes contributor. “This model offers a low-touch, no-friction deployment
mechanism without any administrative overhead. Serverless computing and microservices are
ushering a new form of web-scale computing.

Serverless application code is built on small, single-purpose functions that can be triggered
by cloud events. There is no need to launch or manage a virtual server, or maintain a runtime
environment because the serverless application code just runs directly on the supporting
platform.

While this is a different scenario, some of the core elements are the same. Ultimately, it’s
about being able to design, execute, and maintain apps without regard for the hardware
architecture or operating system platform they will run on. It is more complicated than that,
but one of the main benefits of serverless applications is to separate the code from the
underlying infrastructure.

22
Chapter No. 10

REFERENCES
 REFERENCES

 https://docs.microsoft.com/en-us/azure/architecture/microservices/introduction
 https://www.payoda.com/blog/monolithic-applications-microservices-five-benefits-driving-
shift/
 https://microservices.io
 https://insights.daffodilsw.com/
 https://thenewstack.io/led-amazon-microservices-architecture/
 https://smartbear.com/blog/develop/why-you-cant-talk-about-microservices-without-ment/

24