Why we love Ansible
The orchestration and automation game has seen a blizzard of tools emerge. Everything from expensive system deliveries to open-source desktop tools. Of course, everyone has their favorites, leading to the age-old problem: “If you really like hammers, every problem looks like a nail." Not a good idea for home improvement, and really not a good idea for network automation. The key is not only “the right tool for the job," but also the right tool for a particular job within an architecture.
But what is it about an automation tool that makes it your “go-to" choice? The obvious suspect here is Ansible. Why does everyone like it? Here are my reasons:
It’s not a science project: Ansible is easy to learn and easy to come up to speed on. You can download a copy and begin to create working automations in a single sitting. You work with human readable files (YAML) and you don’t have to be a programmer to make production-grade playbooks.
It’s open source: I don’t have get a P.O. to get started, or even to go into production.
The module library ROCKS: Ansible uses community contributions to create a vast library of “modules." Modules are pre-packaged functionality which you can call from your playbook. Rather than know all the commands and replies needed to program a router, you just call the Cisco IOS module, or Juniper Junos module or F5 module, etc.
It’s an "intent-based" tool: A common factor among my favorite tools is they don't make my brain hurt. When you build an Ansible playbook, you create a list of instructions that define an automation’s actions. Ansible translates your intent into actual CLI commands — can I get an AMEN?
It’s powerful and flexible: Ansible has achieved a rare feat — simplicity and power. It’s simple to use and make content with, but you can do very powerful things and build production-grade automations. Usually, with power comes complexity. But Ansible rolls the power back into the intent-based approach, allowing you to use playbook instructions to leverage its power.
So, Ansible is a beautiful thing, why not use it for every automation problem? Remember my earlier statement — right tool for a particular job within the architecture. Some jobs require that the automation remember what it has deployed and then react to changing states. Service management is such a task. If I deploy a service I need to “remember” where it’s deployed, to what endpoints and who owns it. If the service goes away, I want to cleanly remove it from the network. This is the “day 2” task. With cloud, this is particularly important. I can’t just deploy cloud infrastructure; I need to manage it across its full lifecycle.
Introducing Cloudify, my “Ansible” for cloud
If you haven’t already, take a look at Cloudify. I got to know Cloudify as we developed the Next Generation Central Office (NGCO) solution.
The NGCO enables service providers to move the power of the datacenter out to the edge of the network. This facilitates services which rely on NFV elements like SD-WAN. We chose Cloudify as the orchestration tool and Fortinet as the SD-WAN solution.
I had never worked with Cloudify before. So, I went to the web site and found to my delight that it’s open source! I can download a copy and begin working with it. But not only that, as I continued to explore Cloudify I found it possessed all of Ansible’s great qualities:
It’s not a science project: I created a Linux VM in my OpenStack environment and downloaded the install file. A few commands later, I was connecting my working Cloudify instance to my VIM (in this case, OpenStack). I downloaded plugins and blueprints right from the Cloudify Console. In a very short time, had my first OpenStack elements deployed.
It’s open source: You can download a copy of Cloudify and all the related content — plugins, blueprints, downloads from Github — all available via the GUI console. There is an enterprise license available for large-scale deployments. But everything you develop on the open source version transfers over to the licensed version.
The module library ROCKS: Cloudify works at a higher level than Ansible. Cloudify is made to orchestrate end-to-end services across a multi-domain environment, so it talks to many different systems. Just as with the Ansible community, the Cloudify community is building a robust library of system “plugins." The plugins enable the system to communicate with VIMs, controllers and other orchestration tools (including Ansible). Getting my Cloudify instance to talk to my OpenStack was a simple matter of downloading the plugin that matched my blueprint.
It’s an "intent-based" tool: This is what makes working with Cloudify so “Ansible-like." Cloudify uses TOSCA blueprints to define the intended deployment. TOSCA, like YAML, is a human readable text syntax, from which you structure your Cloudify deployment. I found it not only easy to use but also very “hackable." I could make changes and comment out lines and get to a working blueprint. The blueprints work with a set of system variables called “secrets." The secret store is accessible from the main console and you can very quickly build your secret library to suit your blueprints. Again, the intent you design into the TOSCA file is translated to API calls that flow through the plugins. So, a single TOSCA blueprint can define deployment across OpenStack, Kubernetes, SDN, Ansible, NSO, etc. Take your pick, or pick them all! Cloudify is also stepping up the game with a graphical authoring tool that helps you create the TOSCA files from a pallet of icons.
It’s powerful and flexible: Cloudify goes well beyond just deploying cloud elements. It’s a complete MANO (Management and Network Orchestration) solution. Once it deploys a blueprint (say for a “day 0” underlay), you can then deploy overlay services. All the deployments are kept in the Cloudify database and are viewable from the console. Cloudify will also deploy agents into the various cloud elements. This allows the system to provide full telemetry and lifecycle management for each system. Add to this the fact that it’s fully tenant- based, allowing you to create custom dashboards for each tenant, which means everything is exposed to REST APIs.
How Cloudify works
You begin at the Cloudify console GUI. Here, you can access all important system functions, including blueprints and deployments. The Cloudify catalog gives you instant access to Cloudify’s public content, but you can access any content via Github or local files.
The blueprints area allows you to download and explore your local blueprint library. Each blueprint contains a TOSCA file defining the installation actions, along with other supporting files and reference points. Cloudify renders a TOSCA visualization showing all the logical connections and elements.
The installation into the VIM and other sub-orchestration systems is controlled from imbedded workflows. You call the workflow you wish to execute — install, uninstall, delete, etc. Once the elements are installed into the VIM environment, Cloudify installs agents into key servers and deployed VNFs. These agents provide monitoring and state control.
Blueprints can act as “day 0” with additional blueprints being “day 1” and “day 2” overlays. In this way, Cloudify acts as a complete MANO solution where the VNF infrastructure is built then overlay services are placed into the infrastructure. “Scale In” and “Scale Out” workflows allow you to define how the deployment behaves under various conditions. This is key for MANO operations since VNF deployments can auto-scale given load or failure conditions.
Agent monitoring takes Cloudify beyond just orchestration and turns the entire solution into a fulfillment and assurance platform. You can select specific widgets to apply to your system dashboard to monitor key KPIs and NEs. Additionally, you can create dashboards for tenants with custom skins and content. This makes Cloudify a hub to provide tenant self-management and monitoring. Cloudify allows you to plug into your monitoring technology of choice, providing a means to install your monitoring agents as part of the application installation, and report your metrics to the Cloudify policy engine and metrics database. Cloudify visualizes your monitoring metrics and statistics over web reports and provides you with APIs to query monitoring metrics from any of your systems.
A universe of applications
Just like Ansible, Cloudify’s flexibility and power are driving it into a broad universe of applications. End users, integrators and VNF solution partners are finding new and valuable ways to apply Cloudify and solve problems. Here is a brief list of some of the ways Cloudify is making an impact. You can find a more complete list here.
Enterprise Dev-Ops Orchestration
NFV MANO applications, VNF On-Boarding and Service Chaining
SDN and NFV at Service Providers
Virtual CPE and SD-WAN
Cloud-Native VoLTE at the edge using VMWare
5G, vEPC and Network Slicing
Orchestrated security and SD-WAN
Let us help you get started with Cloudify
WWT is working with Cloudify to create applications for our service provider and enterprise customers. Take a look at some of the content we've developed to help you learn more about how Cloudify can help your organization.