MINAR International Journal of Applied Sciences and Technology

ISSN: 2717-8234
Article type: Research Article

Received: 05/06/2022 Accepted:15/07/2022 Published: 01/09/2022

MICROSERVICES VS. MONOLITHIC ARCHITECTURES

[THE DIFFERENTIAL STRUCTURE BETWEEN TWO ARCHITECTURES]

Nada Salaheddin ELGHERIANI1

Ministry of Technical and Vocation Education, Libya
Nuredin Ali Salem AHMED 2

Ministry of Technical and Vocation Education, Libya

Abstract:

Software development seems to be on the rise, owing to the growing necessity for businesses
to go online,. There is a push to develop upgraded applications that will help businesses
become more efficient and grow. Therefore, Software companies are always working to find
technical strategies to enable their applications to be more agile and scalable. Today's software
architectures include two trendy architectures for applications developing, monolithic and
microservices, which are both popular and powerful. Microservice architecture brings
practical benefits such as scalability and flexibility, as well as being a cost-effective means of
developing large applications. On the flipside, the monolithic approach is losing favor since it
endangers current software delivery methodologies, As well, microservices and monolithic are
always topical when it comes to applications developing. In this paper, we will discuss the
differences between Microservices and Monolithic Architectures, highlighting their strengths
and weaknesses in each, and minding a comparative depending on selecting a simple travel
application structure, which wins to be chosen as the best choice in the software business
world.
Keywords: Microservices Architecture, Monolithic Architecture, Software Architecture,
Application.

http://dx.doi.org/10.47832/2717-8234.12.47

1
Nada.slhxx@gmail.com
2
Nuredin.ahmed@cctt.edu.ly

This article has been scanned by iThenticat No plagiarism detected

Copyright © Published byMinar Journal, www.minarjournal.com
Rimar Academy, Fatih, Istanbul, 34093 Turkey
 Volume 4, Issue 3, September 2022

Introduction:
When it comes to the question of how to structure code, all software needs an
architecture for better understanding, communication, consensus, and negotiation among
the various stakeholders. The security, dependencies, guidance, and implementation of
defined guidelines are all determined by the software architecture, which is the backbone of
the software project. Many companies, like Netflix, Amazon, and eBay, have shifted their
applications and systems to the cloud because the cloud computing paradigm allows them to
scale their computer resources according to their needs. Microservices Architecture is also
regarded as a method for developing software. A software application created using a self-
contained set of components that operate each application process as a service is described
here. A component in a loosely connected architecture is independent of the others, can be
written in different programming languages, use multiple data storages, and only performs
one function. On the other hand, Monolithic architecture is an integrated approach to
software development. All software components are linked and interdependent in this
environment. To run code or compile effectively in such a tightly connected architecture, each
component and its related components must be functional [13][14].

Monolithic Architecture
One of the oldest software architectures is monolithic architecture. The goal of this
design is to construct an application with all of the required components. All components are
interdependent and, in many cases, cannot run or even compile independently. Monolith
programs have a lot of distinct libraries inside of them [15]. Monoliths, on the other side, as
companies grow, the monoliths grow with them, where monolith holds all classes, functions,
and namespaces for the entire application, the benefits of employing a monolithic architecture
include that all logic for handling a request runs in a single process. Certain jobs, such as
testing, become trivial for developers as a result of this. Monolith applications can be divided
into three categories, the one that works across single mono, The relational and non relational
type where developer get the process-oriented database structure, finally the over engineered
tar-ball component as many developers name where the whole code must have been
documented all over.
This paper turns on web application transforming as tacked on using mono architecture
firstly. Therefore, Monolithic applications with only one process are the simplest. Many
components can be combined into a single process in such applications. This is the most
popular sort of monolith system.
There are also monolithic systems that are widely distributed. Distributed monolith
systems may include numerous distributed components that are incompatible with one
another and must be installed together. In most cases, monolithic applications are installed
as a single service, except for distributed applications. Monolith applications are frequently a
single process, therefore monitoring them is straightforward. End-to-end testing of monolith
applications is definitely simple [10]. Monolithic application developers do not have to consider
aspects of securing communication between several services, which is an advantage.
Certainly, cheaper hosting costs for monolithic programs can be significant. Monolithic
applications often perform better than microservices applications. The lack of requirement for
communication with another process or service is the major reason for this. Monolithic
applications have several problems, one of which is their vulnerability. It is common for one
issue to have a huge impact on the overall application, rather than simply a small fraction of
it. Monolithic applications are also technologically driven. The same technological stack must
be used to construct a complete application. It can lead to trouble when updating a software's
code to a newer framework version. Another challenge with monolithic applications is that
they can be difficult to interface with other software [11][13].

