SATURN 2020

Application migration is the process of moving an application from the existing operating environment to a new one. Application migration is a complicated process because the new environment can be substantially different from the old one. The important part of this process is moving application data and relevant application logic while delivering the key application capabilities without any sacrifice to their service levels and taking advantages on the capabilities of a new platform. The migration is usually driven by a strong operational need to add features, add scale, or improve performance that would be difficult to achieve in the existing environment. If we are dealing with a legacy application, it is often the case that some of its parts, modules, data or capabilities are no longer useful and should be retired. At the same time, application parts still could be retained and migrated if they are needed to support the application’s functionality and can operate in the new environment.

Despite providing multiple benefits, moving legacy applications to Microservices Architecture (MSA) poses its own set of additional challenges due to the distributed nature of MSA applications. It requires not only re-architecting the legacy applications, which are usually monolithic applications, as a set of loosely coupled service, but also changing and building infrastructure and tools to manage, monitor, and test microservices. Substantial changes also need to be made in the software development process and the organization of development teams to adopt and advance adoption of DevSecOps practices. If the organization doesn’t have these practices in place, it needs to start following them and making organization and process changes on the early stages of migration.
There are two well-known approaches for breaking a monolithic application into modules or microservices:
• by application capabilities
• by application data or bounded context

Both of these approaches have a few challenges. It is possible to identify application capabilities; however, the capabilities might have inter-dependencies and it might be hard to untangle them in a legacy application. Splitting a legacy application by data domains requires conducting a full analysis, if not a full reconstruction, of an application domain model. In that model some of the data components might be outdated or irrelevant. As a result, it might be hard to decide if they need to be transferred to a new platform or not.

In this presentation, we propose a new approach to split monolithic legacy applications to modules or microservices for purposes of migrating to a new platform. We propose using mission threads as a tool for the analysis of an existing application capabilities and defining how these capabilities will be moved to a new platform.