IBM Turbonomic Reviews

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.

Positive

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.

Negative

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.

The product is looking at things in the cloud or in Azure and it gives us reports of things that it could possibly do in Azure, however, we mainly use it on-prem for our VMware environment. 

The use case for Turbonomic really began with us trying to reduce a lot of the costs, and a lot of the CPU, and RAM. We had an idea that we could possibly save some money, however, it was theoretical and something that we really couldn't put our hands on or touch. Turbonomic was the solution that really gave us a tangible way of being able to see what we could do and to see those changes made in an efficient manner while also having the reports behind it to back up the changes.

That, and the placement that it does in VMware, where it places machines where it best sees fit on different hosts, is how we use the product. 

We've been able to separate different applications into groups in Turbonomic and see how many resources they take. We can see what resources we need and which resources may need to be increased or decreased in certain places. The grouping and analytics enable me to be able to take everything back to my application owners and say to them "your application or your list of servers did this type of work in our environment." It really gives me an opportunity to be able to show a cost. I can show how many resources we're using and how many need to be used.

It's been a very good solution. The reporting has been very, very valuable as, with a very large environment, it's very hard to get your hands on the environment. Turbonomic does that work for you and really shows you where some of the cost savings can be done. It also helps you with the reporting side. Me being able to see that this machine hasn't been used for a very long time, or seeing that a machine is overused and that it might need more RAM or CPU, et cetera, helps me understand my infrastructure. The cost savings are drastic in the cloud feature in Azure and in AWS. In some of those other areas, I'm able to see what we're using, what we're not using, and how we can change to better fit what we have.

It gives us the ability for applications and teams to see the hardware and how it's being used versus how they've been told it's being used. The reporting really helps with that. It shows which application is really using how many resources or the least amount of resources. Some of the gaps between an infrastructure person like myself and an application are filled. It allows us to come to terms by seeing the raw data.

This aspect is very important. In the past, it was me saying "I don't think that this application is using that many resources" or "I think this needs more resources." I now have concrete evidence as well as reporting and some different analytics that I can show. It gives me the evidence that I would need to show my application owners proof of what I'm talking about.

In terms of the downtime, meantime, and resolution that Turbonomic has been able to show in reports, it has given me an idea of things before things happen. That is important as I would really like to see a machine that needs resources, and get resources to it before we have a problem where we have contention and aspects of that nature. It's been helpful in that regard.

Turbonomic has helped us understand where performance risks exist. Turbonomic looks at my environment and at the servers and even at the different hosts and how they're handling traffic and the number of machines that are on them. I can analyze it and it can show me which server or which host needs resources, CPU, or RAM. Even in Azure, in the cloud, I'm able to see which resources are not being used to full capacity and understand where I could scale down some in order to save cost. 

It is very, very helpful in assessing performance risk by navigating underlying causes and actions. The reason why it's helpful is because if there's a machine that's overrunning the CPU, I can run reports every week to get an idea of machines that would need CPU, RAM, or additional resources. Those resources could be added by Turbonomic - not so much by me - on a scheduled basis. I personally don't have to do it. It actually gives me a little bit of my life back. It helps me to get resources added without me physically having to touch each and every resource myself.

Turbonomic has helped to reduce performance degradation in the same way as it's able to see the resources and see what it needs and add them before a problem occurs. It follows the trends. It sees the trends of what's happening and it's able to add or take away those resources.

For example, we discuss when we need to do certain disaster recovery tests. Over the years, Turbo will be able to see, for example, around this time of year that certain people ramp up certain resources in an environment, and then it will add the resources as required. Another time of year, it will realize these resources are not being used as much, and it takes those resources away. In this way, it saves money and time while letting us know where we are.

We've saved a great deal of time using this product when I consider how I'd have to multiply myself and people like me who would have to add resources to devices or take resources away. We've saved hundreds of hours. Most of the time those hours would have to be after hours as well, which are more valuable to me as that's my personal time.

Those saved hours are across months, not years. I would consider the number of resources that Turbonomic is adding and taking away and the placement (if I had to do it all myself) would end up being hundreds of hours monthly that would be added without the help of Turbonomic. 

It helps us to meet SLAs mainly due to the fact that we're able to keep the servers going and to keep the servers in an environment, to keep them to where (if we need to add resources) we can add them at any given time. It will keep our SLAs where they need to be. If we were to have downtime due to the fact that we had to add resources or take resources away and it was an emergency, then that would prevent us from meeting our SLAs.

We also use it to monitor Azure and to monitor our machines in terms of the resources that are out there and the cost involved. In a lot of cases, it does a better job of giving us cost information than Azure itself does. We're able to see the cost per machine. We're able to see the unattached volume and storage that we are paying for. It gives us a great level of insight. 

Turbonomic gives us the time to be able to focus on innovation and ongoing modernization. Some of the tasks that it does are tasks that I would not necessarily have to do. It's very helpful in that I know that the resources are there where they need to be and it gives me an idea of what changes need to be made or what suggestions it's making. Even if I don't take them, I'm able to get a good idea of some best practices through Turbonomic.

One of the ways that Turbonomic does to help bring new resources to market is that we are now able to see the resources (or at least monitor the resources) before they get out to the general public within our environment. 

