Whiteboard's Microservices Architecture: MIS603 Report Analysis

This report provides a comprehensive analysis of microservices architecture, focusing on its application for Whiteboard, a company providing learning management systems. It begins by defining and introducing microservice architecture, highlighting its benefits over monolithic systems. The report then explores successful deployments at companies like Netflix, Amazon, and Apple, illustrating real-world applications and advantages. It delves into service modeling principles, comparing technologies such as SOAP, XML-RPC, and REST. Furthermore, the study investigates the challenges of splitting monolithic backend systems, addressing issues of complexity, inter-service communication, and scalability. Finally, the report examines the ethical, legal, and security problems that may arise during the transition to microservices architecture, providing a balanced perspective on the technology's potential and pitfalls.

Running head: MICROSERVICES ARCHITECTURE
Microservices Architecture
Name of the student:
Name of the university:
Author Note

1MICROSERVICES ARCHITECTURE
Executive summary
The report investigates the definition along with the introduction of the technology microservice
architectures for the case of Whiteboard, a leading company providing students and management
systems of learning. Apart from that, the examples of successful deployment of the innovation are
demonstrated here. Furthermore, the norms of service modeling and accessible tools to incorporate
like XML-RPC, REST, and SOAP are analyzed in this study. Additionally, the difficulties to
fragment the monolithic system at the backend in place of the noteworthy activities of Whiteboard’s
system are studied. Finally, the safety, permissible and moral complications to shift towards the
microservice architecture are assessed in this report.

2MICROSERVICES ARCHITECTURE
Table of Contents
Introduction:..........................................................................................................................................2
Defining and introducing microservice architecture:............................................................................2
Discussion on successful deployment of microservice architecture at various companies:..................4
Discussion on various principle related to service technologies and modelling:..................................6
SOAP:................................................................................................................................................6
XML-RPC:........................................................................................................................................6
REST:................................................................................................................................................7
Problems in splitting backend monolithic system:................................................................................7
Ethical, legal and security problems while transitioning to the microservice architecture:.................8
Conclusion:............................................................................................................................................8
References:..........................................................................................................................................10

3MICROSERVICES ARCHITECTURE
Introduction:
Whiteboard’s chief technology officer has decided to overhaul the strategy of technology and
managing the IT delivery teams. This is to assure that they deliver the dependable students and
management systems of learning of more than 600 universities and various institutions around the
globe. The following report demonstrates the definition along with an introduction to the
microservice architectures. The instance of the successful deployment of innovation is further
discussed in this study. Then, the principle of service modeling and available technologies to
integrate like REST, XML-RPC and SOAP and so on are evaluated. Further, the problems to split
the monolithic system at the backend representing the notable behavior of Whiteboard’s system are
investigated. Lastly, the security, legal and ethical problems to transition towards the microservice
architecture are evaluated.
Defining and introducing microservice architecture:
The microservice architecture also simply known as microservice, is a kind of distinctive
model. This is to develop the software systems trying to concentrate on developing the modules of
single-function having effective operations and interfaces. This trend has been growing popular in
recent days as the various enterprises have been trying more Agile and moving towards continuous
testing and DevOps. This has various advantages for the DevOps and Agile teams like PayPal
Twitter, Amazon, eBay and Netflix and various other tech businesses have come out from the
monolithic innovation toward the microservice architecture (Alshuqayran, Ali & Evans, 2016). This,
unlike the microservices, the monolithic application has been creating an autonomous and single
unit. It has been making changes to the application to become slow as that has been affecting the
total system. The changes done to the small area within the code are needed to deploy and build the

