Hier finden Sie wissenschaftliche Publikationen aus den Fraunhofer-Instituten.

Migration from monolith to microservices with legacy compatibility

Invited paper
: Haferkorn, Daniel; Kerth, Christian; Rodenbeck, Roland; Zaschke, Christian

Postprint urn:nbn:de:0011-n-5958480 (527 KByte PDF)
MD5 Fingerprint: 888f7e01a518e6c8ccc9533874202180
Copyright Society of Photo-Optical Instrumentation Engineers. One print or electronic copy may be made for personal use only. Systematic reproduction and distribution, duplication of any material in this paper for a fee or for commercial purposes, or modification of the content of the paper are prohibited.
Created on: 14.7.2020

Sanders-Reed, John (ed.) ; Society of Photo-Optical Instrumentation Engineers -SPIE-, Bellingham/Wash.:
Situation Awareness in Degraded Environments 2020 : 27 April – 8 May 2020 Online Only, United States
Bellingham, WA: SPIE, 2020 (Proceedings of SPIE 11424)
ISBN: 978-1-5106-3625-5
ISBN: 978-1-5106-3626-2
Paper 1142408, 7 pp.
Conference "Defense and Commercial Sensing" (DCS) <2020, Online>
Conference Paper, Electronic Publication
Fraunhofer IOSB ()
migration; monolith; microservice; domain-driven design; system of systems architectures; legacy systems; ISR; agile

Today’s ISR (Intelligence, Surveillance and Reconnaissance) defense coalitions require storage and disseminationmechanisms that are able to cope with emerging changes to requirements and new features. Previous Systemof systems (SOS) architectures used to be built with years of planning, development, testing and deployment,usually in the form of distributed monoliths. Due to new requirements in ISR, shorter response cycles arerequired. To reach this goal, new approaches are of interest in the architectural style and workload sharingwithin the development team, resulting in the ability to better maintain and change existing software solutions.Ideally, such a shift results in improved scalability, replaceability, modularity and resilience.In this context we examined our existing software that provides and also internally uses legacy middlewaresuch as “Common Object Request Broker Architecture” (CORBA) (among others). The overall codebase waswritten in such a manner that it was easy to produce, i.e., technically motivated. The development team israther small, so efficiency and the possibility to share (developer) knowledge is important.Our goal was to evaluate the state of the art, thus being able to reasonably apply modern software developmentapproaches that support mandatory legacy support. We attempted a restructuring of the codebase applying theprinciples of “Domain-Driven Design” with its “bounded contexts”, resulting in domain-oriented source codethat is easy to verify and maintain.Keeping in mind our small development team, we aimed for shared responsibility, giving us the necessaryresilience for unplanned staff absence.In this publication, we present a possible migration path with its operational constraints (e.g., legacy interfaces) towards a more suitable software solution and the lessons learned during the process. In addition, weoutline how this was achieved with a small headcount.