IBM Turbonomic Reviews

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 wanted the performance assurance because we have seasonal spikes in our volume. One of the use cases was making sure that we could adjust for seasonal spikes in volume. 

Another use case was taking a look at how we increase our density and make a more effective utilization of the assets that we have on the floor. 

The third use case was the planning, being able to adjust for mergers, acquisitions, divestitures, and quickly being able to separate out the infrastructure required to support that workload.

We just upgraded and are using the latest on-prem version. 

We use Turbonomic for our on-prem hosting: servers, storage, and containers. We also use it in Azure. We are trying to use it across multiple hosting environments. The networking team is not really using it. Instead, I am there from a hosting standpoint, where the main focus is on servers and storage, then the linkage to applications with the resources that they are using.

It integrates into our other tools that we have been able to stitch together. When I take a look at an infrastructure cluster, I can see what applications are running on it. I can see down to the transaction level who is actually causing a performance constraint. We can then go back to our application teams to get that issue resolved.

When I start to take a look at a cluster level, I can look to see which application is running in that cluster. Then, we can get down into specific transactions. We can then watch to see how workload is trending and identify where we may need to add more hosts into the environment. With our transactions, we use Turbonomic linked into AppDynamics. When it links in and pulls the application data, it also helps us dig down. So, if I see my utilization trending up, then is it something on the infrastructure side or the application side? Is it something the application team needs to address? Or, is it something my infrastructure team can address? This allows us to make fact-based decisions.

In our organization, optimizing application performance is a continuous process that is beyond human scale. We would not be able to do the number of actions that Turbonomic takes on a daily, weekly, and monthly basis. It is humanly impossible with the little micro adjustments that it can make. That is a huge differentiator. If you just figure each action could take anywhere very conservatively from five to 10 minutes to act upon, then you multiply that out by thousands of actions every month, it is easily something where you could say, "I am saving a couple of FTEs."

On Windows 2008, whenever we did a large scale OS upgrade, it was kind of taking a look at what resources were allocated to each of the applications and server instances. Then, you basically would replicate that. Being able to use Turbonomic, we have been quickly able to go through and take a look, and say, "Okay, wow. This may have been what was previously allocated to you. We now realize that your utilization doesn't require that level." We are able to actually downsize as we go through and rebuild. This part, the planning aspect, is really good.

One of the things that we completed this year was starting to tag applications so we can pull up more critical applications and take a look at their resources needs. We can have a specific dashboard per critical application.

For performance assurance, I love the dynamic resource allocations. We don't have any nuisance performance issues. 

When you take a look at the utilization of our resources, it is great that this solution works both on-prem and in the cloud. We have been able to identify some quick saves in the cloud, and then on-prem, with their algorithm. So, we have been able to go ahead and increase our density by about 35 percent, which has delayed purchases of hardware.

Turbonomic provides specific actions that prevent resource starvation. One of the best features about using their algorithm is it can go through and tell me that I have a specific server instance or virtual image that needs either more CPU or memory added, tell us "These are the ones that aren't using the resources." Then, we can decrease the allocations to those server instances. The nice thing about this is we can schedule which of these activities you want Turbonomic to do automatically for us.

Monitoring and thresholds are very reactive, so somebody would have to be sitting there with eyes on glass, taking action. Whereas, with Turbonomic, we now have our thresholds set, and it automatically takes those actions.

The reporting is good.

It would be nice for them to have a way to do something with physical machines, but I know that is not their strength Thankfully, the majority of our environment is virtual, but it would be nice to see this type of technology across some other platforms. It would be nice to have capacity planning across physical machines.

Between my two companies, I have been using it now for about four or five years.

The stability has been wonderful. We have never had any issues.

The scalability is great. There is no problem with scaling.

There are about a dozen people from engineering, operations, and capacity who login and use the data to make decisions. It is a hands-off type of product. You only need a couple of key people from the different use case areas to use it.

What is really impressive with the Turbonomic team is that after you sign the deal, they don't disappear. In the two and a half years in my current position, Turbonomic has been right there, whether we have an issue, which is very rare, or we are trying to still complete the objectives of the purchase, such as integrating our use cases. The Turbonomic team is very supportive and hands-on with you. I can't say enough about their customer support because it helps drive the value faster. They are always right there working with my team as part of the team.