4MICROSERVICES ARCHITECTURE
latest version of that software (Rademacher, Sorgalla & Sachweh, 2018). Again, the scaling of
particular functions of any application indicates that one needs to scale the total application. This is
able to resolve the issues of the monolithic systems through becoming modular. As the simplest
format is considered, it is helpful to create an application as the suite of smaller services where
everything has been running in individual measures and been deployable independently. The
services have been written down in various programming languages. This can also might utilize
distinct data storage styles. As this results in developing systems that have been flexible and
scalable. This requires a dynamic makeover (Hasselbring & Steinacker, 2017). They are commonly
linked through the APIs and is able to leverage the various similar type of tools along with solutions
developed in RESTful and ecosystem of web service. The testing of the APIs helps validate the data
flow and data across the microservice implementation. Thus, in short, the style can be considered as
the approach in developing one application as the suite of small services. Everything has been
running under its individual process and has been communicating with the mechanisms of
lightweight (Shao, Zhang & Cao, 2018). Apart from that, the services have been developed across
the capabilities and business and cold be deployable independently to be automated machinery of
deployments. Moreover, there has been the bare minimum of the core management of the service
that could be written in various programming languages along with using distinct technologies of
data storage.
Discussion on the successful deployment of microservice architecture at various
companies:
For instance, the case of Netflix can be considered. They have been the use of open-source
software named NGINX for a long time. They have turned out to be the first customer of the
organization named NGINX, Inc as they included that during 2011. This is a fact that Netflix has

5MICROSERVICES ARCHITECTURE
chosen NGINX to be the core of the delivery structure (Leitner, Cito & Stöckli, 2016). Here, Open
Connect has been one of the biggest CDNs or content delivery networks in this world. Having the
ability to serve thousands and also millions of requests every second, NGINX and NGINX Plus are
the optimal solutions for the HTTP delivery of high-performance and enabling organizations such as
Netflix to provide the digital experience of high-quality to million number of customers daily (Kang,
Le & Tao, 2016). However, it must be reminded that complexity from the innovation has just moved
outside and the issues in data exchange need the balance between microservice and ownership sizes.
As per the concern, the same grouping type of microservice to functional groups can reduce changes
to additional microservice groups. The availability, channel recognition, versioning, dependency
resolution, routing, security certificates, messaging, services, orchestration and monitoring have
been found to be assisted through that gateway (Zhou et al., 2018). Further, the web sites of large
scales having a wide range of audiences for minimizing the size of the component and footprint of
the memory. Thus utilizing microservice has turned to be important to demand the operations.
Nonetheless, like another architecture, this has been properly used. It is never exclusive and
streaming the contents. The large sets of results could be handled through the microservice rendering
the web page is based on residual and the static content and the APIs that have been served by that
single gateway (Di Francesco, Lago & Malavolta, 2018).
Again, the case of Amazon could be considered as they have been over the monolithic server
that has been complicated to predict the way how they could meet the demands of fluctuating traffic.
Due to that, they have been bleeding the money. Maximum of the capacity of the server has been
wasted as the downtimes were going (Rademacher, Sachweh & Zündorf, 2017). Hence, moving to
the AWS or Amazon Web services and a maximum of the capacity of the server has been wasted as
the downtimes were going and the cloud allowed them to scale down or up as needed. This also
includes the reduction or duration and number of outages and then saving the money. Again, this has

6MICROSERVICES ARCHITECTURE
permitted them to make a transition towards constant deployment and at present, their engineers
have been deploying the code every 11.7 seconds (Cerny, Donahoo & Trnka, 2018). The
microservice has been highly dependent on messaging as they could witness specific issues. The
communication has been hard despite utilizing the advanced and automation methods like Agile.
They have required to introduce various DevOps tools like the CI/CD servers, platforms of
configuration management and the AM tools. This is to manage the overall network. It has been
great for the business ho have there to use the methods. Nonetheless, adopting additional
requirements have been problematic for them (Granchelli et al., 2017). Further, they have required to
maintain the network leading to additional types of problems also. The thing that they have gained
on the simplicity of the microservice of the single-responsibility, losing the complicacy of their
network. Otherwise, this should have been part of that. Here, for example, as an independent type of
microservices has been better in tolerating faults than the monolithic, the network has been worse
(Granchelli et al., 2017).
Thirdly, the case of Apple can be considered. The relation of Apple with the microservice
could be shown in various ways. They have developed Swift to generate both Mac OSX and iOS
applications (Mayer & Weinreich, 2017). Here, the swift code could be utilized for generating the
framework giving developers a broad range of scopes. This has been possible to generate the light-
weight containers in the Swift that are an integral part of the constant implementation. Further, the
communication between the microservers has indicated the fact that it is poor in performance. This is
because sending messages back and forth has been coming with specific overhead. Thus, the teams
are able to choose their programming platform and the language they need to be using. Here, also
require to make the collaborations better. Besides, above all, they require to control the overall
lifecycle of that microservice from beginning to that end.