We saw immediate value from the product in the test environment. We set it up in a small test environment and we started with just placement and we could tell that the placement was being handled more efficiently than what VMware was doing. There was value for us in placement alone. Then, after we left the placement, we began to look at the resources and there were resources. We immediately began to see a change in the environment.

It has made the application and performance better, mainly due to the fact that we are able to give resources and take resources away based on what the need is.

Our expenses, definitely, have been in a better place based on the savings that we've been able to make in the cloud and on-prem. Turbonomic has been very helpful in that regard. We've been able to see the savings easily based on the reports in Turbonomic. That, and just seeing the machines that are not being used to capacity allows us to set everything up so it runs a bit more efficiently.

The way it handles updates needs to be improved. That would be one of the areas I would focus on.

I wish that the upgrades and updates were more easily accessible. Some of that is based on my environment and how my environment is set up. Due to the fact that we are in such a lockdown environment, I wish that it would be better or easier to perform the updates.

I've used the solution for about three years now.

It's been very stable and we've had no issues with it. We did have an issue with the update, however. Turbo was really, really helpful and just involved right away and we were able to get that problem resolved. That said, in terms of general stability, it has been greatly stable.

We haven't really scaled out with it. We realized we probably needed to scale back in due to the savings that we were able to do thanks to Turbonomic. It is scalable. Our environment is very large and it was able to handle all of it. It can handle scaling your environment out or back in.

We have about eight people on my team. We work in converged infrastructure server engineering. We handle VMware and anything inside of the infrastructure.

It is being used extensively. Our usage would probably stay where it is as the environment is changing a little bit. It will probably hold steady with where we are.

The technical support is excellent. If the problem gets too complex, I've been able to speak to somebody in development for help even if I've had issues with one of the updates.

Positive

We were using VMware beforehand. We switched due to the fact that somebody in the environment had used Turbonomic at a previous engagement or a previous location. We decided just to give it a try and it worked amazingly well.

The initial setup was straightforward. I worked with some engineers and they were really helpful and really kind. They guided me along the path. 

We actually deployed a proof of concept first, over a couple of days. Then we took the proof of concept and applied for a license and then just put it in an environment. The deployment process took a couple of days.

In terms of pricing and licensing, I wasn't involved too much in that portion. In terms of the licensing, I would say it's definitely worth the investment. Even initially, if it seems out of range, the cost savings will make up for it.

We did look at some other options. We had issues with some of the other options and they weren't able to do tasks as efficiently. Turbonomic had a different environment just for testing it out. Another coworker also had used Turbonomic, so we tested it out in the environment.

We looked at VMware, the cost of using some of the VMware products, and how much it costs to do that. I don't remember the names of the other products. I just remember Turbo was high on a couple of our lists and we reached out. Cisco had a relationship with Turbo so they brought them in and we decided to test it out.

I've been using Turbonomic as it moved from different versions for about three years. Right now, we're on the CWOM version of Turbonomic and its version 3.7. We're using it on-prem and we also are using Turbonomic for just cloud reporting.

Turbonomic would be one of the best in terms of application awareness. Just being able to see different applications and see their usage is great. 

I'd advise potential new users to do a proof of concept and try it. It's an excellent product and the level of savings, as well as the reports, will really give them hands-on experience in the environment to get arms wrapped around everything. It's an excellent product that has paid for itself.

For someone looking into Turbonomic that already has a process to optimize their environment and monitoring, it's a good idea to work with somebody in technical support to see if there's something that you could get Turbonomic to help you with. You should evaluate it for savings, test it out and do a proof of concept as well. Turbonomic is hands down one of the best products.

I'd rate it ten out of ten. It does a really excellent job of reporting, handling placement, measuring resources, and increasing or decreasing those resources. Overall the product just sells itself. It has been very helpful in the cloud and on-premise. 

We use Turbonomic for workload placement. We've leveraged it for workload migrations, so if we get a new storage array or a new cluster, and we need to migrate workloads over to it, we can set up a policy and let it just run along as it can. It is especially valuable with storage array migrations, which can be very time-consuming if being done manually.

The biggest thing that we leverage it for is the right-sizing of virtual servers. This is relevant for both hot-add, and during an improvement-maintenance window where resource reclamation of the virtual servers takes place.

Turbonomic provides visibility and analytics into our environment from the application layer all the way down the stack to underlying infrastructure resources. The app dynamics information is a little newer to us but we do have that information there. Utilizing it is a matter of getting the right teams within the consult to understand and essentially automate or utilize the actions that it's suggesting from an application perspective. This capability is something that's important to us as an organization, and this product is helping to show the value of that data.

The visibility and analytics capabilities have helped bridge the data gap between disparate IT teams, which is a never-ending work in progress. Better collaboration between these teams is definitely something that is important to me.

Our mean-time-to-resolution has been improved by the visibility and analytics capabilities that Turbomoic provides, although it is difficult to approximate by how much because it varies on a case-by-case basis. As an example, with the right-sizing feature, a lot of what it's doing is hyper-reactive. I wouldn't call it completely proactive, although it could certainly be in some cases. Essentially, it's providing resources before the app team even knows they need them. As a result, it's preventing a problem from ever happening.

This product helps us to interpret our data alerts and spreadsheets, which is something that's important to us.

With the help of Turbonomic, we are better able to understand where performance risk exists. A lot of it has to do with the automation that we have enabled on the platform. Performance risk isn't necessarily something that we look at every day, waiting for something to start blinking red and then manually addressing it. The real success is turning on automation and having it try to fix the problems as much as it can without human interaction.

