This is the continuation of "The script that refused to stay small".
The conversation had already been happening for months: three data centers, rising costs, aging hardware, and a growing sense that the whole setup was one incident away from becoming a liability.
The decision came quickly after the "kalima" event: everything had to move.
What followed was not elegant, as the platform team scrambled to pull off a lift & shift to the cloud:
- hypervisor VMs mapped 1:1 into cloud instances
- network rules replicated (and occasionally guessed)
- storage reattached, sometimes awkwardly
- timelines optimistic, then revised, then ignored
Most applications... just came along for the ride whilst Marta watched all of this unfold.
Her service was, technically, just another VM in the inventory. It could have been copied over, like everything else, but the lift and shift was rushed and was accumulating tech debt almost by definition. So she made a different call.
Instead of following the 1:1 VM migration path, she opted into an early container platform the company had been experimenting with—something not yet standard, slightly under-documented, but good enough.
Not because she was trying to be innovative, but because her system made it easy.
Containerizing the application turned out to be almost trivial.
Quarkus already produced a lean runtime, with the pipeline living inside a single process with well-defined boundaries. There were no hidden dependencies on the host, no fragile startup scripts, no tight coupling to the underlying machine.
Marta wrote a Dockerfile, wired a couple of environment variables, and that was… mostly it.
The hardest part wasn’t the application, but everything around it:
- getting the right network access
- aligning with security policies
- making sure it could talk to the same external systems as before
So while most systems were being translated from one VM to another, Marta’s was quietly being repackaged.
And once it ran, something became clear:
- It was still a monolith
- Steps still called each other directly, in-process
- The pipeline still lived entirely inside a single runtime
Only the execution environment had changed.
That was the first quiet lesson The Pipeline Framework taught the team: you can move where something runs without changing how it behaves.
A few weeks later, someone asked Marta how long her migration had taken; she hesitated (because the honest answer sounded wrong: “About a day. Maybe two, if you count the networking issues.”
Photo credit: Javier Mediavilla E, CC BY-SA 2.5 https://creativecommons.org/licenses/by-sa/2.5, via Wikimedia Commons
