IBM Turbonomic Reviews

We leverage IBM Turbonomic to manage our 28 on-premises data centers, effectively optimizing resources and ensuring their operational efficiency. It helps us automate workload scaling to guarantee consistent application performance. Additionally, while we primarily use Turbonomic for on-premises management, we also utilize it within our AWS environment for cost optimization purposes. This allows us to identify and implement cost-saving measures within the cloud.

One of our key challenges was finding a tool that could provide a holistic view of our entire environment and report back key data points, such as CPU and memory usage. This would allow us to identify potential areas for cost savings. We were frequently receiving requests to increase resources like memory and CPU, so we needed a tool that not only gave us historical data but also empowered us to take action, whether that meant automating changes or manually making the changes and IBM Turbonomic does that.

We use IBM Turbonomic in a hybrid cloud environment. Although it supports multi-cloud capabilities, we currently operate in a single-cloud setting.

Turbonomic offers visibility into our environment's performance, spanning across applications, underlying infrastructure, and protection resources. 

The visibility and analytics help to bridge the data gap between disparate IT teams such as applications and infrastructure. This is important for awareness collaboration, cost saving, and helping to design and improve our application.

Enhanced visibility and data analytics have contributed to a significant reduction in our mean time to resolve. Tools like Turbonomic provide crucial visualization and insights, empowering us to make data-driven decisions instead of relying on assumptions as we did before. This newfound transparency translates to a massive improvement, going from complete darkness to having a clear 100 percent view of the situation.

Although our applications are not optimized for the cloud we have seen some improvement in response time.

IBM Turbonomic empowers us to achieve more with fewer people thanks to automation. Previously, customers frequently contacted us requesting resource increases to resolve issues. Now, we have a tool that allows us to objectively assess their needs, leading to a deeper understanding of our applications. This solution also generates significant cost savings in the cloud and optimizes hardware utilization within our data centers. Its AI algorithm intelligently allocates servers on hosts, maximizing efficiency without compromising performance. By fine-tuning resource allocation without causing performance bottlenecks, Turbonomic extends the lifespan of existing hardware, postponing the need for new purchases. This effectively stretches our capital expenditure budget. We started to see the benefits of IBM Turbonomic within the first 60 days.

IBM is a fantastic partner. Their tech support has been outstanding, and the product itself is excellent - a very solid offering.

By automating resource management with Turbonomic, our engineers are freed up to focus on more strategic initiatives like innovation and ongoing organizational projects. Previously, manually adding resources was a time-consuming process that interrupted workflows. Now, automation handles scaling efficiently, saving us thousands of man-hours and significant costs.

It has illuminated the need for SetOps. It has highlighted areas of overspending, and the actions we've taken have demonstrated significant cost savings.

IBM Turbonomic has positively impacted our overall application performance.

IBM Turbonomic has helped reduce both CAPEX and OPEX. It has also significantly reduced cloud build times.

On-premises, one advantage I find particularly appealing is the ability to create policies for automatic CPU and memory scaling based on demand. This improves elasticity and responsiveness to application needs. Additionally, IBM Turbonomic helps us track and quantify cloud cost savings, facilitating informed decision-making.

We're also implementing FinOps principles. By collaborating with other departments, we can demonstrate the cost implications of various resource allocations. For example, specifying a minimum processor requirement might incur higher cloud costs. This increased awareness through IBM Turbonomic allows us to predict impact and make cost-effective decisions.

Turbonomic can modernize the look and feel, making it more user-friendly to access and obtain information.

I have been using IBM Turbonomic for over two years.

IBM Turbonomic is one of the most stable solutions that I have worked with in the last 26 years.

IBM Turbonomic is highly scalable.

The technical support team is both responsive and knowledgeable. They quickly escalate complex issues to someone who can resolve them efficiently.

Positive

The initial deployment proved complex due to our extensive environment, encompassing over 23,000 VMs. This necessitated a year-long rollout, overseen by a dedicated team comprising a salesperson and a senior technical expert.

IBM Turbonomic helped us with the implementation. They were a great partner.

We have seen a return on investment with IBM Turbonomic.

IBM Turbonomic is an investment that we believe will deliver positive returns. We justified the purchase based on its potential to significantly reduce costs, which will allow us to recoup the investment and generate additional benefits. This ultimately makes refinancing a worthwhile option.

I would rate IBM Turbonomic ten out of ten.

