Microservices Architecture for Whiteboard Organisation

This report discusses the migration of Whiteboard organisation from monolithic architecture to microservices architecture for efficient management of information and systems. It includes successful implementation examples, service modelling principles, challenges in splitting backend monolithic system, and ethical, legal, and security issues. Recommendations are also provided.

Running head: MICROSERVICES ARCHITECTURE
MICROSERVICES ARCHITECTURE
Name of student
Name of university
Author’s note:

1
MICROSERVICES ARCHITECTURE
Executive summary
It could be observed in the present business world, technology plays a significant part in the
success of the businesses. In the organisation of Whiteboard, there has been a requirement of
overhauling the technology strategy as well as the management of the IT delivery teams for
ensuring that they deliver the most reliable student and the reliable learning management
system. The aim of the report is to discuss the migration of the architecture of the
organisation from the monolithic architecture to the microservices architecture for allowing
the proper handling of information and the systems could be managed efficiently. The
microservices are presently considered as the method of software development, which is the
different from the service oriented architecture, the architectural design of SOA that mainly
structures any application as the collection of the lightly coupled services.

2
MICROSERVICES ARCHITECTURE
Table of Contents
Introduction....................................................................................................................3
Discussion......................................................................................................................4
Examples of successful implementation....................................................................4
Principles of service modelling......................................................................................6
Challenges in splitting backend monolithic system.......................................................8
Ethical, legal and security issues....................................................................................8
Recommendations..........................................................................................................9
Conclusion....................................................................................................................10
References....................................................................................................................11

3
MICROSERVICES ARCHITECTURE
Introduction
In the business of present technological world, it is required to manage the businesses
with the extensive technologies. In the organisation of Whiteboard, there has been a
requirement of overhauling the technology strategy as well as the management of the IT
delivery teams for ensuring that they deliver the most reliable student and the reliable
learning management system to almost 600 universities as well as the institutions across
whole world. This report intends to discuss the migration of the company to the microservice
architecture. The examples of the successful implementation of the microservice architecture
for various organisations are provided in this report. The principles of service modelling as
well as the technologies that are available for the integration are discussed in this report. The
challenges of segmenting the backend monolithic system as well as the ethical issues of
migrating to the microservice architecture has been provided.
The microservices are presently considered as the method of software development,
which is the different from the service oriented architecture, the architectural design of SOA
that mainly structures any application as the collection of the lightly coupled services. In any
microservices architecture, the services are significantly fine segmented as well as the
protocols are extensively lightweight. The main benefits of the decomposition of any
application into the various smaller services is that the segmentation helps in improving the
modularity. With the help of this method, the understanding, developing, testing as well as
resiliency of the application is increased to the architecture erosion. It helps in parallelising
the development with enabling the small autonomous teams with developing, deploying as
well as scaling the respective services individually.

4
MICROSERVICES ARCHITECTURE
Discussion
Examples of successful implementation
The microservices architecture is described as the method of breaking the large
projects of software into the smaller, independent, as well as the loosely coupled modules.
The specific modules are mainly accountable for the highly discrete and defined tasks and
then execute the communication with other modules with the easily, universally available
APIs (Balalaie, Heydarnoori & Jamshidi, 2016). Several companies are implementing this
technology and are segmenting the complete system from the monolithic structure to the
microservices architecture. Some of the examples of successful implementation of the
microservices architecture in the organisations are:
The successful revitalisation of the failing architecture with the help of microservices
by Walmart: This migration is considered as the most common example for executing the
processes that are required when any aging architecture starts to affect the business
negatively (Jaramillo, Nguyen & Smart, 2016). The main problem in the organisation was
that it could not handle over 6 million pageviews that are gained every minute and then
created it significantly difficult in keeping any type of any positive user experience. Prior
embracing the microservices in the organisation, Walmart possessed the architecture for
internet of the year 2005, that was designed around the desktops, the monoliths and the
laptops. The company then took the decision of replatforming the old legacy system in the
year 2012 as the company was not able to the scale for the huge number of pageviews and
was almost down for the majority of the days during the period of the peak events. For
eradicating the issue of pageviews, the company executed replatforming to the microservices
with the purpose of accomplishing almost 100% availability along with the realistic costs.
The migration to the microservices introduced the following benefits:

