Teknisk indsigt

Migrering af en IoT Audit Engine fra Scala (ZIO) til Java 21 + Spring Boot

Af Thomas Bonderup 10 min read

Migrering af en IoT audit engine fra Scala/ZIO til Java 21 + Spring Boot med Strangler Fig, kontrakttests og SRE-guardrails uden at bryde produktion.

Migrering af en IoT audit engine fra Scala/ZIO til Java 21 + Spring Boot med Strangler Fig, kontrakttests og SRE-guardrails uden at bryde produktion.

Vigtigste pointer

  • Behandl migreringer som driftssikkerhedsprojekter først og kodeoversættelse bagefter.
  • Brug Strangler Fig og kontrakt-tests til at bevare adfærd under gradvis migrering.
  • Etablér SRE-guardrails tidligt, så driftsregressioner opdages før de rammer produktion.

Kontekst: Hvorfor migrere (market fit, rekruttering og operationel konsistens)

Dette indlæg er en opfølgning på mit tidligere blogindlæg, Design af en evidensbaseret audit engine til IoT-sikkerhed & driftssikkerhed, hvor jeg beskrev det oprindelige design i Scala + ZIO. Her gennemgår jeg migreringen til Java 21 + Spring Boot.

Den primære motivation er teknologisk market fit. I Danmark er Scala stadig relativt nichepræget, mens Java og C# dominerer backend-jobmarkedet og er standardvalg i mange virksomheder. Migreringen til Java forbedrer:

  • Rekrutteringssignal (matcher mainstream backend-stacks)
  • Operationel konsistens (standardværktøjer, biblioteker og teamkendskab)
  • Vedligeholdbarhed (lavere barriere for bidragydere og fremtidige maintainers)

Min baggrund i Java og Scala

Min Java-erfaring går mere end et årti tilbage i både professionelle og akademiske projekter, før jeg senere gik dybere i Scala til distribuerede systemer og funktionel programmering.

2013-2016: Tidlige Java-projekter (OOP-fundament)

Under min første uddannelse i datalogi arbejdede jeg intensivt med objektorienteret programmering i Java og byggede flere end-to-end projekter, bl.a.:

  • Et system til administration af biavlere
  • Et system til planlægning af flyruter

2018-2020: Java-backend + distribuerede systemer (BSc CS)

Under min bachelor i datalogi arbejdede jeg med mere avancerede backend-koncepter i Java til produktionsnære miljøer:

  • Spring Boot og skalerbare serviceplatformsmønstre (REST API’er, integrationsmønstre, microservices og container-deployments med Docker og Kubernetes)
  • Et Java + Spring Boot + Apache Kafka bachelorprojekt til anomalidetektion på køretøjssensordata

2020-2022: Java-sikkerhed + avanceret streaming med Kafka (MSc)

Under min kandidat brugte jeg Java i sikkerheds-, backend- og systemprojekter:

  • En filkrypteringsapplikation med Java Bouncy Castle
  • En Spring Boot applikation relateret til digital misinformation
  • En prototype af et Virtual Power Plant til mit speciale med Kafka til streaming af vejr-, energi- og markedsdata

Skift til Scala: Akka -> dataplatforme -> FP (efter MSc)

I specialeperioden begyndte jeg at skifte fra Java til Scala, først for at udnytte actor-modellen og Akka-økosystemet. Efter studiet arbejdede jeg fuldtid med Scala i data engineering:

  • Scala i en data lake-kontekst (fx Spark, Hadoop-økosystemet)
  • Selvstudie med fokus på funktionel programmering med Cats og ZIO (inkl. kurser fra Rock the JVM)

Tilbage til det bredere Java-økosystem

Målet er ikke at lære Java fra bunden. Målet er at tage production-grade Scala + ZIO-design med ind i et Java + Spring Boot-økosystem, uden at gå på kompromis med disciplinen omkring driftssikkerhed, operabilitet og sikker forandring.

Princip: behandl migrering som et driftssikkerhedsprojekt

En migrering er ikke bare en omskrivning i et andet sprog. Den ændrer systemets fejlmønstre: konfiguration, threading/konkurrens, timeouts, serialisering, database-drivere/pooling, dependency injection, deployment og observability-defaults. Selv hvis forretningsadfærden skal være den samme, ændrer driftsadfærden sig ofte.

Derfor behandler jeg migrering som et driftssikkerhedsprojekt først og kodeoversættelse bagefter.

Jeg er stærkt inspireret af Working Effectively with Legacy Code1, især idéen om at etablere sikkerhedsnet før større ændringer. Min tilgang er:

  • Refactor før migrering for at reducere kompleksitet i Scala-kodebasen og tilføje kontrakttests.
  • Migrer inkrementelt med Strangler Fig-mønsteret2 (ét slice ad gangen), kontrakttests og SRE-guardrails uden at bryde produktion.
  • Refactor efter migrering, når den nye platform er stabil, så midlertidig glue-kode kan fjernes og Java-arkitekturen forenkles.

Grunden til refactor både før og efter er enkel: denne migrering har en højere risikoprofil end en normal refactor. Skiftet fra Scala + ZIO til Java + Spring Boot ændrer runtime-miljøet, og det giver en række risici, som ofte ikke fanges af unit-tests alene.

Næste del: baseline og sikkerhedsnet, derefter den første tynde Java-slice.

Referencer

Footnotes

  1. Working Effectively With Legacy Code af Michael C. Feathers

  2. Strangler Fig pattern: https://martinfowler.com/bliki/StranglerFigApplication.html

Anvend dette i din platform

If you are dealing with similar architecture or reliability issues, I can help scope a concrete improvement plan.

Relateret indhold

Drøft en lignende udfordring

Del din arkitekturkontekst og det oenskede resultat.

Foretrækker du direkte kontakt? Ring på +45 22 39 34 91 eller skriv til tb@tbcoding.dk.

Bedst til teams med arkitektur-, stabilitets-, security- eller leverance-risiko i kritiske systemer.

Typisk svartid: 1-2 dage