Turbonomic is a real partner, which is a really good thing. I have been in IT my whole life, decades, and there are way too many vendors that once you make the sale, that's it. You are now at the bottom of their pile because they are chasing the next sale.

Before I came to this company, my previous company was using this tool extensively. At my previous job, I had seen the benefits of the tool. When I came over to this company, it was one of the first things that I started to champion.

I have been with the company for three years, and we have used a tool called VMware DRS. We are a heavy VMware shop, and vROps wasn't anywhere near the level of automation needed. DRS, even though it can do some things automatically, it is all based on data pulled from the night before. We didn't have anything in the environment that could do the real-time automated resource moves, like Turbonomic does.

I think DRS is gone now. The engineering team still uses VMware for a couple of things, simply because that is their preference. vROps is still in the environment, but I would love to get to the point where we can continue showing success with Turbonomic and eventually eliminate vROps.

The initial setup was very straightforward. This is one of the very few tools which we were able to stand up and get it running within weeks. 

It is a very simple product to install, then there are just a couple of configurations to tweak. Then, you are up and running. They literally tell you what you need. It's like, "Here are the requirements: You need X number of virtual images - this level." It has very simple instructions. We probably had it installed in one day, then we had everything reporting within a couple of days. After that, we did the tuning, mapping, and everything else. Within 30 days, we were probably getting useful data out of this tool.

We just worked with Turbonomic. Cisco was our reseller, but they actually provide Turbonomic resources.

We have only two people involved with setup and maintenance. I have one main person with a backup person for him. That is how easy it is to set up and maintain. Our future plans are to migrate to the cloud offering probably later this year. Once we do that, that will free up one person.

The main guy is a Windows Server admin who supports the Turbonomic platform, but this isn't his only job. It is something that just takes up a fraction of his time. Once we go to the cloud offering, then the management of the tool goes back to Turbonomic and we will just be a consumer of the data.

When I first put the proposal on the table, we put in the proposal that we would get our payback within three years. We got our payback in 15 months. For example, we went through and increased our density, then we were able to delay the purchase of close to 200 servers.

We are very excited about the fact that it does integrate with ServiceNow, our service management ticketing system. It will go out there, and when it says, "I need to add CPU/memory," then it creates the change ticket for us. So, we can have an automated ticket created and get the approvals in place, then it is automatically executed and the ticket is closed off. This saves my team hundreds of actions every year.

When the application starts to see performance degradation, those tickets will go to their queue, but then they will get escalated to me. I can tell you that I have received almost no calls about, "My application is running slow." Before Turbonomic, during the busy season, it seemed like almost every day that I was receiving calls. So, there is definitely a huge drop in, "My performance is running slow," where you would then kind of scramble to find out, "Okay, why is it running slow?"

We use Turbonomic to help optimize our cloud operations and it has reduced our cloud costs. We have been able to identify unattached premium storage, paying for storage that we weren't using. We have also been able to identify instances that were assigned a larger template than was actually needed. So, we were able to then downsize them. This ended up saving us a significant amount of money by rightsizing those instances. 

By increasing our level of density, we have been able to delay hardware purchases. So, we have been able to absorb growth without hardware purchases. Without hardware purchases, we also save money on software licensing.

It has allowed us to deploy where our resources spend their time by focusing on other project or high-value activities with the business. There is less firefighting and more project work.

The pricing and licensing are fair. We purchase based on benchmark pricing, which we have been able to get. There are no surprise charges nor hidden fees.

We did have to go through and do a comparison of vROps, DRS, and Turbonomic in order for me to get it on board at the company.

The performance assurance and automatic allocations (the automation that comes with it) really drove our decision to go with Turbonomic. They have a level of automation that the competitors don't.

Turbonomic understands the resource relationships at each of the elements of our environment's layers and the risks to performance for each. That is part of what makes them a key differentiator, especially against something like a vROps. Their algorithm is based on: in the moment, what is being used, and what is needed. It will not make an automated move that may cause another issue. Whereas, VMware DRS would move stuff based on data that it had pulled the night before, which may not be valuable or still valid. At that point, you could move something that needed CPU, but you moved it someplace else where now there is a memory constraint instead of a CPU constraint.

A big deciding factor with Turbonomic was you can set how much trending data that you want to keep, whether it is a 30, 60, 90, 120 days, etc. You can set your trending there, then you can schedule your actions based on utilization over that time frame, e.g., the last 90 days.

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.

