Cisco CloudCenter [EOL] Reviews

Our company uses the solution's GUI interface to configure and monitor ports. We look at usage and determine if there are any issues. 

Cisco is a very qualified company and has been in business for many, many years. 

The solution is useful because you can configure all the way down to ports. 

You don't get all the solution's benefits if you have older switches. 

The solution is expensive and includes a bunch of fees. For example, you can monitor but you have to pay for that type of drill down. 

I have been using the solution for several years. 

The solution itself is stable but it is important to have healthy switches. 

We do not need technical support because we have knowledgeable staff and support groups. 

I have never performed an initial setup. I came in as director and built on what was already existing. 

The solution is extremely expensive and has additional fees for things like monitoring. 

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. 

If you have the money to spend on it, then the solution is an option. If you are on a budget, then there are other options. 

I rate the solution a seven out of ten. 

The solution is used in any office as a cloud management platform. It is primarily used by telecom companies who also use Cisco hardware. One telecom customer in Bangladesh and certain US customers are using CloudCenter. 

We are system integrators and deploy this solution for our customers. 

The solution has a blueprint pattern. You can club multiple machines, define middleware components, and define dependencies of components. Let's suppose I'm creating an application pattern for Java Stack. I can define all components and create a blueprint for consumption across all services. Same structure, same TOSCA patterns for CloudCenter, vRealize Automation and ServiceNow. 

Cisco can improve their product by being agnostic, not just specific to Cisco components but also supportive of other vendors. 

Improvements are needed in UI and multi-tenancy for this solution. We primarily work with Cisco View. Cisco CloudCenter is their own product and they are working with us to create a hybrid cloud solution. Our custom CMP solution will  be sold by Cisco as their own solution. I wouldn't say they are doing much research on CloudCenter, but are exploring different CMPs. Cisco acquired CliQr and since then I haven't seen much development on CloudCenter. 

The solution does not have YAML abstractions that allow you to consume the overall YAML to create a relevant infrastructure. 

VMware on AWS needs to be supported because native AWS is not useful in hybrid cloud situations. We have a customer who requires a hybrid cloud, so we went toward vRealize Automation. The solution is primarily for private clouds as they don't support much on public clouds. When we discussed this, they didn't have GCP in their portfolio. I'm assuming they have added it now. 

I have been using the solution for the past few years. 

The solution is stable. It was lacking API abstraction layers which are central to Cisco components so that is why they purchased the functionality. With that addition, they will create a customizable, more stable, out-of-the-box solution. 

Various tool sets and products are available to scale the solution. 

I don't have a need to contact customer support. We have teams who work at support centers like GSS for VMware and Cisco tech support. 

As a system integrator, we work with various solutions based on the needs of our customers. This solution is one of many that we implement routinely. We use VMware vRealize Automation, our own CMP, PMG, a multi-cloud manager from Red Hat, Scalr, Cloud Vault, Cloudify, and Cisco CloudCenter. 

For example, we might work with a sovereign customer or a government-based customer. We know that they heavily rely on a private cloud and we check what hypervisor they are using. Are they using ESXi, KVM or another? Based on the hypervisor, we design the overall virtualization platform which can be natively supported by the CMP. If it is VMware heavy, we go with vRealize Automation and if the customer has financial constraints we go with Cloudify so long as the customer agrees on open source. If not, we require everything to be enterprise grid and go with vRealize Automation or MyCloud, which is our own solution. 

If a customer is primarily looking for app modernization and infrastructure as a code format, we provide a custom solution which includes Terraform for provisioning, Ansible for post provisioning, and ServiceNow to integrate components. ServiceNow acts as a frontend, catalog-driven approach where an end user logs in and requests a catalog and a developer would be able to directly consume the Terraform templates and what we have created them for, be it a public cloud or private cloud. 

The initial setup was complex. The architecture is not in a single appliance or container similar to how VMware has different appliances. None of the companies I use have full-blown architecture in a single appliance. 

Multi-node deployment takes one or two days provided there are no complications with node clusters, load balancers, certificates, and rule sets. Things take time because of third-party dependencies. 

Standalone, single-node deployments are straightforward and take three or four hours to complete.

We implement solutions for our customers. We have master competency relationships with VMware, Scalr, Red Hat, and Cisco. 

As system integrators, we don't recommend solutions though we have partnerships with most of the OEMs. We do our due diligence on the customer's environment during the RFP stage and determine the vision, whether public cloud heavy or hybrid cloud, and identify the consuming partners such as business users or developers. Based on all these scenarios including security concerns, we define a solution. I have knowledge of various solutions because I evaluate them for customers. 