Another thing that this solution helps us with is reducing performance degradation. Again, it's on a case-by-case basis and it's difficult to estimate how much it's saved us. In the past, where we were given proactive notification about upcoming work and were able to capture the baseline, and then watch the product handle it using automation, we've seen where it was successful and did show value. However, a lot of those situations may be happening every day or at least every week, and we don't have proactive notifications. This is because we're not day-to-day working with the end-users or business units. It all ties back to the infrastructure that we support.

This product is certainly helping to improve our applications' response time SLAs, although we haven't focused on establishing that baseline and understanding how much things have improved from that perspective. This is a very important aspect for us and if we had a baseline then it would help to show more value because we could relate the improvement back to Turbonomic.

One thing that we are able to assess is savings from an OpEx perspective as a result of right-sizing. We understand how much an administrator would charge back to the company per hour to troubleshoot a particular issue. Every time a right-size action is performed, whether it's giving more resources or turning down more resources, a ballpark estimate of how much time an administrator would spend troubleshooting, and ultimately providing those additional resources, is approximately 30 minutes. Those actions happen a lot, and we're able to estimate and capture the savings from an OpEx perspective by right-sizing in place rather than having an administrator perform those actions each and every time. We have a dashboard to show the value from an OpEx savings perspective with the automation that it's doing. Last year, for example, we had $188K in operational savings due to automation, and we have saved $16K so far this year.

In general, Turbonomic has helped to reduce our CapEx and OpEx. In terms of CapEx, the right-sizing of workloads ultimately gives us an increased capacity for additional workloads or putting the right amount of horsepower towards the workloads that truly need it.

Turbonomic has helped reduce resource congestion and starvation. It's a powerful orchestration tool and it gives us the platform where, if we did want to innovate in a way that we haven't before, we can leverage the platform to help us toward that. This is something that has happened before and it was able to help us to get there. It's another tool in the belt to help support these initiatives.

The right-sizing feature is the most captivating one for us. It helped in taking the emotions out of what people think they need, basing it off of real data, and providing them what they actually need. It's not really a special feature, but the support that we received from that team really helped us in our success. There were definitely some customizations that needed to take place to make it successful.

This is the most aware of our products, in terms of understanding all of the components from the top down. It is integrated with all of the different modules, all the way down to the core infrastructure. All of it is tied together and there are not many tools that can do that.

The reporting needs to be improved. It's important for us to know and be able to look back on what happened and why certain decisions were made, and we want to use a custom report for this.

Between the different versions and releases, it seems that reporting fell by the wayside. It seems like there was more in the past than there is today, which has made it a little bit more of a challenge for us to capture some historical information.

I have been working with Turbonomic for approximately five years.

This is definitely a stable solution. 

We have had some issues with downtime in the past, realizing it might stop running and we weren't made aware. But the stability's been fairly solid. Working closely with our account team, they understand how we use the product, and more often than not, encourage us not to run the latest version. They want to make sure that we're properly testing before we go to the bleeding edge.

There is value-added from the support team, in them knowing our environment, and what might be impacted by the upcoming upgrades.

This is definitely a scalable solution. We can manage multiple environments using a single pane of glass, which is something that I really like.

The last big update was to create a containerized environment, which laid the foundation for us to continue to grow with this centralized system. From our perspective, it seems scalable and we haven't run into obstacles that I can't overcome.

We have approximately 12 users.

There have been some transitions with the recent acquisitions that have impacted our account team and some of our technical people. However, we are happy with them.

Out of the different products that we oversee, they're one of the best relationships that we've had. They not only help us through problems but help us on an annual basis to reiterate the value that the product can bring to our organization.

I would rate the support an eight out of ten. There is always room for improvement. Nothing will ever score a ten out of ten, even if it is perfect.

The bottom line is that they're superior at the majority of everything they're doing from a support perspective. Some of the biggest hiccups were that a new version would introduce a new problem. For about a year and a half, we'd go to the next version and this very thing would happen. This left us chasing these problems and they kept coming back up. However, it seems that things have stabilized since then, which was a couple of years ago.

We use other tools as part of our operations, including AppDynamics to help with Application Performance Management.

That said, we have not used any other products that have the same capabilities as Turbonomic.

The initial setup was fairly straightforward.

There were some complexities added from our side in trying to make sure that this platform was most successful with the standardizations that we have in our environment. When Turbonomic would perform actions, in most situations, we're actually calling on it to run in-house developed scripts to perform the additional configurations required from that action. Since that has been taken care of, it's been great.

To clarify, the initial setup is simple but we brought some complexity on ourselves. To deploy it to the level that we're using now, it took between six and eight months. This was really taking our time going through non-production environments first, then production, turning on one thing at a time.

There were also scheduling concerns, such as having our maintenance windows every other month. This didn't give us much opportunity throughout the year to deploy, which is why it took several months for us to get fully implemented. Even today, we're still not using it to its fullest potential.

The product was purchased from reseller CDI and I recommend them.

We deployed it ourselves but received assistance directly from Turbonomic.

With respect to product maintenance, it's a fairly hands-off tool. 

We're trying to hand off some of the routine maintenance windows. A lot of the predefined actions are in there but it's a case of setting the window based on our approved maintenance times for reclamation of resources.

