Cloudify Reviews

We were examining Cloudify. We got Cloudify into our organization, and we did some proof of concept and prototyping initially. We liked it. It was a good solution for what it's meant to do, but it wasn't the right solution for what we needed. So, we decommissioned Cloudify and switched to Morpheus instead.

Its version was a fairly recent one.

We had a manager who thought that Cloudify could be used as a replacement for Horizon in OpenStack, but we found that Cloudify lacked the user interface or GUI for doing multitenancy and basic platform management tasks. 

Cloudify was really good at launching, for example, firewalls and configuring them and doing service chaining and rather advanced things like that, but it didn't meet the requirements for a basic platform management solution. It is something that seems to work better as a bolt-on or an augmented solution. It is a bit mis-marketed as a Cloud Management solution. It is not that. It is more of a service orchestration and automation tool. It is very good at doing that, but it fails to meet basic platform management requirements.

Once you have it running, you can't really do anything with it without writing code and scripts. It requires a full-time DevOps person to use it. We deployed a Palo Alto firewall with it. That's basically what the project was for us, and it worked flawlessly once we got it finished, but it took another 12 weeks to get all of the automation and everything else coded, tested, and working. There is certainly a place for this technology, but when we got rid of OpenStack and moved to VMware, we either had to go with the vRealize Automation Suite to do this kind of automation, or we had to find an alternative solution to manage the private cloud. So, we put Cloudify in, but we really couldn't find it useful for basic platform administration tasks.

From a developer's perspective, we use Cloudify to deploy infrastructures and as part of CI/CD. We also use it as part of the system and integration testing, to run and provision infrastructures, and test clusters. Our customers use Cloudify for NVF related needs, telecom, and edge computing use cases. In addition it's used for networking -- VMware, OpenStack and the like. 

There are numerous valuable features in this solution including that Cloudify supports all the major cloud providers. One of the cool features is its extendibility which means you can build your own custom logic by building a Cloudify plugin and deploying that plugin to Cloudify manager. I also like the usage of the Cloudify cluster setup where you can use it for high availability and manage complex use cases. In addition to that, Cloudify support deployment update and day-2 operation where it would be easy to manage and modify existing nodes.  

Cloudify is a DevOps tool that we use for spinning up the VM. In order to do that it needs to communicate with the IP address, with the storage, the network, and with ServiceNow. It communicates with multiple tools and is a single-point tool that enables script development on PowerShell, Python, and PSQL. I'm an engineer and user of this solution and we are customers of Cloudify.

The best feature of Cloudify is that it enables a single platform to communicate with the DB, with applications, and with the entire infrastructure. The product is very stable and has a lot of troubleshooting and analytical features. It's easy to understand and user-friendly. If you want to uninstall something, it's very easy to have the logic created in Cloudify. Other solutions don't have this. For example, if you wanted to decommission after three or four years, rather than going for a full decommission, it's possible to unallocate a particular space. If you want to allocate storage for a new build, it's very easy to deploy, uninstall and release some storage from the TOSCA.

I use a hybrid model of the solution as a blueprint to create and deploy virtual machines to the open stack. 

The solution includes the option to run background scripts and processes from a connected API. 

The YAML format is also easy to use with some practice. 

Documentation is sufficient to learn from examples and modify to any company's needs. 

Our use case is top-level orchestration: Orchestration of applications made up of different technologies, by subcontracting work to underlying orchestrators which are more technology-specific, like IaaS, DBaaS, Kubernetes or home-grown solutions.

The TOSCA model. It allows modeling the application rather than the automation. It is a machine-readable representation of the application and its infrastructure, which can be used for other things too, not just for the orchestration (e.g. enterprise architecture big picture, who connects to whom).

Cloudify also provides the infrastructure-as-code, as well as operational action capabilities (orchestrated startups or upgrades, and more).

Working with a major bank to set up a private cloud and used Cloudify implementation as an orchestrator, based on TOSCA blueprints.

Environment was VMWare and OpenStack based instances that was configured using SaltStack.

Product has given us the ability to catch scaling issues early on that many companies hit on with private clouds.

We’ve found application modeling being abstract blueprints fits the need for developers to implement their much needed bi-product from a simple template.

We configured our application using Cloudify in our production environment. We deployed the REST application with Tomcat and configured it with Cloudify auto-scaling and load balancing configuration. 

I think about the containers (Docker). We can quickly create a local cloud with Kubernetes, a global deployable format (container), good resource utilization, and open source. 

• Good OASIS TOSCA blueprint support
• Extensibility
• Multi-platform nature

It has enabled us to create the DICE Deployment Service. It also simplified deployment of any other services (monitoring, continuous integration, etc.).