5
MICROSERVICES ARCHITECTURE
 No downtime on the Boxing day or the Black Friday
 Conversions significantly increased upto 20% overnight
 40% of the computing power was saved and the savings on the cost was
experienced of 20-60%
The second example of successful implementation of the microservices is the case
study of Spotify who built outstanding user experience along with the microservices. As the
organisation serves almost 75 million active users each month, with the average length of
session of almost 24 minutes, while executing incredibly sophisticated business roles. Due to
this particular issue, the company came to conclusion that if there is as issue of scaling to
millions of users, there is a requirement of the building the system in proper manner that
provides the opportunity of scaling the components independently. This led to the creation of
the building the microservice architecture by the autonomous team of full stack given in
charge for avoiding any synchronisation error in the organisation. The main benefit that is
gained by the organisation is that it allowed the company with having significantly large
amount of the services stopping at the similar time without any of the users even detecting
this.
The third example of successful implementation of the microservices architecture is
the Amazon organisation embracing the philosophy of DevOps with the help of
microservices. The amazon company also successfully migrated to the microservices. Around
2001, retail website of Amazon.com was the large architectural monolith. It had been
architecture in several tiers, as well as those tiers had several components included in them,
but were efficiently coupled together strictly and this made the system to behave like big
monolith. The company comprised of significantly large amount of developers who were
working on the big monolithic website, and although each of the developers worked on the
small segment of the application, it was required to deal with overhead of the coordinating

6
MICROSERVICES ARCHITECTURE
the changes with all other individual who were working on the similar project. When the
addition of the new characteristics or fixing the bugfix was being done in the organisation, it
was required to ensure that nothing else was broken in this project. If in any situation, it was
required to update the shared library for taking advantage of this implemented new feature, it
was required to convince the other individuals included in the project to perform the
upgrading to this new shared library at the similar time. In early stages of the year 2000, the
company even possessed the engineering group who were solely tasked with taking the new
versions of this application and then manually push it across the production environment of
the company.
Principles of service modelling
SOAP: The SOAP or the Simple Object Access Protocol could be described as the
message protocol, which permits the communication among the various distributed elements
of any application. The SOAP could be executed over variety of the lower level protocols that
includes the web associated hypertext transfer protocol (Aderaldo et al., 2017). The SOAP
primarily defines the header structure, which identifies the main actions that are required to
take message by the SOAP, additionally with the payload structure for executing the
information. The main concept of the routing of any message with the help of string of the
nodes, which performs various function is the method by which the SOAP provides the
required support to the things like the addressing, format independence and the security
(Rahman & Gao, 2015). Necessarily, the roles are identified by the headers that in turn offers
the SOA characteristics that is routed to by the SOAP. The stringing of the messages with
following the sequence of the steps in majorly uncommon in the microservice centric
development environments in present business conditions (Sun, Li & Memon, 2017).

7
MICROSERVICES ARCHITECTURE
XML – RPC: XML – RPC could be described as the protocol that is mainly based on
the XML. It is the simple protocol that is used for exchanging the information among the
computer system all across the complete network (Alshuqayran, Ali & Evans, 2016). It could
be described as the remote procedure call as well as it uses the XML for encoding the calls.
HTTP is used by the XML – RPC for the transportation. It permits the complicated data
structures that are required to be processed and then transmitted. XML – RPC would help
while integrating the multiple computing environments deprived of requirement of sharing
any of the sophisticated data structures directly. The communication among the computers
over the network could be easily established easily and fast with assistance of the XML –
RPC. It could be effectively utilised in the associated with the Java, PERL, PHP and Python
and several programming languages and it would allow the java with communicating with the
PERL, Python, as well as ASP. The message of XML – RPC is mainly the request of HTTP –
POST (Bakshi, 2017). There are several responses and requests. The body of the request
would be in the XML. Any procedure is executed on the server. It would efficiently return
any value and this particular value would be in XML format.
REST: The REST or the Representational State Transfer could be described as the
architectural style for offering the standards among the computer system on web and making
it significantly easier for the systems for communicating along with each other. The REST –
compliant system frequently referred as the RESTFUL system has been characterised by the
methods by which these are significantly stateless and also separate the main concerns of the
server and the client (Guo et al., 2016). In any REST architectural design, the deployment of
the server as well as the deployment of the client could be executed independently deprived
of knowing regarding one another. It denotes that code that is present on the client side could
be easily changed at any time required deprived of affecting the main operations of server as

