• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!


Microservices migration patterns

This version was saved 5 years, 3 months ago View current version     Page history
Saved by Nathan T Suver
on April 3, 2019 at 9:27:42 pm


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.



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.



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.



Comments (0)

You don't have permission to comment on this page.