It has a feature called "right-sizing". This makes sure that our virtual machines are sized properly so we don't have a lot of wasted resources, either too large or too small. This way, our machines function much better than they should.

We have a system where our developers automate machine builds, and that is constantly running out of resources. Turbonomic helps us with that, so I don't have to keep buying hardware. The developers always say, "They don't have enough. They don't have enough. They don't have enough," when they just configured it improperly. Therefore, Turbonomic helps us identify configuration issues on their side so it doesn't cost me money on the other end to buy resources that I don't really need.

The solution handles some of our applications and cloud as well as giving us some insight into the storage aspect. While we have other tools, Turbonomic does give me insight onto my storage utilization as well. That part helps us with the virtualization stack. Turbonomic understands the resource relationships at each of these layers and the risks to performance for each of them, which helps us be a little more at the front of the game, giving us a little more insights to be more ahead of what we need to do.

To an extent, the solution helps manage our business-critical applications by understanding the underlying supply chain of resources. Some of our business-critical apps are our large virtualization stacks, and that is what our developers develop on. These keep our development environment running optimally so they can continue to develop without having to wait for resources.

It does suggest actions. It let us know ahead of time: 

• If we need to increase hardware.
• If we're okay.
• If we need to decrease hardware.
• What to expect during peak season.

The most valuable feature is the right-sizing. For my maintenance weekend, I can schedule it to right-size a subset of VMs every month. That works perfectly for me. It goes out on its own and tells me which machines need to be changed, then it will perform that function. I don't have to do any manual intervention. It runs its own report in the background. 

Turbonomic tells me ahead of time to prevent resource starvation. Going into the console, it tells me whether actions can be taken, saying, "Do you want to do these now?" Then, I can push a button and Turbonomic will do them. Or, I could simulate a load by saying, "Well, I'm going to add this, what will happen?" It will then tell me what will happen, so I can know ahead of time.

It optimizes application performance as a continuous process that is beyond human scale.

The solution helps us with troubleshooting issues in certain virtual environments. It gives you good information so you can drill down to different levels. You can get information to help you troubleshoot issues that you are seeing, whether it be storage-related or virtual machine-related.

They could add a few more reports. They could also be a bit more granular. While they have reports, sometimes it is hard to figure out what you are looking for just by looking at the date.

They could update the look of the console.

There are some manual issues. When it comes to forecasting dollar amounts, you have to put in all these inputs. Some of the questions they ask are a little outside of the realm that any engineer should be putting in. If they could streamline that, the solution would be much better.

I have been using it for about two and a half years.

It is very stable. I don't think it has ever gone down unless it was something that we did. If you have a good system that is sized properly, then it works well.

The solution doesn't require any maintenance on our side.

We schedule for change windows because a lot of the times the recommended changes will require a restart. So, we have to do them when they don't affect anybody. For a lot of what we are using Turbonomic, it will suggest actions that require restarts, shutdowns, etc. Those need to be done off-hours.

It scales well. If you need to scale up, you just purchase more licenses.

We have 6,500 endpoints, which are 95 percent virtual and five percent cloud.

We have our operations team who use it sometimes. Operations gets the first call about performance improvements. If someone calls or opens a ticket with them, and says, "Oh, I need more resources," then they will log onto Turbonomic and see if a machine is underperforming for whatever reason. 

My team is managing the resources for right-sizing and forecasting,

We learned that all we have to do is engage the Turbonomic team, and they will help us get anything that we need done. They will make feature improvements if we request them. They are proactive when working with us.

Previously, we used something out-of-the-box or homegrown, in-house scripts.

Upgrading the solution is straightforward. It is pretty easy.

When we are notified of an upgrade, feature pack, or patch, it is like a two or three step function to get to the next level. It is very non-intrusive and easy. It takes 35 to 40 minutes to upgrade or apply a patch, and the solution doesn't go down.

We keep it because we see ROI. For example, I had an issue recently, which was big, and Turbo helped me solve that problem. If we did not have this solution, it would have been a much bigger issue.

It has reduced our IT-related CapEx and OpEx, because you have a lot of people who complain that they need this and that. Those would be capital expenditures if we're buying more machines, and we really don't need them. So, we can just right-size a VM or an environment, and that pays for the capital and operational expenditures. The automation helps a lot with this as well. This has reduced our expenditures around 10 percent because I haven't bought anything in a while. I haven't needed to buy anything, except for replacements.

