Term paper 2073131

1
Microservices as an Emerging Technology in
Software Industry
Shoaib Ahmed
Masters of Computer Science
Shaheed Zulfiqar Ali Bhutto
Institute of Science & Technology
Karachi, Pakistan
Shoaib-Ahmed@Outlook.com
Abstract— The term "Microservice Architecture" has jumped up
in the course of the most recent couple of years to portray a specific
method of desiging software applications as set-ups of
independently deployable applications. While there is no specific
definition of this architectural style, there are some certain
common qualities around organization of business functionalities,
automated deployment, intelligent endpoints, decentralized
control of languages and information. Current industry trends in
ERP architectures indicate transition from Service Oriented
Architectures (SOA) to Micro-services. By understanding the key
constrasts among these two methodolgies and their benefits, we
can deliver a more effective Micro-service architecture by
overcoming Service Oriented Architecture drawbacks. To enable
this, we should acknowledge why this transition is occusring and
how SOA functionalities addressed by key benefits of the Micro-
service based application. Unfortunately, Micro-services do not
address all Service Oriented Architecture drawbacks. In contrast,
Micro-services add greater challenges. This research address a
detailed analysis of the differences among these two methodologies
and their key benefits. Then, we explain both research industry
and research perspectives on the strengths and weaknesses of both
architectural directions. Finally, we identify interest and
challenges in various categories among a variety of recent
research.
Keywords— Microservices, Architecture, SOA, Systematic
mapping study
I. INTRODUCTION
Micro-services is the most recent trend in software
application devlivery, design, and development. They portray
a methodology to systems architecture and software that
develops on the well-defined concept of modularization but
impose technical limitations. Each micro-service each module
is developed and maintained as a small but independent
system, delivering access to its internal logic and information
by a well-defined network protocol. This add up to software
agility because each independent micro-service becomes a
separate independent unit of deployment, development,
operations, maintainance, and scaling.
To begin clarifying the micro-service approach it's helpful
to contrast it with the monolithic approach. a monolithic
application worked as a separate unit. ERP Applications are
frequently built on three fundamental parts: a client side UI
(comprising of HTML pages and javascript running in a
program on the client's machine) a database (comprising of
numerous tables embedded into a common, and normally
relational, DB Management System), and a server side
application. The server side application will deal with HTTP
requests, execute business logic, recover and update
information from the database, and choose and populate
HTML views to be sent to the program. This server side
application is a monolith and a single coherent executable.
Any progressions to the framework include development and
deploying another version of the server side application.
Microservice is an architectural style originated from
Service-Oriented Architectures (SOAs) with the concept of
bringing in the tiny those concepts that worked in the large for
cross-organization business-to-business workflow. The
transition monolith to microservices is a sensitive decision
these days, seeing several companies involved in a major
refactoring of their software systems to ensure the benefits of
the new paradigm.
Over the past few years, industry is in need of software
design and architectures in various directions. The increasing
complexity of ERP applications, along with evolution and
change management it increased the rise of architectures such
as Java RMI, Common Object Request Broker Architecture
(CORBA), Enterprise Service Bus. Service Oriented
Architecture (SOA) became the answer to various industrial
needs for huge enterprises applications, upgrading its
predecessors. However, Micro-service Architecture seem to
replace SOA as the leading software development
architecture.
Both Micro-service and Service-Oriented Architecture
offer breakdown of software systems into smaller services
available over a network or a cloud and integratable among
heterogeneous technologies. In both approach services
communicate to provide features for the overall software
application and thus address the common goal. But, the
approach to achieving the goal is not same. Service Oriented
Architecture focus on design of system breakdown into simple
smaller services, enforcing service integration with smart
routing approach for the large company IT infrastructure. The
smart routing approach consists of a global governance or
centralized management and is capable of enforcing business
functionalities on top of message processing, services, and
service monitoring and control. Service Oriented Architecture
services are not coupled, executing without knowledge of
event trigger action. A new service can easily be integrated by
executing to such action event. For example, a service is able
to write an invoice and second one can trigger delivery. A
system can listen to events, without acknowledgement of other
services.
II. BACKGROUND
Service Oriented Architecture and Micro-services are two
crucial architectures that are being utilized for breakdown of
systems into smaller services. The question is how to
communicate among services to attain sepecific scenario. In
common practice, there are two well-defined methodologies:
centrally orchestrated and independent or distributed.
Centrally orchestrated approaches are the common approach

