Microservices Architecture for DTGOV Travel Application Redesign

This document is a report proposing a redesign of DTGOV's monolithic travel and accommodation booking application to a microservices architecture to facilitate migration to the public cloud. The current application, used by DTGOV customers for booking travel and accommodation, is outdated and experiences performance issues. The report identifies stable modules (engines, cart) and those requiring frequent modification (costs, requirements). The microservices approach will restructure modules like travel requirements (inventory service), account administration (account services), search engine (diversified browsers), and storefront user interface (recommendations). The processing engine will be the shipping service. The benefits of this approach include improved application delivery and deployment, ease of development, improved fault isolation, and technology flexibility. The architecture design and a glossary are also included. The goal is to enhance DTGOV's application availability and global accessibility.

[Document title]
[Document subtitle]
[DATE]
TEMAOS
[Company address]

CONTENTS
Introduction......................................................................................................................................1
Modules...........................................................................................................................................1
Microservices Architecture..............................................................................................................1
Microservices application............................................................................................................1
Microservices approach...............................................................................................................2
The architecture design of the microservices application............................................................3
Glossary...........................................................................................................................................3
Conclusion.......................................................................................................................................4
References....................................................................................................................................4

1 INTRODUCTION
This documentation is a proposal on a redesign of monolithic applications to a microservices
application. This transformation is due to a migration of DTGOV applications and services to a
public cloud. The current monolithic application used for booking by the DTGOV is outdated,
this application which is used by DTGOV customers to book both travelling services and
accommodation services for business trips. The application has a number of modules; travel
requirements, search and the travel recommendation engines, accommodation recommendation,
cart, travel and accommodation and the account administration (Krylovskiy, Jahn and Patti,
2015). Among the listed modules some don’t require any update, for quite a long period of time
since their functionality and outputs are relatively stable. Other modules require frequent
modification as changes occur in the industry; others functionalities slows the application during
workload peaks.
2 MODULES
According to the monolithic architecture of the travelling and accommodation application, the
relatively stable modules in this application are the engine modules and the cart module. This is
due to the fact that the engine's modules are only used to navigate through the application
database basically operating on a single fixed protocol (Garcés, Villamizar, Verano, Salamanca,
Casallas, Castro and Gil, 2015). On the same, the cart module purpose is to check and advice the
client on the proper spelling of the terms and words used in the application.
The modules that require frequent modification will the ones dealing with the costs and the
requirement module. The reason is that the travel and accommodation application, prices and
requirements may differ with the seasons and holiday offers if any. This will require some time
to readjust the inventory database.
By the review of the architecture of this travel and accommodation application, some modules
will experience so much workload during peak times or even when the clients flood up in using
the application. The most likely modules to experience workload peaks are the engine modules.

This is because the engine modules are responsible for navigation through the whole application
when the clients' flood up the modules have to serve each and every client using the same
frequency as orders are being made .
3 MICROSERVICES ARCHITECTURE
3.1 MICRO SERVICES APPLICATION.
The travelling and accommodation application will undergo a serious transformation as the old
and monolithic will be transitioned to the new microservices architecture approach. This is with
the reasoning that the older application now being migrated to the cloud will bring about mobile
browsing or web browsing where much work and interfaces will be replaced by fewer and lesser
coding from the UI, the API and access to the database of the organization travelling and
accommodation application.
The microservices application will support the service modules; travel requirements, the search
engine and the travel recommendation engine, accommodation recommendation, cart, the
account admin. It will also support accommodation services and the travel services. In addition,
the new architecture will be able to accommodate multiple users including both mobile and
desktop browsers. Native mobile applications and expose an API for the third parties to consume
and this will be achieved through integration with other application through web or message
broke.
The application will handle both HTTP and message requests by performing business processes
for instance; access to the database, message exchange between different systems and responding
to HTML request. Exchange of messages between the systems is justified by the difference in
logical components of the functional sections of the application.
3.2 MICROSERVICES APPROACH
This approach will readjust some of the modules while others remain constant. In this approach
the travel requirement and the account administration module will be stable through some
changes in figures can be done. We shall have the travel requirements as our inventory service
module , account administration as the account services, the search engine will be diversified
using a number of browsers. There will be a storefront user interface which will merge the

