MIS603 Report: Transformation from Monolithic to Microservices

This report analyzes the transformation from monolithic to microservices architecture, focusing on the advantages of breaking down business processes into independent, self-sufficient software modules. It explores the experiences of companies like SoundCloud, eBay, and Karma, highlighting the benefits of microservices such as scalability and independent module development. The report details communication protocols like SOAP, XML-RPC, and REST, while also discussing the challenges of transitioning, including technical issues like database segregation and code refactoring. Furthermore, it addresses ethical, legal, and security concerns associated with microservices. Finally, the report provides recommendations for the Chief Technology Officer of the Whiteboard Company on implementing microservices architecture in their learning management system, ensuring a comprehensive understanding of the topic.

Running head: TRANSFORMATION FROM MONOLITHIC TO MICROSERVICES
TRANSFORMATION FROM MONOLITHIC TO MICROSERVICES
Name of the student:
Name of the university:
Author Note:

1TRANSFORMATION FROM MONOLITHIC TO MICROSERVICES
Executive Summary
The monolithic systems of the business processes incorporates imminent challenges while
developing codes or rebuilding new versions of the system. Hence, a new technological
innovation of microservices architecture is facilitating the organizations to segregate their
business activities into individual, self-sufficient software modules that will function on their
own, yet communicate with other systems to enhance smart business decisions.
Microservices architecture has various beneficial aspects such as optimality in services, easier
issue-handling features and so on; however, there are disadvantageous issues with ethical
situations, security hackings and legal issues too. This report will cover all aspects of
microservices architecture such that the CTO of the Whiteboard Company can adhere to it
before implementing the microservices architectural design in their educational management
system.

2TRANSFORMATION FROM MONOLITHIC TO MICROSERVICES
Table of Contents
Introduction................................................................................................................................3
Discussion..................................................................................................................................4
Microservice Architecture in Organizations..........................................................................4
Communication Protocols in Microservices..........................................................................6
Challenges in Transformation from Monolithic to Microservices.........................................8
Issues in Transitioning to Microservices (Ethical, Legal and Security)................................9
Conclusion................................................................................................................................11
Recommendations....................................................................................................................11
References................................................................................................................................13

3TRANSFORMATION FROM MONOLITHIC TO MICROSERVICES
Introduction
The architecture of microservices refers to the breakdown of the distinct systems in a
business process to ensure that each system works independently in spite of being connected
through simplest API’s for communicational purpose. Each of the systems are responsible of
carrying out different services and hence are developed individualistically, after which they
are integrated through API such that they can interact with each other and thereby build up an
integrated module of the business (Cerny, Donahoo & Trnka, 2018). The success behind
some high-profile organizations such as Netflix, Uber and many similar infrastructures is
their decision to shift from monolithic services to microservices such that they can pace up
their business processes with self-functioning modules, while maintaining a cohesive
approach amongst the modules operating in the business.
One of the most advantageous features of microservices architecture is that, since the
modules operate independently, hence they are built on different platforms and the coding of
the distinct systems are not integrated with each other. This allows the developers of each
individual system to attend issues separately for the system having the issue without
disturbing the other systems of the business (Granchelli et al., 2017). Modifying the codes of
one system or upgrading them for user-friendly features will not affect the functionalities of
the other system and bring the process to a halt. Apart from this, microservices architecture,
unlike monolithic services, incorporates the usage of the different programming languages or
databases that will be suitable for the systems to operate, with only one condition to fulfil that
they are compatible with the API versions (Nadareishvili et al., 2016). Thus, this paper will
highlight different aspects of microservices architecture and the elaborate the reason behind
its popularity in the current business companies.