2
for Service Oriented Architecture, and the decentralized is the
dominant approach for micro-services.
Service is a reusable software unit which is used by various
client applications for various purposes allowing control rules.
It provides a particular element of the business logic, display
its User Interface, and is used separately by the network. While
utilizing well-defined interfaces and communication protocols
like HTTP, it brings hetrogenous integration. In Service
Oriented Architecture, services are contained in a directory or
registry to easily communicate them. In order to limit
coupling, services are produced to generate an outcome.
From the history of Service Oriented Architecture,
microservices are actually not that new of a concept. However,
microservices have become more featurefull. All thanks to
improvement in containerization technologies like docker.
With Linux container, we are now enabled to run more than
one parts of an app separately, on the same hardware, with
much more control and autonomy over their life cycles and
process. Along with Application Programing Interfaces and
Dev Ops mechanisms, containerized micro-services are the
start for cloud-native systems.
The communication patterns for centralization and
decentralization are called orchestration and choreography,
respectively. These portray how services integrate and
communicate, how the series of workflows look like, or how
the business logic is developed. Service orchestration involves
a centralized business process, coordinating workflows over
different services and combining the results.
Choreography does not involves a centralized approach for
service composition. Service choreography involves message
exchange and rules of integration as well as policies among
interacting services. The control logic is not in a single
location.
When utilizing orchestration across a mediation layer, we
often add a canonical data set. In such a way that different
system parties agree or generalize their data models on the
business logic they transfer. However, most of the times whole
application ends up having similar kind of business logic. For
example there is a single Person, Order, Entry, Invoice with
matching fields and relations, because everyone agrees on
them. It is easy to introduce this model with orchestration
however, later changes to the model are very complex because
all parties should agree on it and the separate application has
limits on change management.
A different approach came from Domain Driven
development is known as Bounded context. In this approach
each service has to use specific business logic in a specific
context, therefore it make sense for some service to select
certain fields and obsolete others. For example we can take a
User’s address for process of delivery and ignore others.
however, for numeric calculations, it is considered to only
have User customer rank. Therefore a huge model is
breakdown into smaller contexts, enabling the modeling of
business logic differently based on specific needs. Not all
services has the same requirements and thus should have the
independence to construct their requirements.
One crucial reason for utilizing services as components
instead of libraries is services are separately deployable. If you
have a system that involves of a various libraries in a specific
process, a change to a single component results in need of
having to deploy the whole system. Therefore if that system is
breakdown into various small services, you can expect various
single service modifications to only need that service to be
deployed. That is not an absolute, some modifications will
change service user interfaces resulting in some
communication, but the main reason of a good micro-service
architecture is to reduce change through cohesive service
limitations and change mechanisms in the service contexts.
Another result of using services as components is a more
well-defined component interface. Most languages do not
allow a good mechanism for defining a specific published
interface. Therefor it is just documentation and discipline that
prevents applications breaking a component's encapsulation,
leading to overly-tight coupling between components.
Services make it easy to ignore this by using specific remote
call approach.
Utilizing services in this way does have drawback. Remote
calls are far expensive as compared to in process calls, and
because remote APIs should be independent, which is most of
the time more difficult to use. If you need to modify the
allocation of responsibilities among components, such
transition of behavior are difficult to do because you're
violating process limitations.
At first estimation, we can analyze that services map to
runtime processes but that is just an initial estimation. A
service may involve various other processes that will always
be constructed and deployed together, such as a system
process, a database that is only utilized by that specific service.
III. BENEFITS OF MICRO-SERVICES
There are a number of benefits which are often related with
micro-services. The most important ones are improved
scalability, quicker delivery, greater autonomy. It’s not a
coincidence that these benefits are related to market needs and
experienced by a number of organizations. Micro service
based back-end also require modular front-end which can
independently build. Using monolithic front end also inhibits
the purpose of micro service approach.
Although micro-service architectures have different kind
of approaches to implement, they all have one come goal
which is to speed up delivery time. Adopting micro services
architecture would reduce design complexity and code
dependencies. Agility would be ensured due to individual
development, deployment and parallel feature development of
each micro service. Badly designed application architecture
can lead to unintended communication calls, more code
complexity and poor performance. Modularizing front ends to
ensure a full stack micro service architecture. Defining a
framework that can rightly access the responsibility and size
of each micro service. Micro service monitoring and resource
management for large applications.mini- mum of centralized
management.
The word scalability is somehow unclear in terms of
context. It could represent to the application’s runtime
scalability. For reference, its adaptability at a reasonable cost
to modifications of various users accessing it. Or it could
reference the development process’s approach to allow many
developers doing development on it in parallel. These separate
services when developed properly, do not create an impact on
one another. This portray that that if a unit fails, the entire app
do not go down, just like the monolithic application system.
With microservices, the unit of allocating resources is each
microservice. So at runtime, services can be allocated
differently according to their specific need. But the micro-
service itself is a unit of deployment and development. So,
each service can be deployed, implemented, and maintained
by a different team, enabling for a more parallel development
of new features. However the larger app is decomposed into

