What advice do you have for others considering Turbonomic?

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.

I would definitely recommend a trial. It is a very good product, and it is worth its weight. It is something that is invaluable to most customers. I would rate Turbonomic a nine out of ten.

Overall, I would rate it eight out of ten.

I rate Turbonomic nine out of 10. It goes into a lot of detail about what you know and your opportunities, but there's always room to improve.

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.

My advice would be to come up with an agreement, in writing, that support on the product will have quarterly touch-point meetings to discuss what's new, what has changed, and what upgrades there are. Those quarterly touchpoints would be an ask, for me, if I had to buy the product again. For the initial deployment, I would recommend some sort of professional services engagement from IBM, just to make sure that you're utilizing it to its best potential. If you're looking into Turbonomic but already have a process for optimizing your environment and for monitoring, I would suggest doing a comparison between what you have today and what Turbonomic can do. Do a like-for-like on the functions you use today and ask if Turbonomic does the same and whether it does it better. Also, you need to look into the licensing model. Be ready with those questions. You want to make sure Turbonomic will be a suitable replacement and not fall short because your current tool does more. In terms of understanding when a performance risk exists, the solution does help to a certain point. It says "increase," or "decrease." But it doesn't give explicit information as to why. It doesn't say, "This system has been running hot for X number of days or weeks." Those kinds of details aren't there. It just provides a recommendation. I would rate the potential of Turbonomic as a seven out of 10. I love the fact that there is slight automation, if you let it do that automation, and the whole forecasting piece is really good. It's a pretty good solution.

I rate Turbonomic an eight out of ten overall. I recommend evaluating it. Turbonomic might be easier than the product you currently use. You might be able to use the DRS mechanism in Turbonomic to get recommendations, and auto-sizing could make your life a lot easier.

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

I rate IBM Turbonomic a nine out of ten. Before implementing Turbonomic, you should do your research. Check the documentation to see if Turbonomic's processes make sense for what you're doing and if your current setup will handle all the different aspects of Turbonomic. If your current solution does 85% of what you need, and Turbonomic does 87%, I don't think that's enough to switch products. If your solution meets 80% of your need, and Turbonomic does 98%, why wouldn't you change? What do you need to do? I can flip a quarter or half-dollars instead of quarters. If all you're doing is flipping dimes, do you need something that flips half-dollars? I'm frugal. I worked for a 501(c)3 nonprofit most of my life before I came to this college. I look for bang for my buck and stability. I used to describe to other system admins that I may not have the flashiest new Volvo turbo diesel truck that goes up the hills. My Peterbilt with a CAT diesel may smoke and have a little rust on it, but in the middle of a subzero blizzard, it's making that hill while yours is gelled up at the bottom. Take a long, hard look at the pre-generated reports and how it holistically checks your system from top to bottom through the tree to see if that's a good fit for you. You can't change that tree. If the homepage tree doesn't work for you, then Turbonomic won't work. There's not much I know you can do to change that. If that tree makes sense to you, then look at the reporting. Look at how it evaluates load balancing based on shares instead of just the overall weight that VMware does. Turbonomic uses market shares. They turn it into a cost market share to help adjust. It will tell you if a CPU load is heavy. It will give you recommendations to adjust the size. We're not going to move it right away because what is mission-critical is over here, and we don't want to impact that. VMware looks at how heavily the CPU is being utilized in the VM and says, "Well, I'm going to slap that over here," arbitrarily. Turbonomic has a share you set up. Think of it like stock market shares. That share went up, but it's not a blue-chip stock. We try to move it over to where the blue chip stocks would take a hit. We move it someplace that's a lesser value, so to speak, once machines are of lesser value.

I've been using Turbonomic as it moved from different versions for about three years. Right now, we're on the CWOM version of Turbonomic and its version 3.7. We're using it on-prem and we also are using Turbonomic for just cloud reporting. Turbonomic would be one of the best in terms of application awareness. Just being able to see different applications and see their usage is great. I'd advise potential new users to do a proof of concept and try it. It's an excellent product and the level of savings, as well as the reports, will really give them hands-on experience in the environment to get arms wrapped around everything. It's an excellent product that has paid for itself. For someone looking into Turbonomic that already has a process to optimize their environment and monitoring, it's a good idea to work with somebody in technical support to see if there's something that you could get Turbonomic to help you with. You should evaluate it for savings, test it out and do a proof of concept as well. Turbonomic is hands down one of the best products. I'd rate it ten out of ten. It does a really excellent job of reporting, handling placement, measuring resources, and increasing or decreasing those resources. Overall the product just sells itself. It has been very helpful in the cloud and on-premise.