4TRANSFORMATION FROM MONOLITHIC TO MICROSERVICES
Discussion
Microservice Architecture in Organizations
SoundCloud: The company of SoundCloud provides for a platform for distributing audio
online be it songs, podcasts or any other format for their clients to listen to it. Naturally, they
incorporates a huge database and an incomparable quantity of datasets for the functionality of
their business. However, in their monolithic systems, four to five years ago that was built
singly on the application of ‘Ruby on Rails’ had scalability issues in it and the Engineering
Director kept on patching up the system for a certain time period (Alshuqayran, Ali & Evans,
2016). However, after sometime, the company decided to shift its infrastructure to
microservices for its associated potential benefits.
For decommissioning the monolithic architecture, the company invested in the
internal tools as well as the libraries and created new features in the single module systems to
be connected by API interfaces. The company decided not to remove the single-code based
monolithic structure. Instead, they deployed new services one at a time with new codes and
later on joined the databases such that the interaction between the systems contributes to the
smooth functioning of their sound business (Zirkelbach, Krause & Hasselbring, 2018).
Although, the integration of these microservices before it replaced the monolithic architecture
incorporated high costs for the company. Moreover, the company also fell short of developers
who could build the codes for separate systems and the engineers had a feeling that they do
not have any ownership over their domain.
EBay: The organization of EBay incorporates modules of ‘Experience Services’ that directly
reverts back to the clients by providing content from the data sources available at backend
and thereby make way for interaction with users. While conducting their business flow with
monolithic structure, the company realised that many business processes are repetitive in

5TRANSFORMATION FROM MONOLITHIC TO MICROSERVICES
nature that includes ‘Product Review Modules’, ‘Marketing Modules’, ‘Merchandising
Modules’ and many other similar modules. All of these modules are used repetitively in
numerous hosting pages; however, designs are duplicated across various teams (Ueda,
Nakaike & Ohara, 2016). The developers experiences a tough time to deal with a variety of
teams to make any changes because a single change will affect the functionality of the other
teams.
Hence, the company shifted from their monolithic services to microservices to
experience the following benefits. Firstly, the architectural design at microservices minimized
the duplicity of designs across the teams. Secondly, after integrating the modules, the time-to-
market increased at a rapid rate (Di Francesco, 2017). The most beneficial part is that the
developers could apply changes to the hosting pages, mobile or web apps or in the
algorithmic data in the modules separately and for this, they do not have to take permission
from all the teams. Only the team concerned, if allows the change to happen, the developer
can modify the changes without any issue.
Karma: Microservices architecture are facilitating various organizations in this tech-savvy
world and the telecommunication company that incorporated a monolithic structure initially
built on ‘Ruby on Rails’ now has shifted to this new technological adaptation to improve
their business operations (Dragoni et al., 2017). The challenging part of their monolithic
architecture was that the scalability between the different applications varied at a significant
rate and one had to scale faster for another system. The business functions of Karma includes
management of devices, order through online, fulfilment of the orders and self-service of the
customers. However, all these functions had completely separate functionalities.
Hence, the company segregated each business function into separate modules only
establishing connection between them through the interfaces of API. The executives of the

6TRANSFORMATION FROM MONOLITHIC TO MICROSERVICES
telecom business made sure that each system had a separate set of developers who built
suitable codes for each of the systems. Shifting to microservices the company adopted
different coding languages and frameworks and aligned them with the API interface in
common. Hence, there were no more scalability issues in the business processes and thus, the
company could manage the separate databases with proficiency for each of the systems (Bao
et al., 2016). In spite of the beneficiary factors, the telecom company of Karma faced
immense troubleshooting and testing challenges while implementing the system for live
functioning. Hence, they are still working on it to overcome the challenges and influence the
positive outcomes of microservices in their business.
Communication Protocols in Microservices
SOAP: The components or modules of microservices communicate with each other through
API interfaces and thereby requires a protocol for exchanging messages or transferring data
(Yan et al., 2019). SOAP is one such protocol for communication that was used by the
architectural design of microservices in the interfaces of their API in their initial days. The
protocol is XML-based and can be used for accessing the web services through Hyper Text
Transfer Protocol (HTTP).
The purpose of developing SOAP (Simple Object Access Protocol) is to reduce the
development effort of the coders because it serves as a mediatory language through which the
software modules developed on different coding languages can converse with each other at
ease. The SOAP is a lightweight language as it is developed on XML and proves to be highly
beneficial (Villamizar et al., 2016). However, many microservices architecture of SOAP have
shifted to REST API because the SOAP infrastructure incorporates a heavy-weight
processing by including node strings and service-bus models of architecture to pass the
messages that makes the system complex.