www.minarjournal.com
485
MINAR International Journal of Applied Sciences and Technology

The development team is bound to commit to a single technology in monolithic

architecture, which has its own set of limitations. For example, if the application's framework
becomes obsolete over time, shifting to a newer, better framework can be difficult. It's possible
that the development team will have to rewrite the entire application in a new language and
on a different framework, which is both risky and time-consuming.
Monolithic features a massive codebase that is made up of interconnected components.
Because modifying a single component requires the entire application to be redeployed, such
an application structure makes frequent deployments difficult [13]. This not only causes
problems with background processes, but also affects the operation of associated services.
Due to the sheer risk of redeployments, frequent application changes are forbidden, Table 1
presents the strengths and weakness of Monolithic architecture according to its base
structure [4][5][15].

Strengths of Monolithic Architecture Weakness of Monolithic Architecture

Less cross-cutting concerns Understanding
Logging, handling, caching, and performance When a monolithic application grows in size, it
monitoring are all aspects that affect the entire becomes complicated to understand. Furthermore,
application. This section of functionality only managing a complicated coding structure within a
affects one application in a monolithic application. single application is difficult.
Making changes
It is harder to implement changes in such a large
Easier debugging and testing
and complex application with highly tight
Debugging and testing monolithic applications is
coupling. Any code change affects the whole
significantly easier. Whereas monolithic software
system so it has to be thoroughly coordinated.
is one indivisible item.
This makes the overall development process
much longer.
Simple to deploy
There is no need to deal with several deployments Scalability
when it comes to monolithic applications, just one Only the whole application.
file or directory.
Simple to develop
New technology barriers
Any technical team with proper abilities and
Applying new technology to a monolithic
knowledge can design a monolithic application as
application is exceedingly difficult because the
long as the monolithic approach is a typical way of
entire application must be rebuilt.
building applications.
Strengths and weakness points in Mono - [Table 1]

Microservices architecture
Business logic has split down into minimal, single-purpose self-contained services in a
microservice architecture. Each architectural service is in charge of achieving a certain
commercial aim. In essence, the microservice architecture resembles a Lego construction that
has been broken down into several components. APIs [Application Programming Interface]
guarantee that the system's components communicate with one another.
The phrase "microservice" has recently received a lot of traction. Starting with Netflix,
which has been adopted by some companies, including Amazon, Spotify, and Sound Cloud.
The microservice architectural style is a method of developing distributed systems that are
developed to address the shortcomings of monolithic architecture. It is an extension of classic
service-oriented architecture (SOA), highlighting the division of a system into small, compact,
and loosely connected services, each executing on its own process space and developed to
perform a highly integrated business function. The autonomy of services is one of the primary
characteristics of microservices. While microservices are independent of one another and
should not share the same data source, they can also be deployed independently. Each service
is in charge of a little amount of logic that is centered on the same business domain. The
question is whether the microservice should be modest or large. It can defined as an

www.minarjournal.com
486
 Volume 4, Issue 3, September 2022

application that can be rewritten in two weeks. Instead of having one large-scale, service that
handles all business logic, a microservice architecture is a distributed system where all its
modules are microservices, each dedicated to a single business capability. This fosters
separation of concerns and allows each service to be independently replaceable, upgradeable,
and redeploy able at any time [12][13].