3
tiny units, developers can more thoroughly understand,
modify, and improve those units, as a result of which faster
development process, specifically when agile development
methodologies is being used.
Because your micro-service based apps are more modular
and smaller than normal, monolithic applications, the
drawback that come with these deployments are ignored. This
results in need of more communication. Server-less
architecture and runtime allocation of resources based on the
requirement. Teams managing a service have greater
autonomy in terms of deployment, monitoring and
development.
At last, if we talk about the concept of a scalable
application, each separate micro-service is expected to provide
an autonomous, limited unit of both runtime and
implementation decisions. This allows a team to make
localized decisions in terms of each service for example, in
terms of the programming language platform, third party
libraries, frameworks used, the database management system
are used; or any other area of its development strategy. This
allows for a one of the best approach, with each team having
the optimal choice for its particular responsibility.
IV. SERVICE ORIENTED ARCHITECTURE
The important reason a software architect opt to use for
SOA or Micro-services is to decompose a system into
services. SOA, therefore, needs specific upfront
commitments, since the whole organization’s IT must
decompose into independent services. It is easy to add a new
SOA service, one can opt a legacy application and define a
separate network accessible user interface for this. A more
advanced approach divides an entire system onto various
services, for more broader service implementation and service
orchestration. The difficult task when introducing Service
Oriented Architecture is the installation of centralized
governance, the component responsible communication of
services and their integration. typically, the process for
ensuring integration is Enterprise Service Bus (ESB) that
constructs the entire process for SOA. As mentioned earlier, it
enables orchestration. However, services can communicate
through messages and action events where the trigger is not
known while various services react on the specific event. In
contrast, business processes can be defined at the integration
level, allowing more flexible re-configuration. However, this
approach adds toward the introduction of a canonical data
model. The main reason here is that the communication
platform is intelligent, but also difficult to implement. Service
Oriented Architecture is often referred to as simple services
and smart pipes for the this reason. The system is generally an
independent component of the user interface, like a web portal
and a dedicated web application.
To summarize, Service Oriented Architecture, its easy to
change business logic, although, modifying a service need
deployment of the component enabling the service. This may
add to the whole Service Oriented Architecture monolith, not
to mention the requirement to make the changes in the user
interface. The communication platform is typically a very
complex when it refers to the deployment, and since it is the
centralizing element, it can become the system bottleneck that
has to deal with integration overhead or distributed callbacks.
The integration unit is usually an Enterprise Service Bus, that
routes the purpose of communication, orchestration, routing,
event processing, integration, and business workflow
monitoring. From the communication perspective, Service
Oriented Architecture is about orchestrating large
components.
V. MICROSERVICES ARCHITECTURE
These concepts refers to a more reusable component
design, allowing decomposition. The main point is that
services are deployed to production independent of each other,
that is one of the crucial differences with most SOA
implementations. It does not only affect deployment but also
evolution and change management overhead. micro-service
implementation often cite Conway’s law, stating that
“Organizations, which design systems are constrained to
produce designs which are copies of the communication
structures of these organizations.”
Microservices represent lightweight virtual machines.
They are implemented as containers (Docker) or separate
processes. This uneveal dependency on a certain technology,
enabling usage of a service-specific infrastructure.
microservices usually do share the same database schema as it
would pre-determine an initial process as well as integration.
Each micro-service is in responsible of its own data set, which
possibly leads to replication. In the Background section, we
discuss Bounded context, which is the direction for micro-
services.
Likewise Service Oriented Architeure, Microservices do
not consists integration service responsible for service
orchestration and allow choreography. Business logic are
involved in services, and there is no business logic in the
integration. Therefore microservices themselves are
responsible for communicating with others. This gives
bounded flexibility to design and adjust business processes on
the organization IT’s. It is a tradeoff for micro-service free
service management and deploys. Of course, one can instead
use orchestration. But, this is not a general approach.
It is easy to add a new micro-service, one can opt a legacy
application and define a separate network accessible user
interface for this. A more advanced approach divides an entire
system onto various services, for more broader service
implementation and service orchestration. The difficult task
when introducing Microservices is the installation of
centralized governance, the component responsible
communication of services and their integration. typically, the
process for ensuring integration is Enterprise Service Bus
(ESB) that constructs the entire process for Microservices. As
mentioned earlier, it enables orchestration.
However, services can communicate through messages
and action events where the trigger is not known while various
services react on the specific event. In contrast, business
processes can be defined at the integration level, allowing
more flexible re-configuration. However, this approach adds
toward the introduction of a canonical data model. The main
reason here is that the communication platform is intelligent,
but also difficult to implement. Microservices is often referred
to as simple services and smart pipes for the this reason. The
system is generally an independent component of the user
interface, like a web portal and a dedicated web application.
Finally, the tiny size of the microservices, combined with
their clear limitations and integration patterns, makes it easier
for new onboarding members to get the code context and
contribute to it quickly as soon as possible and a clear benefit
in terms of both agility and employee development.
VI. FUTURE CHALLENGES
A. MODULARIZATION
To rightly modularize the application is a challenge. Badly
designed application can lead to unintended network calls and
poor performance. This is especially true for micro-services

