This is probably the first of a series of posts where I’ll try to explain my approach to deploying scalable applications with OpsWorks. More particularly, my goal is to cover the deployment of a fully-optimized Magento website. But first I’d like to share some words over why I’m choosing OpsWorks over the other application management services in the AWS cloud. At the time of this writing, OpsWorks is one of three application management services that AWS features, the other two are: Elastic Beanstalk and CloudFormation. My first question when reading about OpsWorks was natural: what’s the difference with Beanstalk?

I’m in the mood to type, so here’s some AWS history – as experienced from my perspective – that will serve as background for this series. No time for history? Feel free to skip it.

Discovering Fire: CloudFormation


Discovering Fire

Back when Beanstalk was not available we would launch one or more EC2 instances, customize them manually (because Chef or Puppet weren’t as popular yet), and hook them up to other AWS components like LoadBalancers via the API. Probably few users were savvy enough to setup automated deployments for their applications other than manually transferring files through SFTP/SSH. Once all components were setup, we would use CloudFormation for scaling.

CloudFormation was the fire in an otherwise primitive cloud. This doesn’t mean its obsolete: its very much alive today and its perfect for very advanced users and really, really, complex architectures.

Inventing the Wheel: Beanstalk+Chef

Inventing the Wheel

What Beanstalk+Chef looks like

About half a year after releasing the first CloudFormation Public Beta, AWS introduced Beanstalk: a service that would almost completely abstract application developers from their infrastructure. This happened ends of 2010.

Soon after Beanstalk was released many people (like me) were digging deep into the Beanstalk deployment application (which is built in Ruby code) and customizing the Beanstalk AMIs, because they wanted a different deployment model or needed to customize the application server (e.g. to add Varnish). This was not an easy process, because Beanstalk wasn’t really meant to be customized all that much.

In my particular case, I would use Chef to customize the Beanstalk AMIs automatically, which in my opinion is the only “sane” way of going down this road if you wanted to keep you application up-to-date with the latest Beanstalk AMI. Without Chef I would have found myself configuring a server every other month, whenever a new Beanstalk AMI was released (thank God for Chef!).

I’m convinced that Beanstalk+Chef was an excellent combination for app developers: it provided me with all the beauty and automation of the Beanstalk layer while still giving me the flexibility to fully customize the app servers. It was scalable and definitely wasn’t as much work as CloudFormation would have been. But I was literally hacking Beanstalk and bending it to my will – not ideal.

Industrial Revolution: OpsWorks

AWS OpsWorks

As you can see, Beanstalk and CloudFormation are at opposite sides of the spectrum when it comes to abstraction. The honorable people at AWS realized there was a market for a new services that would thrive right at the middle of the spectrum between Beanstalk and CloudFormation. It had to be:

  • Simple and productive, like Beanstalk.
  • Powerful and flexible, like CloudFormation.
  • Secure by default – like much of the AWS cloud.

How OpsWorks is Different to Beanstalk and CloudFormation

And so AWS released early 2013 a new service: OpsWorks. The OpsWorks FAQ quickly covers what makes the OpsWorks offering different to Beanstalk and CloudFormation – you can read about it here. In a nutshell:

Beanstalk is for the typical PHP application that requires no more than a standard LAMP stack – where the M of MySQL stands for RDS. It provides the user with a high level of abstraction from infrastructure and a pretty much fixed model for deployment. In other words its perfect for AWS and infrastructure newbies.

CloudFormation is quite the opposite of Beanstalk, in the sense that its meant to leverage the full range of AWS services via JSON. You need to manually (or through Chef / Puppet) configure each component of your desired architecture – which means there’s no predefined model, you’re completely free to do whatever you please – and once that’s ready you can leverage CloudFormation to easily scale. In other words its perfect for AWS ninjas.

If you’re interested in finding more information on how to choose between the different AWS application management services I strongly recommend this article.



Hmmm I feel like steak!

While this first post is not very technical I do think its important to highlight what makes OpsWorks different. Next in the series: “Custom OpsWorks Stacks” – an article where I’ll share my approach to easily launching highly-customized OpsWors Stacks.

I tried to salt this article with some personal experience, so I enjoyed cooking it and I hope you found it tasty. Though some may say one man’s meat is another man’s poison, I certainly hope that’s not the case with you 🙂 So if you liked it or think it could help someone feel free to leave a comment or share it!

1 Comment The Case for AWS OpsWorks

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.