In engineering at Mobivity, we have a common theme:

“The less we have to manage, the better.”

The less we have to manage the better. We’d rather be focusing on product than infrastructure.

Though with all these fancy managed services and PaaS providers, it doesn’t work too well witch legacy code bases. A lot of products that Mobivity has acquired have a lot of requirements and setup isn’t too simple. It can be like fitting a square peg into a round hole with many managed solutions. At least until Elastic Beanstalk announced docker support.

For a few months now, we’ve been using Docker and Elastic Beanstalk for much of our infrastructure. Overall it’s been a very positive experience with a few key things to follow.

Use Pre-build Docker Images

There are two main reasons for wanting to deploy using an already built image.

Deployments are a lot faster.

If you give Elastic Beanstalk just a Dockerfile, it will build that image on each box each time you deploy it. Having

Avoiding deployment errors

Long image build times can sometimes cause errors on elastic Beanstalk from my experience. Especially if you are using smaller instance sizes and need to compile a lot of stuff.

Clone Environment For Deployment

When deploying a new version to an Elastic Beanstalk cluster, I prefer to clone the entire environment, deploy the new version, then swap the environment url to the new version. The advantages of doing it this way are that you don’t affect the production environment with a deployment and you can easily switch back to the working environment if needed.

We’ve been using these methods of deploying to Elastic Beanstalk for the last couple months now and it has made using the platform a much smoother and reliable experience.