It has saved time. Without this application, I would have to do everything myself. That would take at least eight hours a month, because the right-sizing takes a couple hours, then I would have to prepare it.

It is an endpoint type license, which is fine. It is not overly expensive.

We tested Turbonomic against VMware vROps. Both solutions will tell you, "Oh, you should do this or that. This is an issue. You can do this." However, at the time that we tested vROps, it was an older version. They weren't offering the ability to schedule right-sizing and automating it, where Turbonomic does. vROps would just alert you, so you would have to do the right-sizing yourself. Therefore, vROps would have been a bit more manual with more operational needs.

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.

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're using it for placement automation. Turbonomic will look at the virtual machines that are on different hosts and it will say, "Hey, three are too many machines on this host. And this host doesn't have a lot of machines on it." It will place the virtual machines in a balanced way on different hosts and try to balance the hosts out as best it can.

We're also using it for CPU and RAM addition and automation: Do we need to add more memory or take away memory in the environment or look at a machine to see if it is being used to the best capacity?

We also use Turbonomic for planning. It takes a look at our environment and we can make plans, like if we want to put some of our environment into a cloud-based system, like Azure, it will tell us our costing.

We use it for about 4,000 machines.

Performance is something that should constantly be monitored and constantly be worked on. Turbonomic is doing that in the background, without me having to manually do it. It's a great help. It's monitoring something that I just physically couldn't do all by myself because the environment is too large. It's looking at the resources in any environment and taking snapshots of where things are. At the right time, it's adding or taking away resources, and that's helping make the environment more efficient.

Planning is another way it really helps because it gives us an idea of the cost to move. We wanted to move everything to the cloud. It helps us to figure out what it would look like and how Turbonomic could even help, if we want to do that. But more importantly, it gives us an idea of how much it would cost. We get a round figure of the cost involved.

It handles virtualization, cloud, on-premise, and storage for us. We're moving towards it handling applications. The solution understands the resource relationships at each of these layers and the risks to performance for each. It understands them and makes adjustments based on what's needed. It also lets us know, if we need to make some adjustments, where they are. It definitely does a good job with that. It's not only knowing where to put things, but it's doing it for us.

We use it for implementing scheduling of actions for change windows. We do that based on our service-level agreements. We have to have a certain level of uptime. We do things because of our change process and the way that we have systems going. It's best for us to do it at a scheduled time, when everybody knows that the system will be going through some type of change.

It helps us meet SLAs by making sure that the machine has the resources it needs to function properly. Also, when it does make changes, it does it during the SLA windows.

We also use Turbonomic to show application metrics and estimate the impact of taking a suggested action. We have it doing that based on things in clusters. We'll set something up in the cluster and then have it see if that cluster is being utilized to its fullest or if it's being over-utilized. It gives us visibility.

In addition, it helps optimize cloud operations and reduce our cloud costs. We're putting things on a certain type of storage and moving things to best fit our environment and give us the best cost for our environment. It will also give us an idea, before we put it there, of what the cost will be before we move it to Azure.

It saves me a lot of time because I don't have to do things to monitor the environment to see what machines need RAM or memory or need CPU taken away or added. It can do that for me. I would estimate it saves me 20 hours per month.

The automated memory balancing, where it looks at whether it's being used in the most efficient way and adds or takes away memory, is the best part. If it didn't do that, it would be something that I would have to do. We have too many machines for one person to do that. The automation helps me in that it is done in a really efficient way and a balanced way because of the policies. It really helps.

It provides specific actions that prevent resource starvation. If a machine needs more resources, it will use the automation policies to add resources so that machines get the resources that they need. And if they don't need them anymore, it will take them away.

It provides everything in one screen, one area. I'm able to see not only the planning, and not just the stuff that's on-premise, but things that are in the cloud. I can even narrow down to different applications. It does a lot in one pane. That was really important because we didn't have to go to three or four different products to find what Turbonomic had in one product. It really helps that Turbonomic is showing you efficiencies and the best way to keep things in the environment working properly, instead of me, or even me and co-worker, trying to do it. We just know that it's handling it better.

You can monitor an application and all the hosts and virtual machines that are connected to the application and it will give you an idea of how many resources it is using and what it is using. It also lets you know if it's over-utilized or under-utilized. It helps us to know if we're in an area where a machine might not perform the way we are expecting it to, because of the resources that it has or the resources it needs to have.