If it's a change that involves policy and configuration then the change will be by a senior engineer or someone a little bit higher, because the change can be disruptive if it's not configured correctly. Otherwise, it's fairly hands-off.

The team even considers it an employee at certain times. For storage migrations, as an example, tasks that we had an administrator dedicated to, such as moving workload after workload, have now been assumed by Turbonomic.

We started to realize value from the solution with our first right-sizing, which was probably between three and six months. At this point, we were able to reclaim resources in our environment that were not utilized.

ROI is not something that I am focused on but in general, I think that we see ROI in several areas. I base this on the improvements that I've seen in regard to application performance.

We've turned down VMware's vRSOps advanced suite, which is similar in its basic functionality. The problem is that they are behind and just not at the point where we see it being a replacement for what we're using today with Turbonomic. At the same time, vRSOps does have advantages.

The basic pro for VMware is that you have one vendor with one solution, which is a nice simplification. The cons are that the vRSOps group and VMware, in general, don't have support anywhere near the level of Turbonomic, and the functionality isn't necessarily there as an orchestration and workload placement tool.

Where vROps shows its value is from an operational monitoring and troubleshooting perspective. We have seen value in that aspect and in fact, this is why we still have it in our organization.

We are not actively managing workloads in the cloud but it is something that we plan to do in the future. We are using Kubernetes on-premises, although we're trying to get more engagement from that team on the product. Importantly, the right-sizing on-premises is setting up our next steps in moving toward the public cloud, and toward that consumption model to the best that we can.

We may utilize Turbonomic in the cloud. The licensing switch that we went through really opened up not only the ability for us to easily scale to other private cloud environments that we have outside of our main one but much more easily scale to the cloud when we're there. I definitely would consider this tool to be a requirement as we start deploying infrastructure out in the cloud, just to help us understand that we're sizing to the best that we can.

My advice for anybody who is implementing this solution is to utilize it to its fullest potential. This will include aligning your company's culture. The foundation of the product is putting resources where they're needed, and this is done based on actual data. The politics have to be thrown out the window. As long as that can work in your organization, then this is a great tool that can configure your environment to run optimally.

For someone that is interested in Turbonomic, but already has a process in place for monitoring and optimizing their environment, then this is something that should be evaluated. I can't say that it will replace the existing product but there is more at stake. For us, it's the support and the team that come with the product. This is what surprised me the most and something to look out for.

Overall, Turbonomic has had a positive effect on our application performance. It's helped on many different levels, including toward the resolution of problems. It's even helped flat out prevent problems from happening in the first place.

I would rate this solution an eight out of ten.

We primarily use it as a cost reduction tool regarding our cloud spending in Azure, as far as performance optimization or awareness. We use Turbonomic to identify opportunities where we can optimize our environments from a cost perspective, leveraging the utilization metrics to validate resources are right-sized correctly to avoid overprovisioning of public cloud workloads. We also use Turbonomic to identify workloads that require additional resources to avoid performance constraints. 

We use the tools to assist in the orchestration of Turbonomic generated decisions so we can incorporate those decisions through automation policies, which allow us to alleviate long man-hours of having someone be available after hours or on a weekend to actually perform an action. The decisions from those actions are scheduled in the majority of cases at a specific date and time. They are executed without having anyone standing by to click a button. Some of those automated orchestrations are performed automatically without us having to even review the decision, based on some constraints that we have configured. So, the tool identifies the resource that has a decision identified to either address a performance issue or takes a cost-saving optimization, then it will automatically implement that decision at the specific times that we may have defined within the business to minimize the impact as much as possible.

There are some cases where we might have to take a quick look at them manually and see if it makes sense to implement that action at a specific date and time. We then place the recommendation into a schedule that orchestrates the automation so we are not tying up essential IT people to take those actions. We take these actions for our public cloud offering within Azure. We don't use it so much for on-prem workloads. We don't have any other public cloud offerings, like AWS or GCP. 

We do have it monitor our on-prem workloads, but we do not really have much of an interest in the on-prem because we're in the process of a lift and shift migration for removing all workloads in the cloud. So, we are not really doing too much on-prem. We do use it for some migration planning and cost optimization to see what the workload would look like once we migrated into the cloud. 

From our on-prem perspective, we use it for some of the migration planning and cost planning. However, most of our implementations with this are for optimization and performance in the public cloud.

It provides application metrics and estimates the impact of taking a suggested action from two aspects: 

1. It shows you what that impact is from the financial aspect of a public cloud offering. So, it will show you if that action will end up costing you more money or saving you money. Then, it also will show you what that action will be like from a performance and resource utilization perspective. It will tell you when you make the change, what that resource utilization consumption will look like from a percentage perspective, if you will be consuming more or fewer resources, and if you're going to have enough resource overhead for performance spikes.
2. It will give you the ability to forecast, but the utilization consumption's going to be in the future term. So, you can kind of gauge whether the action that you're taking now is going to look and work for you in the long term.

In our organization, optimizing application performance is a continuous process that is beyond human scale. We see tremendous value in Turbonomic to help us close that gap as much as possible within our organization. Essentially, Turbonomic will provide us with a recommendation on how to address a workload in real time based on its actual utilization. Then, we have pre-defined time slots where those actions can be implemented with minimal impact on the business because some of the changes may require the rebooting of the server. So, we don't want to reboot the server at 2:00 in the afternoon when everyone is using it, but we might have a dedicated time slot that says, "After 5:00 today or 2:00 in the morning when no one is using it, this server can be rebooted."

