We use it to optimize costs and resource efficiency across our environments and present infrastructure change requests to the business.

We had a lack of knowledge about things at our product level, and Turbonomic helped us resolve that. From an integration perspective, it also helped us find connectivity between our gateway tool products.

When it comes to optimizing costs and resource efficiency, before Turbonomic, we would add big, expensive storage and scale up across the tenant. Now, we are able to allocate the resources we need. We can also justify to the business, based on usage, why we are going with those resources. We have all kinds of proof to explain to the business how we are scaling down.

The visibility and analytics into our environment’s performance, from the APM down to the infrastructure, help us illustrate and clarify for the business the types of infrastructure changes we are suggesting. And they give us approval. Although we can collect the same information from Azure, Turbonomic is very user-friendly, and we can also automate notifications.

Regarding policy implementation, that can be implemented by a skilled engineer in five to 10 minutes. But if that same task is assigned to a new engineer who is not familiar with Turbonic, he would have to reference the previous document and the previous policy. Implementing the same thing would take that new engineer 15 to 20 minutes.

I like the analytics that help us optimize compatibility. Whereas Azure Advisor tells us what we have to do, Turbonomic has automation that actually does those things. That means we don't have to be present to get them done and it simplifies our IT engineers' jobs.

The platform is continually updated with new features. If they would educate their customers to understand the latest updates, that would help customers be more satisfied with the updates and push them into their environments.

Also, there are a lot of features that are not available in Turbonomic. For example, PaaS component optimization and automation are still in the development phase. If they could provide those enhancements, that would be really great. For example, we are spending a lot of time on Azure Databricks, exploring it and trying to do cost optimization as well as setting up the policies. If Turbonomic could help us understand how much the Databricks CPU is using per instance or workspace, that would help us optimize it, scale it according to our business requirements, and decrease costs.

We have been using IBM Turbonomic in the cloud for the past year.

The stability depends on how you set up the policies and logic. In general, Turbonomic is stable.

It's scalable because we are hosted in the cloud. We can expand it vertically.

I'm an open-source guy, so I used a lot of open-source code to do the cost optimization through scripting. One reason Turbonomic was our first choice was that our on-prem team was already using it.

We have it set up in the cloud and on-premises. I wasn't involved in the initial deployment as it was already on-prem. We just expanded it to the cloud. That operation was very easy. We just opened the access to the cloud. That was it.

We have a test environment, so we apply things on the test environment and make sure our policies are having the proper effects and are working perfectly. We can work on an environment-by-environment basis.

There is not much maintenance involved, other than applying patches.

There are a lot of options available, but compared to other products, Turbonomic has many features. Other products are at a more beginning stage.

When you do your initial assessment, you have to understand your business needs and then choose the product.

Initially, our use case was to reduce cloud spend. But Turbonomic is much more than just a reduction-in-cloud-spend tool. As we went on, it became more about optimizing applications and making sure that they function as expected, while reducing the cost of cloud resources. It became a question of how we make applications function properly, at speed, with the best cost possible, and without creating any risk for the application itself.

Turbonomic has shed light on processes, on how applications actually function for people. The folks in the IT organization still tend to build large, to oversize things, to make sure that their applications perform properly. Turbonomic sheds light on what could be a more efficient application and deployment.

We use it in a multi-cloud environment.

My favorite part of the solution is the automation scheduling. Being able to choose when actions happen, and how they happen, whether that be through an approval process during the workflow, or whether it be someone executing it on a weekend because they're working in their own environment.

We don't use Turbonomic for FinOps and part of the reason is its cost reporting. The reporting could be much more robust and, if that were the case, I could pitch it for FinOps. You might say that's a weakness, but it's not what it's supposed to do.

If it had the reporting, it would be a 10 out of 10.

I've been using IBM Turbonomic for four years.

Since we moved to the SaaS deployment, I haven't noticed any issues. About five years ago when I started evaluating it, there were some on-prem issues, but not with the SaaS solution.