The planning and costing areas could be a little bit more detailed. When you have more than 2,000 machines, the reports don't work properly. They need to fix it so that the reports work when you use that many virtual machines.

I've been using Turbonomic for about one year.

It's very stable and works the way that it should.

It seems scalable, although I haven't scaled it up or taken anything away yet. We plan to use more storage. We're not using as much storage as we would like.

The support has been really good. The people that I've been working with have been really helpful. It's been working.

We used vRA from VMware. 

The initial setup of Turbonomic was straightforward. I worked with somebody from Turbonomic and we got an understanding of the environment and we worked together to get it installed and to get the placement working first. After the placement, we worked on changing and automating the addition of CPUs and RAM.

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.

We pretty much use it only for load balancing between hosts.

We're a payroll company and Turbonomic is really important for us from about November until March, each year, because our end-of-year processing increases our load by six to seven times. That's especially true in November and December when companies are running their last payrolls. If we're going to be losing any customers, they definitely have to finalize everything all at one shot. In addition, companies that pay out bonuses at the end of the year also have to be running all these extra payrolls. There are a slew of reasons for extra payrolls at that time of year. They may need to do some cleanup if they messed up something and didn't do so all year long. At that point, they have to do it before December 31st. And after December 31st is the beginning of tax preparation, so our systems are very heavily utilized.

It does a great job year-round, but we're in a situation where we have plenty of resources during most of the year, but at year-end, depending on how busy it gets, it can overwhelm the systems if you're not careful, depending on where a VM sits, on which host.

We have parts of our payroll engine that run pretty hot, depending on what's happening. Those pieces of the payroll engine and the SQL servers tend to overrun a server pretty quickly, if you're not careful. But Turbonomic always does a great job of making sure that that is not happening.

Our company is growing like a monster. Even during COVID we've been growing, where a lot of companies, unfortunately, are not. Because we've gained a lot of new customers during COVID, because other payroll companies have gone under or because our pricing model is good, the result has been a lot more load on our systems. And even though we've had much more load, Turbonomic has done a great job of keeping everything balanced. We're able to completely utilize our systems before having to introduce more hardware.

Its whole job is to manage our business-critical applications by understanding the underlying supply chain of resources. In my opinion, applications are applications. When your application is running, it's reserving a piece of memory, it's utilizing the CPU, and it's utilizing the network interface. There is a certain limit to the hardware that's available to it. Applications need watching. If we were to use the pieces where it digs down inside the application, it would probably even do better, but we're not using those pieces yet. In the end, no matter what the application is doing, it's using resources, either on a regular basis or on a random basis, and Turbonomic looks for patterns and spikes and how long these patterns last. It looks at the risk of a spike only happening for 30 seconds versus 30 minutes. It makes decisions to move other things off or move off the application in question. It does a great job keeping that balance.

We hardly do any manual execution. Maintenance windows are when it's probably most important to us. For example, when we're upgrading or doing a repair on an ESX host, we're really taxing the other servers because those CPUs and all the I/O capability on that host are lost. That's when it's even more important for Turbononic to keep the rest of the system healthy enough and to keep the system going without showing any degradation. It helps us while we're doing maintenance.

It provides a proactive approach to avoiding performance degradation, absolutely. It always looks at history and looks for patterns. In a lot of cases, it knows that there's a scheduled task or that, on average, a customer is always like hopping on around three o'clock. After a week or two of seeing the exact same things happening—although that timeframe really depends on how big your organization is, the bigger your organization, the longer it takes to understand the full dynamic—it really understood all the patterns and all the schedules. In the past, we'd see systems starting to get a little hotter and then a little hotter still. With Turbonomic, that issue would just go away by shuffling stuff around. After a week or two we wouldn't see that thing getting warm anymore. When that application or server got hot, it never put that host into any kind of jeopardy anymore, not even a little bit where we thought, "Hey, we should look at that."

We have definitely seen a reduction in tickets open for application performance issues. In some cases we get tickets for performance problems because the developer wrote crappy code and wants to blame us in infrastructure. But I can show them, "Look, we're not overloaded." They look at some of the logs we provide them that show that the servers are operating at full capacity and usually they find that there's some kind of weird issue with a database query that they wrote. The solution has definitely reduced tickets for application performance problems a little bit, but it has mostly decreased troubleshooting time.