We need to perform regular maintenance due to the frequent release of updates.

I recommend that users review their internal processes and partner with other departments to facilitate company-wide implementation. Collaboration will be crucial, so ensure they have a FinOps practice in place, or establish one if necessary.

We are in the healthcare industry and we use this solution for ensuring proper resource allocation for our virtual servers and our virtual desktops.

We use Turbonomic as a single platform to manage our full application stack, and having a single source of truth for application performance management is very important to us. The fewer places you have to go to make changes, the better. Having that available in a single pane of glass to make those changes makes it easier on our admins. Rather than having to go into multiple solutions to make changes, they do it all right there.

Turbonomic provides visibility and analytics in our environment from the application layer, all the way down the stack to underlying infrastructure resources. We don't use it as much on the application level as we do on the hardware and resources level.

This is a feature that's becoming more important to us. We're really starting to look at the analytics more nowadays and will in the future. It was not as important before but has become more so in the past year.

This visibility has definitely helped reduce our time to resolution. We have not quantified how much but it is due to having the visibility and the ability to monitor what's going on and make those changes in real-time. We just didn't have a baseline to compare and see how much it's improved.

With respect to any alerts that come up, it helps us to interpret those faster. This is something that is very important because it triages a lot of stuff that we don't have to then spend extra time doing, especially being a small team. It saves us at least a couple of hours per week.

Using this product helps us to reduce performance risk because it shows us where resources are needed but not yet allocated. Based on that, we're able to see whether those resources needed to be updated. In turn, that helps to limit application downtime or employees waiting for their jobs to get done.

It has definitely helped to reduce performance degradation. It helps us keep up with the changing environment and workloads that change over the course of days or weeks. Prior to this, it was all manual for us and we'd have to react. Now, we're able to be proactive.

This has also had a positive impactive on our applications' response time to SLAs. We're able to keep up and be proactive by fixing issues before the user even notices that there is a problem. This is important because it's great from a customer experience standpoint.

They never experience the problems they had in the past, where they would have to call us to say that their machine was running slowly, and then we'd have to figure out what was going on. Now, we know beforehand that they need additional resources, and many times, we're able to address that before they even realize it.

Generally speaking, using this solution has helped to eliminate resource constraints and it's helped us to understand what resources we need. In terms of that, we are able to modify our plans for the future concerning the acquisition of new hardware because we're able to satisfy the need with what we already have, rather than thinking we need to buy more. Turbonomic helps us to balance that out better, ensuring that we're not over-resourced in terms of hardware, and having resources sitting idle, which is very costly.

Turbonomic has helped our engineers focus on innovation because it has freed their time quite a bit. In the past, we had one person that would spend a lot of time trying to find where things were going wrong. This was precipitated by users saying that their machines were slow or not performing very well. Our staff would have to go in and figure out what was going on, then make the appropriate changes. Now, Turbonomic does that and our staff can focus on other tasks that need to be done.

The resource allocation features are the best for us. They have a lot of different features, but we had it at first in notification-only mode, or recommendation mode it may be called. In that mode, they would recommend what we should do, and then we would manually do it.

Once we realized that we could trust their recommendations, we set it into the automated mode, so it makes those changes on the fly for us. Especially during the pandemic, that really helped as we were scaling up our virtual desktops quite a bit. We almost tripled the number of desktops we had on there within the course of two and a half to three months.

In the automation engine, it is really quick to change things when it needs to scale up. However, scaling back is a little bit slower. Recovering resources when they're not needed is not as optimized as it could be.

I have been working with Turbonomic for approximately four years.

This is a very stable solution. Even when we have to perform upgrades, it's seamless. With other solutions, updates can sometimes be a problem, but with Turbonomic, it's been pretty easy.

Turbonomic is a scalable product.

We have about 280 servers and close to 550 virtual desktops being managed by Turbonomic. It is in a mode to increase resources as needed and then decrease them as the demand goes away.

At this point, we don't have any plans to increase usage. We have it covering all of the workloads that we need.

We only have two people that use it, and they are system analysts. They are in charge of deployment and maintenance.

The customer support has been very positive, although we've had very limited need for it. That said, whenever we've had to call in, they've been able to help us out very quickly.

One of the best parts about this solution is that there are so few issues that we simply don't need to use support very often.

Positive

