IBM Turbonomic Reviews

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

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.

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 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.

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.

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 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.