We have leveraged Turbonomic to not only ingest the data from the utilization of workloads to come up with performance-based driven decisions. We also have used Turbonomic to help orchestrate and initiate those actions automatically for a very large portion of our organization without us having to even be involved at all. For some more sensitive workloads, we look at them and coordinate with the business whether we will take action at another date and time.

We primarily use it in the public cloud for servers. We also monitor storage and databases within Azure. This is another added benefit that we like about Turbonomic. When we look at a decision, we are looking at how that decision is being driven based from a storage perspective, the IOPS being driven to a specific storage solution within our public cloud offering, its decisions based on specific DTU utilization from a database perspective, or if it is even a percentage of memory or CPU consumption. It takes into account all those various aspects and never puts us in a position where we take a decision or action without accommodating these other pieces and having them negatively impact us.

That level of monitoring is what has given us the confidence to allow Turbonomic to implement actions automatically without having IT oversight micromanage decisions, because it provides that holistic view, takes into account all those aspects, and ensures that a decision that is implemented never puts you into a point of contention or concern. We have the confidence to allow the appliance of the software solution to take actions without little to no IT oversight.

Turbonomic has identified areas within our public cloud where we had storage that was not being used at all. So, it provided us with insight into what that unused storage was so we could delete the unused storage and save on the recurring consumption cost. That was very helpful.

We have identified numerous workloads which have been overprovisioned by an administrator. We were able to essentially right-size workloads to use less resources, which cost us less money in our public cloud offering, e.g., a configuration with less memory or less CPU than what it was originally configured for. That helps us reduce our cloud consumption significantly.

In addition to ensuring that workloads are right-sized correctly, we have been able to save even more with our public cloud consumption by identifying workloads where we could purchase reserved instances, essentially long-term contracts for specific workload sizes. This allows us, on average, to save an additional 33% or more on our server run rates.

Turbonomic provides a proactive approach to avoiding performance degradation. It has allowed us to detect issues before they have actually become issues. Traditionally, in IT, we would not be aware of an issue until someone from the business came to us with an issue, then we would investigate the issue. In some cases, we would spend a couple hours trying to figure out what the issue was, then determine if something needed more resources, like more memory. Since Turbonomic, we have been able to almost immediately identify that our system needs more resources and take the action right then and there. Or, Turbonomic has identified there is an issue and we take an action, then notify the business that an action was taken in order to preemptively avoid a business impact.

Previously, a business impact use case would potentially take us hours. With Turbonomic, whenever we run into a business impact use case now, before we even log into a system to initially troubleshoot it, the first thing we do is go to Turbonomic and see, "What is Turbonomic telling us? What is the workload like now? What has it looked like in the last 24 hours or week? Do we see any trends to help guide us towards identifying where we should go from a troubleshooting perspective?" From that aspect, Turbonomic has definitely helped guide our path to resolution.

The ability to look at a workload from an actual consumption perspective for the resources that it's consuming internally is particularly valuable. For instance, when we have a server in the public cloud, we might provision a certain amount of memory resources to it and CPU, e.g., two processors and 24GB of memory. The tool provides the ability to look at the consumption utilization over a period of time and determine if we need to change that resource allocation based on the actual workload consumption, as opposed to how IT has configured it. Therefore, we have come to realize that a lot of our workloads are overprovisioned, and we are spending more money in the public cloud than we need to. 

This solution allows us to have the data to make business decisions without having a concern on whether we are going to be impacting the business negatively by taking the wrong action. We actually have the analytical data to back decisions. This helps us have discussions with the business on if it's the right decision to make or not. 

Turbonomic has the ability to manage the full application stack. We have not plugged in all aspects of our application stacks, but it does provide that. That's one of the things that we love from Turbonomic is that we're not only ingesting the data into Turbonomic and reviewing the decisions that Turbonomic is providing, but Turbonomic is also essentially providing us a single pane of glass to implement those actions. So, if there is an action that we would like to take, whether it is someone manually clicking a button and taking the action or the action being initiated automatically by Turbonomic, that is all taken from within the appliance. We don't have to go and log in somewhere else or log into our public cloud offering and take that action. It can all be done from a single management pane. We can look at our supply chain for a specific application or workload and see if one specific part of the solution is causing a problem, as opposed to having a bunch of people on the phone with a bridge call and having people looking at different aspects of the solution that they are more intimate with. Turbonomic shows us the ability from a service chain perspective, how things pitch together, and helps us identify that single point or bottleneck causing the impact. We have used it from that perspective.

It provides the ability for us to create customized dashboards and custom reports to help showcase info to key stakeholders. We have leveraged the custom reporting for things, like SAP, that we have running in the public cloud to show how SAP is running, both from a performance aspect as well as from a cost perspective.

There is an opportunity for improvement with some of Turbonomic's permissions internally for role-based access control. We would like the ability to come up with some customized permissions or scope permissions a bit differently than the product provides. We are trying to get broader use of the product within our teams globally. The only thing that is kind of making it hard for a mass global adoption, "How do we provide access to Turbonomic and give people the ability to do what they need to do without impacting others that might be using Turbonomic?" because we have a shared appliance. I also feel that that scenario that I'm describing is, in a way, somewhat unique to our organization. It might be something that some others may run into. But, predominantly, most organizations that use or adopt Turbonomic probably don't run into the concerns or scenarios that we're trying to overcome in terms of delegating permission access to multiple teams in Turbonomic.

