Welcome!

XebiaLabs | Continuous Delivery and Agile DevOps Tools

XebiaLabs Blog

Subscribe to XebiaLabs Blog: eMailAlertsEmail Alerts
Get XebiaLabs Blog via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Blog Feed Post

From Dev to Prod in the Cloud By @XebiaLabs | @DevOpsSummit [#DevOps]

How XL Deploy and Amazon AWS OpsWorks Take Away the Pain

From Dev on your Laptop to Prod in the Cloud: How XL Deploy and Amazon AWS OpsWorks Take Away the Pain

By Andrew Phillips

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-xld

2. XL Deploy invoking OpsWorks to instantiate the stack:

xl-deploy-invoking-opsworks

3. New environment and infrastructure in XL Deploy:

new-environment-in-xl-deploy

4. XL Deploy automatically deploying the app layer to OpsWorks:

xl-deploy-deploying-app-layer-to-opsworks

If 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!

The post From Dev on your Laptop to Prod in the Cloud: How XL Deploy and Amazon AWS OpsWorks take away the pain appeared first on XebiaLabs.

Read the original blog entry...

More Stories By XebiaLabs Blog

XebiaLabs is the technology leader for automation software for DevOps and Continuous Delivery. It focuses on helping companies accelerate the delivery of new software in the most efficient manner. Its products are simple to use, quick to implement, and provide robust enterprise technology.