Characterized control and data management are also provided by independence. The
database per service pattern refers to each service having its own, independent storage system
that can be built with the most appropriate technology stack for the work at hand.

Microservice architecture is flexible and creates opportunities for companies to respond

faster to inevitable change because of its evolutionary design. Microservice architecture can
increase agility, developer productivity, resilience, scalability, reliability, maintainability,
separation of concerns, and ease of deployment. However, all of this comes with its own set
of challenges. Services communicate over the network as microservices are built
independently. This requires service discovery, enhanced security management, improved
communication, and load balancing. Microservices architecture allows developers to build
applications utilizing a variety of technologies (languages, frameworks, and operating
systems). With a single technological stack, this eliminates dependency and long-term
commitment. A new, better technology stack can be implemented whenever a new service is
established or an old service is updated [11][13].
This also reduces the development team's dependence on a single resource for creating
or updating services. Each component of an application is operated and scaled separately in
microservices. This means that if one of the application's services is changed, the other
services will remain unaffected. Furthermore, microservices do not exchange code or
implementation with other microservices. Microservices architecture makes continuous
development and deployment of large, complicated applications simple [13]. Using these little
standalone, applications that provide specific functionality have both strengths and Weakness
points. Table 2 - presents the strengths and weakness of Microservices architecture [4][5][15].

www.minarjournal.com
487
MINAR International Journal of Applied Sciences and Technology

Strengths of Microservices Architecture Weakness of Microservices Architecture

Independent components
Starting with, all of the services can be installed
Extra complexity
and upgraded independently, allowing for
Whereas a microservices architecture is a cloud-
greater flexibility. Moreover, a problem in a
based system, the connections between all of the
single microservice affects only that service
modules and databases must be established and set
and does not affect the entire application. In
up. Furthermore, if an application has independent
addition, adding new features to a microservice
services, each one must be deployed separately.
application is significantly easier than adding
them to a monolithic program.
System distribution
Easier understanding
Since a microservices architecture is a
Microservice applications are better to
complicated system with many modules and
understand and manage since it is broken
databases, all of the connections must be
down into smaller and simpler components.
carefully managed.
Better scalability
The microservices architecture also has the Cross-cutting concerns
advantage of allowing each component to scale To deal with many cross-cutting concerns when
independently. As a result, the entire process is developing a microservices application.
less expensive and time-consuming than with Externalized configuration, logging, metrics,
monoliths, where the entire application must health checks, and other features are among them.
be scaled even if it is not required.
The higher level of agility
Any flaw in a microservices application only Testing
affects one service, not the entire solution. As a Testing a microservices-based solution is
result, all of the modifications and significantly more difficult due to a large number
experimentation are carried out with fewer of independently deployable components.
risks and errors.
Strengths and weakness points in Micro - [Table2]

Paper Questions
How do monolithic work [3][4]?
The monolithic architecture is made of various components that work with each other to
define it. These include the following:
Business layer; this layer specifies what the application must do to meet with business logic.
Database layer; It serves as a repository for all required data objects.
Presentation layer; this layer improves the communication between the user interface and
the browser.
More specifically, the application's requests and responses.
Persistence layer; it takes care of object-relational mapping and other tasks.
In a monolithic architecture, all the layers act in isolation from each other. It implies
that any change in any layer requires an update on the remaining layers to be executable.
How do microservices work [3]?
Microservices architecture divides functions into smaller parts known as services. These
services are set up to carry out specific activities or operations. Moreover, the database
structure is such that depending on the type of data needed to handle specified tasks, each
microservice has its own database or may share one. The microservices communicate with
one another using an API. An application-programming interface [API] is a collection of
instructions that allows users to call the application and receive the necessary data. The API
retrieves data from numerous microservices in order for the end client's mobile or desktop
applications to conduct the appropriate requests.