It has been somewhere between two and a half to three years since we started our relationship with them.

The stability is very good. We have not had to open up any support tickets for the product to troubleshoot or recover the appliance. It has been running just fine. We haven't had to redeploy or recover anything with it, surprisingly, in the two and a half years that we have had it. The code updates are pretty easy to perform as well. Ongoing maintenance is really simple, and our account team helps us with the code updates. They get a meeting invite together, then it is less than a whole 10 minutes, but they are there every step of the way.

It is pretty scalable, in terms of any concerns that we would have. Right now, we are using on-prem appliances. However, if we needed to, they have the ability of pouring into a SaaS-based offering, which would help us adopt it faster, in terms of some of our sister companies, because we are not isolated to network access within this particular data center. We could leverage the same licensing from a SaaS perspective, then they wouldn't have to use a VPN to connect to the appliance to use it. 

There are situations from a scalability perspective where we have to take into account things like GDPR. For things where GDPR or data sovereignty come into play, the scalability becomes a bit of a concern because you can only keep the appliance within that specific region. You need separate instances of Turbonomic, but the team has the ability to allow us to tackle that from a licensing perspective. This is a pretty minimal concern. We tackle GDPR or data sovereignty from the perspective that we just apply an instance of Turbonomic within that specific country region.

If we have any questions or concerns, the account team as well as the product support team are always there and very accommodating to help us. With any problems that we have, even if they are not built into the product, we have worked with them to give them feedback on the product and on how we would like it to work. They have worked with us to help import some of that functionality into the product so it is available, not just for us, but for other customers who use the product as well.

Positive

The initial setup was relatively straightforward. It was a pretty easy setup. I wouldn't say it was any more difficult than any other tool that we set up or have used in our environment. It is pretty easy to deploy, then probably just as easy to configure once it was deployed.

It helps us gauge our return on investment for the purchase of Turbonomic, based on the overall actions that we've taken and how much money we have saved by taking those actions over a period of time.

In the last year, Turbonomic has reduced our cloud costs by $94,000. It has identified a lot more cost saving areas, but we haven't taken advantage of those.

The amount of tickets that we have had come in for performance issues has surmounted to almost nothing in the calendar year. I don't know what we had before, but now in a calendar year, it is less than 10 to 12 tickets a year for a performance issue.

It has definitely provided a huge benefit in the area of man-hours saved. Without the tool, we would be flying blind on that and would probably be spending a lot of man-hours trying to formulate in-house strategies on how to reduce costs. Our company is a very lean company, in terms of headcount for IT resources as well as cloud skillset awareness. Having a tool like Turbonomic has allowed us to adopt and implement strategies like this, like cost saving measures with the public cloud, probably making us exponentially faster than we could have been without them.

When we had hit on how it ingests the workload performance data to help provide performance-driven analysis or recommendations to provide a recommendation for whether a workload should be scaled up or down, one of the things that has been kind of like a side effect to the ingestion of this data and the business decisions coming out of Turbonomic is it has been helping us identify workloads which are really not being used at all. From identifying those workloads that are not being used, we are able to go through our lifecycle management faster and more efficiently than we would have in the past. We have been able to decommission servers, essentially deleting them from our public cloud and completely reducing the operational cost of that workload altogether. So, it is not just ensuring that the VM is right-sized or locking in a commitment, but identifying that the workload is so low to utilize.

We are able to go back to the business and having a discussion with them based on the utilization of that VM over the course of a period of time for the data that we have, then have the justification and communication with the business to say, "Yeah, it doesn't make sense to have this workload in the environment anymore. Let's delete it." or, "Yeah, it's something that isn't used it all. Let's go ahead and delete it." It is allowing us to identify areas to save cost in those areas, but it's also helping us say, "This workload is costing us this much money. Is it really worth spending this much money every month or so for this solution that is running in the public cloud? Is it generating enough revenue for the business to warrant the run rate? Is the solution providing a service to the business that justifies the operational consumption on a monthly basis?" We are able to have these internal discussions within the business based on the data that Turbonomic is providing. This is a side effect of the product because the product is not providing these decisions and implementing them, but the product is providing us the data to have these discussions and net these decisions as an outcome. Then, this ends up saving money in our public cloud offering.

We did try some other solutions as PoCs before we worked with Turbonomic. Unfortunately, I am not aware of who those companies were because that was before I came onboard with the team. The big thing that it always came down to was whether we were going to adopt the entire implementation setup and configuration aspect. For example:

• How much work was it going to take to deploy the appliance? 
• How many man-hours would it take to configure it? 
• What the continuous configuration and management was going to be?
• Was it really saving us time and money in the long run?

Other solutions always fell flat because of how much involvement it would require from IT to deploy and work it, but also because of the ongoing configuration and maintenance of the appliance.

It doesn't pick up the entire supply chain automatically. It requires minimal effort in configuration. We have to show a relationship in a sense that this workload is associated with another workload. However, once that relationship is established, the solution helps us manage our business-critical applications by understanding the underlying supply chain of resources.

Our capital expenses are relatively flat. We are not purchasing any new equipment. We are actually in a consolidation process. Everything is getting moved to the public cloud. From an operational perspective, with our workloads being in the public cloud, it has provided us:

1. The ability to identify what we have running in the public cloud and how much it will actually cost us. 
2. How we can reduce public cloud operational costs, e.g., what actions can we do to help reduce operational expenses in the public cloud? 

It identifies areas where we can delete storage that is not being used. We can address right-sizing workloads that are overprovisioned in the public cloud as well as logging in long-term commitments with workloads in the public cloud and saving on incidents, on average for us, over 33% or higher for our workloads, as opposed to just paying the pay as you go hourly rate with the provider.

Try to look at things, not just from a cost savings perspective, but also from performance avoidance. We looked at: How do we quantify our spend in the public cloud and how do we avoid our spend in the public cloud? But we always forgot that there were workloads out there that do have performance impacts. So, we counted this as a cost savings and cost optimization tool, but it became so much more than that. 

We developed a crawl, walk, run approach. We took some workloads in our public cloud and looked at the business decisions. We took the decisions, then we tested to see what the outcomes were with them. As we went through those actions manually, gained the confidence on how those actions were being made, and what the post impact of that was, that allowed the business to become more confident in the tool. We no longer needed to have meetings to discuss why we were doing what we were doing.

It then became a point of communication. An action would be taken because Turbonomic said it was the right thing to do. Nowadays, it's not even questioned. When I talked to people about trying out Turbonomic and looking at how to adopt it in their workload, I say to look at areas which are current pain points in your environment and see where Turbonomic would fit into that instead of trying to come up with the workloads or use cases to plug into Turbonomic. Instead of trying to figure out what you have or seeing where you could put Turbonomic in your environment, see where your environment fits into Turbonomic. That was the way that we were able to drive adoption much faster and use it, not just as a reporting tool, but also as an orchestration tool as well.

They have some room to grow. I wouldn't give them a perfect 10. I would probably give them an eight and a half or nine (as a whole number).

I belong to the on-premises team. We're a telecom company with a private and public cloud, but we don't use Turbonomic for the cloud infrastructure. We use Turbonomic for capacity forecasting and analysis. We do not use the solution as much on the application layer. We scan only the infrastructure. Turbonomic isn't providing any useful reports on the application layer. We did some application groupings, but it didn't help us because we didn't receive any application information. 

There are more than 50 Turbonomic users at the company, including admins and developers. There is a 10-person admin team, and the rest are end-users with limited access to see the reports on their machines.

Turbonomic provides recommendations about ideal resource levels. It helps us identify where we lack capacity and require more resources. These forecasts save time because we can avoid a capacity crisis. It tells us where to place the machines, so resources are automatically balanced. Those recommendations are there from the tool. That has helped.

It is a standard tool that helps to analyze capacity metrics. Without Turbonomic, we would struggle to manage capacity planning. It is essential to have a tool like Turbonomic because we rely on it for VMware capacity planning.

Turbonomic helped to reduce performance degradation by forecasting utilization and notifying us when we need to increase hardware resources before it reaches a critical threshold. Our SLAs require us to maintain 24/7 availability. 

The most valuable features are the cluster utilization reports and the resource capacity planning. We can simulate how much capacity we can add to the current resources. The individual DM reports and VM-facing recommendations report are also helpful. 

It can tell us where performance is lagging on the hardware layer. It's not on the application layer. Turbonomic can tell us where our memory and disks are to the point where performance will suffer. 

Turbonomic will identify causes and suggest actions in one unique report. For example, if a memory center is underutilized, it might suggest increasing utilization from 16 to 20 percent.

The automation area could be improved, and the generic reports are poor. We want more details in the analysis report from the application layer. The reports from the infrastructure layer are satisfactory, but Turbonomic won't provide much information if we dig down further than the application layer. 

I would like them to add some apps for physical device load resourcing and physical-to-virtual calculation. It gives excellent recommendations for the virtual layer but doesn't have the capabilities for physical-to-virtual analysis.

Automated deployment is something else they could add. Some built-in automation features are helpful, but we aren't effectively using a few. We want a few more automated features, like autoscaling and automatic performance optimization testing would be useful. 

I have been using Turbonomic for nine years.

Turbonomic is 100% stable. I've never seen any downtime. 

Turbonomic is scalable. 

I rate IBM support a nine out of ten. They've been there when we needed support. We haven't had to escalate any tickets lately, but they provided decent support during the initial deployment.

Positive

Before Turbonomic, I used a solution called VMware ONE Service. I started to use Turbonomic when I switched roles. I don't know why the company adopted Turbonomic, but it was in use when I joined. 

The setup is straightforward. It involves bringing down all the services from vCenter. There's nothing complicated about it. Deployment takes half a day once you have all the prerequisites, like the IP hosts, record ports, firewall configurations, etc. The virtual operations team handles deployment and maintenance. It's about ten people. 

I rate IBM Turbonomic six out of ten. I would recommend it for capacity planning. Decision makers want to predict workloads and plan. We get excellent reports and recommendations for machine optimization and sizing. I wouldn't recommend it for monitoring. 

My main purpose is to provide an assessment for clients, agencies, or the government to help them understand their workloads and what it would take for us to do a migration of their workloads, before we do it. I generate a report based on the client's existing on-prem workloads, and see how Turbonomic optimizes everything and how things would look once they are migrated to either Azure or AWS. I review that report and all the possible savings if they move their workloads to the cloud.