4
and other approaches in which poorly constructed boundaries
can lead to increased network overhead of communication.
Such an increase might add a system unsuitable for its
preferred tasks and abnormal performance.
B. FRONT-END INTEGRATION
User Interfaces are typically an important component in
micro-service architectures. This is normally because they are
not the focus of most of the architects, who typically are
dealing with back-end mechanisms. This can add to
applications having a monolithic front-end utilize a number of
back-end micro-services. Such methodologies occasionally
can be perfectly fit for a scenario, but they often inhibit the
goals of micro-services because all the drawbacks of a
monolithic approach still are there.
Decomposition of front ends user interface of different
kinds, whether native, web, and hybrid, along with their
realtion as part of either microservices or a communicating
entity, is often badly required to ensure organizations
implement a full-stack microservice environment.
C. SELF REPAIR
To reduce the impact of partial implementation,
developers should implement fault tolerant components that
can gracefully respond to specific kind of failure. Researchers
and practitioners have introduced ways to differentiate failures
so that they do not have to go throughout a distributed system.
Therefore, more work is required on self repair or automated
failure management and self-healing implementation to fix an
application after a fault.
D. RESOURCE MONITORING & LOGGING
As micro-service applications code and complexity grow,
the size and variety of infrastructure resources allocations (for
instance, virtual containers, machines, services, messages,
processes, thread pools, and logs) that must be continuously
managed and monitored at runtime also increase. In addition,
services might be deployed across multiple areas and
availability zones, which ensures the difficulty of collecting
up-to-date data about their status and implementation.
However, with the increasing complexity of automation that
recent monitoring technologies enable, application developers
may find themselves amid a flood of monitoring actions, not
able to make decision for timely management.
The drawback of this methodology is that it bounds the
ability to update and scale services separately. It also creates
complexity in managing dependencies. For example all the
services hosted on the similar server will access same version
of pragramming language. Further, these separate services can
create unwanted side effects for other running services which
could be a very complex process to recreate and solve.
Although micro-service architectures have different kind
of approaches to implement, they all have one come goal
which is to speed up delivery time. Adopting micro services
architecture would reduce design complexity and code
dependencies. Agility would be ensured due to individual
development, deployment and parallel feature development of
each micro service. Badly designed application architecture
can lead to unintended communication calls, more code
complexity and poor performance. Modularizing front ends to
ensure a full stack micro service architecture. Defining a
framework that can rightly access the responsibility and size
of each micro service. Micro service monitoring and resource
management for large applications.mini- mum of centralized
management.
To solve such problems, a preferred approach is to take
advantage of a centralized logging service that aggregate logs
from each service instance. Users can search through these
logs from one centralized spot and configure alerts when
certain messages appear.
E. VERSIONING
When you modify to latest versions, keep this in mind that
you may violate backward compatibility. You can develop in
conditional business logic to develop this, but that gets
weirdly, fast. Alternatively, you could create up various live
versions for various different clients, but that can be more
difficult in management and maintainance.
F. TESTING
Integration testing, also known as end-to-end testing, can
become more complex, and more crucial than ever. Know that
a fault is one part of the architecture could create something
a few steps away to failure, depends upon on how you have
constructed your services to integrate one another.
G. DEPLOYMENT
This is also a complex challenge, at start in initial set up. To
make deployment easy, you have to first invest in a lot of
automation as the difficulty of micro-services becomes an
obstacle for human deployment. Have a thought about how
you arre going to monitor services and in which order.
ACKNOWLEDMENT
The Author would like to Thank his Teacher Dr. Husnain
Mansoor Ali for his Guidance throughout the Research
process.
CONCLUSION
This paper attempts to uneveals ambiguous usage of term
and definitions of Service Oriented Architecture and Micro-
services. It specifies functionalitites and differences of both
architectures, pointing out their weaknesses, strengths, and
differences. While both architectures address application
integration, the industry seems to transition toward micro-
services for ERPs and Large Applications, leaving Service
Oriented Architecture as legacy. The main credit for this
tendency can be given to the ability of separate service deploy,
autonomy and elastic scalability.
REFERENCES
[1] Zheng, Ling, and Bo Wei. “Application of Microservice Architecture in
Cloud Environment Project Development.” Edited by Nader Asnafi. MATEC
Web of Conferences 189 (2018): 03023.
https://doi.org/10.1051/matecconf/201818903023.
[2] Cerny, Tomas, Michael J. Donahoo, and Michal Trnka. “Contextual
Understanding of Microservice Architecture: Current and Future
Directions.” ACM SIGAPP Applied Computing Review 17, no. 4 (January 29,
2018): 29–45. https://doi.org/10.1145/3183628.3183631.
[3] Baboi, Mihai, Adrian Iftene, and Daniela Gîfu. “Dynamic Microservices
to Create Scalable and Fault Tolerance Architecture.” Procedia Computer
Science 159 (2019): 1035–44. https://doi.org/10.1016/j.procs.2019.09.271.
[4] Bucchiarone, Antonio, Nicola Dragoni, Schahram Dustdar, Stephan T
Larsen, Manuel Mazzara, and Fondazione Bruno Kessler. “From Monolithic
to Microservices: An Experience Report,” n.d., 4.
[5] Balalaie, Armin, Abbas Heydarnoori, and Pooyan Jamshidi.
“Microservices Architecture Enables DevOps: An Experience Report on
Migration to a Cloud-Native Architecture,” n.d., 13.