7MICROSERVICES ARCHITECTURE
Discussion on various principle related to service technologies and modeling:
SOAP:
It is an XML based message protocol. This has been using WSDL for their communication
between the provider and consumer. Further, this invokes the services through calling the method of
RPC. As the transfer gets over HTTP, it uses the other type of protocols like FTP and SMTP. Here,
SOAP based reads could never be cached. This is never much scalable and more suitable for those
enterprise systems and the high range of security systems like the banking ones., However, this
never supports the poor handling and utilizing service interfaces for exposing the logic of business
(Boucher et al., 2018).
XML-RPC:
Here, the client performs the RPC through sending the HTTP request to the server
implementing the XML-RPC. It has been receiving the response of HTTP. Here a call is able to have
numerous parameters and a single outcome. It defines some of the data types for the results and the
parameters (Mendonça et al., 2019). Few of the data types have been complex and have been nested.
Here, for instance, one is able to have the parameters, which is an array of 5 integer numbers. Here,
the parameters or the structure of the result and set of the data types has been meant to mirror those
used in the case of common programming languages (Samanta & Tang, 2020). Further, the
identification of the clients for the purpose of authorization could be gained through leading HTTP
security processes. Further, the basic access authentication could be utilized for authentication and
identification. Apart from that, the protocol is unable to permit the HTTPs. This is the obvious and
common variation for using HTTPS in the area of HTTP.

8MICROSERVICES ARCHITECTURE
REST:
It is used best through the systems that never need the extra data apart from the rise in speed
with the eschewing XML. This has also included the strong functionality of the system. It scales
highly and quickly and has been much more extensible under the dynamic system that that of SOAP.
As seen at that framework of the web application, it has the natural candidate because of the reality
that it is able to inherit high deals of activities from the stack of HTTP (Lu et al., 2017). Moreover,
because of the fact that it has been less restrictive as compared to SOAP, it has been seen to be
supporting a great amount of future and experimental functionalities.
Problems in splitting the monolithic backend system:
One is the greatest drawback is a notable rise in the complexity of the application. Besides,
technical debt also rises notably and various types of intentional efforts are made to assure that every
resource of the team knows smaller services empowering the application (Khanda et al., 2017).
Secondly, there is the inter-service communication and the persistent of information around the
services. Here, the communications around the services are complex as the datasets get separated.
Further, there are issues with health monitoring and then the debugging turns out to be difficult to be
scaled. Lastly, there is total buy-in from everything involved (Lu et al., 2017). Here, all the
stakeholders and the development should be buying in. Here for the client to the team members,
Whiteboard should assure that every people involved might believe the microservices to be the
proper method of proceeding.

9MICROSERVICES ARCHITECTURE
Ethical, legal and security problems while transitioning to the microservice
architecture:
There might be security challenges for the developers as they cannot ensure that the rest of
the team is knowledgeable about the setup. Again there are risks with slow performances. As every
microservice is able to consume resources, the burden on the servers is higher than monolithic
applications. Again, there are problems with consistencies. Since it requires multiple amounts of
resources to be updated, the developers require to assure that the components have been
synchronized for avoiding the unexpected type of bugs (Khanda et al., 2017). Next, there are greater
costs for maintenances. The legal issues consist of problems with the standardizations. For
effectively controlling the overall infrastructure, the strategies of standardization require to be
deployed. Having numerous teams to be working on various applications and the components, plans
for the needs of standardizations have been carefully designed. Again, a wide range of skills is
required (Mendonça et al., 2019). For successfully controlling those applications, one requires to be
familiar with numerous programming frameworks, languages and APIS.
Conclusion:
Whiteboard is a leading provider of learning and student management systems that supports
more than a hundred million students throughout the world. Its agility and flexibility are vital for
them such that they can include the latest core and technologies facilitating learning and tracing.
This should be as frequently as they could and then measure the efficiency of that. Their frequent
and constant delivery is at the heart of their IT strategy. This has been offering high competitive
edges to Whiteboard that its competitors. The implementation of the microservice architectures
brings various issues. They could be overcome through suitable strategies. Through understanding
where and when to look for the solutions are useful to take benefits that the innovation has got with