We did not use a similar solution prior to this one. All of the work was done manually. We knew that our workload was increasing and the time spent on managing these types of workloads throughout our server stack was also increased. We implemented Turbonomic because we found it was a good way to free them up from a lot of that busy work.

Compared to what we were doing before, Turbonomic has given us full visibility. Prior to this, we had to look in multiple locations, and in some cases, we didn't have any visibility at all. 

The initial setup was very straightforward, and it was done within a couple of days.

Resources from Turbonomic assisted us with the deployment. They were very knowledgeable and were able to help our staff, who had never used the product before, understand it very quickly.

We have not measured ROI, although application performance has improved because we're not resource-constrained. We're not running into situations where our applications are failing due to a lack of resources, so it's helped us most with uptime and customer experience.

It has definitely helped in terms of CapEx because we've been able to avoid purchasing hardware that we originally thought we needed.

The pricing is in line with the other solutions that we have. It's not a bargain software, nor is it overly expensive.

I do not recall evaluating other solutions.

I believe that we use version 8.3, and we may be a couple of versions behind the latest.

Turbonomic has tools for optimizing and monitoring cloud-based environments, although, at this point, we use it mainly for our on-premises environment. We used it to help estimate what our cloud costs would be. Consequently, we realized that we were much better, at the time, not migrating to the cloud from a monetary standpoint.

Using the cost estimate to run our workloads in the cloud, we found 25% to 30% savings by staying on-premises versus going to the cloud. This is because our workloads are not optimized for the cloud. We'd have to retool a lot, which becomes very expensive.

The problem with moving is based on our application stack, rather than something that can be changed in Turbonomic. They saved us money in this regard because their estimates are very well thought out and very informative.

My advice for anybody who is looking into Turbonomic is that it's a great product. There are other options on the market but from what I've seen, this is one of the better ones. I'd suggest starting slowly when it comes to the recommendations. Make sure that you're verifying what their recommendations are and building that trust up before going into a more automated mode. Once it is automated, it can move pretty quickly and if you're not ready for it, it can cause some issues.

If somebody were looking into Turbonomic but already has a process automator and does monitoring, it would really come down to whether they are looking for better ease of use, or having an all-in-one platform if they currently use multiple tools. It's going to do a lot of the same tasks and they would have to do their own research to see what is better for them. I like that it gives that single pane of glass visibility, whereas they might have multiple vendors and multiple applications in their current use case.

In summary, it's a good product. There are things that they're working on and they keep adding new features, so we're happy to see that.

I would rate this solution a nine out of ten.

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 do vMotion through VMware. We let Turbonomic control our vMotion. We do server rightsizing and capacity management with it.

With Turbonomic, we were able to reduce our ESX cluster size and save money on our maintenance and license renewals. It saved us around $75,000 per year but it's a one-time reduction in VMware licensing. We don't renew the support. The ongoing savings is probably $50,000 to $75,000 a year, but there was a one-time of $200,000 plus.

It also saved human resource time and the cost involved in monitoring and optimizing our state by 25%.

Rightsizing is the most valuable feature because it helps with our capacity management and server density so that we are always optimized. 

Turbonomic provides specific actions that prevent resource starvation. It'll tell us if a server is overpowered or over-provisioned so that we can recover resources. And on the same note, it'll tell us if a server is under-provisioned and we need to add resources to it to help the performance.

It also provides us with a single platform that manages the full application stack. This was the secondary reason we went with Turbonomic. The primary reason was for the server optimization.

In my organization, optimizing application performance is a continuous process that is beyond the human scale. We're always looking to better optimize the environment.

We use Turbonomic's automation mode to continuously assure application performance by having the software manage resources in real-time for sizing-up. Sizing down is a manual process.

Turbonomic handles on-prem, virtualization, and storage. Turbonomic understands the resource relationships at each of these layers and the risks to performance for each. As far as we can tell, they are risk-averse. So they put controls in so that you don't cause outages. It makes the operations more secure.

We do a piece of automation in real-time, scheduling them for change windows, or manual execution for implementing Turbonomic actions. The vMotions are automation, the rightsize up is done automatically, and the rightsize down is during change windows.

We do the automation piece so that it is continuously rightsizing how many VMs are on a host for best performance, same with increasing resources on a VM to make sure application performance is where it should be. And then we do change control for the rightsize down because it requires a reboot.

The fact that Turbonomic shows application metrics and estimates the impact of taking a suggested action gives us a window into seeing what will happen if we do make the change. So it provides better visibility.