We are not actively managing workloads in the cloud but it is something that we plan to do in the future. We are using Kubernetes on-premises, although we're trying to get more engagement from that team on the product. Importantly, the right-sizing on-premises is setting up our next steps in moving toward the public cloud, and toward that consumption model to the best that we can. We may utilize Turbonomic in the cloud. The licensing switch that we went through really opened up not only the ability for us to easily scale to other private cloud environments that we have outside of our main one but much more easily scale to the cloud when we're there. I definitely would consider this tool to be a requirement as we start deploying infrastructure out in the cloud, just to help us understand that we're sizing to the best that we can. My advice for anybody who is implementing this solution is to utilize it to its fullest potential. This will include aligning your company's culture. The foundation of the product is putting resources where they're needed, and this is done based on actual data. The politics have to be thrown out the window. As long as that can work in your organization, then this is a great tool that can configure your environment to run optimally. For someone that is interested in Turbonomic, but already has a process in place for monitoring and optimizing their environment, then this is something that should be evaluated. I can't say that it will replace the existing product but there is more at stake. For us, it's the support and the team that come with the product. This is what surprised me the most and something to look out for. Overall, Turbonomic has had a positive effect on our application performance. It's helped on many different levels, including toward the resolution of problems. It's even helped flat out prevent problems from happening in the first place. I would rate this solution an eight out of ten.

I rate Turbonomic 10 out of 10. For anyone thinking about implementing Turbonomic, I would suggest having someone familiar with Kubernetes — the more familiar, the better. You need someone who knows how to run a Kubernetes command to see what's happening with the state of the Turbonomic deployment if necessary. If you've got someone who knows how to use Kubernetes, include them in the deployment process.

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.

It doesn't pick up the entire supply chain automatically. It requires minimal effort in configuration. We have to show a relationship in a sense that this workload is associated with another workload. However, once that relationship is established, the solution helps us manage our business-critical applications by understanding the underlying supply chain of resources. Our capital expenses are relatively flat. We are not purchasing any new equipment. We are actually in a consolidation process. Everything is getting moved to the public cloud. From an operational perspective, with our workloads being in the public cloud, it has provided us: * The ability to identify what we have running in the public cloud and how much it will actually cost us. * How we can reduce public cloud operational costs, e.g., what actions can we do to help reduce operational expenses in the public cloud? It identifies areas where we can delete storage that is not being used. We can address right-sizing workloads that are overprovisioned in the public cloud as well as logging in long-term commitments with workloads in the public cloud and saving on incidents, on average for us, over 33% or higher for our workloads, as opposed to just paying the pay as you go hourly rate with the provider. Try to look at things, not just from a cost savings perspective, but also from performance avoidance. We looked at: How do we quantify our spend in the public cloud and how do we avoid our spend in the public cloud? But we always forgot that there were workloads out there that do have performance impacts. So, we counted this as a cost savings and cost optimization tool, but it became so much more than that. We developed a crawl, walk, run approach. We took some workloads in our public cloud and looked at the business decisions. We took the decisions, then we tested to see what the outcomes were with them. As we went through those actions manually, gained the confidence on how those actions were being made, and what the post impact of that was, that allowed the business to become more confident in the tool. We no longer needed to have meetings to discuss why we were doing what we were doing. It then became a point of communication. An action would be taken because Turbonomic said it was the right thing to do. Nowadays, it's not even questioned. When I talked to people about trying out Turbonomic and looking at how to adopt it in their workload, I say to look at areas which are current pain points in your environment and see where Turbonomic would fit into that instead of trying to come up with the workloads or use cases to plug into Turbonomic. Instead of trying to figure out what you have or seeing where you could put Turbonomic in your environment, see where your environment fits into Turbonomic. That was the way that we were able to drive adoption much faster and use it, not just as a reporting tool, but also as an orchestration tool as well. They have some room to grow. I wouldn't give them a perfect 10. I would probably give them an eight and a half or nine (as a whole number).

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.

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 are using it mainly to manage the resource utilization for our virtual environment. We are using it for project planning, like the Windows 2008 upgrade with the infrastructure that needs to be built out for that. We are using it to manage our cloud expenses and the utilization within the cloud, which then drives cost reductions there. In the last few months, we started to do the application tagging so we can start to get down to specific application dashboards. This year, we want to start to drive more of the automation to reclaim unused resources, so I can then go ahead and delay further purchases. Our plan is to continue driving up the density of the environment. Right now, we have certain tasks that get automatically done today. We are working on the piece which does the scheduling, using the change tickets, because we wanted to ensure there was an audit trail so we had an interface with our ticketing system worked out. So, we are getting ready to do that. Adding resources throughout the business day is no big deal, but we want to make sure we don't remove any resources (during the business day). We want to do this during a maintenance window to ensure that there will be no business impact. It is just being ultraconservative and sensitive to the business's needs. As they get more comfortable, we will continue ratcheting up the level of automation that we use. Everything is very specific with Turbonomic. We can take manual action throughout the day, if we see that it is necessary. We can have Turbonomic take certain specific actions automatically, then we can decide which ones we want to actually schedule so we can link them to approve change tickets. It will show application metrics and estimate the impact of taking a suggested action from infrastructure resource utilization. I don't know if it will get down into the transaction level performance. I think the new release does that, but we haven't tested that piece out. However, this is the planning piece, e.g., if I were to remove the CPU, what would the performance and utilization look like? Or, in the case of some stuff that I was recently looking at, if I were to add the CPU, what does that do to the overall utilization metrics? You can then decide: Do I want to take that action? The biggest lesson learnt is probably that people are afraid of change. Our biggest hurdle was putting their faith in automation versus we have always done it this way. We have always been oversized so the application teams would make sure that we never run out of resources, but they needed to be open to change. My favorite analogy that I like to use with them is, "I understand it is hard because instead of you telling me, 'I want this many CPU or this much memory.' I'm telling you trust me." It's like the gas gauge in your car. Don't look at the gas gauge when you get in your car. Just trust me that I have put enough gas in the car for you to get where you are going. It's a very difficult mindset for application teams who are used to saying, "Okay, I have eight CPUs over here. Don't touch them." But, Turbonomic actually gives us the data to show them, "You have eight CPUs over here. You'll never get above 40 percent utilization, so you are costing us money." So, it is fact-based decision-making. My advice is, "Go for it." Don't let other teams hold you back because this is how they have always done it. Trust the Turbonomic team because they are great at being able to implement, and they are ready to move fast. Make sure you get all the right stakeholders, because we have had to deal with everything from: * Engineering * How do we do an internal chargeback? * The application team's perception that I can't run with anything less than this. Get ready to be able to put some facts on the table and lean on the Turbonomic team because they are just phenomenal at helping put together business cases and doing the implementation. However, also get ready to tell your people to go for it. Don't be saddled with, "This is how we've always done it," because technology changes. I have seen nothing in my infrastructure career that was as great as this product when it comes to resource utilization. I would give them a 10 (out of 10). The tool does what it says, and the Turbonomic people don't sell it to you, then disappear. They are always there and a pleasure to work with.