5
[6] Jamshidi, Pooyan, Claus Pahl, Nabor C. Mendonca, James Lewis, and
Stefan Tilkov. “Microservices: The Journey So Far and Challenges Ahead.”
IEEE Software 35, no. 3 (May 2018): 24–35.
https://doi.org/10.1109/MS.2018.2141039.
[7] Tapia, Freddy, Miguel Ángel Mora, Walter Fuertes, Hernán Aules, Edwin
Flores, and Theofilos Toulkeridis. “From Monolithic Systems to
Microservices: A Comparative Study of Performance.” Applied Sciences 10,
no. 17 (August 21, 2020): 5797. https://doi.org/10.3390/app10175797.
[8] Newman, Sam. “Building Microservices,” n.d., 102.
[9] Di Francesco, Paolo, Patricia Lago, and Ivano Malavolta. “Architecting
with Microservices: A Systematic Mapping Study.” Journal of Systems and
Software 150 (April 2019): 77–97. https://doi.org/10.1016/j.jss.2019.01.001.
[10] “Microservices – A New Application Paradigm,” 2018, 8.
[11] Daya, Shahir, Nguyen Van Duy, Kameswara Eati, Carlos M Ferreira,
Dejan Glozic, Vasfi Gucer, Manav Gupta, et al. “Microservices: From
Theory to Practice,” n.d., 170.
[12] Wu, Andy. “Taking the Cloud-Native Approach with Microservices,”
2017, 13.
[13] Christudas, Binildas. Practical Microservices Architectural Patterns:
Event-Based Java Microservices with Spring Boot and Spring Cloud.
Berkeley, CA: Apress, 2019. https://doi.org/10.1007/978-1-4842-4501-9.
[14] Taibi, Davide, Valentina Lenarduzzi, and Claus Pahl. “Continuous
Architecting with Microservices and DevOps: A Systematic Mapping
Study.” In Cloud Computing and Services Science, edited by Víctor Méndez
Muñoz, Donald Ferguson, Markus Helfert, and Claus Pahl, 1073:126–51.
Communications in Computer and Information Science. Cham: Springer
International Publishing, 2019. https://doi.org/10.1007/978-3-030-29193-
8_7.

Term paper 2073131

More Related Content

What's hot

Similar to Term paper 2073131

More from mtestman

Recently uploaded

Term paper 2073131