We are a solution partner and have existing customers. I'd rate the solution to others. They should buy it. It's very simple for modern infrastructure needs. I'd rate the solution ten out of ten.
System Engineer at a non-tech company with 10,001+ employees
Real User
2020-04-14T06:13:00Z
Apr 14, 2020
For standard use it is quite easy to use, but for more complex tasks it's definitely more complex to use. An example of a simple task is deploying a new server, while a complex task would be configuring a bucket or another repository. Overall, it's easy to use. You need to have a clear idea of what you are doing before creating blueprints in Calm. It is a really good solution for doing simple tasks, but it's not a good solution for complex tasks. But it can definitely save you a lot of time. In terms of the solution's abilities when it comes to team collaboration, our team is really small; we are three people. It's quite easy for us to communicate and to tell each other what we are doing.
Tech Lead Platform Services | Infrastructure Consultant at a logistics company with 1,001-5,000 employees
Real User
2021-10-25T10:29:00Z
Oct 25, 2021
It's very important to think ahead about what your automation strategy will look like. You should really think about creating reusable components and also have good source control and a CI/CD strategy. If you start building without thinking about these things, you will have to do a lot of rework and re-engineering to be able to scale up. In terms of Calm unifying container and virtual machine automation and orchestration in a single orchestration platform, we're not doing containers yet, only tenants. But in the future, I expect it will do so because our next step we'll be looking into container workloads. But that's not where we are for now at Vopak. Similarly, we haven't used Calm’s AIOps and automation capabilities.
Leader of Environments and Automation at a financial services firm with 1,001-5,000 employees
Real User
2021-04-22T15:04:00Z
Apr 22, 2021
Anyone who is looking to implement Calm has to sit down and put forward a vision. If they're just blindly thinking, "Here's an automation solution. We'll bring it in and it will magically solve all our problems," that is not true. It requires some amount of initial design thinking. We actually went through a workshop. We specifically sat down and said, "Here's what Calm is offering us and here's how we will fit it into the existing pipelines in our ecosystem. We were very clear, in those initial few months, about what we were trying to achieve. That really helped us in the long run. There are two things we have learned in this entire process. One is to look at the software and figure out what gap it fills, rather than trying to make one tool solve all of our problems. We were very cognizant of that from the beginning and it has worked out nicely. The second thing is that while we have focused heavily on one particular use case to make it production-ready, we have not invested enough time in exploring more of what Calm does. We know blueprints and automation, and we know runbooks, but we haven't fully explored everything that's available. We'll have to put more effort into exploring it further. We are currently using the solution's one-click self-service feature in a proof of concept. We are looking to create marketplace items to start using it more. We expect it will help simplify our operations. Once we give that one-click to our end users, they won't have to create a service desk ticket, and that ticket won't have to go through different processes and then reach the tech team so that it can stand something up. If the end-user needs something they will be able to click a button to get their environment and it will be done in 10 minutes. That would be in place of logging a ticket, that ticket going to the service desk, the service desk figuring out which team to assign it to, that particular team prioritizing it, and then actually doing the work. It could be that the work, even if done manually, would only take one hour, but the entire process could take a week or two weeks. Every organization will have its own set of tools. It has been interesting to see how Calm fits into ours. I don't believe there is a single solution that will solve all of the problems, but the way we have leveraged Calm is to make good use of its abilities to fill gaps inside of our automation ecosystem. It required an initial vision and design for how we were going to fit Calm into our pipeline. It did a really nice job of fitting into our ecosystem. We did not have to go out of our way to redo or reinvent the wheel to get Calm to work in our environment. It nicely fit into our existing pipeline where there were gaps. That is where I rate Calm highly because it's very flexible enough to fit into an existing ecosystem. If we had no existing tools—if we did not have Azure DevOps and Octopus Deploy or anything else—and we just had Calm, I don't think that Calm would be able to solve all of the problems. We would have to look for additional tools to fill gaps. In our case, it worked well because we had tools that were already doing a good job, but there were gaps. Calm came in and filled all those gaps. It has acted as a single orchestrator and it is able to orchestrate multiple other orchestrators. It has tied everything together.
Project Manager at a healthcare company with 201-500 employees
Real User
2020-09-30T08:03:00Z
Sep 30, 2020
My advice is "use it." To use Calm, the precondition is that you have Nutanix. To me it doesn't make sense to have Nutanix on-premise and then not use Calm. Then you would have to use SaltStack or Chef or whatever other management software exists for managing virtual machines or physical machines. If you go with Nutanix, it makes really sense to use Calm. SaltStack and Ansible are also good, but it doesn't make sense to use them when you have Calm. With Nutanix you have one platform where you can manage everything. Calm gives you a lot of possibilities because you can script and easily integrate and control the whole Nutanix cluster with APIs. And you can easily integrate other services because you have the ability to call Python scripts very easily. For us, it was very easy because we didn't have a lot of existing scripts. Other companies that have a lot of Salt scripts or a lot of Ansible scripts have to recreate them in some way. So we were in a good situation. We now have 14 blueprint templates, and still growing. We are coming from the Citrix XenServer platform. We are not automatically creating a blueprint. It's ongoing. We had a lot of virtual machines on the Xen platform, and we have moved them over, but we don't automatically have a blueprint when we do. You must create the blueprints. We do them one-by-one. When we touch a system again, we create the blueprint for it. That way we can scale out, scale in, and make test systems. There is a template for creating a machine, and then you manage that machine with this template. But when you have machines from another platform, like the XenServer virtualization platform, you can move it over, because Nutanix is also a virtualization platform for running VMs. But then you don't automatically have a blueprint, so you have to start a new project to make these blueprints. The strategy is that we will have all the code for our infrastructure so that we can build all our system out of blueprints. I cannot say Calm is providing centralized control of all our applications because we have some legacy systems. We have IBM iSeries, which is another technology. But with Calm we can centralize all our x86 machines. It's still early time and there is room for improvement. I give Calm a nine out of 10. I cannot give it a 10 because other platforms are also really good. Ansible and SaltStack are also powerful. It's more an issue of strategy and the fact that it is very easy to use. It's not a complex tool. They make it easy to use. Other frameworks are more complex to use, but may also be more powerful. But for our purposes, it fits exactly what we need. We haven't been blocked from doing anything we need to do with Calm. We haven't had any showstoppers. Compared with other tools, Calm is newer and the scope of what you can do with it is still growing. They improve things. They make it easier to handle.
Learn what your peers think about Nutanix Cloud Manager (NCM). Get advice and tips from experienced pros sharing their opinions. Updated: December 2024.
Head of Operations at a university with 1,001-5,000 employees
Real User
2020-06-18T08:15:00Z
Jun 18, 2020
The biggest lesson I've learned using this solution is how easy it is to empower users to achieve what they need to achieve. Without this, it would be very hard to build the trust up and allow our academics to do what they need to do. In our case, Calm doesn't help us to implement standardization across our organization because the research is usually quite specific. The types of VMs that they would spin up would all be slightly different. Some might have much bigger storage requirements, some might have higher RAM requirements, and some might need to be quite low compute but for longer periods. It does tend to vary quite a lot. But on the flip side, it allows them to all work the same way so they're not going off and burning money in public cloud environments. When we first got it, it probably would have been a five out of 10 because it wasn't the easiest to build the initial blueprints. Now, we're certainly up to an eight. There's always room for improvement with something like this.
Nutanix Cloud Manager (NCM) is a cloud management tool that drives consistent governance across private and public clouds for its users. The solution brings simplicity and ease of use to managing and building cloud deployments by providing a unified multicloud management that addresses common cloud adoption challenges. Nutanix Cloud Manager offers four key value drivers:
Intelligent operations: They include monitoring, insights, and automated remediation.
Self-service and orchestration:...
Overall, I rate the solution a ten out of ten.
We are a solution partner and have existing customers. I'd rate the solution to others. They should buy it. It's very simple for modern infrastructure needs. I'd rate the solution ten out of ten.
For standard use it is quite easy to use, but for more complex tasks it's definitely more complex to use. An example of a simple task is deploying a new server, while a complex task would be configuring a bucket or another repository. Overall, it's easy to use. You need to have a clear idea of what you are doing before creating blueprints in Calm. It is a really good solution for doing simple tasks, but it's not a good solution for complex tasks. But it can definitely save you a lot of time. In terms of the solution's abilities when it comes to team collaboration, our team is really small; we are three people. It's quite easy for us to communicate and to tell each other what we are doing.
It's very important to think ahead about what your automation strategy will look like. You should really think about creating reusable components and also have good source control and a CI/CD strategy. If you start building without thinking about these things, you will have to do a lot of rework and re-engineering to be able to scale up. In terms of Calm unifying container and virtual machine automation and orchestration in a single orchestration platform, we're not doing containers yet, only tenants. But in the future, I expect it will do so because our next step we'll be looking into container workloads. But that's not where we are for now at Vopak. Similarly, we haven't used Calm’s AIOps and automation capabilities.
Anyone who is looking to implement Calm has to sit down and put forward a vision. If they're just blindly thinking, "Here's an automation solution. We'll bring it in and it will magically solve all our problems," that is not true. It requires some amount of initial design thinking. We actually went through a workshop. We specifically sat down and said, "Here's what Calm is offering us and here's how we will fit it into the existing pipelines in our ecosystem. We were very clear, in those initial few months, about what we were trying to achieve. That really helped us in the long run. There are two things we have learned in this entire process. One is to look at the software and figure out what gap it fills, rather than trying to make one tool solve all of our problems. We were very cognizant of that from the beginning and it has worked out nicely. The second thing is that while we have focused heavily on one particular use case to make it production-ready, we have not invested enough time in exploring more of what Calm does. We know blueprints and automation, and we know runbooks, but we haven't fully explored everything that's available. We'll have to put more effort into exploring it further. We are currently using the solution's one-click self-service feature in a proof of concept. We are looking to create marketplace items to start using it more. We expect it will help simplify our operations. Once we give that one-click to our end users, they won't have to create a service desk ticket, and that ticket won't have to go through different processes and then reach the tech team so that it can stand something up. If the end-user needs something they will be able to click a button to get their environment and it will be done in 10 minutes. That would be in place of logging a ticket, that ticket going to the service desk, the service desk figuring out which team to assign it to, that particular team prioritizing it, and then actually doing the work. It could be that the work, even if done manually, would only take one hour, but the entire process could take a week or two weeks. Every organization will have its own set of tools. It has been interesting to see how Calm fits into ours. I don't believe there is a single solution that will solve all of the problems, but the way we have leveraged Calm is to make good use of its abilities to fill gaps inside of our automation ecosystem. It required an initial vision and design for how we were going to fit Calm into our pipeline. It did a really nice job of fitting into our ecosystem. We did not have to go out of our way to redo or reinvent the wheel to get Calm to work in our environment. It nicely fit into our existing pipeline where there were gaps. That is where I rate Calm highly because it's very flexible enough to fit into an existing ecosystem. If we had no existing tools—if we did not have Azure DevOps and Octopus Deploy or anything else—and we just had Calm, I don't think that Calm would be able to solve all of the problems. We would have to look for additional tools to fill gaps. In our case, it worked well because we had tools that were already doing a good job, but there were gaps. Calm came in and filled all those gaps. It has acted as a single orchestrator and it is able to orchestrate multiple other orchestrators. It has tied everything together.
My advice is "use it." To use Calm, the precondition is that you have Nutanix. To me it doesn't make sense to have Nutanix on-premise and then not use Calm. Then you would have to use SaltStack or Chef or whatever other management software exists for managing virtual machines or physical machines. If you go with Nutanix, it makes really sense to use Calm. SaltStack and Ansible are also good, but it doesn't make sense to use them when you have Calm. With Nutanix you have one platform where you can manage everything. Calm gives you a lot of possibilities because you can script and easily integrate and control the whole Nutanix cluster with APIs. And you can easily integrate other services because you have the ability to call Python scripts very easily. For us, it was very easy because we didn't have a lot of existing scripts. Other companies that have a lot of Salt scripts or a lot of Ansible scripts have to recreate them in some way. So we were in a good situation. We now have 14 blueprint templates, and still growing. We are coming from the Citrix XenServer platform. We are not automatically creating a blueprint. It's ongoing. We had a lot of virtual machines on the Xen platform, and we have moved them over, but we don't automatically have a blueprint when we do. You must create the blueprints. We do them one-by-one. When we touch a system again, we create the blueprint for it. That way we can scale out, scale in, and make test systems. There is a template for creating a machine, and then you manage that machine with this template. But when you have machines from another platform, like the XenServer virtualization platform, you can move it over, because Nutanix is also a virtualization platform for running VMs. But then you don't automatically have a blueprint, so you have to start a new project to make these blueprints. The strategy is that we will have all the code for our infrastructure so that we can build all our system out of blueprints. I cannot say Calm is providing centralized control of all our applications because we have some legacy systems. We have IBM iSeries, which is another technology. But with Calm we can centralize all our x86 machines. It's still early time and there is room for improvement. I give Calm a nine out of 10. I cannot give it a 10 because other platforms are also really good. Ansible and SaltStack are also powerful. It's more an issue of strategy and the fact that it is very easy to use. It's not a complex tool. They make it easy to use. Other frameworks are more complex to use, but may also be more powerful. But for our purposes, it fits exactly what we need. We haven't been blocked from doing anything we need to do with Calm. We haven't had any showstoppers. Compared with other tools, Calm is newer and the scope of what you can do with it is still growing. They improve things. They make it easier to handle.
Take a tour for yourself online: www.nutanix.dev You shoud REALLY try this. It is just 5 minutes of your time!
The biggest lesson I've learned using this solution is how easy it is to empower users to achieve what they need to achieve. Without this, it would be very hard to build the trust up and allow our academics to do what they need to do. In our case, Calm doesn't help us to implement standardization across our organization because the research is usually quite specific. The types of VMs that they would spin up would all be slightly different. Some might have much bigger storage requirements, some might have higher RAM requirements, and some might need to be quite low compute but for longer periods. It does tend to vary quite a lot. But on the flip side, it allows them to all work the same way so they're not going off and burning money in public cloud environments. When we first got it, it probably would have been a five out of 10 because it wasn't the easiest to build the initial blueprints. Now, we're certainly up to an eight. There's always room for improvement with something like this.