Monoliths can do Multicloud

Three years ago, at IncrediScribe, our transcoding needs had outgrown the cozy confines of Heroku, so we made the leap to serverless with AWS Fargate. The promise was one of infinite scalability and cost-effectiveness. In reality, though, we faced a trade-off that didn’t quite sit right with us: with bandwidth and compute savings came complexity and a sluggish development cycle.

Just a few months ago, we took a hard look at our setup. It was eating up a huge chunk of our budget and had become the bottleneck of the whole transcription pipeline, slowing down half of our files. It didn’t make sense, our state-of-the-art speech recognition was quicker and cheaper than just converting video formats. The transcoding code? It had been tweaked maybe five times in three years. This wasn’t for lack of necessity, but because the prospect of wading through the painful development process was a deterrent in itself. Clearly, something needed to change.

Today, we’ve taken a step that some may see as unorthodox: we’ve adopted what we like to call a Multicloud Monolith. This isn’t a story of a grand revolution, but one of a deliberate, practical step towards streamlining our operations.

Our transcoding is now four times faster, video processing and streaming costs have plummeted to a twentieth of what they were, and we can iterate on the code locally in just a couple of seconds. All this while keeping the core of our app in good-old Heroku.

Let’s take a look at our new setup