Turbonomic provides a proactive approach to avoiding performance degradation. That's what rightsizing does. It continuously optimizes so there are fewer application performance issues.

We have seen a 20% reduction in tickets opened for application issues.

Using Turbonomic does it all-in-one versus the approach of using monitoring and threshold to assure application performance. Sometimes your monitoring tool does not do the optimization as well.

The GUI and policy creation have room for improvement. There should be a better view of some of the numbers that are provided and easier to access. And policy creation should have it easier to identify groups.

I have been using Turbonomic for four years. 

We have not had any issues, it's pretty stable.

We've been able to add resources or things for it to look at without any issues so far. So there haven't been any scalability issues.

We are monitoring 3,000 workloads with Turbonomic.

There are two systems engineers who use it. In terms of maintenance, it only requires software updates. 

We may do some more integration with other applications like AppDynamics, but the platform itself, we've integrated it completely.

We've had great success with their support. They have good response times and willingness to engage.

The initial setup was straightforward. It's point and click. You install the VM and point it to your environment and it starts working.

The initial deployment took a couple of hours. 

We have seen ROI in cost reductions and savings. That directly applies to the cost we pay for Turbonomic licensing.

Our ROI is positive when it comes to the assurance of application performance in your company. It's a benefit for us.

Pricing is pretty straightforward. We haven't seen any major increases in it. It's a flexible model.

There aren't additional costs to the standard license. 

We also looked at VMware vRealize. The big difference between vRealize and Turbonomic is integration. It's easier to integrate Turbonomic than it is vRealize. There are more components to install.

It's a worthwhile investment, at least to get it, get some sort of trial installed to see because it'll give you recommendations as to what it can do and it'll allow you to determine if it will help your environment or not.

There were many things that could be optimized in our environment that we did not know about before.

I would rate Turbonomic an eight out of ten.

The primary reason we initially got it was to help us to right-size all of our VMs, to make sure that they were the appropriate size for the amount that they were being used. That was the biggest push to get this, and we implemented it. 

We have also discovered that Turbonomic can automatically suspend virtual machines that were on a schedule. For example, in the afternoons and the evenings when a VM wasn't going to be used, it could just be shut down, so that we wouldn't be charged eight to 10 hours of compute time, per machine, that wasn't going to be used at all during that time. That's been pretty useful. 

We're also using it to help us determine the reserved instances that we need. We haven't purchased the reserved instances yet but we're using Turbonomic's suggested reserved instance purchasing algorithms to assist us in finding the right balance for the number of RIs that we want to purchase.

It has provided us with a pretty good deal of savings on the front-end, helping us to correctly size VMs that were over-provisioned. We were paying a lot for VMs that really didn't need to be as big as they were. There has been a pretty drastic decrease in compute and cloud spends, due to either making the changes suggested by Turbonomic, or letting Turbonomic make the changes. That, coupled with using the suspend functionality to suspend machines that are not being used, pulled down our cloud spend a good bit.

The solution also provides a proactive approach to avoiding performance degradation. When you check in daily, it does evaluations on where your VMs and your infrastructure stand on that day. As a VM starts becoming more utilized, it will let you know to start planning on upgrading the machine because it's starting to show some extra usage that may grow beyond its capacity.

The right-sizing is the most valuable feature. It constantly lets you know if a machine is being over-utilized or under-utilized, so that you can make it the appropriate size for what you need it for.

It also brings up a list of machines and if something is under-provisioned and needs more compute power it will tell you, "This server needs more compute power, and we suggest you raise it up to this level." It will even automatically do it for you. In Azure, you don't have to actually go into the cloud provider to resize. You can just say, "Apply these resizes," and Turbonomic uses some back-end APIs to make the changes for you.

The way they evaluate reserved instances could use some polishing. The people that make decisions on what to buy are a bit confused by how it's laid out. I don't know if that's the fault of Turbonomic, or if that's just the complexity of reserved instances that Microsoft has created. It's not really that confusing for me, but for some people it's a little bit confusing. Trying to explain it to them is a bit tricky as well. We get to a point of impasse where we just accept that they don't really fully understand it, and that I can't fully explain it either. It would help if Turbonomic could simplify it or clarify it, and help non-technical people to understand what's going on and how the reserve instances are being calculated and what they apply to.

We've been using Turbonomic for about two-and-a-half years.