www.minarjournal.com
488
 Volume 4, Issue 3, September 2022

Why microservices [4]?

Each microservice can be deployed independently There is no need to re-deploy the
entire application with each update, and for complicated applications, continuous deployment
is conceivable. The team dedicated to that service in terms of development can build
Microservice independently. Decomposing an application makes it considerably easier to
design applications that are more comprehensible and maintainable. Adapting to new
technologies is simple since developers are free to choose the technologies that make sense
for their service rather than being restricted to the choices made at the start of the project.
Which software architecture to choose [7]?
To answer this question, business requirements such as project budget, estimates, and
revenue must first be stated. Small enterprises and startups will thrive from the monolithic
approach since that allows for easy development and deployment. But at the other hand,
microservices will aid in the implementation of changes and upgrades to the application
structure.
By considering the following scenarios, for choosing to choose a monolithic architecture
firstly, a project must be informed in many different ways, Like:
• Plan to create a basic application that will not require future upgrades. The project's
complexity will be a disadvantage in this situation due to the microservices architecture's
complexity.
• The product must be deployed as soon as possible.
• Will not have a staff of specialists who can partition the system into different functionalities
and assign roles.

Reasons for making the choice to choose a microservices architecture secondly:

• Set to deploy a large-scale, sophisticated application. The implementation of new
technologically advanced stacks will be the ideal answer if new functionalities and upgrades
to the application that required in the future. Microservices strategy will be particularly useful
for gaining a competitive advantage in this regard.
• If there were specialists who are strongly tied to microservices and have extensive knowledge
in this industry, this would be ideal for microservices architecture strategies.
Not all architecture is created equal. Likewise, although not all applications are created
similarly. Microservices are better suited to sophisticated and dynamic applications, on the
other hand, will be a monumental task without sufficient competence in these technologies.
In addition, many people think differently in architecture. Some people believe that the
application should build as a monolith initially for being easier at first then switched to
microservices when growing. However, the main point in software architecture is that there
would be no need to start with monoliths if the goal was to construct a microservices
application. Choosing the best architecture always depends on the software’s structure and
the purpose created for the service.

www.minarjournal.com
489
MINAR International Journal of Applied Sciences and Technology

What are the differences in software development methodologies among microservices

and monolithic architecture [4][15]?
Monolithic Architecture Microservices Architecture

Tightly connected service components. Loosely coupled service components.

Usually takes longer to develop. Quick to develop and takes little time.
All of the components are interdependent, and if one Any service that goes down can be addressed
goes down, the entire application falls. independently without affecting the application.
Requires less resource distribution because the services
Each team can work independently.
are It follows a centralized approach dependent.
Continuous and rapid application delivery is tough The entire team contributes to numerous advancements,
for the application development process must be allowing for speedier development and ongoing
initiated from scratch. delivery.
Less scalable Highly scalable
Difficult to communicate amongst teams. The team's communication is clear and effective.
Project-based approach. Product-based approach.
One technology can be utilized at a time, and the
Various technologies can be applied to different service
application cannot be upgraded with newer
components.
technologies.
Differential differences for Micro and Mono Architectures [Table 3]

Software Industry Issues and Priorities

All software companies aspire to be more agile and faster, to deliver products more
quickly, to have shorter release cycles, and to help their customers achieve Digital
Transformation. Hundreds of legacy apps are sitting in on premise data centers for the
majority of mid-to-large businesses, and they want to shift them to the cloud. They commonly
transfer their applications to the cloud in their current state, but this is ineffective. Cloud
applications must build in such a special manner.
This paper will show how shifting an application structure from monolithic to
microservices can change the whole business strategy, Where Microservices provide lots of
benefits over monolithic systems, although they are a relatively new idea. Numerous
monolithic applications have previously been developed. They are not really cloud natives.

Methodology
To compare the structure of two different architectures on travel applications. Initially
identify the first application, which is built using monolithic and prove the challenges of
shifting to microservices, then understand how microservice application can provide backend
capabilities by exposing APIs, where the gateway displayed in the frontend of the entire system
that includes all of the APIs of every microservice application in the system.