We completed a partnership with Cisco where we created a custom solution. Earlier, it was branded as CliQr but is now called CloudCenter and they're moving toward MyCloud which is the custom solution we built for Cisco.

Cisco offers bundle pricing and categories of service for their solution. The same is true for Cloudify where you have free, starter, pro, and enterprise. And for VMware you have standard, advanced, and enterprise. 

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.

It is a benefit that the solution supports Amazon Azure, GCP and vSphere. As a cloud management platform, I rate the solution a seven out of ten. But as a true CMP they lack multi-tenancy and out-of-the-box support for new tool sets like Terraform, Ansible Vault, and Conjur from CyberArk. 

I'm not sure if this support has been added because we started focusing on MyCloud for enterprise VMware vRealize Automation, Cloudify for small business customers, and Terraform and Ansible for IAC customers. 

If you provide an API abstraction layer, you can integrate with anything rather than needing to provide plugins or adapters. For example, VMware used to only have support for Puppet but not Ansible. Then they supported Ansible and Salt. Now they have created an out-of-the-box solution where you can integrate with any configuration management tools like Chef, Puppet, Ansible, and Terraform.

The same process is being used by Cloudify but in a much better way. Rather than creating different plugins, they created plugins for endpoints like Amazon, Azure, GC, and vCenter and created a custom solution that is API based. You can integrate any of your configuration management tools and execute any scripts in PowerShell or Shell.

Every new CMP solution is going with API based which allows you to create a solution that is customizable.

CloudCenter is a tool that handles a hybrid kind of deployment or is basically more like infrastructure code. We're moving away from it due to the fact that they discontinued the product and introduced something new that does not fit our purpose. That's why we're going to a new product called Resolve.

They have a tool in CloudCenter called Action Orchestrator that helps you to build workflows.

There are workflows, automated workflows, of different tasks between different infrastructure divisions, like your VMware, your firewall, and your network. We're also using a different kind of network called ACI, so we orchestrate the infrastructure and orchestrate from the user and automate the process of deploying the infrastructure.

The solution is stable.

You can scale it easily.

I would say there's a lot that can be done to improve the product.

From the time we got it to today's last version, a lot was done, and I still believe there's a lot that can be done to improve it, to make it better.

For example, on Action Orchestrator, they can improve it to handle more, to cater to different languages. Right now, it caters mainly to Python and Partial, so there are a lot of groovy languages around.NET, Java, and Go Language, for example. They can add some of those features to make the platform more usable for different backgrounds and developer skills.

On Action Orchestrator, that's the main thing I look at and the logging. Logging could be looked at a little bit differently. When you run a process and want to track the steps of that process, logging could also be improved.

I’ve been dealing with the solution for three years.

The solution is very stable. It doesn’t crash or freeze.

There are different business units that use it. They have a concept of a tenant. Therefore, we have a cluster running around multiples. We have two clusters running, one in non-production and one in production. Production is mainly for testing QA, and production is production. However, then different organizations have different logging. As a developer, we are about six people. The Linux team will have about 15 people. VMware will have a lot of users in general.

It's actually very easy to add a node and scale the ports in different nodes. It does it automatically since it's managed by Kubernetes.

We’re moving off of it. However, it will take a while. The support ends in 2024. Since we're starting development with Resolve, obviously, the time to migrate all the stuff we've done from one from CloudCenter to the other tool will take some time, so we will still be running it.

They're very helpful. They were responsive, and they take you around the sun, so if you log an attack, maybe the European guys will take you. and when they knock off, they will bounce you off to another team in a different country, which is still working and that is the good thing. At the end of the day, they're trying to get the issue resolved.

The only downside is that they bounce you off to another team and you have to repeat yourself. The handover is not always a hundred percent, and in that sense, there is room for improvement.

Positive

We’re actually moving to Resolve Platform. We just bought it. It is not fully implemented. However, the system is replacing CloudCenter.

Initially, when we started the project, I was using Terraform. However, Terraform is more a script-orientated type of automation tool. The reason why we then went for CloudCenter was due to the GUI, the workflow development, and certain other things like Workload Manager. And then they also have a billing tool that helps you handle your billing, the billing of all the deployment. It’s just ultimately more useful than Terraform.

It’s relatively complex to set up. It is a Kubernetes cluster. The installation could be easy, however, if you're not prepared well, you might have issues. On the other hand, if you have everything set up, it could also go very smoothly.

