What is our primary use case?
We are currently using Calm to automate our infrastructure and platform provisioning, including going into infrastructure-as-code, standing up environments, and triggering deployment processes.
We aren't looking for it to automate application management to a single platform because we are spread across Azure Pipelines and Octopus Deploy and multiple methods of automating our application deployments. In the last year, we have standardized what we are doing with Calm in terms of infrastructure automation. We haven't stepped into application life cycle management with Calm. We are mostly focusing on leveraging Calm as our platform and infrastructure provisioning orchestrator.
It is based on-premises on our Nutanix cluster.
How has it helped my organization?
The Runbook automation makes it easy because we can do a lot of operational tasks in a single click. Our hope in the future is that we can tie it into our AI operation software, wherein these runbooks can be called through APIs and that it can lead us to self-healing. But it really helps us in reducing manual intervention and manual effort in operations. We've just been proving it out in certain cases and it looks very promising. We haven't set it up fully and gone to the extent of fully automating all of our operations yet.
The beauty of Calm is that although it's built into Nutanix, it is not just for automating what's in Nutanix. We've also used Calm to trigger API calls to external systems and services, to orchestrate other automation. For example, we use F5 for load balancing. Using Calm, we are able to call APIs on F5 to configure load balancing for our applications. And from Calm we are also able to trigger Octopus Deploy, which we use for deployment automation processes. Overall, we are able to configure and trigger other orchestration or automation tools from within Calm. It creates a line, nicely.
We also use Calm with Azure DevOps, which is our central orchestrator. That is where we have our CI/CD pipeline. Azure Pipelines in Azure DevOps, triggers Calm for environment provisioning and then comes back and executes test automations within Azure DevOps pipeline.
Using them together absolutely helps speed up the integration and delivery of applications in two specific ways. One, as I said, is that we were able to pull in Calm and tie it into our existing pipeline. We did not have to retrofit or build pipelines from scratch just for Calm. It naturally fit into our pipelines. The second way is that we also use Azure DevOps as our source control and repository tool. We are able to store infrastructure configurations as code inside Azure DevOps and Git repositories. When Azure DevOps triggers Calm, we are able to pull configurations from the source repository and pass it on to Calm, so that our provisioning is truly from the configurations that are stored in the source repository. We are able to really perform infrastructure as code.
As an example, we recently had to stand up an environment for a new project and we were able to do that in under two weeks, including deploy and deliver. In the past, that same project would have taken two or two and a half months. And after completing that initial end-to-end process in two weeks, we can just clone and replicate it multiple times. So there was the initial decrease in deployment time, and then, depending on how many times we replicate that environment, we are gaining more and more savings.
We also make use of the solution’s support for scripts and API. The initial hours of setting them up created additional overhead, but once that was done, because of how well it works with APIs and scripts, it definitely reduced manual effort, over time. Say we spent 10 hours setting up a script or an API call. Every single time that particular application is deployed, if that script saves us one hour, we have to deploy it only 10 times to start getting a return on investment. We deploy many of our applications many times, so our savings are exponential.
What is most valuable?
The blueprints and templates are very nice and easy to use. They are very valuable because we can configure the entirety of an environment as a template and reuse it multiple times. In our delivery process, we have multiple environments going all the way to production, including dev, test, staging, and performance environments. We have to stand up the same environment again and again, before taking it all the way to production. Having a template, which is fully configurable through parameters, is really useful. And now that we have those templates and we can stand them up fairly easily, we are also able to decommission an environment when we don't need it because we can, again, click a button and stand it up fairly easily and it becomes a standard process.
What needs improvement?
One thing that comes directly to mind is how they manage version control. I would love to see Calm create a built-in source control feature, one that we could tie into a repository and it would self-manage changes in versions. All the version control is built within Calm right now. I would love to see that integrated with an external repository and make it easy to tie it into GitHub or Git repositories.
For how long have I used the solution?
I have been using Nutanix Calm since early 2020, which makes it a little over a year now.
What do I think about the stability of the solution?
We have had issues with bugs or version mismatches, more so because Calm is part of the bigger Nutanix ecosystem. If someone upgrades AOS on one side, there can be a mismatch with the version of Calm we have. Nutanix has this huge ecosystem and Calm is just a virtual layer working with Prism and AHV underneath.
This past week, we had a bug. After working with Nutanix support we figured out that we had to upgrade AOS to get rid of the bug.
Overall, Calm has been solid at what it does. We are early in the intake process. We are not fully mature with Calm. When it comes to issues and bugs, there is a solid path of escalation and we get good support. We feel comfortable where we are right now and we also feel Calm has been solid in what we have been able to achieve so far.
What do I think about the scalability of the solution?
It's a great technology and it's part of the larger ecosystem which scales really real. Because of how it is tied into the Nutanix ecosystem, I am confident that scalability, and maintainability, will be very easy and smooth in the long term.
How are customer service and technical support?
A lot of our technical support comes directly through our technology partner, Reliant, whose consultants are certified by Nutanix. Reliant will work with someone from Nutanix professional services, and that person from Nutanix has been working with us over the past two years during our journey.
When we have to go beyond them and raise a support ticket with Nutanix support, they have been very good as well. Their overall engagement model is good, and we have multiple ways of reaching out and getting support.
Which solution did I use previously and why did I switch?
For infrastructure automation, we had no solution. In the past, one of our teams had tried vRA on top of VMware to try to achieve automation, but it wasn't quite successful. Up until Nutanix, we had no automation, other than a little bit of automation to assist a group of individuals writing a PowerShell script. We never had this level of focused, end-to-end automation.
The reason we picked Calm is that it's tied into the Nutanix ecosystem. We are leveraging everything that comes out-of-the-box from Nutanix as a solution, to take full advantage of the full capabilities of the ecosystem.
How was the initial setup?
Setting up the Calm module and getting it running was pretty straightforward. We got that done in under two hours.
But if we are talking about setting up something within Calm, like a blueprint or a runbook, if someone is completely new to Calm it takes about two to three weeks to get used to it and to set everything up. After that, it becomes very easy.
Calm has an initial learning curve to get used to the modules and how Calm ties into the rest of the Nutanix ecosystem. Once we got through that initial learning curve, it became fairly simple. We have a choice of either using PowerShell or Python to do our custom scripting and the UI itself is intuitive enough. My team of sys admins and automation specialists took about two weeks to get used to it, before they could start making good use of it. And anyone new who starts to use it takes an initial two to three weeks period to really understand the implementations. From there on, it's just organic growth and knowledge.
When we brought in Calm we were going through a full infrastructure modernization project which included bringing in Nutanix and all of its components. We had professional services from Nutanix take us through all of this, and we had a plan upfront. Calm was coming in as part of the whole Nutanix ecosystem. The Nutanix professionals helped to the point that we just had to install the modules, enable access, and we were done.
In terms of our staff involved in the deployment, the entire team was consulted and informed, but there was just one person required. Because it's on our servers, Nutanix professional services needed one person from our side in system administration to give them the necessary access and to work with them in setting it up.
We don't maintain a lot so that doesn't require much staff time for it. There are regular updates but they aren't too frequent. It probably takes one person about half an hour in a week to maintain, which is very negligible. We are going through a huge intake process right now and that means most of the effort involved is in getting everything automated. There's very little maintenance effort.
We have five or six individuals trained and using it actively. We plan to get up to 15 individuals trained and actively developing blueprints and runbooks in Calm. When it comes to consumption, I'm hoping we can get up to 50 users using the self-service feature in the next year. From there, we'll have to see how much more we can expand.
What about the implementation team?
We worked with Nutanix professional services, but we assigned this whole project to Reliant, our technology partner. Reliant, in turn, engaged Nutanix professional services. We had technology consultants from both Reliant and Nutanix helping us on this.
Reliant has been a really good partner. They've done most of the heavy lifting in getting Nutanix in and setting it up. It's a strategic partnership and it has worked really well for us.
What was our ROI?
We haven't calculated any kind of ROI number. Anecdotally, there are two spaces where we expect to be seeing ROI. One is on the provisioning side, because everything will be automated and that will result in a lot of reduction in manual efforts. There will also be a lot of reduction in the overhead costs of the ticketing process and assigning of tickets.
The other main area should be that, because we can spin up and spin down platforms and infrastructure on-the-fly, there will be a reduction in the load we have in terms of static environments, meaning things that were stood up but never decommissioned.
What's my experience with pricing, setup cost, and licensing?
The pricing is fair. We got a really good price to start with. We'll have to see over the years how it turns out.
In terms of additional costs to their standard licensing fees, there's the effort involved in training and upskilling employees to be able to use Calm. That's an indirect cost. Regardless of what new technology we would bring in, we would have to pay that cost. That cost has been minimal. The Nutanix University helps a lot as it has a lot of training programs, and the software itself is intuitive enough. The cost is well worth it.
Which other solutions did I evaluate?
There were a couple of solutions we are looking at, and we are even evaluating some right now. In the past, we looked at vRA, because we were on VMware, but from the time we switched to Nutanix, we focused heavily on Calm, especially because it comes out-of-the-box from Nutanix.
vRA and Calm are apples and oranges because they have different underlying technologies and different ways of handling automation. I don't think it would be a fair comparison. We didn't really put any effort into trying to compare them.
What other advice do I have?
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.
Which deployment model are you using for this solution?