Microservices Platform
For this type of application, a microservices-based system would be suitable. A
microservice would handle each phase of the data preparation process: data collecting,
filtering, normalization, enrichment, aggregation, and reporting. The microservices approach
naturally provides a trackable lineage, making it very easy to trace back, which microservices
may need to be modified if data issues happen. In the case of microservices architecture works
through component isolation. If one microservice fails in this loosely connected architecture,
it is easy to spot and assures that other sections of the program are unaffected. The proactive
avoidance of platform inefficiencies and failure through microservice autonomy is becoming

www.minarjournal.com
490
 Volume 4, Issue 3, September 2022

increasingly relevant for industries and enterprises that frequently deal with a high volume of
requests or the interchange of sensitive data across multiple applications. Furthermore, the
separation of distinct platform components makes monitoring easier, technical staff can also
tap into deeper functionality from a service-layer perspective, and empower continuous
development, integration, and refinement of their important processes in a way that can
actually transform and move ahead, due to the power of microservices architecture [12].

Travel application architecture Scenario

Software Company has implemented a travel platform, this application has implemented
using a monolithic backend system. While it was difficult to integrate hundreds of service
providers because its technology differs greatly and some have minimal technical expertise.
The replacing architecture base is needed eventually [9].

Monolithic architecture in use

Serving so many routes with so many different transport modes, plethora of offers,
promotions, rules, dynamic timetables, moving grounds, and a seemingly unlimited amount
of journey segment permutations is no small engineering achievement. The magic that
transpired between pressing the search button on the landing page and showing a list of the
most intriguing connections was managed by a single monolithic application at
the beginning, for when the volume of the traffic, data, codebase, and number of external
integrations was significantly was much smaller. However, as everything continued to rapidly
increase in numerous dimensions, it became increasingly difficult to build and operate. The
whole stiff working probably knows what happened next, by keeping up with current software
architecture and technical advances. Everything concerning provider integration was built
as a monolithic service because the design was simple enough.
Integrating providers is just one part of the puzzle when it comes to creating a search
result. Originally, all of the code was contained within a single monolithic application.
Conflicts arise frequently among teams working on the same codebase. Changes in one place
had unintended consequences in other others. It was difficult and time-consuming to
coordinate releases amongst teams. A large number of changes released at the same time
raised the chance of failure. Difficult to trace the particular commit that caused a failure if
one occurred, and it may not always be possible to reverse it because there may have been a
lot of other changes stacked on top of it [15][6].

Application Architecture
Travel: Airfares displayed and airline tickets purchased.
Hotel: Hotel room listings and reservation.
Purchase: Providing users with the ability to make payments.
Authentication: Identification service for signups, logins, and logouts, among other things.

www.minarjournal.com
491
MINAR International Journal of Applied Sciences and Technology

[Figure1] explain how mono works as one block.

[Monolithic Architecture] [Figure 1]

Thinking Microservices
Application growing study: By choosing to use feature toggles, one may easily enable or
disable new code execution pathways and functionality based on database entries. This would
be nevertheless, frequently difficult and blunder, as there was sometimes a need to branch
the logic in multiple locations. Away from the increased development complexity, the
application grew increasingly difficult to start and demanded increasing amounts of
resources. As a result, increasing the number of replicas in production proved challenging
and inefficient in terms of CPU and memory usage [6] [Figure2].
First, a single architecture that controls the layout of basic search results, bookings, and
travel modes, among other things. The model comprises a search result structure that
incorporates travel legs, segments, stations, trains, stops, and offers, among other things.
Second, a bootstrap application that serves as a runtime framework around the code for a
specific provider search integration and displays all of the required API endpoints as specified
in the Search Core contract.
Finally, when building a new integration, a code-generation tool based on Rhythm templates
is used to generate all of the glue code.