8
MICROSERVICES ARCHITECTURE
well as the code on server side could be easily altered deprived of affecting the operation on
the client (Viennot et al., 2015).
Challenges in splitting backend monolithic system
Some of the major technical issues that requires the efficient solving prior it is likely
to the use the microservice architecture. The main issue in this situations is the separation of
the services. When starting point is the monolithic application, organisation could then
probably be significantly acquainted with domain already as well as have the proper
knowledge regarding the locations where the seams of the application could be discovered
(Salah et al., 2016). It could intake significant time as well as effort for refactoring the
services out from the monolithic architecture. When the splitting of the services is being
done, extensive attention is required to be devoted to fact that the services does not grow to
be increasingly fine - segmented. The microservices could deploy the overhead of
performance specifically if communication has been executed over any network (Wolff,
2016). If communication is being done with the utilisation of the REST over the HTTP,
separate inter-service call adds the overhead from the latency of the network as well as from
the marshalling along with the unmarshalling of the data.
The main issue that is faced is the integration among the various microservices. It is
suggested to not tie the collaboration among the services to any particular technology as the
teams may wish to utilise the various programming languages while deploying the services
(Balalaie, Heydarnoori & Jamshidi, 2015).
Ethical, legal and security issues
The segregation of the architecture of the organisation from monolithic to the
microservices architecture creates the fail safes that pre-emptively helps in stopping the
security issues within any particular services prior the spreading to other areas is done in the

9
MICROSERVICES ARCHITECTURE
system (Selimi et al., 2017). The management of the distinct services might seem to be
increasingly complicated but there are several tools accessible for making it significantly
easier to manage the multiple sophisticated pipelines as well as the deployments as the
organisation performs the scaling up to the microservice architecture. From the perspective of
the engineering, it could be observed that the utilisation of the microservices architecture
makes it significantly easier for the various parts of any system to be efficiently developed.
With the splitting of any application up into distinct services, the various engineers could
oversee the main development of all the parts separately and it makes it significantly easier to
the update as well as manage (Pahl & Jamshidi, 2016). Some of the ethical issues included in
the microservices architecture are the proper maintaining of the data of the customers during
the migration and to ensure that this data is not misplaced or misused by any individual.
Legal issues includes the proper maintenance of the system of the organisation after the
segmentation and the data is properly migrated in the system of the organisation.
Recommendations
It is recommended to the Whiteboard organisation that this implementation of the
microservices architecture within the organisation could be beneficial if the implementation
is done by considering and analysing all the negative aspects of the microservices. The
microservices could allow the development of the products rather than the projects. Indeed
the microservice architecture provide the teams in focussing on the development of the
business functionality rather than the writing any glue code (O'Connor, Elger & Clarke,
2017). Microservices provides the main developers significantly more independence for
working autonomously as well as make the technical decisions at quick pace in the smaller
groups. The microservices could be significantly beneficial for the tackling the issues of
productivity as well as the speed by the decomposition of the applications into the
manageable services that are significantly faster to create. The microservice provides the