The stability is good. We've never had any issues with the server running and doing what it's supposed to do. It's never crashed. I've never had an issue bringing up the user interface. Nothing has ever caused any issues.

I think it would scale very well. Our size is in the medium range, but based on the way I see it working, I don't think it matters what size your cloud infrastructure would be. I think it would handle it very well.

In our company, Turbonomic is monitoring pretty much all of our machines in the Azure cloud. If they're in AWS, those are not managed. That's a separate side of the house and they don't want to have their stuff managed by Turbonomic. But we use it to manage everything from size to suspending, for all of our Azure-based machines.

As we move forward, we'll be using it more. We're going to look into using the suspension feature to suspend more VM. As we start getting comfortable with reserved instances, we'll probably use it to help us gauge how many reserved instances we need to buy.

I had to use their technical support when I set up the suspensions process. They were good. They did a good job. They got back with me fairly quickly and they were able to walk me through the process of how to configure it. They took the time to explain it very well. They even walked me through the process to make sure I understood how it works. As simple as a suspend of a VM might seem to be, initially, when you look at how it works in Turbonomic, it's not super-simple.

We didn't have a solution in place at all.

I was working for the company when they implemented Turbonomic but I wasn't part of the project that implemented it. I have since taken over one of the primary roles in utilizing it and we've deployed an updated version of it. I have a co-manager who uses it as well, on the same level as me. We back each other up on it.

That's something where there is room for improvement: upgrades. We have deployed the newer version, version 8 of Turbonomic. The problem is that there is no way to upgrade between major Turbonomic versions. You can upgrade minor versions without a problem, but when you go from version 6 to version 7, or version 7 to version 8, you basically have to deploy it new and let it start gathering data again. That is a problem because all of the data, all of the savings calculations that had been done on the old version, are gone. There's no way to keep track of your lifetime savings across versions.

Maybe there's a way that they can go and retrieve those specific bits of data, but so far I haven't seen how that happens. I would like to see them make major version upgrades work, first of all, because you can't currently upgrade to a major version. You have to deploy it to a new server. But at the very least, if we have to deploy it to a new server, give us a way to pull in that lifetime savings information, and track the information they've built up. We've had the same one for almost two years and it would be nice to keep all that tracking information for future reference.

I'm not involved in any of the billing, but my understanding is that is fairly expensive. 

It would be great if the price of the solution would scale with the amount of money that you are saving in the cloud. If the solution itself cost, say, $300,000 over the course of three years, it should be saving you $750,000 in cloud spend. They should make it worth it. At this point, I don't think there's any built-in tool to show you if the price that you're paying for Turbonomic is worth the cost savings that you're getting from it.

Or maybe the licensing and pricing could be done in tiers. If you had 100 virtual machines in the cloud, they would sell you licensing for 100 machines, and then 500, and then 1000. It would help if they did it in tiers so that you're not paying a massive amount of money for Turbonomic as a whole, and not saving as much as you were hoping.

I don't think Turbonomic provides you with a single platform that manages the full application stack. It manages a lot of the infrastructure stuff, Layer 1 through Layer 3 of the OSI model. It's mostly focused on infrastructure and making sure your infrastructure isn't over-provisioned. I wouldn't say it could all the way through the application.

Optimizing application performance on a continuous process is beyond the scope of a human to be able to do on a consistent basis. In other words, if you have 20 virtual machines, it's reasonable that a human could watch the utilization and determine size changes as needed, but if you're getting into hundreds of virtual machines, it becomes a task that's beyond the ability of a person to do by himself. It's a question of scale. As you get into hundreds of VMs, it becomes too tedious to keep track of and it becomes very time-consuming as well. Having said that, we don't use Turbonomic for that. We don't use it to manage any applications. We only use it to manage virtual machines.

We have only just started using containers. We haven't gotten into letting Turbonomic manage those containers. That's the only other thing that we would probably use it for at this point: managing the containerization. We use it right now for just cloud. We're pretty solid on on-prem because we've been doing a lot of migration of our on-prem stuff to the cloud. So we actually have a lot of compute resources available on-prem and we're not really worried about running into any resource issues.

Before Turbonomic, there was no person or group of people managing those aspects of our environment that it manages for us, but if there had been then, obviously, it would have reflected time savings at this point.