[Microservices Architecture] [Figure2]

Layout service in Microservices

Since microservices are lightweight, self-contained, and Cloud hosting that are simple
to comprehend, deploy, and scale. While constructing this application as a collection of small
services, each executing in its own process and communicating using lightweight mechanisms
[HTTP resource, and API].
Description: Microservices supports dividing a monolithic application into smaller bits
or components. In other words, it separates each module from the monolithic architecture as
a standalone monolithic architecture. It takes a modular approach to huge application
development. The microservices’ individual services or components are loosely coupled with
one another. Additionally, they function as a self-contained unit. By comparing the monolithic

www.minarjournal.com
492
 Volume 4, Issue 3, September 2022

architecture to microservices, standing on three basic steps (Development, Troubleshooting,

and Deployment) greatly enhance the company's experience when developing an application.

Development
The monolithic design will most likely use a single codebase or repository. This implies
that all developers contribute separately to a single codebase. They are pulling the most recent
code from a remote repository, as well as pushing and merging their own. This creates a lot
of code clashes as a development workflow. As a result, resolving these issues may cause the
workflow to slow down. As going in-group of developers is working on the payment mechanism
of application. Another team could be working on the authentication module at the same time.
However, they are both bringing in new code and pushing it to the same repository. This is
not necessary because their activities are unrelated and could generate confusion. The
payment team no longer has to be concerned about the authentication team's most recent
codebase changes. Similarly, the authentication team can push their code without involving
the payment team. Definitely a cleaner, nicer, and more enjoyable development process.

Troubleshooting
The architecture in monoliths is tightly coupled frequently leading to difficult-to-trace
faults and defects. This is due to the fact that modifications in one component or module can
frequently result in unintended changes in other connected modules. As working on a flaw in
the authentication module.
However, as it is so close to the payments module in the same codebase, technical
staff accidentally introduced an unwanted behavior in the payments module. In this situation,
the monolith suffers from the drawback of being more vulnerable to application bugs. In
addition, microservices are more flexible in this situation. Because of payment module is
lightly connected with the authentication module, no matter how many flaws are created in
the authentication module, the payment module will stay intact. Since the authentication and
payment modules are different projects, even inadvertent changes to the authentication
module will not affect the payment module.

Deployment
In monolith, updating the authentication module on the server requires redeploying the
entire application. One of the major drawbacks of monoliths is that a slight change in a
supposedly isolated module can result in the entire application being deployed. Furthermore,
if the factor in the resulting downtime, it could be a difficult condition for company, users,
and entire product. In this situation, the related delay is only visible in the authentication
microservice. All of the other microservices continue to function normally [15][13] [Figure3].

Monolithic Microservices

Full Application Deployment [Figure3] Individual Services Deployment

Cost and Complexity

www.minarjournal.com
493
MINAR International Journal of Applied Sciences and Technology

For microservices the more components the architecture has, the more complex it is to
manage and maintain them. As a result, the whole application's cost and complexity
increases, having many services, each hosted separately means having independent
codebases. In addition, each microservice should have its own database, the additional cost
and complexity of hosting databases could be significant. Monolithic is straightforward, not
lavish. In terms of infrastructure, just one server is required for the application and another
for the database [14].

Communication between sectors

To book a flight, the user launches the application. Two application modules are used
in this scenario. The first is the travel one, which displays all available flights, reserves a seat
for user, and generates e-tickets, and so on. Second, payment; without paying, no reservation
can be made.
By mentioning how the travel module communicates with the payment module
in monolithic, first; at the time of payment, invoking the payment module from the travel
module. Furthermore, in monolithic architecture, all modules are in one location. The code
works from any location.
The travel microservice must communicate with payment microservice. Each
microservice need to interact with the others if user wanted to book a complete travel package
like, airline tickets, hotel room. Furthermore, some use cases may require a lot of back-and-
forth across multiple microservices. For example, user may buy a flight and a hotel for
themselves, and then book a hotel for a business visitor. Clearly, monolithic systems have the
ability to be faster than their microservice equivalents.