I target it at the cloud to get a baseline against other tools, e.g., which ones we are going to go with long-term. Turbonomic, in our cloud, points towards development environments, not production environments. We are not really application-specific. However, it does work well with the monitoring and ensuring performance. I can identify a performance issue just by opening the dashboard, even if I am not necessarily looking for one. I would give it an eight (out of 10). It is a really good product.

We are installing the Kubernetes version of Turbonomic now. Then, it will be able to see application issues when they come up. Once we transitioned to Turbonomic version 8, we will be able to see the application side of things, which we were not able to see before. Application performance wasn't even something we considered until Turbonomic 8 was announced and revealed to us. This will open a whole new door for us in terms of savings that we probably never even considered in the past. I am pretty impartial to Turbonomic. I have not used anything to optimize cloud previously, but I'm going to base my rating solely on the support that we have received, the engagements that we had, the attention to detail, and the overall feel of the company and the interactions in the software. I would rate it as a 10 (out of 10).

Unfortunately, a lot of our infrastructure in the cloud is still legacy. So, we can't make full use of it to go out and resize a server, because it will bring the application down. However, what we are doing is setting up integration servers now. This puts a change control out to make the recommended change and the owner of the server can approve that change, then it will take place within a maintenance window. We don't manage resources in real-time. Most of our applications just don't support that. We don't have enough changes required that it would be mutually beneficial to us, so we aren't doing that yet, but we're headed in that direction. It would be a big stretch for us to actually use Turbonomic to take resources away from servers. Our company has a philosophy, which was decided four or five years ago that the most important thing for us is for our applications to be up. So, if we waste a little money on the infrastructure to bolster applications when there is a problem, that is okay. We even have our own acronym, it's called margin of error (MOE). Typically, we are looking to have at least 30 percent free capacity on any server or cluster at any given time, which is certainly not running in the most efficient way possible, but we're okay with that. While we may spend three million dollars more a year on infrastructure, an hour long outage might cost us a million dollars. So, if there is a major problem with it with big performance degradation, then we want to have the capacity to step up and keep that application afloat while they figure out the issue. It projects the outcome of if you are going to move from one set of infrastructure to another, then it will make a recommendation. For example, if I'm moving from one type of server to another type of server where there are different core counts, faster cores, and faster memory, then it will tell me in advance, "You need fewer resources to make that happen because you are moving to better equipment." Biggest lesson learnt: What you should do is the obvious, it is just difficult to get people to do it. You need to have servers grouped and reported up to an executive level that can show the waste. Otherwise, you are working with server owners who have multiple priorities. They have a release that's due in two weeks which will impact their bonus at the end of the year, etc. If you hit them up, and go, "Hey, you're wasting about a thousand dollars a week on this server, and more on the others, so we need to resize them." They don't care. On an individual application or server basis, it's not a big deal. However, across a 26,000 server environment, $10,000 here or there pretty becomes real money. That is the biggest challenge: competing priorities. You have one group trying to manage infrastructure for the least possible amount while getting the best performance, and you have other people who have to deliver functionality to a business unit. If they don't, the business unit will lose a million dollars a day until they get it. Those are tough priorities to compete with. Build that reporting infrastructure right from the beginning. Make sure you have your applications divided up by business unit, so you can take that overall feedback and write it up when you are showing it to a senior executive, "Hey look, you are paying for infrastructure. You are spending a million dollars more a month than you should be." I would rate this solution as an eight (out of 10). It is a great app. The only reason I wouldn't give them a higher rating is from a reporting standpoint. That's just not their focus, but better reporting would help. We use an app called Cloud Temple with them, who is actually a partner of theirs. Turbonomic will tell you reporting is not what they see as their core competency, and they are going to take actions to optimize your environment. However, at the same time, they have done these partnerships with another company who does better reporting.