7TRANSFORMATION FROM MONOLITHIC TO MICROSERVICES
XML-RPC: The procedure to call a function that is available on a separate software module
is referred to Remote Procedure Call or RPC, a methodology for communication which is
quite ancient than web communication. The RPC protocol of communication allows the
coders to define the API’s in a way such that they can be called through network
connectivity.
The functionality of XML-RPC is quite simple, by which the interfaces can call for a
function between different computers. The information that is exchanged is passed from the
client computer to the server computer and vice-versa using the HTTP protocol. To support
the mechanism of this information transfer, the RPC makes use of a XML vocabulary to store
the types of requests and the responses as well (Avritzer et al., 2018). XML-RPC is
advantageous to integrate the software modules of microservices because the mechanism is
swift to establish communication and incorporates the reusable logic between different data
models.
REST: Experimenting with the disadvantageous factors of SOAP protocol and XML-RPC
protocol, in the year of 2000, Roy Fielding came up with a new architectural protocol known
as the REST (Representational State Transfer). It is designed in a way such that the coupling
is loose amongst the applications concerning HTTP, thereby often used for the web services
deployment. The protocol of REST is only concerned about mentioning the guidelines of
high-level design and allows the coders to implement it at their free will. It does not enforces
any rule for low-level implementation.
The REST API incorporates six architectural constrictions that can be aligned with
any web service. The first one is that REST allows for a uniform interface, thereby making
the message-exchange platform easier to function (Herrera-Quintero et al., 2018). It is not
incorporate any specific state and thus keeps no history of sessions. The client and the server

8TRANSFORMATION FROM MONOLITHIC TO MICROSERVICES
share low coupling and thus can evolve at their own pace. REST makes the resources
cacheable and can be implemented on both server as well as client-side, thereby making the
system more scalable and flexible to perform. The most advantageous two factors of REST
architecture are that, it allows for layered system and incorporates any coding language
suitable for the system.
Challenges in Transformation from Monolithic to Microservices
Breaking down of the business processes into simpler, self-sufficient applications is
the first step of shifting a monolithic structure to microservices architectural design.
However, the separate applications of microservices structure will have their own separate
databases to support the functionality and manage the data of each system (Rufino et al.,
2017). The domain of data will vary in each database because the applications will have
separate role of operations in the business processes. However, all the individual databases
with respect to the different modules of microservices needs to share a centralised repository
such that each system can access to the common data of another system and in turn optimise
the operations of the business in microservices architecture.
Technical Challenges: To start a microservices structural design from scratch is way
more easier than shifting from the monolithic structure of the business to its microservices
format. The major problem in this architectural transformation is breaking down the single
database into smaller databases according to the division of the applications. The systems
should be segregated in a manner such that it does not affect the functional operations of the
business processes (Zhao & Medvidovic, 2019). Another technical issue that is faced by the
organizations to shift from monolithic to microservices is redefining the codes for the new
systems. The change in the existing codes might not align with the API interfaces of the new
system. Moreover, there are high chances of bug generation while restricting the existing
codes.

9TRANSFORMATION FROM MONOLITHIC TO MICROSERVICES
Hence, it is recommended to design new codes for the new microservices architecture
and thereby conduct testing at each building stage to verify the optimum functionality of the
modules. Finally, the biggest technical challenge is to integrate the modules into one huge
architecture such that the monolithic system is transformed completely to microservices
along with each module sharing smooth functioning with the other (Higashino, Kawato &
Kawamura, 2018). The organizations should hire skilled coders to integrate the modules of
the microservices and thereby check the optimization of the processes.
Organizational Challenges: The organizations will require transforming their
corporate culture along with this alteration from monolithic to microservices. Firstly, due to
the different modules, the organizations will also break down their functional divisions
accordingly and set up specific teams for each application. Unlike monolithic structures
where teams were divided according to the specialisation of the expert personnel such as
developers or testers; in microservices, each application team will incorporate one
specialisation expert of each field to handle the technical functionalities of the system
(Baškarada, Nguyen & Koronios, 2018). For this, the departmental cohesiveness will increase
at a significant rate, but the employees of the organization need to be aware of the functional
culture due to this change in the systems.
Issues in Transitioning to Microservices (Ethical, Legal and Security)
While changing the overall monolithic architecture, the companies that are
undertaking the change need to determine the ethical, social as well as the security issues
besides the technological challenges such that the functionality of the new venture turns out
to be successful in all aspects.
Ethical Issues: Not all ventures in the microservices architecture of the organizations
will turn out to be successful at one shot. Hence, the organizations need to train their