Results
Users are always looking for services that are faster, more efficient, and more
performant. Monolithic services might be faster than their microservice equivalents.
Interservices communication is where this performance comparison differs. Each
interservices connection with microservices will almost certainly take the form of an API call
[16]. This API call is transformed into code calls or function invocations in monoliths.

Scalability
Using a load balancer and many server nodes to achieve horizontal scaling in monolithic
architecture. Monolithic would be able to scale effectively without a single point of failure. As
a result, if one of the server nodes or the API server fails, the other nodes can step in to help.
However, one disadvantage of scaling monoliths will always be the separation of business logic
[13] [Figure4].

[Horizontal scaling- Monolithic Architecture] [Figure4]

www.minarjournal.com
494
 Volume 4, Issue 3, September 2022

At the business level, the requirement to divide modules or components becomes more
critical. Microservices are incapable of horizontal scaling. Individual microservices can be
scaled as and when needed, allowing for granular scaling [14][6] [Figure5].

[Granular scaling- Microservices Architecture]

[Figure5]

Conclusion
According on the comparisons, the software firm must select which factors are crucial.
Monoliths is a good place to start. It is also a good idea to have a small team for monolithic.
When it goes to scale the application from a medium to a somewhat large size, horizontal
scaling in the monolithic is good. As microservices, fits with a large and diverse workforce,
and a diversity of tech stacks, wins this one. As a result, the decision is to bear the cost and
complexity of microservices.

Acknowledgement
While attempting to make the implementation even easier, companies must be aware
that rapid coverage expansion requires a transition to generic deployments and the
development of APIs and tools that allow others to integrate with us rather than the other way
around. Besides from expanding coverage, additional features are being added to the site to
help travelers from the moment they decide to take the journey, through planning, searching,
purchasing tickets, the actual journey, even after it has ended. The more comprehensive and
intelligent the platform develops, the more advanced the technology supporting it becomes.
Microservice architecture solves many problems, but it also brings new ones. It requires a
significant initial investment in infrastructure, which may be difficult to achieve in smaller
enterprises. However, when the number of developers, system size, and traffic increase, the
solution really shines.

Concepts
API “Application Programming Interface” [16][17]
Consider as a set of operations that allow applications to interface with external software
components, operating systems, or microservices in order to access data and interact with
them.
There are two parts to an application programming interfaces:
• Technical standards providing the choices to data interaction across solutions, written in
the form of a request for processing and data delivery protocols.
• Software interfaces written for the standard describing it.
Each API includes and implemented via function calls, which are language statements that
instruct software to do specific activities and services. Function calls are made up of verbs
and nouns:
• Start or end a session.

www.minarjournal.com
495
MINAR International Journal of Applied Sciences and Technology

• Get amenities for a specific type of accommodation.

• Objects can be restored or retrieved from a server.

Application Programming Interface -Gateway [API-Gateway]

In any microservice architecture, an API gateway is essential. It is single, consistent API
access point across one or more internal APIs provided by an API gateway. Rate limiting and
security are usually layered on top of each other. The number of services in a microservice-
based architecture can range from ten to one hundred or more. Regardless of the number or
composition of internal microservices, an API gateway can assist provide a unified entry point
for external users.

www.minarjournal.com
496
 Volume 4, Issue 3, September 2022