Scalability is not a problem. If you need more, just buy more licenses and it expands. They monitor that and expand your instances. It's not something you need to worry about.

Their tech support is very responsive. They are part of IBM and not just Turbonomic anymore, so they've grown exponentially over time. But I found, in working with their engineers on the tickets we submitted, that they were very responsive, getting back to us as quickly as they could on the challenges we were having. They have been helpful.

We would go quarter-to-quarter and say, "Okay, go optimize our application environments." We could use Azure Monitor or a couple of other tools that aren't nearly as robust, and without knowing the impact, other than what Azure Monitor gives you. But Azure Monitor, which doesn't do memory metrics, would tell you, "You can reduce size by doing this," but maybe memory was the problem. Turbonomic is much more robust. Before using it, we were doing things in a very manual way.

The way I got Turbonomic through the door was by saying, "You want to have your entire staff clean up the cloud every quarter?"

The initial deployment is very straightforward. The Kubernetes stuff was a little beyond me because I'm not a Kubernetes person. But once we got somebody who knew Kubernetes involved, it was pretty straightforward. It takes less than a few hours and that's for an enterprise. It can be done very quickly.

We started with the solution on-prem, but I quickly moved it to the SaaS model because with on-prem there's a lot to manage. It's a Kubernetes cluster and you need a Kubernetes administrator. You have to have rights to it. There are a lot of other moving parts when you manage it yourself. Once you move to a SaaS-based solution, the burden of keeping the product upgraded and up to date is on Turbonomic. I don't want to manage updates and patches.

With the SaaS solution, there is no maintenance on our side.

Our internal resources worked with the Turbonomic team. After that, I turned over the application to the team that is going to be supporting the applications, because I have no insight into applications. That's not my role. Turbonomic is meant to be in their hands, not mine.

There were three to four people involved initially. Once you get it installed, you start bringing in your DevOps engineers to have them understand it, and they'll work with the application support people.

The team grows as large as it has to, depending on how many application teams and DevOps engineers you have. People can manage their applications or they can manage multiple applications. You can divide it up, so the teams vary in size. But it's always going to land as close to the application as it can, to get the right people to make the right decisions. If you're a very large organization, you don't centralize the product. It doesn't work well that way.

Everybody tells me the pricing is high. But the ROIs are great. Like any software, if it sits on a shelf and no one uses it, it's a waste of money. If you implement it and do the right things before you start using it, the ROI is very fast. And then you can justify the cost, because the ROI is very quick.

We had a couple of hiccups, but we planned for about a nine-month ROI, in the course of a three-year plan. If you put the resources into it and you dedicate the time to it, then ROI is very attainable. If you just let the product churn and tell you what's going on, and don't do anything, then you don't get ROI and don't actually reduce your cloud spend.

I looked at CloudHealth, Cloudability, and one other. We went with Turbonomic because of the intelligence engine. It uses AI to make determinations on data that's coming in at a faster pace than humans can comprehend. People can't monitor a thousand VMs and keep track of them on a daily, hourly, or minute-by-minute basis. With Cloudability, it's not done as efficiently and it's not done with AI. It has cloud-native optimization tools, and they're not as accurate. Turbonomic provides you with accurate, almost up-to-the-minute, information about your application performance, VMs, databases, and storage performance at a much faster pace than humans could ever do. That's why I liked it so much.

Turbonomic does give you visibility into your environment’s performance as well as analytics, from the application layer all the way down the stack. But it does not give you as much as others do. More specialized applications, like New Relic, go much deeper, but with those products, those features are an additional cost. How much is enough is what it really comes down to. How much monitoring and in-depth analytics do you need? Some applications need much more and some don't. If a website is running fine, don't worry about it. In that case, you just need to know the up/down status and that's it. If you're running database queries and things are running slow, you might need deeper analytics. Turbonomic doesn't do that.