10MICROSERVICES ARCHITECTURE
it to offer. As one is utilizing SOAP, it must write a long letter and next place that to the envelope
and then print that address, return that address and net the attaching postages. As one wraps the
message such that the main system is able to evaluate where, how and who must be delivering that.
On the other hand, the REST has been similar to a pre-paid postcard. One could be forgone the
envelope that was in favor of the highlight. This was the device of succinate delivery easy to handle
and interpret with a message scribbled fast on the back. This postcard has been using less material or
bandwidth and has been shorter typically in the content and has been actually getting the neighbor
quick as there is less amount of bulk for moving across.

11MICROSERVICES ARCHITECTURE
References:
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.
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.
Boucher, S., Kalia, A., Andersen, D. G., & Kaminsky, M. (2018). Putting the" Micro" back in
microservice. In 2018 {USENIX} Annual Technical Conference ({USENIX}{ATC} 18) (pp.
645-650).
Samanta, A., & Tang, J. (2020). Dyme: Dynamic Microservice Scheduling in Edge Computing
Enabled IoT. IEEE Internet of Things Journal.
Khanda, K., Salikhov, D., Gusmanov, K., Mazzara, M., & Mavridis, N. (2017, March).
Microservice-based iot for smart buildings. In 2017 31st International Conference on
Advanced Information Networking and Applications Workshops (WAINA) (pp. 302-308).
IEEE.
Mendonça, N. C., Jamshidi, P., Garlan, D., & Pahl, C. (2019). Developing Self-Adaptive
Microservice Systems: Challenges and Directions. IEEE Software.
Granchelli, G., Cardarelli, M., Di Francesco, P., Malavolta, I., Iovino, L., & Di Salle, A. (2017,
April). Microart: A software architecture recovery tool for maintaining microservice-based

12MICROSERVICES ARCHITECTURE
systems. In 2017 IEEE International Conference on Software Architecture Workshops
(ICSAW) (pp. 298-302). IEEE.
Zhou, X., Peng, X., Xie, T., Sun, J., Xu, C., Ji, C., & Zhao, W. (2018, May). Poster: Benchmarking
microservice systems for software engineering research. In 2018 IEEE/ACM 40th
International Conference on Software Engineering: Companion (ICSE-Companion) (pp.
323-324). IEEE.
Rademacher, F., Sorgalla, J., & Sachweh, S. (2018). Challenges of domain-driven microservice
design: a model-driven perspective. IEEE Software, 35(3), 36-43.
Kang, H., Le, M., & Tao, S. (2016, April). Container and microservice driven design for cloud
infrastructure devops. In 2016 IEEE International Conference on Cloud Engineering (IC2E)
(pp. 202-211). IEEE.
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.
Leitner, P., Cito, J., & Stöckli, E. (2016, December). Modelling and managing deployment costs of
microservice-based cloud applications. In Proceedings of the 9th International Conference
on Utility and Cloud Computing (pp. 165-174).
Hasselbring, W., & Steinacker, G. (2017, April). Microservice architectures for scalability, agility
and reliability in e-commerce. In 2017 IEEE International Conference on Software
Architecture Workshops (ICSAW) (pp. 243-246). IEEE.

13MICROSERVICES ARCHITECTURE
Lu, D., Huang, D., Walenstein, A., & Medhi, D. (2017, April). A secure microservice framework for
iot. In 2017 IEEE Symposium on Service-Oriented System Engineering (SOSE) (pp. 9-18).
IEEE.
Mayer, B., & Weinreich, R. (2017, April). A dashboard for microservice monitoring and
management. In 2017 IEEE International Conference on Software Architecture Workshops
(ICSAW) (pp. 66-69). IEEE.
Rademacher, F., Sachweh, S., & Zündorf, A. (2017, April). Differences between model-driven
development of service-oriented and microservice architecture. In 2017 IEEE International
Conference on Software Architecture Workshops (ICSAW) (pp. 38-45). IEEE.
Di Francesco, P., Lago, P., & Malavolta, I. (2018, April). Migrating towards microservice
architectures: an industrial survey. In 2018 IEEE international conference on software
architecture (ICSA) (pp. 29-2909). IEEE.
Shao, J., Zhang, X., & Cao, Z. (2018, October). Research on Context-based Instances Selection of
Microservice. In Proceedings of the 2nd International Conference on Computer Science and
Application Engineering (pp. 1-5).

14MICROSERVICES ARCHITECTURE