Juju: a robust cloud strategy built on choice

Ubuntu is the reference platform for scale out computing.  Some manifestations of scale out computing include: edge of network workloads, dev/test environments, big data (Hadoop), and Cloud (OpenStack).  Not only do all these next-generation workloads run on top of Ubuntu but what’s truly amazing is you can deploy and orchestrate them with just one tool – Juju!

From the start Juju was designed around these key principles:

1. Allowing faster spin-up of new services

2. Re-use expertise across teams and community

3. Choice of Infrastructure-as-a-service (IAAS) and avoidance of lock-in

4. Migration between IAAS providers

For the purposes of this post, I’m going to focus on Juju features 3 and 4 because too often they are overlooked in a company’s Cloud strategy.  The proof comes directly from the field where we frequently hear, “We are worried about our reliance on <insert Cloud provider name here>,” “we need to reduce <insert technology> footprint in our data centers,” or “I need to be able to burst more easily.”   Just like any robust Cloud application needs to be platform agnostic and dynamic (e.g. scale, highly available, etc.), a company’s IAAS strategy needs to have the same flexibility and reliability.

By adopting a flexible IAAS strategy you not only avoid vendor lock-in, but you open yourself to other advantages.  For example, you can “Juju deploy” your software application where it’s most cost effective.  If Cloud service provider A increases their rates, you can move to Cloud service provider B.  Or ask both providers to bid for your workload.  Even better, you could bring your application back to your in-house hardware (why not use what you’ve already paid for) via OpenStack and burst to a Cloud service provider if needed.

Today, Juju deploys to LXC, bare-metal via Metal-as-a-Service (MAAS), OpenStack, and on a growing list of public clouds such as Amazon’s AWS, HP Cloud, Microsoft Azure, etc (see the full list here).  The Juju community has added support for Mac OSX and Windows clients as well.  Via the Juju GUI, the ability to design and deploy workloads to various IAAS has never been easier.

Here’s a quick example:

• From the Juju GUI drag and drop services, aka Juju Charms, to create your tiered application and relations.  For example, mine looks like:

    Watch this video if you’re not sure how to drag and drop Juju Charms into the Juju GUI.

• Export your tiered application by clicking on the up arrow at the top of the Juju GUI or press SHIFT+D and save the .yaml file to you computer.  The file name defaults to “export.yaml” but feel free to make it something more relevant as you’ll see why later.  In Juju terminology, this file is called a “Juju bundle”.

• Assuming you’ve followed the Juju tutorial’s Getting Started page and correctly configured Juju’s environments.yaml file for Cloud services you want, we bootstrap our Cloud environment

$juju bootstrap -e <your Cloud environment>

e.g.juju bootstrap -e ec2

• Install the juju-deployer package

$sudo apt-get install juju-deployer

• Deploy your Juju Bundle file from your system

$juju-deployer -c <your buddle file name>.yaml envExport

If you want to deploy to a different Cloud environment, just bootstrap that environment and deploy your Juju bundle:

$juju bootstrap -e <Cloud environment #2>

$juju-deployer -c <your buddle file name>.yaml envExport

That’s it!  It’s two simple commands to move between Cloud service providers or deploy to my private OpenStack cloud.  As a bonus, you can socialize your Juju bundle with colleagues and they can Juju deploy your bundle to the environment of their choice!  In my team, we keep a collection of Juju bundles in a shared folder so it helps to give bundles a meaningful name and/or bundle versions.

With respect to the Cloud, choice is power and Juju is the fastest way to get the most out of your tiered application.

Ameet Paranjape

Canonical Sales Engineer