The primary use case is to optimize our environment. We will take our OpenShift environment and use Turbonomic to monitor the size of the pods, then determine where to place the pods as well. We will make recommendations from that perspective. Turbonomic is an excellent product as far as we are concerned for managing the pod sizes and determining the best sizing for those pods. Right now, our development staff prefer to maximize the size of their pods and requests in terms of memory and CPU, and that causes us to potentially run out of resources.

We are managing the pods, their performance, and the utilization. It is more of a pod deployment model. Right now, we are monitoring the whole application as well as its allocation of resources, CPU, memory, etc. So, the application will be optimized and Turbonomic will help us optimize that sizing, because that is a problem right now.

We will be deploying this solution across all our OpenShift platforms to manage our existing environment.

The most valuable features have been the resizing, then the allocation of resources and where to run the pods. Those have been a huge success for us. It is a self-funding initiative in that regard.

Turbonomic provides specific actions that prevent resource starvation. Potentially running out of resources is a possibility. Now, we have an overallocation of resources. However, each time we use the resources, we incur additional costs from a licensing perspective. Turbonomic allows us to maximize our resources before we have to utilize additional resources. 

We like that Turbonomic shows application metrics and estimates the impact of taking a suggested action. It provides us a map of resource utilization as part of its recommendation. We evaluate and compare that to what we think would be appropriate from a human perspective to what Turbonomic is doing, then take the best action going forward. So far, we like exactly what we see from the product. It is very powerful.

After running this solution in production for a year, we may want a more granular approach to how we utilize the product because we are planning to use some of its metrics to feed into our financial system.

We have been currently using the product in our OpenShift environment for about six months. We did a PoC starting last Fall. We are now in the process of implementing it in production.

So far, the stability has been good. There is always room for improvement, but so far we have had no complaints from our team in regards to the product and how it operates in the OpenShift environment.

The technical support is outstanding. We have had a great relationship with the Turbonomic folks from the beginning. They have given us some excellent resources. Their support is five-stars.

We did not use another product. We are not replacing anything. We were familiar with the Turbonomic product in the context of our VMware environment. We thought it was the ideal product. Because of the way it calculates things, we also thought it was the right approach going forward. So, we went directly to choosing Turbonomic.

Our admins who deployed the technology said it was fairly straightforward. Because Turbonomic in OpenShift runs as a pod, it is fairly straightforward from a deployment model.

It is a relatively easy product to implement. If you're familiar with OpenShift, my OpenShift admins had no problems deploying it and working with the Turbonomic team. Their support has been great.

Phase one in deployment is to understand what actions would be from Turbonomic regarding resizing, then take actions based on those recommendations. After we are satisfied with what Turbonomic is doing, we will let Turbonomic take automated actions, which is phase two. We will be building a better trust relationship between our app and operations teams, when we allow Turbonomic to automatically deploy and take actions.

We like that Turbonomic provides a proactive approach to avoiding performance degradation. In phase one, we will do a manual evaluation of the recommendations. Then, in phase two, we plan to have Turbo fully automated and take actions based on what it thinks the best resource allocation model is.

We have two separate OpenShift clusters. We will be deploying one environment with more than 100 nodes and the other one with more than 50 nodes.

Working with Turbonomic consultants, the deployment was probably a couple of days. That was more to familiarize ourselves with the environment, what the commands were, etc. It was not a function of the complexity of the tool.

We don't have many people working on the product. We have about three people going through the testing and PoC environment right now and setting it up for deployment in our dev stage, and then finally in our production environment. There are about three individuals working on that. 

Because the product is self-managing in many ways and runs the way that it does, i.e., it runs as an application inside of OpenShift, I would probably dedicate half a resource from the OpenShift side to managing Turbonomic over the long-term.

While we are in the process of deploying now, we did a calculation and think that we definitely will be showing value and savings. Our expected ROI is 2:1. 

The product is fairly priced right now. Given its capabilities, it is excellently priced. We think that the product will become self-funding because we will be able to maximize our resources, which will help us from a capacity perspective. That should save us money in the long run.

I did some research on other products out there, but nothing met what I required from. Some of the products were cloud-only solutions, and that wasn't going to work for us because we are an all on-prem environment. However, we still think that the model that Turbonomic uses to make us determinations (its secret sauce) is actually the best thing out there.

You need to know OpenShift well to utilize the product. That is probably my biggest piece of advice. The more you know OpenShift, the better off you are when it comes to the product. The product can be self-driving in many ways.

