Skip to main content

This post is from the XebiaLabs blog and has not been updated since the original publish date.

Last Updated Apr 20, 2015 — DevOps Expert

From Dev on your Laptop to Prod in the Cloud: How XL Deploy and Amazon AWS OpsWorks take away the pain

DevOps

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
Result: I can get my app running without hassles whenever I need to - locally, in the cloud, in whichever size environment I need. I don't have to worry about any of the usual environment- or OS-maintenance stuff, and I also don't have to write and maintain deployment scripts, manifests, cookbooks, playbooks, Dockerfiles or anything like that for my app.

Here's what it looks like in action:

1. An OpsWorks stack defined as an Environment Template in XL Deploy:opsworks-stack-defined-in-xld2. XL Deploy invoking OpsWorks to instantiate the stack:xl-deploy-invoking-opsworks3. New environment and infrastructure in XL Deploy:new-environment-in-xl-deploy4. XL Deploy automatically deploying the app layer to OpsWorks:xl-deploy-deploying-app-layer-to-opsworksIf you'd like to give this a try, you can download XL Deploy, get the XL Deploy OpsWorks plugin and sign up for OpsWorks right away!

More from the Blog

View more
Mar 01, 2021

Discover the change management practices that are ripe for optimization

DevOps
Change has become the most important part of modern digital product cr ...
Read More
Feb 22, 2021

Reckoning DevOps’ role in the enterprise value stream

DevOps
If you’re a software or digital solutions company, you may use DevOps ...
Read More
Feb 10, 2021

Customer spotlight: Schneider avoiding bumps in the road with DevOps adoption

DevOps
Everyone wants to deliver software faster and more reliably. Companies ...
Read More
Jan 06, 2021

How testing automation can build a culture of QA while accelerating continuous delivery

DevOps
An organization’s level of automated test coverage is quickly emerging ...
Read More
Contact Us