10
MICROSERVICES ARCHITECTURE
unique type of modularisation, they make the big solutions significantly easier, and help in
increasing the productivity, provide significant flexibility in the selection of technologies and
this architecture is beneficial for the developers.
Conclusion
Therefore, it could be concluded that the organisation Whiteboard could gain
significantly from the implementation of the microservices in the organisation by replacing
the monolithic architecture. The microservices architecture is described as the method of
breaking the large projects of software into the smaller, independent, as well as the loosely
coupled modules. The individual modules are mainly accountable for the highly discrete and
defined tasks and then communicate with any other modules with the simple, universally
available APIs. The SOAP or the Simple Object Access Protocol could be described as the
message protocol, which permits the communication among the various distributed elements
of any application. The SOAP could be executed over variety of the lower level protocols that
includes the web associated hypertext transfer protocol. XML – RPC could be described as
the protocol that is mainly based on the XML. It is the simple protocol that is used for
exchanging the information among the computer system all across the complete network.

11
MICROSERVICES ARCHITECTURE
References
Balalaie, A., Heydarnoori, A., & Jamshidi, P. (2016). Microservices architecture enables
devops: Migration to a cloud-native architecture. Ieee Software, 33(3), 42-52.
Aderaldo, C. M., Mendonça, N. C., Pahl, C., & Jamshidi, P. (2017, May). Benchmark
requirements for microservices architecture research. In Proceedings of the 1st
International Workshop on Establishing the Community-Wide Infrastructure for
Architecture-Based Software Engineering (pp. 8-13). IEEE Press.
Sun, L., Li, Y., & Memon, R. A. (2017). An open IoT framework based on microservices
architecture. China Communications, 14(2), 154-162.
Viennot, N., Lécuyer, M., Bell, J., Geambasu, R., & Nieh, J. (2015, April). Synapse: a
microservices architecture for heterogeneous-database web applications.
In Proceedings of the Tenth European Conference on Computer Systems (p. 21).
ACM.
Salah, T., Zemerly, M. J., Yeun, C. Y., Al-Qutayri, M., & Al-Hammadi, Y. (2016,
December). The evolution of distributed systems towards microservices architecture.
In 2016 11th International Conference for Internet Technology and Secured
Transactions (ICITST) (pp. 318-325). IEEE.
Wolff, E. (2016). Microservices: flexible software architecture. Addison-Wesley
Professional.
Selimi, M., Cerdà-Alabern, L., Sánchez-Artigas, M., Freitag, F., & Veiga, L. (2017, May).
Practical service placement approach for microservices architecture. In 2017 17th
IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing
(CCGRID) (pp. 401-410). IEEE.

12
MICROSERVICES ARCHITECTURE
O'Connor, R. V., Elger, P., & Clarke, P. M. (2017). Continuous software engineering—A
microservices architecture perspective. Journal of Software: Evolution and
Process, 29(11), e1866.
Rahman, M., & Gao, J. (2015, March). A reusable automated acceptance testing architecture
for microservices in behavior-driven development. In 2015 IEEE Symposium on
Service-Oriented System Engineering (pp. 321-325). IEEE.
Balalaie, A., Heydarnoori, A., & Jamshidi, P. (2015, September). Migrating to cloud-native
architectures using microservices: an experience report. In European Conference on
Service-Oriented and Cloud Computing (pp. 201-215). Springer, Cham.
Jaramillo, D., Nguyen, D. V., & Smart, R. (2016, March). Leveraging microservices
architecture by using Docker technology. In SoutheastCon 2016 (pp. 1-5). IEEE.
Guo, D., Wang, W., Zeng, G., & Wei, Z. (2016, March). Microservices architecture based
cloudware deployment platform for service computing. In 2016 IEEE Symposium on
Service-Oriented System Engineering (SOSE) (pp. 358-363). IEEE.
Pahl, C., & Jamshidi, P. (2016, April). Microservices: A Systematic Mapping Study.
In CLOSER (1) (pp. 137-146).
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.
Bakshi, K. (2017, March). Microservices-based software architecture and approaches.
In 2017 IEEE Aerospace Conference (pp. 1-8). IEEE.

13
MICROSERVICES ARCHITECTURE