Report on DTGOV Cloud Immigration

The changes in the DTGOV architecture and migrating to micro services, it is important to examine numerous features design in the DTGOV. Similarly, before micro services adoption, one must understand the drawbacks and benefits of different architectures to be implement in the company. To transfer to the micro service, it is essential to split the existing monolith system into smaller parts by recognizing the appropriate boundaries service (logical and physical) amongst different quantities. This selection of the boundary is the main challenge.  In case of the immigration from existing architecture to the cloud the Domain Driven Design offers an appropriate solution to recognize the border and break the system. One challenge for system dividing is how to divide the modules. For the DTGOV travel applications of the database is the state. In this case, DTGOV travel applications database must be divided in order to deformalize into one data source in a table. Similarly, DTGOV travel applications can establish the foreign key relationships and transactions between 2 micro services. In this report, there would be discussion about the DTGOV travel applications migrations of the architecture from monolith system to micro services architecture (Linthicum, 2016).

 Which modules are likely to be relatively stable, a together with the reasons for this categorization,

For this categorization of the DTGOV travel applications, the modulus that are likely to be stable would be travel recommendation engine, accoumendation recommendation engine and travel recommendation. The whole process of these three modules in the DTGOV travel applications will be same even after the immigration to the cloud by using the micro services application. Because these three modules not have to deal with the real time process and the data available on the modules are static, so there is not be need to change the module and they remain stable after the migration (Pachghare, 2016).

Which modules are likely to require frequent modification, together with the reasons for this categorization,

For this categorization of the DTGOV travel applications, the modulus that would require the modification would be cart, search engine, travel and acumination search engine. The whole process of these three modules in the DTGOV travel applications will be modified after the immigration to the cloud by using the micro services application. Because these three modules have to deal with the real time process and the data available on the modules are dynamic, so there is need to change the module and they would be modified after the migration (Paradkar, 2018).

Which modules are likely to experience workload peaks, together with the reasons for this categorization.

For this categorization of the DTGOV travel applications, the modulus that would experience workload peaks would be account administration, search engine, travel and acumination search engine. The whole process of these three modules in the DTGOV travel applications will be experience workload peaks after the immigration to the cloud by using the micro services application. Because these three modules have to deal with the real time process and the data available on the modules are dynamic, so the process of the account administration, search engine, travel and acumination search engine would be higher after the migration and it also result in workload peaks (Pachghare, 2016).

DTGOV wants to transition to a micro service approach with the Travel Booking application. But they want to move in a phased approach so that they can handle the workload peaks first.

In the DTGOV travel applications immigration to the micro service architecture, the application can be divided into numerous components or parts, known as micro services. These modules are scaled individually.  It is the architecture approach is beneficial when system has high work load with more modules that are reusable. The architectures of the micro service is comparatively simple. It emphases just on one module at a time. The DTGOV travel applications designed by using the architecture of the micro service is insecurely attached as the modules of an independent system work. In order to perform the task, each service is assembled, choosing the most appropriate tool. This DTGOV travel applications architecture permits numerous developers and teams to work independently with the help of the micro services architecture (Pachghare, 2016).

The DTGOV travel micro services applications can also reduce the overall workload of the application because it handle each module independently and all of the processes among the modules are independent of each other, this quality of micro services of DTGOV travel applications  also allow it is manage heavy workload. The micro services also offers numerous benefits to developers.  The micro services code is easy to understand and small, smaller teams, easy to scale, capability to employ various technology, easy to deploy, system resilience and easy to throw away (Paradkar, 2018).

Which modules should be refactored first

In the DTGOV micro services architecture the account administration module have to be refactored first because this module is very much depends on the architecture of the system and once the architecture of the system is changed, the whole account administration module have to be changed. The shift of the company to the DTGOV micro services architecture required to modify most of the process and operation of the application. It can also cause the change in the user experience about the application. In the DTGOV micro services architecture all of the modules would be in depended and now in the account administration module there is a needed to refactor to reduce the coding of the program and it would also decrease the overall complexity and workload of the user on the DTGOV tourism application in the micro services architecture

 Discuss how a move to a micro service approach for these modules would resolve issues around workload peaks?

In case of DTGOV travel applications modifications the micro services is a mechanism and also architecture, and is confused with services of the traditional SOA-type. It is DTGOV travel applications architecture design in which multifaceted applications are composed of minor, independent procedures that connect with each other by using the APIs language-agnostic. It is also known as service-oriented computing, disintegrating the application to basic function, and structure it as sets of services that can leveraged by applications. It is also known as the basis of reuse, and the services are systemic to use non-container and also containers applications.                                                                                                                                                                                        