About three people, including myself, one consultant, and one person at Cisco, handled the deployment.

The deployment is pretty easy if everything is set up. For us, it would take about two hours to be set up, and configured, and get it running.

The initial setup was done mainly via a consultant that we got initially and in conjunction with the technical support from Cisco.

I don’t deal with the pricing or licensing.

We’re just customers.

We started off with version four point something, and we migrated to version five. We're currently using 5.2.0. However, they have a newer version - that's 5.3. I’m actually in the process of upgrading. So within the next two weeks or so, I should have it running in my data center soon.

We try to do server deployment between on-prem and the cloud, so we try to handle the hybrid deployment. We have the local infrastructure, and we're also partially using the cloud for mainly dev environment stuff, and for production, we'd use our on-prem. The reason why we're using CloudCenter is due to the fact that it's facilitated the deployment of this infrastructure and some other applications.

There's a tool called Action Orchestrator in Cisco CloudCenter. It’s a tool for building workflows for automation. That's very helpful. I really use it a lot.

There's another tool called Workload Manager for handling VM deployment. Workload Manager is an orchestrator that will orchestrate VMware. If you want to deploy a VM, you will build a workflow using Action Orchestrator, you would talk to the Workload Manager API, which would then talk to your VMware infrastructure.

I’d rate the solution eight out of ten.

If there's a company that does not have the local infrastructure, it’s a good idea to definitely go cloud to reduce the amount of operational support. Not that there's a lot. However, it will be better to just use the tool than worry about issues related to the operations. On the other hand, if they just want something that's really automation of infrastructure, it will be something great to use with Action Orchestrator and Workload Manager. It's a tool that I would recommend for people that are just going through the automation of the infrastructure journey. I would definitely recommend the tool.

We use the product for demonstration, device provisioning, and data management.

They should provide an entire cloud offering, from architecture to network security features.

We have been using Cisco CloudCenter for a couple of months.

I rate the product’s stability a nine out of ten.

I rate the product’s scalability a nine out of ten.

The technical support team could be faster, more knowledgeable, and customer-friendly.

The initial setup process is straightforward.

We plan to get help from an integrator to implement the product in the next couple of months.

I recommend Cisco CloudCenter to others and rate it a nine out of ten.

The solution is agile and it has APIs for integration. 

The tool should improve its security on the XDR part. 

I have been working with the product for four years. 

I would rate the solution's stability an eight out of ten. 

I would rate the product's scalability a nine out of ten. My company has 300 users for the product. 

The solution's initial setup is easy. 

The tool's pricing is balanced with the market. 

I would rate the product an eight out of ten. 

We're only using it because we create tenants and each OU inside of our company is with our DevOps. With CloudCenter, you are able to use their own VMs and manage their own workload. 

The stability of the solution is quite good.

The initial setup is fairly straightforward if you have a basic setup.

I'm looking for another product that's going to be quite simple and that's going to be more aligned with DevOps orientation so that they can do scripting, etc. I know that you can do it with CloudCenter, with the API, however, it's not perfect yet.

I'm not a big fan of CloudCenter. I don't have anything against it, however, the on-premise version has been so hard to upgrade and maintain. 

We need too many machines just to have a cloud portal. That is very hard to manage and sustain with the versions. Every time that we have upgraded this product to go from version 4.0 something to the latest version under 4.0, we have to spend days and days with Cisco due to all the bugs. Our setup is straightforward. It's not because we did the setup too much complex. We have the base setup and every time that we're creating it, it's pain. 

The upgrade is always failing. They need to get way better at upgrading the solution.

We're the company that uses this solution the most in the entire world, and we've really been pushing for Cisco to make improvements, however, now it's coming to end of life, so they aren't going to happen.

We've been using the solution for three years.

The stability of the product is quite nice. We have had only one or two issues in three years with it in which the system actually crashed. However, for the rest of that time, stability has been great. We didn't have any problems.

There have been no limits as to what I know and what we have reached, as of today. I haven't seen a ceiling on its ability to expand. The scalability is nice.

All the users on our end are DevOps and we are the admins of the VMware identity infrastructure. We have roughly 50 to 60 users actively using it at any given time.

Cisco's technical support is not ideal, and we've dealt with them a lot as we've had a lot of issues with bugs after updates. I would rate them three out of five.

For us, we did a basic setup and the initial setup was straightforward. It depends on the company, however. It can get complex depending on the requirements.

We have a team of five people that handle maintenance on the solution. 

