The Migration That Started With a Question
STRV, a Prague-based digital agency, moved an internal project off Fargate containers to serverless AWS in a few months. Not through a vendor engagement or formal migration program, but through knowledge exchange with AWS expert Michal (connected via AWS Hero Filip Pýrek) and Engineering Manager Marek Čermák.
The original architecture - Fargate, Aurora, S3 - worked fine. STRV still uses it. But for this project, the team wanted something leaner to maintain. "Our main goal was to move away from the monolith and adopt a low-code backend that would be easier to maintain and more cost-effective," Čermák said.
What's notable: they turned architectural learning into a weekend hackathon that shipped working code.
Two Teams, Two Approaches, One Saturday
The Prague office hackathon split developers into two teams. Team A went full serverless - AppSync, DynamoDB, Lambda. Team B blended familiar tools with incremental AWS adoption. Both built functional prototypes by Sunday.
This contrast proved useful. Same problem, different trade-offs based on what you optimise for: speed vs familiarity, operational overhead vs control. Principal Engineer Tomáš Kocman noted it "strengthened technical skills and deepened team connections."
The Pattern Worth Watching
The STRV approach - ongoing knowledge exchange over predefined architecture - aligns with AWS's own Cloud Enablement Engine (CEE) framework for reusable patterns. Companies like Shutterfly achieved 25% cost reduction through similar native AWS migrations (800 systems, 400TB, zero high-severity incidents post-move).
But migration timelines compress fast. Shutterfly pulled theirs forward six months due to vendor issues. The risks in mainframe decoupling and tight coupling patterns remain real - quick lift-and-shift works for end-of-life systems, but complex apps need decomposition strategies.
What This Means in Practice
STRV demonstrates a viable middle path between expensive consulting engagements and DIY disasters. The hackathon model for architectural validation is clever - it proves patterns work before committing production workloads.
The real test: whether the serverless architecture holds up under production load and whether STRV's developers maintain it as easily as they hoped. We'll see.
History suggests monolith-to-microservices migrations succeed when teams understand the new patterns deeply, not just implement them. STRV invested in understanding first. That matters.