Whenever we have a specific application that we need to go into deeper, we will use New Relic or SolarWinds or the like; a dedicated application performance monitoring tool. Turbonomic does have the ability to target apps, but we're not quite there yet.

Educate yourself on the product, as well as on the process. The process is even more important than the product because people need to understand that you're going to be making some changes to the environment. If they're resistant to that, then you're going to have challenges getting Turbonomic to be useful.

You not only need executive buy-in and senior leadership buy-in, you also need your engineers' buy-in. If your executives don't buy into it, your engineers certainly aren't going to. And even if your executives have bought into it, you still have to get the engineers on board because there are all kinds of ways not to do work.

And you have to understand your own company's processes around how to make changes to an environment. What is your change control process? Can you make changes in dev, test, and QA without a change ticket? How do you do production? Do you, in fact, do production?

I would recommend doing something like a workshop where you look at all the applications you're going to point Turbonomic at. Get each team together and explain to them how it's going to work and how it benefits them, as opposed to: "We bought a new product. You're going to use it. Deal with it." People like to know how it impacts their lives and why they're potentially doing more work. In the long run, it actually becomes less work. It's just hard to get past that point. In the movie "Cast Away" it was really hard for Tom Hanks to get past those waves. But once he got past them, he was fine. It's something like that, but not as dramatic; it's not that you're trying to save your life. But you have to explain to people why there's going to be some upfront work: to save them a lot of work on the back end.

In terms of the solution's visibility and analytics helping to bridge the data gap between disparate IT teams, we're working on that. Implementing Turbonomic is a journey. It's not "install it, and then it does what it does." You have to learn it and integrate it into your environment and your workflows. It does shed light on infrastructure and application teams having to work together, and that's a good thing. Application teams generally don't like infrastructure teams because they don't give them enough infrastructure. Infrastructure teams think the application teams complain too much. Turbonomic says, "Here is what you guys are doing. And here is how to get it done right. Work together," and everybody will be happy. That's more of a "people challenge" and less of a technology challenge.

But the visibility and analytics have not yet reduced our mean time to resolution. The solution hasn't had any impact on our application response time and it's not supposed to. Turbonics is supposed to change your resources based on your schedule, and you shouldn't notice it doing anything, except for the downtime that an application sometimes requires. It should be seamless.

Similarly, when it comes to helping our engineers focus on innovation and modernization, it's a work in progress. That's hard to quantify. It's our role, as architects, to help people do their jobs better and have more time to do innovation versus fixing. We are definitely spending less time worrying about application performance, because Turbonomic takes care of that. But in terms of innovation, I have no way to quantify that. We have people learning it and using it, but are we innovating better? I hope so.

We did some digging into Kubernetes and the solution does show you some good insights there, and it may have come a little farther in that regard since the last time I was hands-on with it. It gave us good insight into what our Kubernetes clusters were doing. Since then, we have moved on to doing more IaaS-based stuff.

Overall, it's the best product for APM that I've seen.

We don't use the full functionality of Turbonomic because our company is subject to regulations around making those changes. Some of that functionality would require going through a change process. We've been using it more for heuristics and analysis on the right-sizing of our VMs and VMware.

At the resource level, Turbonomic has enabled us to right-size our converged infrastructure to a more appropriate level. Instead of using 12, we can use 10. It has been really good in helping us size the environment for our compute.

Another benefit is that it has helped reduce performance degradation. That happens at the application layer sometimes, and then a reset happens and everything is fine again. I would estimate it reduces performance degradation by 10 percent.

It has helped us streamline a lot of those applications. We're leveraging faster configurations on our VMs. Those systems that are being virtualized are operating with better peak performance whenever it's required, and that's what Turbonomic really does. It gives us insight into those peaks and valleys that we tend to go through.

The solution has also reduced resource congestion and starvation. For us, it's always a matter of refreshes. I like the forecasting tool that Turbonomic has where you punch in what you have today and it assesses the history of that setup. Then you can say, "I want to replace it with a snazzy, new compute/storage component," and it will provide a recommendation. That is a very good forecasting tool.