We came in with a very specific set of goals, and Turbonomic has been able to meet those goals. We have had no real roadblocks so far

Our only context for productionizing is Turbonomic for containerized environments in OpenShift. We have taken a look at using Turbonomic for VM management, but that is not part of our initial work.

We are not running any cloud activities right now.

I would rate them as a nine out of 10. There is always room for improvement. For example, if they lower the cost, I could get a 3:1 ROI.

We typically use it for optimizing the performance and resource allocation of virtual machines.

It offers visibility and analytics for monitoring performance across our environment, starting from the application layer and extending down the stack to the underlying infrastructure resources. Specifically, it concentrates on optimizing memory and CPU resources as part of our focus on hardware and environment optimization, without delving into additional aspects.

There was a single project where it helped us reduce the size of hundreds of VMs. This represents the only example with which I am familiar.

It's important to note that optimizing the monitoring of our private cloud is not the primary function of this tool. It is specifically utilized for optimization purposes. We employ it for tasks such as trending predictions and VM utilization performance. However, for monitoring, we rely on a completely different tool.

It has resulted in cost savings, specifically at the infrastructure layer.

The primary features we have focused on are reporting and optimization.

I have been working with it for more than five years.

It has proven to be highly stable.

I haven't directly interacted with tech support, but based on what I've heard, the overall experience was satisfactory.

Maintenance is necessary, and one person is sufficient for the task.

Overall, I would rate it eight out of ten.

We use the Reserved Instances and the recommendations of sizing of our family types in Azure. We use it for cost optimization for our workloads there.

We started with the on-prem solution, but then we went with the SaaS model. Now, Turbonomic handles the installation and the support of the appliances.

The volumes feature lets us know which volumes or disks are not attached or that are not being used anymore and that we can go ahead and delete them. It tells us how much money we'll be saving if we delete them. It's the same thing with Reserved Instances. It has that ability, that visibility, with those recommendations. 

There is also the family type that tells you which family the VM is going to and how much you're going to be saving. Disk tiering is one of the latest features. If you go from premium to standard, it shows you just how much you're going to be saving. It makes those decisions based on metrics.

When it comes to cloud costs, to VMs, the solution is saving us about $30,000 a month. It has also definitely reduced our IT-related expenditures by about $40,000 per month. And when it comes to the human resource time involved in monitoring and optimizing our estate, it saves us about 20 hours a week.

The recommendation of the family types is a huge help because it has saved us a lot of money. We use it primarily for that. Another thing that Turbonomic provides us with is a single platform that manages the full application stack and that's something I really like. 

One other useful feature in Turbonomic is the support for Kubernetes. That's one of the things that I have worked on with Kevin, our account rep, from Turbonomic. We're going to work on setting that up because our developers are pushing hard for Kubernetes for containers this year. Knowing that it's supporting that is awesome.

Something that Turbonomic started doing, just a couple of months ago with one of their latest releases, is the potential savings when it comes to disks. It is very promising. They make recommendations based on the type of disks. For example, if you're using a premium SSD, it makes recommendations, based on I/O metrics, to go to a standard SSD. Those types of recommendations are very valuable and that's another area where we see cost savings, which is awesome.

One ask that I'm waiting for, now that they have the ability to make recommendations for disks, for volumes, and disk tiering, is all about consumption. For example, we have a lot of VMs now, and these VMs use a lot of disks. Some of these servers have 8 TB disks, but they're only being used for 200 GBs. That's a lot of money that we're wasting. In Azure, it's not what you're using. You purchase the whole 8 TB disk and you pay for it. It doesn't matter how much you're using. So something that I've asked for from Turbonomic is recommendations based on disk utilization. In the example of the 8 TB disk where only 200 GBs are being used, based on the history, there should be a recommendation like, "You can safely use a 500 GB disk." That would create a lot of savings. And we would have more of a success rate than with the disk tiering, at least in our case.

Also, unfortunately, there is no support for cost optimization for networking.

I've been using Turbonomic for about three years.

It was definitely more stable on-prem. The reason I say that is because we've had several times where we have run into licensing issues. I don't know why that has been the case, although they have been few and far between. 

But when it has no issues, it runs just as if it were on-prem. The performance and the stability are not a problem.

It's a mature product. It very quickly detects when new VMs, new workloads, are added. You don't have to wait long. The tool picks things up very quickly in our environment.

