Architecture Systems – Case of Whiteboard Company

Transiting From Monolithic to Microservices

EXECUTIVE SUMMARY

Whiteboard is a well-known company offering reliable student and learning management systems (LMS) to several universities and educational institutes supporting over 10 million students across the world. As the company is utilizing the monolithic system of IT for enabling its LMS software, it has been facing several obstacles due to which the CTO (Chief Technology Officer) has decided to make a shift towards micro-service based model. The organizations that have shifted from monolithic structure to microservice architecture include, but are not limited to Amazon, Netflix and Uber. All of these companies have shifted from monolithic to microservices by overcoming challenges like building of in-house team for development, integration of testing the application, decoupling each tier, increased cost, company’s expenses, bug fixing and cultural challenges. Several benefits like improving the loading capacity, liveness processing, debuggability, processing delays, visibility, processing delays, productivity, speed of operations, shadow traffic routing, automatic rollout of code and configuration safe and management of requests for rides by passengers were enjoyed by these companies as discussed. Whiteboard is recommended to use REST and SOAP as these will fit easily in the current system. In order to move from monolithic structure to microservices, Whiteboard will face several challenges including difficultly in identifying the components of services and how these can be transited. Ethical and legal challenges could also act as bottlenecks including data security, privacy, log duplication and hacking threats. Several recommendations are made for Whiteboard for transiting successfully from monolithic to microservices architecture.

Introduction

Whiteboard is a well-known company offering reliable student and learning management systems (LMS) to several universities and educational institutes supporting over 10 million students across the world. Whiteboard’s LMS aids the institutions in managing the chores throughout the lifecycle of students starting from their enrolment to tuition fee payments, academic record maintenance and issuance of certificates. As the company is utilizing the monolithic system of IT for enabling its LMS software, it has been facing several obstacles due to which the CTO (Chief Technology Officer) has decided to make a shift towards micro-service based model. In order to do so, this report has been structured so that CTO can be advised on how to achieve the objective of producing codes that operate in isolation instead of being dependent on the other components across the system. The report has the following sections:

Section 1: In this section, the micro-services architecture will be defined and will be compared to the monolithic system as followed by Whiteboard currently.

Section 2: In this section, the renowned companies that utilize micro-service architecture based IT will be outlined along with the advantages they reap, the challenges they face and the lessons they’ve learnt.

Section3: In this section, the relevant principles of service modeling and technologies will be outlined like Rest-API.

Section 4: This section will discuss the challenges that Whiteboard could face during transiting from monolithic system towards micro-service architecture.

Section 5: In the last section, several legal, ethical and security issues associated with micro-service architecture transitioning process will be discussed. In the end, conclusion and recommendations are made to follow a smooth transition towards micro-service architecture from monolithic model.

Defining Micro-service Architecture

Micro-service architecture (microservices) is a method of software development that focuses on the building of single-function modules with precisely defined operations, codes and interfaces (Krylovskiy, Jahn, & Patti, 2015). The system allows the companies to design a software application encompassing independently deployed services that are highly maintainable and testable. In short, it is an approach that allows the companies to develop and follow a single application composed of suites of small services that run on its own process and communicate through lightweight mechanisms like API (Namiot & Sneps-Sneppe, 2014). Every component of micro-service architecture works in isolation as opposed to the monolithic application where all the components are interdependent and work as a single process (see figure 1 below for differentiation).

Figure 1: Monolithic Architecture vs. Microservice Architecture

Source: Mazur (2020)

Since the monolith applications bind all the components together as a single unit, any changes required for a small part of a unit requires the whole monolith to be rebuilt and deployed. Due to this, increasingly, the IT professionals are finding it hard to keep a good modular structure based on monolith system (Dragoni, 2017). Thus, these challenges have led several companies to move from monolith architecture to microservice architectural style where each service is allowed to be written in different programming languages that can also be management by different teams (Bucchiarone, 2018). The figure above illustrates how monolithic architecture binds user interface, data access layer and business logic together and how each of these components maintains a single database. Whereas, microservice architecture allows each service to manage its own database that can have either different instances of the same database or can have entirely different databases systems (Polygot Persistence). Nonetheless, it is due to the popularity of the microservices architecture system that many companies like The Guardian, Netflix, Amazon, Realstate.com.au, UK Government Digital Service and Forward are moving to microservices from monolithic architecture system (Al-Debagy & Martinek, 2018).

The figure 2 below shows the main characteristics/features of microservice architecture.

Figure 2: Characteristics of Microservice Architecture

Source: Dragoni et al. (2017)

Example of Successful Implementation of Microservice Architecture

The organizations that have shifted from monolithic structure to microservice architecture include, but are not limited to, the following:

Amazon

Amazon is one of the Fortune 500 e-commerce company based in Seattle, Washington with its distinction as one of the first large companies to sell goods over the internet. With being founded in 1994 by Jeff Bezos, the Amazon.com retail website was structure as a large architectural monolith (Jung, 2016). However, the global e-commerce giant achieved its success in the times where the best way of developing IT systems was considered to be monolith architecture.

Although the company’s architecture wasn’t one great monolith, but all of its services and the components were tightly knitted together. Due to all codes being tightly locked, they used to get stuck in the deployment pipeline weeks before the customers could utilize them. In order to shorten and simplify the pipelines, Amazon made a shift towards microservice architecture by breaking down the components into single applications so that the developers could identify the bottlenecks and rebuild a service-oriented architecture (Perera & Perera, 2018). As a result, Amazon emerged to be one of the largest online players in modern architecture (see figure 3 below for structure of microservices at Amazon).

Figure 3: Powerful Microservices Architecture of Amazon

Source: Jung (2016)Benefits of Microservices Architecture