References:
[1] Lebedev, A. (2021). monolithic and microservices-based architecture. Retrieved from:
https://morioh.com/p/54271e7358ad?f=5c224490c513a556c9042463&fbclid=IwAR0Uly4Y
TIS0cKeKPCR5I_e8ZcrIRJEwA62AUoAAciOT4vhD8VcHZcetkfU
[2] Dissanayake, B. (Nov 17, 2019). Level up coding. Monolithic vs. Microservices Architecture.
Retrieved from: https://levelup.gitconnected.com/monolithic-vs-microservices-architecture-
b333c8754187
[3] Kharenko, A. (2015). Monolithic vs. Microservices, Monolithic Architecture. Microservices
Practitioner Articles. Retrieved from: https://articles.microservices.com/monolithic-vs-
microservices-architecture-5c4848858f59
[4] Jain, P. (October 28, 2020). Monolithic vs Microservices – Difference, Advantages &
Disadvantages. Retrieved from: https://k21academy.com/docker-kubernetes/monolithic-vs-
microservices/?utm_source=facebook&utm_medium=referral&utm_campaign=kubernetes31
_jan21_cloud_for_beginners&fbclid=IwAR3KFlLGXZt_dVIh6DitflogpS2JubJo0DZswr4ods0G
YakwHBdb6vrshNU#8
[5] Spratshi. (Aug 13, 2021). Monolithic Vs Microservices Architecture. Retrieved from:
https://rollbar.com/blog/monolithic-vs-microservices-architecture/r
[6] Eisele, M. (June 16, 2019). Monolithic Vs Microservices. Retrieved from:
https://programmerfriend.com/monolith-vs-
microservices/?fbclid=IwAR0YO3B8H2Q43YG2INYHIO7AZ5I6yAb2UwavO3O_s0K16_9Rf1cD
bI_Cirk
[7] Kaczmarek, A. (Jan 8, 2021). Monolithic vs Microservices - which architecture to choose?.
Retrieved from: https://softwaremill.com/monolithic-vs-microservices-
architecture/
[8] Matloka, M. (Aug 03, 2020). How to design microservices architecture?. Retrieved from:
https://softwaremill.com/designing-microservices-architecture/
[9] Maddikera, B. (Mar 20, 2021). How to Build Micro Services - Real World - Travel App.
Retrieved from: https://www.linkedin.com/pulse/micro-services-travel-app-bhargav-
maddikera
[10] Vistola, L. (July 23, 2021). The Move Away from Monolithic Application Development.
Retrieved from: https://devops.com/the-move-away-from-monolithic-application-
development/
[11] Sontz, M. (2022). From Monoliths to Microservices – Benefits, and Challenges. RCG
Global Services. Retrieved from: https://rcgglobalservices.com/monoliths-microservices-
benefits-
challenges/?fbclid=IwAR0YO3B8H2Q43YG2INYHIO7AZ5I6yAb2UwavO3O_s0K16_9Rf1cDbI_
Cirk#:~:text=Refactoring%20a%20monolithic%20application%20to,ahead%20and%20plan%
20for%20failure
[12] Garcia, L.M., Aciar, S., Mendoza, R., & Puello, J.J. (2018). Smart Tourism Platform Based
on Microservices Architecture and Recommender Services. Mobile Web and Intelligent
Information Systems, pp.167-180.
[13] Blinowski, G. Ojdowska, A. & Przybylek, A. (Nov 30, 2021). Monolithic vs. Microservices
Architecture: A Performance and scalability Evaluation. IEEE Access.
[14] Na, N., Wang, W., Xu, Y & Luo. W. (2019). A Microservice–Based Big Trajectory Data
Processing Platform for Multimodal Trip Planning. International Conference on Big Data,
Electronics, and Communication Engineering.
[15] Harries, S. (2020).Microservices Vs. Monolithic. Retrieved from:
https://www.atlassian.com/microservices/microservices-architecture/microservices-vs-
monolith.
[16] Johnson, J. (Dec 16, 2020). Microservices Vs APIs: What’s the difference?. Retrieved from:
https://www.bmc.com/blogs/microservice-vs-api/.

www.minarjournal.com
497
MINAR International Journal of Applied Sciences and Technology

[17] Longbottom, C. (Jul 29, 2021). Microservices Vs APIs: How they differ and work together.
Retrieved from: https://www.techtarget.com/searchapparchitecture/tip/Microservices-vs-
APIs-How-they-differ-and-work-together.

www.minarjournal.com
498