Cloudify vs. Ansible

Cloudify vs. Ansible – Where Each Works Best

Last month, we compared Cloudify with Terraform, HashiCorp’s infrastructure automation tool. This month we will explore some of the strengths and use cases of Cloudify and another widely used automation tool, Red Hat’s Ansible.
Cloudify is a TOSCA-compliant full orchestration tool. It’s available as an open-source product which uses declarative orchestration language. It leverages blueprints to allow for end-to-end management. Ansible is an imperative automation tool that is widely used in the industry. Ansible’s simple, yet powerful setup makes it very attractive for infrastructure and configuration management. Both tools are very strong at what they do, so let’s see how they stack up.

Get in touch and learn how Cloudify can take your environments to end to end automation

Ansible Strengths

It’s Easy!

Why is Ansible so popular in most markets? Because the lift is light. Seasoned DevOps engineers or newly branded operations folks can stand up an Ansible installation and start automating with just a few plays. Organizing plays, playbooks, and templates is very straightforward. The process is agentless—orchestration is executed over SSH for Linux or WINRM for Windows. The executions can be parallelized and you can watch automation occurring over hosts as it happens. Even though design considerations come into play with more complex environments—as does with Chef or Puppet—the lack of real server/client architecture makes for simpler management and decoupled execution.

Strong for Operations Adoption

Many sysadmins and traditional operations personnel who start on the DevOps journey have difficulty coding and building automation solutions through tools. Because Ansible is imperative by nature—which means, “automate in the order and the way I want you to”—it’s a much simpler approach for traditional ops personnel to grasp. This means it adds value to business faster, with less training, and with less time investment. Because developers are already familiar with coding principles, they can easily learn Ansible’s straightforward construct and Jinja2 templating to make plays or playbooks. In short, time to automate is short.

Gateway from Scripts to Imperative Operations

Since Ansible plays are straightforward (much like a script), it’s easy to execute scripts through plays first, and then convert scripts into plays. Since many enterprises are weighed down with scripts holding together the seams of server maintenance, backups, and software deployments, Ansible gives cloud engineers an extremely accessible way to get the same job done with little to no effort.

Galaxy

The Ansible Galaxy is a community managed repository of canned solutions. It contains resources such as a play for a Mongo server, or Apache, or a SQL cluster. In fact, it has more than 18,000 solutions to browse. The solutions are ranked by downloads and community rated quality. For those who like to give back to the community, this is a way to share your hard work. It makes adopting and using Ansible that much easier.

Cloudify Strengths

Manage by Code and GUI

Cloudify offers a CLI for coders and a GUI for those who need the graphical representation. The Web UI assists with much quicker adoption and solution building. As other solutions become more complex, it’s difficult to grasp the end-to-end picture and a full collection of all the code and execution it takes to manage that end-to-end picture. Moreover, the ability to use quick and easy “click and modify” changes to an environment replaces what would normally be complex coding, such as auto-healing, scale on demand, or rip and replace. These features are available to Cloudify users through the command line utility and in the GUI.

As a completely “included” feature, Cloudify provides architectural graphics on the relational nature of deployed Blueprints. This is amazing and a tremendous added value for solution architects and security professionals.

Simplified Full-Scale Management

Deploying a web server configuration or a database cluster isn’t a big deal with modern tools, but an entire ecosystem? That’s another story. Where many solutions become extremely complicated for writing, testing, and execution, Cloudify shines because it can handle a deployment as a single function. If your deployment involves creating Linux servers running Rails applications with Nginx for reverse proxy, some Redis servers for caching, and a MongoDB cluster for a database, that can be a blueprint which can be deployed repeatedly across different environments as a single orchestration. This automation power helps wrap individual components as full solutions.

Deployment Metrics and Analysis Included

Metrics tools are available in automated paid-for utilities, such as Ansible Enterprise, but the reporting, logging, and metrics tools offered by Cloudify help alleviate dependency on external tools like Elasticsearch or Datadog. The dashboards provide users with real insights into end-to-end deployments. They provide fast answers, such as an ecosystem running hot and requiring scaling (or a notification that an ecosystem scaled because of increased application pressure). In many cases, it’s exactly what’s necessary to understand how your environment is performing.

Ansible Weaknesses

Struggles at Scale

Ansible may be easy to get off the ground, but as the environment and managed nodes scale, Ansible struggles to keep pace. The solution is lighter because it isn’t server/agent based. But deploying changes to many nodes requires open connections to each server. That requires either throttling or careful consideration to deploy changes across many nodes.
Another consideration is managing a large number of like nodes. Since Ansible doesn’t maintain state, it’s definitely possible for different configuration versions to be applied across like nodes and to trigger indirect version configuration drift. This can be mitigated by always pushing any change to all nodes. However, if there are many servers that require updating, this parallelization problem will be compounded.

Fire and Forget Deployment

Fire and forget is good and bad. Ansible configures servers based on plays or playbooks, but then it’s done. There is no maintained or managed state. It’s challenging if you want to understand if things have changed, or track drift. If you schedule plays to deploy regularly (like desired configuration state models) to mitigate this problem, you can aggravate the parallelization model again. An effective way around this issue is to use Ansible to configure a system, take an image, and then deploy that image. That way, configuration is easy to version and manage across very large environments. This workaround is popular for deploying Kubernetes nodes and not having to worry about drift since containers are scheduled after deployment.

Challenging to Deploy End-to-End

Can Ansible be used to deploy entire stacks and ecosystems? Absolutely. Can it deploy them as an entire unit? That’s a much larger challenge. In most cases, playbooks will allow you to chain together different plays to bring a server to complete configuration. As solutions become stacks and combinations of stacks, deployments must be carefully chained to create a predictable and repeatable state. This is not a simple design process and requires careful wrapping of orchestration with Ansible.

Cloudify Weaknesses

Heavy Lift for Entire Environments

Can Cloudify deploy entire environments? It certainly can. Is it super easy? No, but having that level of automation requires care, thought, and some code to wrap together everything into a deployable bundle. Luckily, Cloudify’s blueprint templates are in a very approachable YAML-like language. No matter what solution is used, you have to provide configuration files and scripts for different solutions. Cloudify’s blueprint just takes all those standard configs and templatizes them into a deployment model. Regardless, this is a lot for a new shop to pick up, but talented DevOps engineers and developers can use this orchestration power to their advantage.

Additional Layer of Abstraction for Orchestration

Even though Cloudify provides a framework to build blueprints and create deployments, anything outside of the provided plugins requires additional development work. Environments that are more complicated require creating more complex blueprints. That means testing becomes even more critical. Unlike deployable units or modules, building testing frameworks for an entire deployment requires a more intensive effort. Also, another layer of code (the Cloudify orchestration) should be tested as well. For those who need a quick and easy solution, this can be a tough sell.

Smaller Community, But Growing

Unlike its competitors, Cloudify is growing its open-source code community. Cloudify does publish examples for the community to use, but it’s still growing in maturity to meet the same level of contribution such as Ansible Galaxy. As more engineers or companies adopt full-scale deployment orchestration such as an SAP environment, Cloudify’s code base should also grow with those adoptions of codified ecosystems and full-stack solutions.

Summary

As with any automation tool, there are always best-use cases and reasons to invest time into leveraging orchestration code. When considering your options, keep in mind that there are open-source options available for nearly every tool. Focus on both the short-term and the endgame when picking solutions. A quick win now may require significant refactoring later. Think about simplifying your solutions into tools that can do more for you without adding complexity. Cloudify can solve your end-to-end orchestration needs, at scale, and in a fully codified, repeatable method. You can easily get started with the community edition of Cloudify or contact us to set up a demo.