By moving towards microservice architecture, the developers at Amazon solved the issue of data overloading. The new system allowed data migration from one to other parts in a secure way thereby reducing the overloading of data (Jung, 2016). Through this, the productivity and speed of operations at Amazon enhanced drastically. It also allowed the company to enhance automation amongst its cross-functional teams  (Jung, 2016).

Challenges of Microservices Architecture

During transition, the company faced challenges like limited communication due to high level of standardization and dependable sources  (Jung, 2016). Besides, it also escalated the cost of operation as more training amongst the employees for using microservice architecture was required. It also faced issues during deployment including building of in-house team for development, integration of testing the application, decoupling each tier and bug fixing  (Jung, 2016).

Netflix

Netflix is the renowned American media-services provider founded in 1997 by Reed Hastings and Marc Randolph as a company that was based on a monolithic DVD-rental application structure. Till 2009, it had the traditional monolithic application produced by 100 engineers. With passing time, the company found it difficult to provide quality entertainment in a matter of second to around 98 million subscribers in 190 countries with more than 10 billion hours of video streaming per day (NGINIX, 2015). The developers quickly assessed the possibility of moving towards microservice architecture for controlling each part of its services i.e. saving customers’ watch history, deducting monthly fee, preferred video file for the device or showing the “you may like” list of movies to its subscribers (Lobo, 2018). Netflix considered the transition in steps i.e. at first they moved movie encoding and non-customer facing application. Then they moved customer facing elements like account sign ups, device selection and movie selection. Now, the company uses around 700 microservices to control each part of entire Netflix service (see figure 4 below for its simplified and actual microservice structure) (Fulton, 2018).

Figure 4: Microservices Architecture at Netflix

Source: Fulton (2018)

 Benefits of Microservices Architecture

The microservice architecture of Netflix allowed it to improve the loading capacity, liveness processing, debuggability, processing delays, visibility and the processing delays. Previously, the Netflix datacenters were bulky and slow to adapt changes, with move towards microservices, it was able to build data centers quickly enough to meet its subscribers demands (Piela, 2016). The new structure also allowed it to expand its services to over 130 new countries in 2016.

Challenges of Microservices Architecture

While moving towards microservices, the company faced challenges including development of highly skilled programmers, implementation of necessary framework for learning new code language before integration and increased cost and company’s expenses. While hiring DevOps experts, the company also incurred losses (Fulton, 2018). The escalating costs were also due to training staff for learning new coding language and cost of additional servers and database licenses. Overall, the cost was a big challenge for Netflix to overcome during integration process.

Uber

Uber is an American multinational ride-hailing company that offers food delivery, ridesharing and a ride service hailing company founded in 2009 by Garrett Camp and Travis Kalanick. Like other startups, Uber began its services using monolithic architecture for a single city. Due to less complexity, the monolithic structure at that time seemed perfect, but with worldwide expansion, Uber faced issues related to scalability and continuous integration (Kappagantula, 2018). All features including passenger management, notification features, trip management, driver management and payments were incorporated as single framework. The single system made it difficult for developers to re-build, deploy and re-test a single feature whenever required. Moreover, whenever the need for new features was identified, the developers had to change the code again and again making it difficult to handle the whole structure together (Reinhold, 2016).

As a solution, the developers decided to shift to 1300 microservices in order to follow Amazon, Twitter and Netflix  (Reinhold, 2016). The structure below shows the difference between old and new architecture of Uber and depicts how it is managing API gateway through which all drivers and passengers remain connected (see figure 5 for change from monolithic to microservices) All the units are now shown to be individual and can be deployed separately using separate functionalities (Kappagantula, 2018).

Figure 5: From Monolithic to Microservices Architecture by Uber

Source: (Kappagantula, 2018)

Benefits of Microservices Architecture

The microservices at Uber allowed it to carry on variety of functions including improved integration testing framework, replaying traffic, hermetic replay of live traffic, capacity planning, recording traffic, shadow traffic routing, automatic rollout of code and configuration safe and management of requests for rides by passengers (Kappagantula, 2018). It also gave Uber the ability to update the individual services, achieve reliable fault tolerance, facilitate fast scaling of service and boost the speed, quality and manageability of new development.

Challenges of Microservices Architecture

While making the shift, the company had to follow clear standardization strategy to eliminate the danger of spiraling out of control (Gud, 2020). It faced challenges in developing standards of each microservice, scalability, cost of developers and training. It also faced cultural challenges of successful implementation of microservices architecture  (Reinhold, 2016). The company also had to look for microservice developers with prime operational skills and reliable as well as sophisticated application platform infrastructure. The cost was also a bottleneck for the company (Gud, 2020).

Principles of Service Modeling & Technologies

Service modeling has various different policies including loose coupling (Shivakumar & Shailesh, 2015). In the traditional application, the single service data model shares space between different components. The data being stored in one database can cause several issues including schema change, communication, deployment change, scaling issues and coordination. All of these can impact on the performance of the application (Shivakumar & Shailesh, 2015). Out of data-driven model, domain-driven model and event-driven model, the event-based communication system is advised to be integrated for Whiteboard Company as asynchronous communication (Microsoft, 2018). Asynchronous communication is perfect enough for running job, forming connections, adding new users data without interrupting stored data and can be easily decoupled. In order to handle the increasing number of requests, Whiteboard can take help of Tornado (Python event-loop-based asynchronous networking library) as it can help it in integrating with current networking code of the company.

The event-driven data model is a loosely coupled and scalable system that can maintain the data’s consistency and reliability. The figure 6 below shows the event-driven data model and its performance between different services.

Figure 6: Event Driven Data Architecture

Source: For Whiteboard Company, REST and SOAP are recommended to be used as these will fit easily in the current system (Garcia & Abilio, 2017).

Purchase Complete Assignment Solution