Skip to main content
DevOps icon showing cogs

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
Sep 13, 2021

The Expedited Journey of Digital Transformation

DevOps
Alan Brown, Digital Transformation Advisor at Digital.ai conducts a se ...
Read More
Aug 23, 2021

Is Data Analytics Missing From Your Digital Transformation?

DevOps
Nearly every major enterprise is already in the process of digital tra ...
Read More
Aug 19, 2021

Creative Ways to Automate Developer Workflows

DevOps
When an organization begins an Agile or DevOps journey, the process ca ...
Read More
Aug 12, 2021

How Automation Enhances Efficiency and Delivery Speed In a DevOps Environment

DevOps
When organizations make the decision to move to a DevOps environment, ...
Read More
Contact Us