The containers use to containerize or wrap current applications have some of the advantages, with the aptitude to decrease work load and complexity by leveraging the abstractions container. Some of the containers in the micro services architecture eliminate the dependences on the services of the fundamental infrastructure that decreases the trouble to deal with those platforms. This means DTGOV travel applications new architecture can abstract the resources access, for example the storage, from application (Linthicum, 2016). It is also likely to make DTGOV travel applications portable, but the overall speeds of the refactoring applications, meanwhile the containers handle the access to native resources of the cloud to be used in the DTGOV travel applications.

The DTGOV travel applications new module architecture also provides the aptitude to influence automation to portability maximization, and, with transportability, their worth. Although the automation use, the DTGOV travel applications feature scripting could do automatically, for instance the migrating DTGOV travel applications architecture from to the cloud. Certainly, most DTGOV travel applications are built to take containers advantage, but current applications are frequently challenging to containerize. The leveraging containers objective in the DTGOV travel applications seems to be distributed transportability versus architectural value, as initially thought. Though, portability is continuously a leveraging containers byproduct that also help the DTGOV travel application to handle more workplace modules in the applications (Paradkar, 2018).

Discuss how a move to a micro service approach will improve DTGOV’s ability to maintain high availability for this application.

The benefits of DTGOV travel applications architecture include capabilities through micro services reuse. As DTGOV travel applications architecture rebuild cloud applications, DTGOV new applications architecture change them to services expose that are available by other cloud applications. More significantly, DTGOV travel applications architecture can consume services from the application rebuilding so don’t have to shape functionality from beginning.

For example, some DTGOV micro services architecture programs have built-in systems for example mapping, credit, address and validations services that should be maintained. DTGOV micro services architecture can cost increasing thousands of dollars each year.  The service-based approach in the DTGOV micro services architecture lets reach out and consume remote services that offers this functionality, so DTGOV micro services architecture can get out of maintaining services business that can be found in places. DTGOV micro services expose services to use in the other applications enterprise, or sell services to other initiatives over the Internet though cloud architecture (Linthicum, 2016).

It is also important to keep in mind the ability to offer better governance and security services by employing those services around the containers. In some of the cases, governance and security services are platform, not specific application. For instance, outdated applications on-premises incline not to have governance and security purposes application innate. The capability to place governance and security services outside of DTGOV micro services architecture domain offers less complexity and better portability while refactoring. The leverage micro services ability in this case the offers the same benefits, no matter if DTGOV micro services architecture using containers. The containers can offers better disseminated capabilities computing as well. An outdated application can be distributed into numerous different areas, all exist in containers. These are said to be the containers can be run different platforms of the cloud, including the one that provide highest performance and cost efficiencies (Paradkar, 2018).

Draw a diagram that shows the architecture of the Travel Booking application after the transition to a micro service approach

CONSLUSION

Summing up the discussion about the DTGOV travel application architecture, migration to the micro services architecture, it can be said that to transfer to the micro service, it is essential to split the existing monolith system into smaller parts by recognizing the appropriate boundaries service (logical and physical) amongst different quantities.

DTGOV travel applications can establish the foreign key relationships and transactions between 2 micro services the modulus that are likely to be stable would be travel recommendation engine, accoumendation recommendation engine and travel recommendation. The DTGOV travel applications, the modulus that would require the modification would be cart, search engine, travel and acumination search engine. The modulus that would experience workload peaks would be account administration, search engine, travel and acumination search engine. The DTGOV travel applications designed by using the architecture of the micro service is insecurely attached as the modules of an independent system work. The micro services code is easy to understand and small, smaller teams, easy to scale, capability to employ various technology, easy to deploy, system resilience and easy to throw away. It is also known as the basis of reuse, and the services are systemic to use non-container and also containers applications Although the automation use, the DTGOV travel applications feature scripting could do automatically, for instance the migrating DTGOV travel applications architecture from to the cloud. DTGOV micro services expose services to use in the other applications enterprise, or sell services to other initiatives over the Internet though cloud architecture (Pachghare, 2016).

REFERENCES of DTGOV Cloud Immigration

Linthicum, D., 2016. Practical Use of Microservices in Moving Workloads to the Cloud. [Online]

Available at: https://www.cloudtp.com/doppler/practical-use-microservices-moving-workloads-cloud/

Pachghare, V. K., 2016. Microservices Architecture for Cloud Computing. Journal of Information Technology and Sciences , 2(1), pp. 1-13.

Paradkar, S., 2018. A Full Approach to Migrating to Microservices Architecture. [Online]

Available at: https://blog.leanix.net/en/approaches-to-migrating-to-microservices-architecture