, , , ,

Breaking up the Monolith while Migrating to the Cloud in 6 Steps

When migrating applications to the cloud, we apply one of the 6-R Migration Patterns for each app: Retain, Retire, Re-host, Re-platform, Re-purchase or Re-architecture. Monoliths that get migrated often end up in the Re-Architecture bucket which…
, , , , , ,

Monolith to Microservices – Release the Microservice

Based on the result of the previous blog posts, we identified the microservice OrdersService that now has its own code repository and defines its own domain model. To launch this service in a staging (or pre-production) environment, it is not…
, , , , ,

Monolith to Microservices – Drop TicketMonster’s legacy User Interface on OpenShift

In the previous article of this blog series, we decoupled the UI from the monolith to have the monolith and the UI as two separated maintainable, deployable, and testable artifacts. However, decoupling parts from an existing application in production…
, , ,

Monolith to Microservices – Drop TicketMonster’s legacy User Interface

The previous part of our blog post series ended with the decoupled user interface component tm-ui-v1 for TicketMonster. This component runs as single Cloud Foundry app and forwards user actions to the endpoints of TicketMonster. Nevertheless,…
, , , , ,

Monolith to Microservices – Set up TicketMonster on OpenShift

In the first article of this series we have introduced the problem of a monolithic application and the idea to break it into microservices. In this article, we will take a look at the demo application and how to set it up on the Openshift platform.…