It's deployed on-premises, but we have been using it for public and private cloud.

It provides visibility and analytics at the underlying infrastructure stack level, in the way I use it. That is key. That's what differentiates between an agency saying, "Go ahead and move our workload because we see the value," or "Just decommission everything and we'll find an alternative to keep our workloads going." Most of my discussions are around trying to get things from on-prem to the cloud, and Turbonomic has been very helpful with that.

The visibility and analytics help bridge the data gap between disparate IT teams. They give us a central point around which we can sit down and discuss the savings and how we would actually move the workloads, based on how workloads are truly running today on-prem. That is very important because we want to show the client savings and help them to optimize their workloads, whether a system is on-prem or in the cloud.

In addition, the visibility and analytics have helped reduce our mean to resolution when it comes to identifying places where we can optimize things and getting that to the customer as soon as possible. Instead of having to search and discover all the infrastructure and calculate things based on usage, I have a single pane of glass with Turbonomic. I can look at the graphs because the data is already there.

The solution gives us a single source of truth for application performance management. That is vital because when we migrate workloads for any client. I've been doing migrations for almost eight years now, moving people from data center to data center, and workloads from data center to data center or to the cloud. One of the key factors in doing that is a single point of truth. If you don't have that, you repeat work. You don't know what's truly correct and the migration could fail.

Turbonomic also gives us the ability to review reports with our clients on a monthly basis. It makes us look good. It shows that we're being proactive and that we're looking ahead to ways we can help our clients optimize and save money. And if we're saving them money, they're happy.

From a performance standpoint, we know before we move workloads that we have optimized the performance for that workload. That means that when we migrate it, it shouldn't be a problem. In all the migrations we've done, performance hasn't been a problem, based on the performance readings we got from the Turbonomic reports.

In addition, it helps us meet our SLAs. When many workloads were running on-prem, we could not track our SLAs as well as we can now, thanks to tracking things with Turbonomic in the cloud.

Overall, from our organization's standpoint, the solution has helped to build our entire migration effort. Our migration team can follow a single path and understand how to present the data to our clients and help them in moving from one point to another. It helps the engineers to focus on issues and it really helps them do their migration prep. The smoother the migration prep, the smoother the actual migration will be.

The feature for optimizing VMs is the most valuable because a number of the agencies have workloads or VMs that are not really being used. Turbonomic enables us to say, "If you combine these, or if you decide to go with a reserve instance, you will save this much." That feature gives you an estimate using, for example, a Microsoft cost model, to show clients how much can be saved.

Another key aspect that I really like about Turbonomic is the user interface. It gives you a visual representation of where there might be issues. That stands out. When I'm looking at resources for migrating different workloads, if something is shown in red, that identifies a risk. If it's a risk where it's currently running, it's definitely going to be worthwhile to migrate it. It helps us to mitigate that risk before we do the actual migration.

They have a long road map when we ask for certain things that will make the product better. It takes time, but that's understandable because there are other things that are higher on the priority list.

I've been using Turbonomic for a little over two years.

The customer support is definitely a 10 out of 10, and the training gets a 10-plus.

Positive

We use IBM Turbonomic to automate our cloud operations, including monitoring, consolidating dashboards, and reporting. This helps us get a consolidated view of all customer spending into a single dashboard, allowing us to identify opportunities to improve their current spending.

It can consolidate and amalgamate all the efforts. Before using it, we had multiple reports, tools, and sources of information that we needed to consolidate. With IBM Turbonomic, we can operate everything in a single console and view everything in a unified way. This allows us to address key performance issues and spending concerns that we identify, optimizing our operations to work better for our customers and us.

The overall price, the dashboards, and the FinOps capabilities are important features. The ability to manage all the budgets is also crucial.

The implementation could be enhanced.

I have been using IBM Turbonomic as an integrator for the past year.

50 users are using this solution. As an integrator, we're constantly looking for new logs and trying to make some of our customers for whom we do not provide cloud services part of that new ecosystem.

Initially, it can be tricky as you have to configure everything. The setup requires a significant level of effort. If there were a way to migrate or import some features or have some preconfigured settings, it would greatly help with the initial setup. It takes three to four months as per standard operation.

We have engineers who are certified in the tools. We have a couple of product managers, but the main source of disruption, or at least delays, is the integration and dependency on other areas. For example, if we want to integrate the CMDB with the monitoring tools we already have in place for each of our different customers, it requires time and dependencies not only on the availability of people but also on the ability to make changes to the environments.

The ROI is very good. Although it's expensive, you can fully implement the recommendations from the various tools and dashboards and easily recover the investment within the first year.

It offers different scenarios. It provides more capabilities than many other tools available. Typically, its price is set as a percentage of the consumption of some of our customers' services. The cost will vary depending on the specific scenario, but it is not cheap.

You can easily maintain it once you get into a stable mode with IBM Turbonomic. The operations team that adopted the tool is getting a lot of value from it, making it easier for them to manage and consolidate their work. It doesn't ramp up your AppDV or resource needs but helps improve and optimize them. We are using fewer people now.

It has a lot of capabilities. We haven't encountered any scalability issues. The way we have implemented it has helped us easily incorporate new customer sets.

There weren't many people with the skills to implement and manage IBM Turbonomic, so we had to develop the team's expertise. However, once we overcame that hurdle, managing it became easier.

Overall, I rate the solution a nine out of ten.