A lot of the features in Turbonomic are valuable. The placement features are really good, allocating the load of VMs between systems within a VMware cluster. The notifications saying, "This is a corrective action," even though some of them can be automated, are always welcome to see. They summarize your entire infrastructure and how you can better utilize it. That is the biggest feature.

It also offers hot-memory increases, whenever they're applicable.

In addition, it gives us visibility and analytics into our environment, to a limited point. It does SQL components and, likely, in the newer versions, it has more of that layer. But, we're using it at the VMware level. We have tie-ins to our Pure Storage, and we're using it for discovery of that, as well as of our Cisco UCS for compute. It does delve down into the infrastructure level, if you allow it to do so.

Those analytics are important for understanding, historically, what sort of load a system handles over a certain period of time. If you have a system that is running efficiently and fine, but there is a year-end or month-end or quarterly-end report that needs to run, Turbonomic allows us to anticipate our requirements. For example, when those reports come up, it might be one of those times when we need to bump up the memory and CPU for that cycle. Turbonomic is very good for that aspect, from the standpoint of productivity. It does a lot of recommendations for placement, although we don't enable that in our environment because it's controlled. But it has a lot of good features.

Before IBM bought Turbonomic we had already been using it for four years.

The stability has been pretty good.

One thing of note is that we did go through an upgrade from one Turbonomic appliance to a newer version and, unfortunately, a policy that was created and that was meant to be kept disabled, was transferred over and enabled. That wreaked havoc on our VMware landscape. It started making changes to servers, such as memory-up and memory-down changes, and that caused a big kerfuffle.

Before IBM bought it, the support was fantastic. After IBM bought it, the support became very disappointing.

When Turbonomic was under its own flag, they would hold our hands every step of the way. That included everything from proactive upgrades to the appliance, to recommendations, and best fits for us.

When IBM bought it, we renewed the product for one more year. When I had a license that had expired, I was having such difficulty doing anything on their portal or getting support on the product. Ever since IBM took it over, it doesn't look like we have been getting the support we used to under Turbonomic.

We did not have a previous solution.

I'm the one who deployed the virtual appliance, connected it to our vCenter, and did the add-ons for Pure Storage and Dell storage. The setup, back then, was pretty straightforward. The complexity came in when we started having to use policies and rules. That's where we got a lot of help from Turbonomic.

The full deployment from end to end, with policies, took just over a couple of weeks. We have under 10 users of the product.

I did the deployment of the appliance by myself while the configuration of the group policies and rules was done with Turbonomic's assistance. There were two of us from my company who were focused on the deployment and we had two or three individuals on it from Turbonomic.

I consider the pricing to be high.

We looked at one or two other solutions, but those would probably have been renamed or rebranded since then, just like Turbonomic.

My advice would be to come up with an agreement, in writing, that support on the product will have quarterly touch-point meetings to discuss what's new, what has changed, and what upgrades there are. Those quarterly touchpoints would be an ask, for me, if I had to buy the product again. For the initial deployment, I would recommend some sort of professional services engagement from IBM, just to make sure that you're utilizing it to its best potential.

If you're looking into Turbonomic but already have a process for optimizing your environment and for monitoring, I would suggest doing a comparison between what you have today and what Turbonomic can do. Do a like-for-like on the functions you use today and ask if Turbonomic does the same and whether it does it better. Also, you need to look into the licensing model. Be ready with those questions. You want to make sure Turbonomic will be a suitable replacement and not fall short because your current tool does more.

In terms of understanding when a performance risk exists, the solution does help to a certain point. It says "increase," or "decrease." But it doesn't give explicit information as to why. It doesn't say, "This system has been running hot for X number of days or weeks." Those kinds of details aren't there. It just provides a recommendation.

I would rate the potential of Turbonomic as a seven out of 10. I love the fact that there is slight automation, if you let it do that automation, and the whole forecasting piece is really good. It's a pretty good solution.