The licensing, as I understand it, isn't too much, as we're working end to end with Cisco. We have an SLA in place that provides us good pricing and they want us to keep our contracts with them.

That said, I don't know the exact cost structure of this solution.

We're a Cisco partner and part of the board with Cisco CloudCenter and Cisco ACI, etc.

We are using CloudCenter now, and we know that CloudCenter is going to be on its end of life by 2024. We're in process of looking for a new replacement.

We're using the latest version, which is something like version 4. Version 5 is on the on-premise cloud-only, and we are not using this. We were planning to migrate to the cloud version, the faster version of Cisco CloudCenter, however, we just learned last week that the end of life was 2024, and so we've decided to not move forward in that direction.

It's a good product. It's working. The only thing that I don't like is the upgrade process. However, for the rest of the solution, the product is doing a great job for what we require.

I'd rate the solution a six out of ten. The upgrades are difficult and I would note that it is coming up to its end of life, so no more upgrades are really going to happen.

We've actually used a private cloud within our company. Typically, we needed a single pane of glass to provide infrastructure services to our clients. CloudCenter is really at the center of everything we built for our data center to keep its initiative. We're really using it to push applications in DMS into the different clouds, as part of the recent additions of other functionalities within our five companies. Since we were an existing company, our customers are still waiting for the pipeline upgrade. A lot of the new features are really interesting, so we are trying to go towards a public cloud. We need to be able to get all the costs, computational features, and the actual Orchestrator to be able to more easily orchestrate across the different targets. We have multiple targets and that's going to help us actually.

The tool is really at the center of our whole digital transformation. That is how people will consume infrastructure in the future.

Cost Optimizer is a new module that works alongside the Workload Manager. They are specifically going to be using it in a lab, on the modulator. This is for public consumption, so to be able to deploy workloads into the call. However, not all of your actual standard inner cloud is going to be managed through CloudCenter. They might have SaaS offerings or might be using other guys, so typically what Cost Optimizer is doing is it's connecting to your actual ORG structure in your public cloud offering and will pull all of the costs you actually had into that cloud account. Along with the other ORGs under that cloud account, you will typically see what's managed by CloudCenter and what's not managed by CloudCenter. 

For us, it's going to provide insights as to where we are spending money. One nice thing about the Cost Optimizer is that let's say you've deployed an M4 large something on an Amazon or another size of VM on Azure. If it says to you that typically you are using a small M1, you're spending too much money, it will tell you. You could save $300 a month because this server is under maintenance, so that feature is typically something that there will be doing recommendations to customers on how to work. My work as a business unit last year involved looking into different ways of doing warm recommendations, such as how you can typically bring it back on-prem or move it or have a policy for aging or scaling that could help you minimize the cost. I think the potential of Cost Optimizer is just starting out because, with the recommendation they can do, they can really bring this to the next level.

The improvement I would like to see are not one thing particular to CloudCenter. I'd say it's more of a message that the system is still using a lot of the different products and if they would all just fit better together, they all could be faster together. We noticed it's just the pace at which the actions start. CloudCenter could integrate faster with all this cloud. CloudCenter is one thing. We're doing a good job. We're asking them all a job together so that I get the best value out of purchasing online.

We typically use a lot of Cisco products at the same time. One of the things that are holding us back right now is the fact that, first of all, we're on the old version, version 4.10. The upgrade path towards CloudCenter Suite, version 5, is actually available as 5.1, which is targeted to be released this summer or early Q4. So we're still waiting on that. They have to port the old VM based on a Java-based application and database into the container. It has to migrate all of our stuff from the old system to the new one. So we have a lot of work to do there because they did a significant architecture change for that.

Once we've done that, the next thing missing for us is as follows. We have ACI, another product introduced exclusively with CloudCenter software. They have a system stack. In order to manage this stack, which we have deployed in at least three sites right now and have had to use, we'll call it the multi-site orchestrator. So that tool actually provisions the software networking points on every site. We will need CloudCenter to talk to that component instead of talking to an individual site. We are going to be using the multi-site capabilities of ACI. Typically this is a feature that will be added. I've already met with the Cisco team and they know about it. We've seen them two times to build up the backlog. That's how customer-driven Cisco is for us right now. We're able to meet them on a regular basis and share and build a backlog.

Those would be the things that I would like to see, but they're all already aware of them and it's stuff that's on the roadmap. For the rest, they're very responsive to their environment.