10TRANSFORMATION FROM MONOLITHIC TO MICROSERVICES
employees about the mechanisms of handling the business processes in microservices such
that no ethical issues occur during the live installation of the systems. Moreover, the data
consistency in these systems along with data integrity is one major lookout of the
organizations (Haselböck, Weinreich & Buchgeher, 2017). The members in the organization
should ethically function with each other and in case of dilemmas take the decision that will
be in the best interest of everyone.
Legal Issues: The microservices structural design of the organizations will
incorporate innovative technological applications due to which the business agenda will gain
huge revenue from the systems. Hence, the organizational executives should adapt the
regulatory compliances and the legal procedures according to the instructions of the
government and thereby avoid any kind of legal issues (Jamshidi et al., 2018). If the company
builds its own codes, it should make all legal arrangements such that the other contemporary
organizations cannot hack their code by any means. They should also maintain the legal
methods while shifting their in-house databases to cloud storages.
Security Issues: Since the functionality of the microservices is completely based on
Internet and network connectivity, security is a serious concern of the software modules of
the business applications. The organizations will be prone to data breaching and malicious
attacks and hence the IT experts of each application department should implement strong
encryption algorithms to secure their processes (Krivic et al., 2017). Multi-factor
authentication of the databases is a necessity in microservices to avoid hacking of the
database. In addition, the cyber security measures should be implemented to avoid malicious
attacks over cloud storages.

11TRANSFORMATION FROM MONOLITHIC TO MICROSERVICES
Conclusion
The report specifically demonstrates about the architectural specifications of
microservices and its benefits in the organizations. A brief introduction at the starting of the
report conceptualises the difference between the monolithic and microservices architecture
followed by the discussion of three companies who have incorporated such structure and are
deriving huge benefits from it. The protocols for application interfaces are elaborated in the
next section followed by the challenges and the issues faced by the organization. The report
will end with recommendations for the Whiteboard Company for adapting the microservices
architecture for implementing learning systems across 600 universities.
Recommendations
The CTO of the Whiteboard organizations is suggested to take the following steps for
adapting microservices from scratch in their systems:
 Methodical segregation of the business units such that each unit will incorporate its
own software module and a database associated with it.
 The application of enrolment will ensure the admission of the students in the
universities according to their respective streams by verifying the marks criterion.
 The accounting application will manage the fee structure of the students regarding
their respective courses.
 The application of course distribution will provide the online study materials to
students and conduct examination through websites.
 A centralised repository will connect all the databases of each application such that
the software modules share common data.
 Finally, before the live functioning of the system, the company should ensure
mitigation measures for ethical, legal and security issues.

12TRANSFORMATION FROM MONOLITHIC TO MICROSERVICES
References
Alshuqayran, N., Ali, N., & Evans, R. (2016, November). A systematic mapping study in
microservice architecture. In 2016 IEEE 9th International Conference on Service-
Oriented Computing and Applications (SOCA) (pp. 44-51). IEEE.
Avritzer, A., Ferme, V., Janes, A., Russo, B., Schulz, H., & van Hoorn, A. (2018,
September). A quantitative approach for the assessment of microservice architecture
deployment alternatives by automated performance testing. In European Conference
on Software Architecture (pp. 159-174). Springer, Cham.
Bao, K., Mauser, I., Kochanneck, S., Xu, H., & Schmeck, H. (2016, December). A
microservice architecture for the intranet of things and energy in smart buildings.
In Proceedings of the 1st International Workshop on Mashups of Things and
APIs (pp. 1-6).
Baškarada, S., Nguyen, V., & Koronios, A. (2018). Architecting microservices: practical
opportunities and challenges. Journal of Computer Information Systems, 1-9.
Cerny, T., Donahoo, M. J., & Trnka, M. (2018). Contextual understanding of microservice
architecture: current and future directions. ACM SIGAPP Applied Computing
Review, 17(4), 29-45.
Di Francesco, P. (2017, April). Architecting microservices. In 2017 IEEE International
Conference on Software Architecture Workshops (ICSAW) (pp. 224-229). IEEE.
Dragoni, N., Lanese, I., Larsen, S. T., Mazzara, M., Mustafin, R., & Safina, L. (2017, June).
Microservices: How to make your application scale. In International Andrei Ershov
Memorial Conference on Perspectives of System Informatics (pp. 95-104). Springer,
Cham.

