Tom Callway
on 10 February 2015
The following is a guest post by Samuel Cozannet, a Strategic Program Manager for Canonical, an Azure partner and the company behind Ubuntu.
At Canonical, we’re really happy to see Microsoft increasingly engage with the open source community. This is particularly true with its cloud platform, Microsoft Azure, where users can now easily spin up Ubuntu instances.
So when the Azure team came to us a few weeks ago to discuss how our cloud orchestration tools could be deployed more easily by Azure users, we were excited about collaborating with them to build an easy and streamlined user experience for Juju.
Life before Juju
In a previous life I built a complex architecture that managed a distributed fleet of digital signage players. These players decided what to play back based on real-time analytics from their environment and audience. Part of that architecture was deployed on-premises, and the rest was built on public clouds to leverage the power of tools like Microsoft Azure Media Services.
The main components used were noSQL data stores (document and columns), time series analytics, LAMP stack, a bit of networking stuff, and a lot of micro services written in Node.js and Python, in an effort to be as close as possible to the 12 factor app. Of course, there was the usual laundry list of supporting technologies: log monitoring, identity management, backups, and so on. In total, the bare minimum deployment per client required 15 virtual machines and three physical hosts, on top of which we had the usual management layers. And everything had to be highly available, of course.
The biggest challenge we then faced was the replication of the environment into development, staging and production, as well as the ability to demo the on-premises deployments to clients and prospects. The number of instances, interconnections between them and versioning issues quickly made the whole architecture a beast to manage, despite using some of the most advanced configuration management tools available at the time.
Looking back, had Juju been available I believe it would have solved many of these problems.
What Makes Juju So Compelling?
Juju Focuses on Services
A Charm (enablement of a workload in a Juju environment) describes the life cycle of a service, from deployment to integration and scaling.
Juju Manages Relationships
At the abstract service layer, Juju is aware Service A is related to Service B (for example, web front end connects to database). It will then manage how those services expose themselves and are consumed on the other end of the relationship, dynamically creating connections whenever scaling out or scaling in.
Juju Is Environment Agnostic
While most cloud strategies are image-based, Juju believes starting with a blank instance is actually better. This increases deployment time, but users trade that for maximum flexibility as it removes the need to handle the cloud or host APIs. With the optimization work Canonical has performed for Azure, deployment takes just a few minutes. This means the same charm or solution can be used in the cloud, on OpenStack, in containers, on bare metal, with Vagrant, or when an image-based deployment requires the creation of templates/images for every substrate.
Juju Handles Architectures
Whenever a deployment matches the functional and technical requirements, its design can be exported into a simple YAML file referencing all services and the relations that unite them. The same file can then be imported in a completely different environment and will effectively repeat the deployment on this new substrate. Think dev > staging > prod AND demos managed in a single file, portable across the cloud, on-premises, and even on containers and bare metal.
Working with Juju Is Very Easy
Charms can be written in any scripting language. Puppet or Chef users can reuse the manifests or recipes within charms and parametrize them through relations. Another strength is charms are open source but stored centrally. Therefore any changes made benefit the whole community and over time distill the best DevOps practices.
Juju Scales
Juju charms are deployed as units. A unit of a service can be a VM, a container, a physical host, name the substrate. Then users can juju add-unit -n 100 , which will scale the service by 100 further units. Those units can be constrained by resources or location. Services can also scale down depending on demand.
Juju Fits into Any DevOps Environment
Juju has a complete API to manage its behavior. For example, if metrics indicate scale-out is required, just trigger add-unit commands. If using a hosted logging management tool is preferable, simply expose SaaS within Juju environments. If configuring management and running an old server on the side, use Juju to scale out and manage cloud resources. Keeping configuration management for compliance with company policies is also possible.
Juju Can Leverage IaaS and PaaS
Juju can deploy PaaS on top of IaaS, which gives users maximum flexibility for developments. For example, if a user wants CloudFoundry for internal apps but some workloads require bare metal, Juju has it covered.
So yes – if I had to build that digital signage system again, I would use Juju as the cloud-level abstraction (regardless of other tools used) because it would guarantee compliance and configuration consistency across my whole deployment.
Getting Started with Juju on Azure
Juju is now available to all Azure customers to help simplify and accelerate the deployment and orchestration of their applications. Working closely with the Azure team, Canonical has made it easier than ever to use Juju, so now scale-out applications are just a few clicks away!
When starting the Juju template on an A1 instance, users will be presented with a web page (see below) and a link to download the Azure “Publish Settings” file.
This file is used to configure the Azure multi-platform CLI to easily interact with Azure from the command line. It also contains enough information to configure Juju.
Upload this file to the instance and we’ll use it to configure a Juju environment in the default subscription, bootstrap it, and install the GUI so Juju can be played with right away.
Why DevOps Love Juju
Users who come from the DevOps world like me will love how easy Juju makes it to start engaging with all the cool stuff there was never enough time to play with before:
- Want WordPress at scale? Juju makes building that must-have, load-balancing feature a snap!
- Need Hadoop fast? It’s easy with Juju. But it’s also a breeze to add an IPython notebook and immediately start hacking into data or quickly deploy MapReduce jobs.
- Gotta have a new ELK stack? Juju lets users build a three-node Elasticsearch cluster in less time than it takes to make a cup of coffee.
- Want to do some data-hacking? Deploy YARN, Hadoop and IPython notebooks with Scala support along with some example datasets in minutes.
And once it’s ready, Juju helps move the cool stuff seamlessly into production, adding monitoring, log management, identity management, and other goodies along the way.
Let me be clear: Juju fundamentally changes the way DevOps is done. Iterations on paperboards are a thing of the past. With Juju, sysadmins can now iteratively design and deploy architectures at scale in just minutes rather than days, weeks, or months.
But what if the application a user wants isn’t in Juju? No worries. Juju is fully open source and so are charms. Join the growing community of charmers and start “charming up” an app in any scripting language, or learn how to do it at our our bi-weekly charm schools.
More questions? Join our mailing lists by emailing juju@lists.canonical.com or joining the Juju community on IRC freenode #juju.
Ready to get started? Here are a few videos.