The older version of the product, which is 4.10, is pretty stable. We had the opportunity to talk with the business units and some of the engineers that are actually building up the product, formerly from CliQr. So what's nice is that anytime you have something that's not necessarily to our liking, provide as much feedback as you can. We're generating value for Cisco at the same time that they're fixing stuff for us. Going with the TAC endeavor, opening a TAC case with Cisco is one of the most joyful scenarios that you can actually use in IT that we have seen.

I have one example. I was at home around 10:30 PM, finished for the day, but there was something not working in a non-cloud environment. I'm not able to fix it, since it's not related to the product. I just opened a TAC request before going to bed, thinking that they'll ask for me tomorrow, but I was just going to do it that night. I got a call back from a guy in Sydney in about 10 minutes. I got an email saying, "Call me back." Okay, I get into a Webex call and by 11:00 everything was fixed and I knew how to do it. So the customer experience with Cisco support is amazing. 

Typically, the stability of the product is not an issue.

We're all set, at least at this moment. Obviously, the product is one thing and then there's what we're doing with it. So when I'm dealing with a new script and my script is not on par, this is a problem. CloudCenter does two things: it applies a lot of the operations with going into the cloud. You can also personalize for your specific application, your specific, company-owned stuff. In this area, we could be making errors. We don't have the QA that CloudCenter has in their product. So I think the product is stable. We're still making sure our stuff stays stable as well.

Scalability is actually pretty good. When we started using the product, we told them we would need a DR option and so they designed the out-of-region DR option for their database for us to be able to point our database. And so from a scalability perspective, it's very interesting. Now as of CloudCenter 5, they've reduced the complexity significantly inside the platform, so it's not Kubernetes-based and it's cogs, you don't necessarily need a per cloud Orchestrator like you needed before to deploy stuff based on customer feedback. And we're obviously not the only ones, but previously you needed to have some VM running into different clouds and they tried to reduce that. So we don't spend money just for being able to meet in the cloud. There are different components. As of CloudCenter Suite version 5, the scalability is based on Kubernetes, so if you need more compute in the workload manager, they'll just spawn more pods for the Action Orchestrator. So typically anything you would see with the containers is something that you'd be able to feel as to how scalable it is because typically the limit is how much compute you're going to be giving to your actual deployment. If you have the pleasure of installing the product, you have to make a choice at the beginning. The size of the workers and masters you want to give. That's typically where you do your first choice afterward. It's really based on the capacity of either your VMware Endpoint or other cloud endpoints and how much you can consume on their scalability.

This project is a little bit of my brainchild. I've worked on this project for the last two and a half years. We worked as a team with everybody else; I have other colleagues that have worked with us to actually build the core of this thing. In the end, the idea is really that once we've done the proof of concept with it, it was on a try and buy basis. Cisco has that type of offering. We're able to try this stuff before we buy it. In the end, we figured out that this was the way we wanted to go. I was a part of that process.

The initial setup was a little more complex than it is now with the CloudCenter Suite. It's is not so relevant to 4.7 now that 5 is out. Typically it's calling an old VA inside of VMware in our example. Once that's up, it's called the CloudCenter Screen Installer and you typically just give it credentials towards your vCenter or VMware environment and it will spin up the manager and worker images for the community's cluster and it will actually install everything for you.

So you just need to be patient, get a coffee and wait for it. Once it's up, you have to do additional configurations for your email, your SSL certificates. It can't automatically decide that for you. But otherwise, it's pretty much spun up by itself, so it's very easy. 

Upgrades are very simple as well because they've allowed us to get updates directly in the CloudCenter Suite manager. If you need to do an upgrade to your setup afterward, you just push a button and it rolls out the parts and retires the old ones. It's seamless and very simple compared to what we've done before.

When we started working on CloudCenter, the most difficult thing for us was knowing how to build applications. So the product getting installed and everything is stuff we've done for years. Getting the actual application profile built, however, was a little bit more complicated for us. We went to Work Space Infotech engineering here in the region of San Francisco. We asked them who can help us. Cisco found us a partner, who was able to provide us with the needed training or speeding up of our process and be able to have some valid service technologies.

I don't think we're in a position right now to be able to actually have a specific number for ROI. I wouldn't not share that in any case. We just finished putting out our third site. We got one client in production, another one's starting to go into it. We're still working on how we're going to actually be building the charge. Without talking about the specific ROI value add, however, the new team's working in that environment can deploy releases in CICD fashion, continually delivering new features. They have access to their environment. They have access to what they're deploying in DevOps from an organizational perspective. The transformation is probably the best value that we are driving within the organization. So typically it's not dollar signs per se, it's just the culture with an impact that we're trying to share. That's going to enable us in the future to be the company we want to be for our clients.

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.

