Loading article...
Loading article...
Stream/Area:
-
Subject:
-
Paper ID:
IJSREM35447
Volume:
8 |
6 |
Jun 2024
Pages:
1-5
Publication Frequency:
Monthly (12 issues per year)
License:International Journal of Scientific Research in Engineering and Management follows the Creative Commons Attribution 4.0 (CC BY 4.0) License, allowing free use and distribution with proper attribution.
Independent Researcher
Independent Researcher
The move from a monolithic application to microservices is one of the most commonly attempted and most commonly botched transformations in enterprise software. The usual failure is not technical but strategic. An organization freezes the monolith, spends eighteen months building a replacement against a specification that is already stale, and delivers nothing until a risky big-bang cutover that often does not work. This article presents the Strangler-at-Scale Method, a phased and iterative framework for migrating a monolith to services incrementally, with the system in production and delivering value at every step. The method treats migration as a loop applied one business capability at a time: map the domain, establish a seam, route traffic through a facade, extract and verify the new service, and retire the old path. I give particular attention to the decomposition of the shared database, which is the step where most migrations stall, and to the question of when a service should not be extracted at all. The framework is deliberately independent of any particular language, framework, or orchestration platform, and is drawn from migrations I have led for large-scale systems where downtime was not an option.
KEYWORDS
The monolith-to-microservices migration fails most often for reasons that have nothing to do with microservices. It fails because organizations attempt it as a big-bang replacement, freezing a moving business behind a rewrite that delivers no value until a risky cutover at the end. The Strangler-at-Scale Method is an argument for the opposite. Migrate incrementally, in production, one business capability at a time, with the ability to roll back at every step and real value delivered at every step. None of the individual techniques here is novel. The strangler pattern, bounded contexts, facades, parallel running, and database-per-service are all well established. What the method contributes is the insistence that they be applied as a disciplined loop rather than a heroic project, and the honesty about the two places migrations actually fail: the data, which is harder to split than the code, and the boundaries, which must follow business capabilities rather than technical layers. In the migrations I have led where downtime was not an option, the teams that treated the work as a loop finished. The teams that treated it as a rewrite are, in several cases, still rewriting.
M. Fowler, "StranglerFigApplication," martinfowler.com, 2004. E. Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston, MA: Addison-Wesley, 2003. S. Newman, Building Microservices: Designing Fine-Grained Systems. Sebastopol, CA: O'Reilly Media, 2015. S. Newman, Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith. Sebastopol, CA: O'Reilly Media, 2019. C. Richardson, Microservices Patterns: With Examples in Java. Shelter Island, NY: Manning Publications, 2018. F. P. Brooks, The Mythical Man-Month: Essays on Software Engineering. Reading, MA: Addison-Wesley, 1975. N. Forsgren, J. Humble, and G. Kim, Accelerate: The Science of Lean Software and DevOps. Portland, OR: IT Revolution Press, 2018.
Publication Date
6/25/2024
Peer Review Type
Double-Blind Peer Review
Review Rounds: 2
Documents
Article Views
1
Total views since publication
PDF Downloads
11
Total downloads since publication
Geographic Reach
5
Digital Preservation: This article is permanently archived on Zenodo and complies with all data preservation standards across major indexing platforms.
Plagiarism Screening
This manuscript has been checked for plagiarism using TurnitinPlagiarismChecker software.
Conflict of Interest
The authors declare no conflict of interest related to this research work.
Funding Information
No funding information available for this research.
Related research in the same subject area
Loading similar articles...