Cisco CloudCenter Reviews

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.