I would advise someone considering this solution to contact Cisco and be briefed by their account manager so that you can see the full breadth of integrators that are available to help build it up fast. Don't try to take it upon yourself to actually learn all of this at a particular speed. Make sure you get the help that you need. Then you'll be able to be running fast instead of walking in six months. If you start crawling, start by walking and you'll be running in six months.

If you want to have a return on investment quickly, you'll want to be able to bring it to production and have people using it quickly.

Use whatever tools you can from the creator regardless of who it is. Make sure that it's a nice fit with what you're using it for. My advice would be to talk to the vendor. Talk to a Cisco representative and look at how it works. Make sure it integrates with what you have and in the end, make the decision for your company, not for whichever vendor you're buying it from. If it's good for your company, then go for it.

I would rate it an eight out of ten.

We're an implementor, and therefore we deploy this solution for our clients. As a use case example, one client is a service provider in Bolivia, and they deploy an ISP for their customers. They need a solution that includes the cloud server solution of Cisco with an ACI and an ASX-T solution. It basically becomes an in-house solution for the customer.

It's difficult to pinpoint the value, as clients don't have the same system before this implementation. However, they are very happy with the solution, as they are implementing it for a number of customers. It allows for new local services. Some companies, especially the public sector, prefer that the provider stores the information locally in the country, not outside the country. This particular option is of great value to them.

Cisco has a very high position in Latin America. They are very trusted. They have a long history of experience in the space, and that is important for the customers. Others, such as VMware or Juniper don't have the same level of recognition or the same reputation.

Cisco has a lot of published information and documentation that helps users understand the product and its offering very well.

Due to the branding reputation and field experience, the customers in our country are very confident about the Cisco cloud DC solutions however the competition is very hard and vendors like Huawei can provide the same solutions with a less expensive budget or another like VMWARE that have a stronger software based solution available to be mounted in any hardware.

The add value of Cisco is the integration through the layers of network, servers and software for virtualization where his powerful network solution is the core bit the budget may be an issue for the customers and could be opening an space to other vendors.

It would be ideal if there was more automation available within the product. I'm not sure if this is possible in the short term, however a lot of clients ask about it.

I've been dealing with the solution for about three years at this point.

The solution is very, very stable. We've only had good experiences with the stability aspect. It doesn't crash or freeze. It's very reliable.

The scalability is excellent. Cisco has a reputation for being a very easy product to scale. If a company needs to expand, it should be able to do so without issue.

We tend to work with large-scale organizations such as banks, service providers, and companies in the finance sector. I would estimate we have no more than five customers, however, they are all sizable.

We suspect that our clients will increase usage in the future. Many are developing cloud centers like this.

Technical support is okay. It could be a bit better. We don't typically contact technical support. There are some issues a Cisco tech can resolve, however, there's also a lot of public information for troubleshooting. If we have issues with the software version recommendations, we may reach out. We often need to try to seek out the most information possible before we reach out. 

As implementors, we work with a variety of solutions, for example, we also work with Lenovo and Aruba.

I don't participate directly in the implementation as I am more dedicated to the sales side of the business. However, it's my understanding that the initial setup is very easy and very straightforward. It's not complex. Our engineers, of course, have a lot of experience in the process.

The base implementation and the configuration can take about three or four months. After that, however, we spend about six months in the migration of services. The migration times vary and depend on the customer and what needs to be migrated over.

In general, an entire project may take about ten months or so.

We handle the implementation for our clients.

The product is very expensive.

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.

We are implementers, and we are a company specializing in professional services. We don't represent any vendor. We are multi-vendor. We provide professional services.

I'm on the sales side. I'm not sure which version of the solution our clients are using. The last implementation we did was for an operator in Bolivia. I would assume we deployed the latest version, however, I don't know the version number.

I would recommend the solution in general to the customers. However, companies should note that they need the best product, and they need the best services. It's very, very, very important that the planning, the design, the development, of the solution are all handled properly in order to avoid future problems during installation.

In general, I would rate the solution at a nine out of ten.

The solution needs to be more simple. 

Cisco CloudCenter is stable. 

Cisco CloudCenter's scalability is good. 

Cisco's support is the best. 

Positive

The tool's setup was complex. 

The tool's pricing is expensive. 

I would rate Cisco CloudCenter a seven out of ten.