This post is from the XebiaLabs blog and has not been updated since the original publish date.
From Dev on your Laptop to Prod in the Cloud: How XL Deploy and Amazon AWS OpsWorks take away the pain
As a developer, I want the pain the effort required to go from a code change to a running version of my app (which I can test) to be as minimal as possible. Luckily, there are a whole bunch of frameworks and tools that will give me an on-demand environment: Vagrant, Terraform, all the virtualization and cloud management platforms and now, of course, containers and all the related orchestration frameworks too. But I really also don't want to have to re-tool my environment provisioning scripts or container definitions every time I add or change some aspect of my app. And there are other use cases to consider: if I'm working in a plane, I'll (for a little while longer, at least ;-)) want an offline version using Vagrant, Docker or so; when I want to test a bigger setup in e.g. EC2 that is a bit more like my production environment, I'll use something like AWS OpsWorks. Using XL Deploy in combination with OpsWorks can make both of these problems go away. Even better, I can delegate the problem of defining, testing, updating etc. my environments to an Ops or platform team. I then only have the "app layer" - the part I'm actually working on - to worry about:
- I can use the standard OpsWorks ens defined by my platform team, or simply pick up off-the-shelf community blueprints
- I can use other environments when I need to, such a local Vagrant or Docker env when I'm offline
- When my environments are updated with security patches, I don't even notice: and because I don't have to own my env setup unless I want to (it's not specific to my app, after all), I can leave all the boring maintenance stuff to someone else
- My app layer - the stuff I care about - is deployed to my environments automatically, even if they are differently sized or configured