It's helped us to always meet our SLAs. In previous companies I've worked at, the company was either so cheap, or the boss didn't understand how the infrastructure works, that we got to the point where we were over utilizing our hardware. That's where Turbonomic really makes a difference because without it you can be way over-committing what you have versus what you need. You always have servers that are sitting there idle, so it's best if you can balance the ones that run hot with the ones that run idle and shuffle around use of them based on what you're utilizing. If you don't have Turbonomic, then whatever boxes happen to be on there could be in overdrive to the point where you start ballooning and paging. That can cause a denial of service because you don't have enough resources to handle the workload. It's really great to try to maximize every inch of your infrastructure, to make sure you're utilizing everything to its fullest capacity.

Whoever is on call loves Turbonomic because if we didn't have it we'd be getting alerted much more often. That's especially true at three o'clock in the morning when some backup or something that's not even important is running and the pager will go off because it hits some threshold for too long. Turbonomic sees, "Okay, this server does this at this time and it's going to use a lot more resources than anybody else," and it just shuffles everything away.

I only deal with the infrastructure side, so I really couldn't speak to more than load balancing as the most valuable feature for me. It provides specific actions that prevent resource starvation. It always keeps things in perfect balance. Most of the time it tends to be our SQL servers. 

When I first started at this company, only the boss knew about Turbonomic, and he had totally forgotten to even mention to me that they had it. They weren't using any other software like that. I was always curious and I kept asking all the other guys about how the system always stays so balanced and that we never seem to have a host that runs really hot, under any circumstances. Finally, in my first review, I asked him, "What are you guys doing there in the background that you haven't told me about, that keeps the system so balanced?" And he said, "Oh yeah, we're using Turbonomic." For whatever reason, they didn't have a DNS entry for it. The guy who put it in, he always just connected to it by IP, and he totally forgot about it because it just works. You don't have to go in there and do a lot to it unless there is a problem, and we never have a problem.

Also, since we're only using it for the infrastructure part, it's not telling us anything about the application. It just tells us about the server that is running the application. But if the application is getting bogged down because you're starting to see disk I/O problems, it does a fabulous job of recommending. "Hey, let's move this here or do that there." In every case that I can ever remember, it has always done a great job.

It doesn't really require any maintenance. Just set it up and let it do its job.

On the infrastructure side, they've been doing it long enough. But until I get a better use case for the cloud, the only thing I can think of is that I'd like to see it work with SevOne, when you're doing true monitoring, so that the software packages work together. 

It would be good for Turbonomic, on their side, to integrate with other companies like AppDynamics or SolarWinds or other monitoring software. I feel that the actual monitoring of applications, mixed in with their abilities, would help. That would be the case wherever Turbonomic lacks the ability to monitor an application or in cases where applications are so customized that it's not going to be able to handle them. There is monitoring that you can do with scripting that you may not be able to do with Turbonomic. So if they were able to integrate better with third-party monitoring software—and obviously they can't do them all, but there are a few major companies that everybody uses—and find a way to hook into those a little bit more, the two could work together better.

We were actually a customer of theirs even before it was Turbonomic, back when it was VMTurbo. It's been at least 10 years.

I've never ever had it crash or go down.

Turbonomic is one of the best software solutions ever written. You just set it up and you only go in there when you're having a problem. The truth is that we don't have that many problems anymore. The only time we had a problem was shortly after I first started, because none of the guys even paid attention to it because it always did its job. We ended up having to change our vCenter server. We moved from a physical box to an appliance and when we did that, the vCenter had to have a new name. Because none of the guys, other than my boss, were around when Turbonomic was set up, they didn't log into it because it always did its job. They totally forgot about it. And for something like two weeks we were seeing some goofiness where boxes were getting hot. I messaged, "Hey, did you put that change in Turbonomic?" and he replied, "Did I put what in what?" Other than that, we just don't have to go in there. It works so well that we just don't do anything to it.

We have it set up to throw out some alerts if things get too haywire, but it didn't even get to that point. We like to be very proactive in keeping our systems very low in resources. Had we let the problem go on a little bit longer, it probably would have thrown out an alert, but the problem was that we didn't have the vCenter in there.

