July 2018 Summaries

The blog post series provides a detailed guide on transitioning a monolithic application into microservices, focusing on the extraction and data management of a specific microservice called OrdersService, responsible for booking tickets. The process involves utilizing Dynatrace for monitoring and identifying traffic flow, thereby helping to decouple the service from the monolith. It emphasizes the importance of understanding both data and domain models, using Teiid to virtualize these models and manage legacy and new data sources. The guide also covers the technical steps necessary for setting up and configuring the microservice, including creating a separate database and using annotations like @InsertQuery and @SelectQuery to manage data operations. The ultimate goal is to ensure the new microservice is fully functional and integrated with both its own and the monolith's database, setting the stage for its deployment in subsequent posts.

The text outlines a detailed journey of transitioning a monolithic application, TicketMonster, to a microservices architecture using a guided approach. Initially, the blog series decouples the user interface, leading to a thinner code base without legacy UI elements, employing canary release strategies. The process then focuses on understanding the business logic to effectively identify microservice candidates, using Andi Grabner's 8-step recipe, which emphasizes continuous experimentation with tools like Dynatrace without altering code or impacting users. Dynatrace aids in detecting service dependencies and capturing transactions, helping to identify potential microservices like MediaService and a simulated OrderService. The text highlights the importance of understanding service dependencies and internal code workings, emphasizing collaboration among domain experts, architects, and developers. It also suggests considering business risk, product roadmap, and strategic impacts before deciding on the first microservice extraction. The series aims to extract the OrderService in future steps, continuing with re-factoring and monitoring efforts.

The blog post explores strategies for transitioning from a monolithic to a microservices architecture, focusing on deploying a new user interface for the TicketMonster application. It emphasizes the use of dark launches and canary releases to mitigate risks associated with sudden changes in production environments. The process involves initially releasing the decoupled UI to a limited group of users to test its functionality and stability, gradually increasing traffic through canary releases, and using tools like Dynatrace to monitor performance and error rates. The article also discusses cleaning up the monolith's code by removing legacy UI components and ensuring the new backend version, backend-v1, communicates with the same database. The post concludes by highlighting the importance of strategic deployment mechanisms to facilitate a smooth transition and hinting at future discussions on identifying and extracting the first microservice.

The blog post series details the journey of migrating the TicketMonster application from a monolithic structure to a microservices architecture, focusing on removing the legacy user interface (UI) and introducing a new decoupled UI component, tm-ui-v1. The process involves assessing the performance of the new UI, which, despite slightly higher response times due to an additional service layer, is deemed acceptable. As the legacy UI becomes obsolete, the code is streamlined by removing the old UI, creating a more compact backend version, backend-v1, deployed using canary release strategies. This involves an informal dark launch to internal users and gradually increasing the traffic load to the new backend and UI components. The article emphasizes the use of Apigee Edge API Proxy to manage traffic routing and deployment, ensuring a smooth transition with full end-to-end visibility, ultimately enabling the next step of extracting specific domain-based microservices within the backend.

The text outlines a series of blog articles detailing the process of migrating a monolithic application, TicketMonster, to a microservices architecture using the OpenShift platform. The guide starts by setting up the TicketMonster application on OpenShift, emphasizing the need for a MySQL service and a proxy web server, and utilizing Dockerhub for image deployment. The process incorporates the Strangler pattern and best practices to transition from monolith to microservices, beginning with the decoupling of the user interface to enhance flexibility and reduce deployment times. The blog highlights the importance of monitoring via Dynatrace and the GitHub repository containing necessary resources. A strategic approach is recommended, suggesting the initial release of the decoupled UI to a small group of users, with plans for future articles to explore OpenShift’s routing mechanisms and canary releases.