Something we need to do is make the solution aware of business-critical applications by understanding the underlying supply chain of resources. We need to make it aware of what's critical. We do that by setting up clusters and then setting certain policies on what is in each cluster. We separate critical things through clusters.

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.

If you have a big shop, and it's scattered all over the place, then definitely take a look at this tool. Make sure you take a look at this tool because there is probably fit for purpose licensing for any size organization. It's a great automation process. Turbonomic shows application metrics and estimates the impact of taking a suggested action based on its input from AppDynamics. So, we plug it into AppDynamics, then AppDynamics and Turbonomic seem to work together for that. It knows what business-critical applications we have, but I don't think it manages anything specifically within the application itself. It is mostly just resource-driven. As money starts to get tight and budgets start to get really scrutinized, I think people are going to have to start looking at using Turbonomic to help optimize cloud operations to reduce cloud costs. We are going to continue to use it going forward. I just don't know at what level. There are a lot of changes being made to the infrastructure, so it's going to depend on the tools and things that become available, like VCF as well as all the products that they have built-in through vROps, enhanced vROps, and things that already come with the software. I would rate it an eight (out of 10). Personally, there is a lot that it does that a regular person like me does not have the time to sit down and dig into it. We expect things to be a little bit more automated. That is why I gave it an eight. I would give it a 10 (out of 10) if I got in there and it's like, look, click, click, and click. However, I don't know if there is that kind of a comfort level here yet to just let this thing go and have its day with the place.

If you're looking into Turbonomic, just do it. You will not regret it. The biggest thing that I've learned is that you don't realize how much your hardware can do until it's truly balanced. Some people operate foolishly and they just won't step up because they're being cheap. Other people want to be ultra-conservative because they don't ever want to have a problem, but using software like this, you realize that there is a balance. If you trust the software, you get to utilize your hardware better while still feeling like you have those reserves available without putting yourself at risk by being foolish. It provides a single platform that can manage the full application stacks, but we're not using that aspect. Our developers are not interested in using it yet. We're in the process of looking for a new monitoring software as well, and I'm pushing heavily for them to look at SevOne but we've had some unfortunate experiences with the people at SevOne. If we go down that route and start using SevOne, my boss is going to lean on them much more heavily to start integrating with Turbonomic. It only handles virtualization right now, for us. It's probably going to start handling cloud soon, because we're just starting to migrate things there. We have some things in the cloud, but we're looking at moving quite a few other servers up to Azure. The solution understands the resource relationships perfectly, on-prem. From what I have seen so far of the cloud piece, it seems to understand that, mostly, although the cloud is still fairly new compared to on-prem infrastructure. I have no doubt that they're going to make huge strides and make that part even better. I don't know that it's as good in the cloud as it is on-prem. We have used it a little bit in some testing, but we haven't run it in production for any long periods of time. But we're really hoping it reduces our cloud cost at some point, because those cloud vendors really take advantage of every ounce of I/O that you use. Honestly, on a scale of one to 10, I would give Turbonomic a 12. It's way better than a lot of software. Other solutions look really shiny—and if you're like a fish and all you care about is like looking at something shiny, that's one thing—but when those products are delivered, they don't do half of what they say they're going to do. They'll say, "Oh, that's in the next release," or "Oh, we're working on that". Turbonomic was very upfront about what their software did. Yes, they had a few bugs, but they were also just opening at the time. We expected that in the beginning because it was a brand-new company. But what they told you it would do, it did, and it did it well, too. Nowadays, that's hard to find.

Wonderful account team and support. Training is exceptionally thorough.

The sales team was amazing in helping put together a slide deck for me to sell the solution to Management and also were able to negotiate pricing within our budget to help get us on-board.

I highly recommend this product, particularly if you have a heterogeneous virtual environment.