At the first shop I worked at where we got Turbonomic, we had over 60 hosts and it did a magnificent job. In my current company we're only monitoring 15 or 20. I can't see it having a problem. The more servers you have, the more return you get on it.

In terms of increasing our usage, we're always pushing the developers to do stuff with it. The problem for us is that we're owned by a parent company and IT infrastructure works for and reports to the parent company. But the IT development software group reports to the actual company. They're under a totally different chain of command, so we can't really dictate anything that they do. All we can do is make recommendations, but their director has his own plans. We try to show them the benefits, but it's a lot of work to sit down and configure it, which is not worth it if they're not going to use it. And we have enough other projects that we have to work on, so we have to pick our battles.

Their tech support is awesome. We've never had any problems with them. But to be honest with you, we haven't really had to call them in 10 years, except for one time when I called them because I couldn't find our license key. It was not about supporting the software, per se.

We were trying to use VMware's version of it, but it's a pile of junk. It doesn't work. It just sees that something is busy and moves it somewhere where it's slower. Turbonomic is better because it trends and it looks at history. If it knows that something is only going to run hot for 30 seconds, but it's going to take 45 seconds to move everything around, then it's not worth moving. You don't get that out of VMware's product. It just saw, "Okay, so it's hot, start moving." But the problem is that when you start doing the move, you're also now utilizing even more resources, and you could save on those when the move is going to take longer than the actual task that's causing the spike. Turbonomic sees that and it doesn't necessarily move stuff just for the sake of moving it. It knows that this is something that happens every day at this time and we're just going to ride it out.

We were actually one of their first customers, when they were still ironing out all the wrinkles of their algorithm. My boss and I were both looking at it and seeing how it was shuffling stuff around non-stop. It couldn't even gather data at a point. It was already moving it somewhere else. We called in, took some notes, and they produced a new version. We did what felt like beta-testing even though it had been a production piece for a while. But they were very responsive and produced patches really quickly. The company was a really good company. They were really friendly, and they're always trying to deliver what they promise.

If you can't set this thing up then you shouldn't be in IT. We're only using it from the infrastructure side. You log into it, you set your passwords, import your vCenter into it, put in the credentials, and tell it what vCenters you want it to monitor. And it just starts gathering data.

We did our setup many years ago and, back then, we had a guy there walking us through it because they were a brand-new company. They really gave us the white-glove treatment. I think we may have spent two hours on it, but most of that was talking. If you buckle down and just shut up and do it, it would probably take 15 or 20 minutes. It only takes one person to implement it.

We have six guys who use Turbonomic now. Some are higher-level guys and we have our entry-level guys, but everybody has access to it and looks at it if they need to.

I don't know what we would have bought if we didn't have it, so it's hard to say how much we have saved. We may have bought more hardware thinking we needed more hardware when we didn't. We just needed to shuffle stuff around. So it's hard to say what we would have done if we didn't have it, and if we didn't have that reporting telling us, "Hey, this is where the problem is".

If you're a super-small business, it may be a little bit pricey for you. The problem with small businesses is that the owners are super-cheap and they don't want to spend anything unless they absolutely have to. It's really hard to explain this solution to people with that mentality. But you can run more servers on less physical hardware because it will keep things balanced based on your usage patterns. 

But in large, enterprise companies where money is, maybe, less of an issue, Turbonomic is not that expensive. I can't imagine why any big company would not buy it, for what it does.

If you didn't have it and you went out and bought a whole new server, you're talking about spending something like $7,000 with Microsoft for a decent license, and then you're talking about a VMware license as well, which I would venture is in the $5,000 to $7000 range. And memory is so expensive all the time. And another server is going to cost, say, $10,000 to $15,000. If you do that twice over a couple of years, Turbonomic will have paid for itself. And that's not to mention the fact that it's also made things so much better for you because it has kept the system stable. I don't think Turbonomic is expensive, in that sense.

I put in a lot of expense and time in the very beginning, because I was trying to learn it. But if you're smart, you'll look back and see how well it's managing your systems now and you'll feel like a fool that you went out and bought all that new hardware in the past, because you probably could have gotten away without it. If you're truly maximizing your systems, the way that Turbonomic does, you can get away with less hardware with the same infrastructure because it's maximizing the hardware better. And that keeps your licensing costs down.