Their technical support is excellent. I would rate them a nine out of 10. Whenever I send an email, they respond back. The only reason I don't give them a 10 is that I have been waiting for some time now on the Reserve Instances to work again. That's the only thing that has been a downer because we rely on them heavily. We are now having to use the Azure tool for that, and before the issue with Reserve Instances, we didn't have to. There's a lot of overlap between Azure on Turbonomic, but Turbonomic works better for us.

An aspect of the Turbonomic team that I have found, working with them over the years, is that whenever we've had an issue, they have always been willing to listen and to address it and to add the features we need. For example, when we started, Reserved Instances was really not up to par. But they listened to their customers and they started making changes. As time has gone on, the product has matured. They've incorporated a lot of the features that we've asked for into their appliance.

We tried it first on-prem, years ago. We used to host it. I installed it and updated it, working with the Turbonomic team. When it was hosted in our environment, I was responsible for everything.

The initial setup was straightforward. Because it was an appliance, the deployment took about an hour to stand it up. We use VMware on-prem so it was done with an OVA file, and it was pretty much a "next-next" process because the OVA is already packaged with how the tool should be deployed. There are certain custom inputs needed, like the name of the appliance, and how much storage. But everything else was already pre-packaged. The configuration definitely took a little bit longer.

The only downside was that Turbonomic came out with many releases. The latest releases had the latest features, but it required continuous upgrades. If we wanted to take advantage of one feature we continued to have to upgrade the appliance on-prem. That is why, when we found out that they do have a SaaS model, we went with that instead. We wanted Turbonomic to worry about things like the licensing, the updates, et cetera. We don't have to worry about that at all now, and that has been a huge relief. That has saved us a lot of time, for sure.

We didn't have to do any type of migration to their SaaS offering. They took care of everything in the back end.

We have five engineers who use the product, including a networking engineer, a storage engineer, and our DevOps team.

There are competitors out there. Since we're in Azure, which is the only cloud vendor that we use today, it has something called cost Azure Advisor, to help you with costs. I've tried it because it comes with it and we're paying for it, but Turbonomic is a better tool for us. We always seem to gravitate more toward it because everything is right there in that single pane of glass. It gives you recommendations based on Reserve Instances, even though right now, unfortunately, that's not working 100 percent. It does a lot of things, like the family types and the deleted volumes, and that type of automation for us, which is awesome. Azure Advisor does give you that as well, but it doesn't have everything. We have to drill down in it and it's not easy to navigate.

At one point the most valuable feature for us was Reserved Instances. The only problem with that today is that last year we changed from the EA licensing model to an MCA. At this moment, unfortunately, the Reserved Instances is not working. They're still working on it. It's in the roadmap, but that definitely was a big selling point for us. It worked well for us because we purchase a lot of Reserved Instances for our VMs.

Turbonomic makes a lot of recommendations to help prevent resource starvation. We can't implement all of them because it depends on our workloads. Not all the recommendations work for us because workloads on some of our VMs are very seasonal. There may be three times throughout the year, for about two weeks, where those VMs' usage is very high. They have to work at a high level. The solution can only go back a maximum of three months, and it won't work for us in some of those workloads because it doesn't have full visibility into the past year. But for some of our other workloads, those recommendations work.

Optimization of application performance is an ongoing process for us, especially as we move VMs from on-prem to Azure, or even build new VMs in Azure. More apps are being created and more services are being created, and we're taking advantage of that within Azure. However, we don't use Turbonomic's automation mode to continuously assure application performance by having the software manage resources in real-time. Our DevOps team is using Azure to control that automation.

For us, Turbonomic is an infrastructure service, VMs. As for applications, not yet, because now that we're introducing Kubernetes into our Azure environment, while it does have support for that, I don't know what it looks like yet. I have a meeting scheduled with them in order to configure that. It doesn't create it for you automatically in the back end. But it's more for our IaaS, infrastructure as a service. For storage, the closest thing now is the disk tiering with recommendations for going from and to different types of standard and premium SSD and HDD disks. Before, there wasn't that level of support. It was just VMs and family types, in our case.

We use manual execution for implementing the solution’s actions. We use manual because it depends on the business. We run a 24/7 shop. That's how it has always been on-prem, and that's how it is now in Azure, for our production VMs. We need to schedule maintenance windows because some of the recommendations from Turbonomic require a reboot. We need to schedule downtime with the application owners within the business.