When using the word ‘ephemeral’, it’s hard not to think of Snapchat these days, however the concept applies to the on demand computing pattern we promote here at Iron.io with our task processing service IronWorker. At a glance, each Docker container in which a task runs is only alive for the duration of the process itself, providing a highly effective environment for powering applications that follow the microservices architectural style.
Continue reading “The Ephemeral Life of Dockerized Microservices”
|Docker in Production at Iron.io
Earlier this year, we made a decision to run every task on IronWorker inside its own Docker container. Since then, we’ve run over 300,000,000 programs inside of their own private Docker containers on cloud infrastructure.
Now that we’ve been in production for several months, we wanted to take the opportunity to share with the community some of the challenges we faced in running a Docker-based infrastructure, how we overcame them, and why it was worth it.
Continue reading “Docker in Production — What We’ve Learned Launching Over 300 Million Containers”
FFmpeg is the leading cross-platform solution to record, convert and stream audio and video. Dealing with audio and video can eat up resources, making the activity a great fit for IronWorker by moving the heavy lifting to the background.
In the past, usage of FFmpeg with IronWorker would require that our users include and install the dependency within each worker environment. In order to streamline that process for developers, we’ve included FFmpeg in an IronWorker stack as a custom runtime environment specifically meant for video processing. Continue reading “New FFmpeg IronWorker Stack For Easy Video Processing”
|Docker Solved a Key Problem
Ever since we started Iron.io, we’ve been trying to solve a problem: how to keep our IronWorker containers up to date with newer language runtimes and Linux packages. For the past two years, IronWorker has been using the same, unchanged run-time environment. That is until a couple of weeks ago when we released custom language environments.
Since the inception of our service, we have been using a single container that contained a set of language environments and binary packages – Ruby, Python, PHP, Java, .NET, and the other languages we support as well as code libraries such as ImageMagick, SoX, and others. Continue reading “How Docker Helped Us Achieve the (Near) Impossible”
When we built the first version of IronWorker, about 3 years ago, it was written in Ruby and the API was built on Rails. It didn’t take long for us to start getting some pretty heavy load and we quickly reached the limits of our Ruby setup. Long story short, we switched to Go. For the long story, keep reading, here’s how things went down.
Continue reading “How We Went from 30 Servers to 2: Go”