We did a lot of research, especially at that time, and there aren't really a whole lot of other software solutions out there, at least nothing that's comparable to Turbonomic. There are other companies that do something similar, but they don't have anywhere near the level of complexity or the type of algorithms that Turbonomic is using to keep the system stable. 

I don't remember what we evaluated at the time, other than VMware, because everybody works with Vmware, but the other solutions we had looked at were not even in the realm of Turbonomic, so we didn't evaluate them for more than a day.

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.

We implemented this solution in our company and we also implement it for our clients. We use it because it connects to monitoring tools over APIs and if you have a monitoring solution, it removes data intelligently. Our aim is to optimize our customers' systems. The solution also offers insight into the financial impact of an event. We are partners with IBM which purchased Turbonomic earlier this year, and we are resellers of Turbonomic. I'm the company CEO/CIO. 

The help desk analyzes metrics events and Turbonomic tells you exactly what is wrong and how to resolve it. The solution improves the function of the help desk and saves time by making repairs quickly.

Optimization is a valuable feature. For example, if I have eASICs running and several VMwares running, it shows me how to optimize the system and get the best out of it. It reduces the cost of the two systems. I like that the solution integrates almost automatically with other products.

The solution could be improved by having all interfaces together and I'd really like to see more interfaces. 

I've been using this solution for two months. 

We haven't had any stability issues, the solution is running well.

Scalability is fine. We're using the product extensively with deployment of almost 54,000 systems. We receive a lot of alerts from those systems and do a lot of monitoring, so it's used constantly. 

The technical support is now done by IBM.

The initial setup is very straightforward. You execute an application or a script, depending on whether you're running it in Linux or Windows, and then you deploy the containers. It's pretty much one command and then everything is automatic. It took us about 20 minutes. 

We already had a good return in the first couple of weeks. 

Licensing costs are middle of the road; you need to take into account what the solution delivers to the customer. If it's running automatic remediation then it saves a lot of money for an organization. 

This tool is excellent for a CFO, while other tools are geared more towards a CIO. This tool has a different market. We're currently working in Europe, carrying out implementations in both Italy and Portugal, and we're starting on a new deployment project in Dubai next week. 

I rate this solution nine out of 10. 

We looked to this product to help us to right-size our virtual machines and containers. Most people who request virtual machines tend to request more resources than they need, and most of the time it's hard to prove that they don't.

Our environment is entirely on-premises. We have virtual machines and Kubernetes running on some of those VMs. We also have plans to go to the cloud with some workloads in the future, so it's good to have this tool to help get the sizing just right when the time comes to pull the plug.

Turbonomic has been helping us use our resources more efficiently, the challenge we currently face internally is getting people to allow the servers to be turned off to make the changes recommended.

I also like the planning tool, which is helpful to make sure we have enough capacity for failing over one datacenter to the other in case of disaster, while still maximizing what we already have and helping to keep us from making host purchases we don't need yet. It's nice not having to make all those calculations on my own.

At the moment, I have only really had the opportunity to manage virtual machines with it.

We're starting to let it look at our Kubernetes workloads as well.

The automation and orchestration components are definitely the best part, as you can tell it what it can do and when, and just let it be. However, I haven't reached that point yet. That is the plan for the future though.

I really like the planning tool so I can make sure we have enough resources for upcoming projects that require servers, while still having enough resources for our disaster recovery failover needs.

The reporting feature could be made a little more seamless with the rest of the tool. It would be nice to be able to share and print the reports a little more easily.

Some features are only available via changes to the deployment YAML, and it would be better to have them in the UI.

The upgrade process is a bit tedious, but I know the team is working on that.

The ability to set the scope at the dashboard level and let it flow down to all the widgets you add would be amazing. Having to select the scope per widget is a bit tedious.

We have been using Turbonomic for just under a year.

It is pretty stable, we have not had issues with that.

Turbonomic seems scalable to me.

Technical support is where Turbonomic shines.

Lots of features are still in the works but the company really makes sure you have a lot of attention and support after the sale, which is sometimes hard to get. Most of the time, once a vendor has your money, you never hear from them again. However, I have had a great experience with post-sales support and a lot of hand-holding.

It is really well done on their part to make their customer happy.

We did not use a similar solution prior to this one.

The initial setup is pretty straightforward.

Deployed was completed in-house.

We have no ROI so far.

It's worth the time and money investment if you can afford it.

We evaluated VMware vROps before selecting Turbonomic.