Source:

A. Balalaie, A. Heydarnoori, and P. Jamshidi, “Microservices migration patterns”, Technical Report No. 1, TR- SUT-CE-ASE-2015-01, Automated Software Engineering Group, Sharif University of Technology, 2015.

Abstract:

Microservices architectures are becoming the defacto standard for building continuously deployed systems. At the same time, there is a substantial growth in the demand for migrating on-premise legacy applications to the cloud. In this context, organizations tend to migrate their traditional architectures into cloud-native architectures using microservices. This article reports a set of migration and rearchitecting design patterns that we have empirically identified and collected from industrial-scale software migration projects. These migration patterns can help information technology organizations plan their migration projects toward microservices more efficiently and effectively. In addition, the proposed patterns facilitate the definition of migration plans by pattern composition. Qualitative empirical research is used to evaluate the validity of the proposed patterns. Our findings suggest that the proposed patterns are evident in other architectural refactoring and migration projects and strong candidates for effective patterns in system migrations.

Summary

This article deals with the process and problems of migrating monolithic legacy systems and traditional architectures into a microservices architecture.  The authors propose using a situational method engineering approach (SME), which provide an implementer with a series of canned process patterns for performing this type of migration.  They list a number of migration pattern selection factors that can be used to determine if a given approach is warranted for the team's particular migration.  Factors such as high availability, fault tolerance, scalability and understanding are listed.

They documented a total of 15 patterns, and each pattern is fairly generic, listing criteria for applying the pattern, such as reuse intention, reuse situation, context, the problem it attempts to solve, a solution, known challenges, and a proposed technology stack.  Examples include "adding a service registry" and "decomposing the monolith based on ownership".  They document a few cases studies where they applied the above patterns, noting that not all patterns are always needed, and not all need to be applied in any particular order.  They note that they had an overall positive experience applying the above patterns with the migration of the "Backtory" product.

They conclude by noting that research into microservices is sparse, that very little appears in the academic literature before 2014, most data on this architectural pattern has been generated by industry (e.g.. netflix, pivotal, etc..).  Future work includes ways to automate some of the patterns.

Building on the approach:

There is a lot of great content in this paper.  Applying a handful of the prescribed migration patterns would be extremely useful for this project. In particular, the "recover the current architecture", "decompose the monolith" and "change code dependency to service call" migration patterns.  Although using a a full-blown microservices migration to tackle the proposed anti-pattern isn't necessarily a good fit (due to cost, refactor complexity, time to market, etc..), applying a subset of the migration patterns makes a lot of sense.  In addition, if an implementor decided in the future that migrating to a microservice architecture might make sense at some point, the fact that the above patterns were already applied would be a significantly beneficial investment.

Relevent content:

Migrating current on-premise software systems to microservices introduces many benefits including, but not limited to, the ability to have differentiated availability and scalability considerations for different parts of the system, the ability to utilize different technologies and avoid technology lock-in, reduced time-to-market, and better comprehensibility of the code base.3,4 F