recommendations for both travel and accommodation engines. Lastly the processing engine
module will be the shipping services where after the submission of the client's order and all the
other services have checked the order, the service will process the order against the inventory the
other services and give a response to the client either through messages or an HTML response
updating on the submitted order. Refactoring of the modules will follow the same order in the
transition.
For the modules which experience workload peaks (all the engines), the issue will be resolved by
this approach since micro-services will help in resolving this catastrophe. This will be achieved
bit by bit (Le, Nef, Stewart, Kelley, Fritzinger, Dascalu and Harris, 2015). The first bit will be
combining the recommendation engines; by this, the module will be transitioned to a single
service protocol where the client will specify on his/her order. The other bit is the search engine.
The integration of the application with the other systems will call for interaction and diversified
number of search engines linking it to the web browser which can serve millions at a go without
any effect to the application. Then the shipping services which will serve as the processing
engine for all the orders. The shipping service is internetwork based which collectively counter
checks the inventory and the requirements services against the clients' order and gives an
immediate response via message or an online HTML response (Taibi, Lenarduzzi, and Pahl,
2018).
This approach will bring about an improved DTGOV’s ability to maintain high availability for
this application as explained below in point form;
 Services such as application delivery and deployment are facilitated by the microservice
application.
Under this, several features of the application that facilitates the capability are.
i. The services are of a small scale making it time conscious in testing thus better
testability.
ii. Each service is smaller and easy to understand and change. This improves on its
maintainability.
iii. Deployment of the services can be done independently.

iv. It facilitates the deployment efforts around the autonomous/ multiple teams to be
organized.
 As each service is relatively small, its development is easy to understand. Initialization of
the application is swift, thus boosting the productivity speed of the developer.
 Has an improved fault isolation capability were unlike the monolithic architecture where
a misbehaving component brings the whole system down, in a microservices application
a defect at one section is independent thus does not affect the operation of other services.
 The microservices application also allows a user to change a technology while still
creating a new service, this is made possible by elimination of the long term commitment
to a particular technology.

3.3 THE ARCHITECTURE DESIGN OF THE MICRO-SERVICES APPLICATION (NADAREISHVILI,
MITRA, MCLARTY, AND AMUNDSEN, 2016)
4 GLOSSARY
HTTP- hype text transfer protocol
HTML – the hypertext markup language
API – this is a collection of corresponding function or procedures. They enable the creation of
development of application or access to feature and data from application, OS and other unit
services.

5 CONCLUSION
The migration of the DTGOV’s Travelling and Accommodation booking application to micro
services application will be much successful and ensure the availability of the application even in
the revolution of the technology. This will also bring the growth of the DTGOV organization as
the application will serve anywhere globally via the world wide web.

5.1 REFERENCES
Krylovskiy, A., Jahn, M. and Patti, E., 2015, August. Designing a smart city internet of things
platform with microservice architecture. In 2015 3rd International Conference on Future
Internet of Things and Cloud (pp. 25-30). IEEE.
Villamizar, M., Garcés, O., Castro, H., Verano, M., Salamanca, L., Casallas, R. and Gil, S.,
2015, September. Evaluating the monolithic and the microservice architecture pattern to deploy
web applications in the cloud. In 2015 10th Computing Colombian Conference (10CCC) (pp.
583-590). IEEE.
Nadareishvili, I., Mitra, R., McLarty, M. and Amundsen, M. 2016. Microservice architecture:
aligning principles, practices, and culture. " O'Reilly Media, Inc.".
Le, V.D., Neff, M.M., Stewart, R.V., Kelley, R., Fritzinger, E., Dascalu, S.M. and Harris,
2015.F.C.Microservice-based architecture for the NRDC. In 2015 IEEE 13th International
Conference on Industrial Informatics (INDIN) (pp. 1659-1664). 2015.
Taibi, D., Lenarduzzi, V. and Pahl, C. March. Architectural Patterns for Microservices, 2018.: A
Systematic Mapping Study. In CLOSER (pp. 221-232).