13TRANSFORMATION FROM MONOLITHIC TO MICROSERVICES
Granchelli, G., Cardarelli, M., Di Francesco, P., Malavolta, I., Iovino, L., & Di Salle, A.
(2017, April). Towards recovering the software architecture of microservice-based
systems. In 2017 IEEE International Conference on Software Architecture Workshops
(ICSAW) (pp. 46-53). IEEE.
Haselböck, S., Weinreich, R., & Buchgeher, G. (2017, August). Decision guidance models
for microservices: service discovery and fault tolerance. In Proceedings of the Fifth
European Conference on the Engineering of Computer-Based Systems (pp. 1-10).
Herrera-Quintero, L. F., Vega-Alfonso, J. C., Banse, K. B. A., & Zambrano, E. C. (2018).
Smart its sensor for the transportation planning based on iot approaches using
serverless and microservices architecture. IEEE Intelligent Transportation Systems
Magazine, 10(2), 17-27.
Higashino, M., Kawato, T., & Kawamura, T. (2018). A Design with Mobile Agent
Architecture for Refactoring A Monolithic Service into Microservices. JCP, 13(10),
1192-1201.
Jamshidi, P., Pahl, C., Mendonça, N. C., Lewis, J., & Tilkov, C. (2018). Microservices.
Cerny, T., Donahoo, M. J., & Trnka, M. (2018). Contextual understanding of
microservice architecture: current and future directions. ACM SIGAPP Applied
Computing Review, 17(4), 29-45.
Krivic, P., Skocir, P., Kusek, M., & Jezic, G. (2017, June). Microservices as agents in IoT
systems. In KES International Symposium on Agent and Multi-Agent Systems:
Technologies and Applications (pp. 22-31). Springer, Cham.
Nadareishvili, I., Mitra, R., McLarty, M., & Amundsen, M. (2016). Microservice
architecture: aligning principles, practices, and culture. " O'Reilly Media, Inc.".

14TRANSFORMATION FROM MONOLITHIC TO MICROSERVICES
Rufino, J., Alam, M., Ferreira, J., Rehman, A., & Tsang, K. F. (2017, March). Orchestration
of containerized microservices for IIoT using Docker. In 2017 IEEE International
Conference on Industrial Technology (ICIT) (pp. 1532-1536). IEEE.
Ueda, T., Nakaike, T., & Ohara, M. (2016, September). Workload characterization for
microservices. In 2016 IEEE international symposium on workload characterization
(IISWC) (pp. 1-10). IEEE.
Villamizar, M., Garces, O., Ochoa, L., Castro, H., Salamanca, L., Verano, M., ... & Lang, M.
(2016, May). Infrastructure cost comparison of running web applications in the cloud
using AWS lambda and monolithic and microservice architectures. In 2016 16th
IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing
(CCGrid) (pp. 179-182). IEEE.
Yan, L., Cao, S., Gong, Y., Han, H., Wei, J., Zhao, Y., & Yang, S. (2019). SatEC: A 5G
satellite edge computing framework based on microservice
architecture. Sensors, 19(4), 831.
Zhao, Y., & Medvidovic, N. (2019, May). A microservice architecture for online mobile app
optimization. In 2019 IEEE/ACM 6th International Conference on Mobile Software
Engineering and Systems (MOBILESoft) (pp. 45-49). IEEE.
Zirkelbach, C., Krause, A., & Hasselbring, W. (2018, February). On the modernization of
explorviz towards a microservice architecture. CEUR Workshop Proceedings.