Our Cisco switches were dying left and right so we had to come up with a plan that fit our environment, was affordable, and offered a bit more stability. 

Ubiquiti is less expensive and more intuitive so we are migrating to their switches. 

We always discuss our customers' use case, landscape, and architecture, and match them with the best solution. We never propose a specific vendor but provide options that match specifications. This solution is one of those options. 

If you compare who has the best way of creating application patterns, I would say Cloudify because of their declarative approach. I can utilize the whole pattern in a code format and provide it to any of the DevOps toolsets like Jenkins or CodeStream where the overall YAML is consumed to create a relevant infrastructure. A business user can log into Cloudify Manager and consume that pattern directly. CloudCenter doesn't have YAML abstraction, they only have the UI part. I like Cloudify from a solution point of view because I have seen the way they use their TOSCA patterns. I'm aware of the new version for which they provide out-of-box support for Terraform and Ansible.

I also used PMG about three years ago, but haven't had any new customers since. That customer was using PMG for frontend and Cloudify for backend. 

The last solution we proposed for a customer was version 8.4.2 of a vRealize suite. We have multiple customers in the UK, Europe, and US using VMware vRealize Automation. Different health sciences use it, including the company who created the first vaccine for COVID. We created an environment managed by VMware where they conducted their research. vRealize Automation has achieved the same with declarative approach. A graphic designer has the overall pattern in a UI format. And on the right hand side, you can see the overall YAML format which is like infrastructure as code and can be provided to any of the DevOps tool sets. You can export that YAML content and release those pipelines. 

Previously when we used VMware, we had several Windows machines and Linux but they've now containerized everything to a Linux-based machine which is much smoother. They have also created a different component within the suite called VMware VRealize Life Cycle Manager which you deploy with the overall CMP suite of VMware. It used to take three to four days to deploy VCap which is now VRA for VMware. Now it only takes four to six hours to deploy the overall suite via Life Cycle Manager. 

With CliQr, containers didn't exist at the time and I'm not sure if they have developed any new solution.

We looked at another product that I believe is high ranked, which is another product from Cisco that we've used in our internal data center, our traditional data center, to actually accelerate our deployments inside the traditional data center. So that was one of them that we were kind of looking at and we wondered why we should use a new one if we already have that one in our hardware center instead of being a software application. So the development and evolution of that product put emphasis on change a little bit. We felt we were better equipped with the cloud-based there. And there are other competitors that we had also considered at the time, but the problem was always the same thing: "How will it mix with the rest?" "How does it function with all the technology that is not in the VMU?" So in the end, the choice was more about impact and change. I need a broader set of functionalities that I found in one product and no discrimination from the other one at the same time. Both products evolve and I'm sure we could have done a pretty good job with that one as well.

We did have other vendors on the shortlist. The issue was outside of CloudCenter. CloudCenter for us was a given, because of the stack that we were using in the integration with this. It turned out to be a very heterogeneous environment from a compute perspective. Other vendors, like software-defined networking operators, were not cutting it to cover all of our needs. So eventually you get into a situation where you actually select one product and then it helps you find synergies in ways that show you why you would actually choose the other one. This led us down a path where if you wanted everything to integrate together and work and be able to have one head to knock on if ever something didn't work right, we want it to be with one vendor. That's typically what it needed to be done and a lot is to be able to confirm our choice of having a cloud service.

We've had a few customers that asked us to compare Cisco to Huawei, and some ended up choosing Huawei. We can implement either and we've found Huawei to be stable as well.