IBM Turbonomic Reviews

Our use case: Planning for sizing servers as we move them to the cloud. We use it as a substitute for VMware DRS. It does a much better job of leveling compute workload across an ESX cluster. We have a lot fewer issues with ready queue, etc. It is just a more sophisticated modeling tool for leveling VMs across an ESX infrastructure.

It is hosted on-prem, but we're looking at their SaaS offering for reporting. We do some reporting with Power BI on-premise, and it's deployed to servers that we have in Azure and on-prem.

The proactive monitoring of all our open enrollment applications has improved our organization. We have used it to size applications that we are moving to the cloud. Therefore, when we move them out there, we have them appropriately sized. We use it for reporting to current application owners, showing them where they are wasting money. There are easy things to find for an application, e.g., they decommissioned the server, but they never took care of the storage. Without a tool like this, that storage would just sit there forever, with us getting billed for it.

The solution handles applications, virtualization, cloud, on-prem compute, storage, and network in our environment, everything except containers because they are in an initial experimentation phase for us. The only production apps we have which use containers are a couple of vendor apps. Nothing we have developed, that's in use, is containerized yet. We are headed in that direction. We are just a little behind the curve.

Turbonomic understands the resource relationships at each of these layers (applications, virtualization, cloud, on-prem compute, storage, and network in our environment) and the risks to performance for each. It gives you a picture across the board of how those resources interact with each other and which ones are important. It's not looking at one aspect of performance, instead it is looking at 20 to 30 different things to give recommendations.

It provides a proactive approach to avoiding performance degradation. It's looking at the trends and when is the server going to run out of capacity. Our monitoring tools tell us when CPU or memory has been at 90 percent for 10 minutes. However, at that point, depending on the situation, we may be out of time. This points out, "Hey, in three weeks, you're not going to be looking good here. You need to add this stuff in advance."

We are notifying people in advance that they will have a problem as opposed to them opening tickets for a problem.

We have response-time SLAs for our applications. They are all different. It just depends on the application. Turbonomic has affected our ability to meet those SLAs in the ability to catch any performance problems before they start to occur. We are getting proactive notifications. If we have a sizing problem and there's growth happening over a trended period of time that shows that we're going to run out of capacity, rather than let the application team open a ticket, we're saying, "Hey, we're seeing latency in the application. Let's get 30 people on a bridge to research the latency." Well, the bridge never happens and the 30 people never get on it, this is because we proactively added capacity before it ever got to that point.

Turbonomic has saved human resource time and cost involved in monitoring and optimizing our estate. For our bridges, when we have a problem, we are willing to pay a little bit extra for infrastructure. We're willing to pull a lot more people than we're probably going to need onto our bridge to research the problem, rather than maybe getting the obvious team on, then having them call two more, and then the problem gets stretched out. We tend to ring the dinner bell and everybody comes running, then people go away as they prove that it's not their issue. So, you could easily end up with 30 to 40 people on every bridge for a brief period of time. Those man-hours rack up fast. Anything we can do to avoid that type of troubleshooting saves us a lot of money. Even more importantly, it keeps us productive on other projects we're working on, rather than at the end of the month going, "We're behind on these three projects. How could that have happened?" Well, "Remember there was that major problem with application ABC, and 50 people sat on a bridge for three days for 20 hours a day trying to resolve it."

In some cases you completely avoid the situation. A lot of our apps are really complex. A simple resource add in advance to a server might save us from having a ripple effect later. If we have a major application, as an example, and to get data for that application, it calls an API in another application, then pulls data from it. Well, the data it asks for: 80 percent of it's in that app, but 20 percent of it's in the next app. There is another API from that call to get that data to add it to the data from application B to send it back to application A. If you have sometimes a minor performance problem in application C that causes an outage in application A, which can be a nightmare to try and diagnose those types of problems, especially if those relationships aren't documented well. It is very difficult to quantify the savings, but If we can avoid problems like that, then the savings are big.

We are using monitoring and thresholds to assure application performance. It is great, but at the point where our monitoring tools are alerting, then we already have a problem in a lot of cases, though not always. The way we have things set up, we get warnings when resource utilization reaches 80 percent, because we try to keep it at 70 percent. We get alerts, which is kind of like, "Oh no," but we can do something about it when the applications are at 90 percent. The problem is there are so many alerts and it's such a huge environment. Because there is too much work going on, they get ignored. So, they can work into the 90s, and you end up a lot more often in a critical state. That's why the proactive monitoring of all our open enrollment stuff is really beneficial to us.

You have different groups who probably use almost everything. We use it for sizing of servers, and if somebody feels like their server needs additional resources, we validate it with the solution. We have a key part of the year called "open enrollment", where we really can't afford anything to be down or have any problems. We monitor it on a daily basis, and contact server owners if Turbonomic adds a forward-looking recommendation that they are running low on space. So, it keeps us safe. It is easy to monitor the virtual infrastructure and make sure there is capacity. However, with the individual VMs, in production alone, there are 12,000 of them. How do you keep up with those on an individual basis? So, we use Turbonomic to point out the individual VMs that are a little low.

Turbonomic provides specific actions that prevent resource starvation. They make memory recommendations and are very specific about recommendations. It looks at the individual servers, then it puts them in a cluster. At the end of the day, it comes back, and goes, "I can't fit these on here. There's not enough I/O capacity." Or, "There's just not enough memory, so you need to add two hosts."

For implementing the solution’s actions, we use scheduling for change windows and manual execution. The issue for us with the automation is we are considering starting to do the hot adds, but there are some problems with Windows Server 2019 and hot adds. It is a little buggy. So, if we turn that on with a cluster that has a lot of Windows 2019 Servers, then we would see a blue screen along with a lot of applications as well. Depending on what you are adding, cores or memory, it doesn't necessarily even take advantage of that at that moment. A reboot may be required, and we can't do that until later. So, that decreases the benefit of the real-time. For us, there is a lot of risk with real-time.

You can't add resources to a server in the cloud. If you have an Azure VM, you can't go add two cores to it because it's not going to have enough processing power. You would have to actually rebuild that server on top of a new server image which is larger. They got certain sizes available, so instead of an M3, we can pick an M4, then I need to reboot the server and have it come back up on that new image. As an industry, we need to come up with a way to handle that without an outage. Part of that is just having cloud applications built properly, but we don't. That's a problem, but I don't know if there is a solution for it. That would be the ultimate thing that would help us the most: If we could automatically resize servers in the cloud with no downtime.

The big thing is the integration with ServiceNow, so it's providing recommendations to configuration owners. So, if somebody owns a server, and it's doing a recommendation, I really don't want to see that recommendation. I want it to give that recommendation to the server owner, then have him either accept or decline that change control. Then, that change control takes place during the next maintenance window.

Three years.

Because of the size of our company, earlier versions were slow. However, they rearchitected the product about a year or 18 months ago and containerized parts of it, so we could expand and contract. Performance has been good since then.

I've a couple of guys who support it. We upgrade six or seven times a year. We are upgrading fairly often, so we are very close to current.

We have one guy spending maybe three weeks of the year doing upgrades. The upgrades are easy and fairly frequent, but there are almost always enhancements with these releases.

There are probably 50 people using it now. There are a handful who use it almost every day for sizing and infrastructure. We have a capacity management team who uses it all day long, every day. There are also multiple cloud teams and application teams who have been given access, so they can use it to appropriately size and work on their own applications. We are in the process of automating that to get that data out to everybody. There are a lot of other key teams who have found out what we were doing, and are like, "Can we have access to it now? So, we don't have to wait?" We are like, "Sure."

The scalability is good. I don't see any issues at all.

We were initially on the high-end of their customers. We ran two instances of it for a while, just because there was a limit of like 10,000 devices per system, and we were significantly past that.

Just from a server perspective, we are running about 26,000 servers right now, where 97 to 98 percent are virtualized. One person can't get a handle on that. Even figuring out what direction to look, you need to have tools to help you.

The technical support is good. We actually rarely call them. We have done quite a bit of work with them. Because of the number of purchases, they provided a TAM to work with us. So, we have kept that TAM around on an ongoing basis. We pretty much just call them, and they handle any support issues. From a support perspective, it has been one of the better experiences.

If it stops doing its thing and moving VMs around, it will be many days before it is going to have any impact on the environment, because everything is configured so well. From that perspective, it is an easier application to score than if you have a VMware host crash and trap a bunch of VMs on it.

We started using Turbonomic as a replacement for VMware DRS, which handled the VM placement.

We knew we were having some performance issues and ready queue problems that we felt could be improved. We worked with VMware for a while to tweak settings without a lot of success. So, we saw what Turbonomic said that they could do. We tried it, and it could do those things, so we bought it.

From a compute standpoint, Turbonomic provides us with a single platform that manages the full application stack. When we originally started, we were primarily looking for something that would make better use of our existing infrastructure. Because it does a much better job of putting VMs together on hosts, we were able to save money immediately just by implementing it. At the time, we were non-cloud. There was a period of time where we just couldn't put anything into the cloud for security reasons. We have moved past that now and are moving to the cloud. This solution has a lot more use cases for that, e.g., sizing workloads for the cloud and monitoring workloads in the cloud.

It's incredibly easy to set up. It took a couple of days. You spend more time building servers and getting ready for it.

It gathers its own data from vCenter. It doesn't touch the actual servers at all. Same thing with the different cloud vendors. It looks at your account information. It doesn't actually have to touch the servers themselves.

As far as the product goes, it's not an agent based. It can gather information, and start making recommendations within two or three days, then better recommendations within a week. After that, you're good. It doesn't get much easier.

We did the implementation ourselves. It took one guy to deploy it.

My group built a couple of the VMs that we needed and installed it. It took a couple of days. As far as gathering information, you don't have to put agents on any servers or anything like that. You give a user an ID for vCenter, and we have multiple vCenters.

The open enrollment applications are all mission-critical apps. If they go down, then the clock starts ticking on its way to seven-digit sales losses. It helps us avert situations like this multiple times a week. We are constantly using it to watch and notify application owners. If we don't use Turbonomic for this, then what would typically happen is the node recommendations that they would get from Dynatrace would start showing them that there is latency in their app. If they started digging into Dynatrace, then it would come up, going, "I'm running at 90 percent CPU all the time. I better get some more CPU." Well, Turbonomic tells us two weeks before that happens, that, "We need to be adding CPUs." So, it has a proactive nature. There are a lot of other tools in play that are monitoring what is happening. For our managers, Turbonomic helps us figure out what is going to happen.

We use Turbonomic to help optimize cloud operations, and that has reduced our cloud costs. We have a lot of applications that we run which are very cyclical. Fourth quarter of the year, they get the crap beat out of them. The other three quarters of the year, they are not used a whole lot. Without Turbonomic, would it be appropriate for the application to get resized nine months out of the year. Probably not.

It has helped save cloud costs by seven figures.

The tool itself is not free, but it's easily a positive ROI. It's hard to measure the benefit of just doing the DRS and optimizing our virtual infrastructure. I just can't stress enough how much it does such a better job of stacking VMs onto a set of ESX infrastructure. If you're using Turbonomic and looking at a cluster, you will see pretty much even utilization across a set of hosts. If you let VMware manage it, you will see one host at 95 percent, then another at five percent. Everything is running fine, and that's all they care about. However, if something starts going wrong on the host that is running at 95 percent, then you may see some degradation, just like rats leave the sinking ship trying to get out through that 5 percent host. Because it does a better job of balancing things, it utilizes infrastructure better, so you have fewer servers to host the same amount of VMs.

We have probably reduced our server purchase by a million dollars, just having Turbonomic manage the VDI infrastructure. Before they were static, so they just put an X number of VMs on each host, e.g., there are 70 VMs on that one, then it goes onto the next one. If we saw hotspots, then we would manually try and move a VM or two around.

We are using Turbonomic now to manage that and the supercluster feature that lets us migrate across clusters, which is really key for the VDIs, because we had infrastructure that wasn't well utilized 24 hours a day. So, we were buying lots of extras. The reason for that was we have developers in India, tons of people offshore, and people in the Philippines. As those people come and go, the utilization of different clusters shifts radically. So, if you're trying to have enough infrastructure to manage each cluster individually, then it takes a lot more than if you're managing it as a whole. That is one of the things that we use it for.

When we have expanded our licensing, it has always been easy to make an ROI-based decision. So, it's reasonably priced. We would like to have it cheaper, but we get more benefit from it than we pay for it. At the end of the day, that's all you can hope for.

We paid for our TAM, but I'm sure it's embedded in the cost. However, that's optional. Obviously, you can do it all yourself: Open all your own support tickets and just send in an email to your TAM. Our TAM has access to log in, because she's set up as a contractor for us. So, she can actually get in and work with us.

There weren't a lot of other options available at the time, but we did look at three others. I know there are other companies on the market. I don't remember which ones were competing with it at the time. There was only really one other in that space at the time, and there's a bunch now. Then, VMware was there competing as well, saying, "You just don't have it configured right. We can do better," but they really couldn't.

The model behind the scene that Turbonomic uses to make decisions just has a better way of balancing resources. It considers a lot more factors.

We use other tools to provide application-driven prioritization, to show us how top business applications and transactions are performing.

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.

We have a hybrid cloud setup that includes some on-prem resources, and then we have AWS as our primary cloud provider. We have one or two resources on the Google Cloud Platform, but we don't target those with Turbonomic. Our company has a couple of different teams using Turbonomic. Our on-premise VMware virtualization and Windows group use Turbonomic to manage our on-prem resources. They use it to make sure that they're the correct size. 

I'm on the cloud engineering team, and I use it in a unique way. We use it for right-sizing VMs in AWS. We're using it to improve performance efficiency in our Kubernetes containers and make sure the requests are in line with what they should be. If an application has way more memory allocated than it needs, Turbonomic helps us decide to scale that back.

We have a platform that we use for our internal deployments. I use our API to get data and transform it for use in our platform. I've developed APIs that go in between our internal platform and Turbonomic. When our developers create and release code, these APIs allow them to take advantage of Turbonomic without using it directly. It's built into our platform so they can benefit from the performance improvements Turbonomic can recommend, but they don't need access to Turbonomic.

Cost savings is a significant benefit, especially with our AWS computing. It cuts down on human error. For example, sometimes someone will spin up some resources in AWS and then forget about it. We can go into Turbonomic's reporting and see that a virtual machine is idle, so you might want to scale it down. If it's not being used, you should delete it. Then you can save X amount of money. Turbonomic will automatically apply those things for you and tell you how much you're going to save. It's integrated with your AWS billing report and everything; it can give you real data. You click a button, and it'll apply all the functions for you, so you save a bunch of money. I would say that that's a huge part of it for us.

We have a couple of different use cases, and it was essential for us to meet all of them without the need to go to several different vendors. Turbonomic can manage on-premises and cloud-native resources all in the same place, providing direct cost benefits through our cloud providers and our on-prem hardware storage.

Turbonomic has also helped us improve our efficiency as an organization. We can better understand the actual cost of our applications and how to optimize, so we've become more efficient and cut down some of the extra expenses. It's also useful for capacity planning. We can understand how much resources we're using right now and how much we'll need when we bring on new clients for our software solution.

Turbonomic has helped us manage multiple facets of our business-critical functions. Our company provides a software platform for our clients. They log into a portal that's hosted either in the cloud or on-premises. Turbonomic can monitor those applications as well as the underlying storage and computing resources. It's monitoring the applications themselves, the production environments, development, and QA for future changes. We can understand how changes are going to impact our production.

It depends on the system that we're looking at. We have a change-management process for our business-critical things and our production resources. With that, we either schedule a change or manually execute the change during a planned maintenance window. Our change management board approved other functions, like development and QA-type resources that aren't in production that we're developing. We can automate those kinds of things all the time. I know that our storage team automates a ton of tasks, but I'm not exactly sure. I assume they wouldn't be automating production resources either.

We follow some pretty strict change management policies. Applying some of these resources will require restarting your process. We would do it either in a change management window that we schedule through Turbonomic or manually apply it. 

Turbonomic's application-driven prioritization helps us identify where risks are coming from while proactively preventing performance degradation. It's nice to be able to avoid problems before they happen. I don't have to wake up in the middle of the night and respond to some alert because one of our applications ran out of memory, and people couldn't use our product. It's helped me get some sleep. Our storage teams are super stoked about that, too, because they had all sorts of alarms going off all the time, and they set up a ton of automation with Turbonomic to handle that all for them. We've seen a significant reduction in open tickets for application issues.

Turbonomic can show us if we're not using some of our storage volumes efficiently in AWS. For example, if we've over-provisioned one of our virtual machines to have dedicated IOPs that it doesn't need, Turbonomic will detect that and tell us. You can save like a thousand bucks a month by switching the storage class. With a click of a button, it automatically makes the changes for you, and you can go in and save a ton of money on AWS with it. That's one of the primary ways I've used it. 

Kubernetes integration is excellent. Turbonomic helps us right-size deployments and replica sets. They've come a long way since I started here. I've been working with the team that uses Kubernetes or develops the Kubernetes integration, and it's been fantastic. Turbonomic helps prevent resource starvation too. Inside the console, there's a little graph that tells you what your application has been doing over the last week. You know that you need to take action right now before you run out of CPU or memory and your application starts to suffer. 

With Turbonomic, you have everything in one place. There aren't a bunch of different things to worry about or manage. It helps you manage full-stack applications as well. It's a challenge for many of our developers to understand what resources their application needs. We can automate that. Turbonomic processes all of the data, makes intelligent decisions, and automatically applies changes to the application. These are problems that are difficult for humans to solve because of the complexity of taking into account all these variables and determining how much memory to give an application. If you don't make the right decision, Turbonomic can discover that for you and fix it.

You can automate all of these functions. It tracks your application performance, and you can automate everything or have it wait for your input. It'll do it in real-time asynchronously in the background. Turbonomic can predict the impact of any given action, and that's one of the things I like about it. There's a little graph that pops up when you're about to do something. It shows you the history and predicts the future impact of what will happen when you click the button. For example, it can tell you that your utilization of the resource allocation will drop by this much, and you're going to be at about X percent utilization.

It's reasonably accurate. I haven't had a situation where it told me that everything would be okay, but it didn't work when I applied the change. So far, everything has been smooth sailing. Turbonomic can tell you how everything is currently performing, but we use other tools for that kind of monitoring. It can show you how your system is currently acting. If some things don't need action at the moment, it will tell you why. For example, it'll say you have this much memory allocated, and you're right on target, so you don't need to do anything. 

It's harder to use a monitoring tool to understand how your application performs over time. It depends on the monitoring tool, but often you have to set it up to ingest all this data and pick the right things to look at. Turbonomic does all that for you in the background. You can look at a suggestion, for example, if you need to up your memory allocation by a certain amount — and see all the data Turbonomic has gathered to make that decision. With a standard monitoring tool, you have to make that decision yourself. You're the one ingesting all the data. 

A monitoring tool is probably better if I want to see what my application is doing right this instant. As far as thresholds go, I think that's something I would probably use monitoring tools for. I would set it up to alert me when my resource allocation or memory usage exceeds 80 percent. I haven't used Turbonomic to do things like that. It's more forward-looking. When something is happening, like my application is running low on startup resources, I'll hop on a Turbonomic to see if there's a solution that I should apply. 

It's tough to say how they could improve. They've done a lot better with their Kubernetes integration. If you'd asked me a year and a half ago, I would say that I think their Kubernetes integration needs work. They started with more of a focus on on-prem VMware virtual machines. I think it was called VMTurbo at one point. Their main goal was to help you with these virtual machines. 

Now they've pivoted to also supporting containers, cloud-native tools, and cloud resources. At first, it was a little hard because they had this terminology that didn't translate to cloud-native applications for the way that Kubernetes deploy things versus a virtual machine. 

I was left wondering if this was a Kubernetes resource but now, it's come a long way. I think they've improved our UX as far as Kubernetes goes. I'm interested in seeing what they do in the future and how they progress with future Kubernetes integration. I would say that's something they've improved on a lot. 

I've been at my current company for a little over three years, and I believe we started looking into Turbonomic around that time. I would say I've been using it for two to three years.

I have never had Turbonomic go down or had a problem with it not being available when I need it, so I would say stability is great.

I've never had an issue where I would need to scale Turbonomic to handle more resources. Knowing what I know about how the solution is deployed, I would say it's scalable since it's built on Kubernetes. You can install the Kubernetes cluster and scale up instantly. Turbonomic has a micro-service architecture, so it appears to be scalable on the backend. I would say it's very scalable, but I haven't had any direct experience with scaling it myself. 

We're using it fairly extensively, but we don't have a ton of people working with it right now. Every relevant team uses it, including my team, cloud engineering, storage, and networking groups. In total, that's around 10 or 15 people using it. We are planning to increase usage. We're working on some new applications for Turbonomic, like integrating some of the data from Turbonomic into our platform as a service. 

I've also worked with some of their engineers on this. It's not necessarily things that I wouldn't figure out on my own, but they've helped to smooth the process along. Every once in a while, one of my contacts at Turbonomic lets us know a new feature is coming and ask us if we want to beta test it. We install it, update to the beta version, then go through and take a look. Some of those things would be cool, like a scaling solution with Istio, a Kubernetes load balancer service mesh tool.

I want to delve into scaling applications horizontally with Turbonomic based on response times and things like that. It would be nice to be able to automate more actions. Right now, I've integrated this into our platform, but in the future, we want to automate some of this more, especially for non-production resources. For example, if a developer decides to spin up a development application using way too many resources, we can automatically scale that down. That's the problem Turbonomic is trying to solve. It's tough to know how much you need. 

I rate Turbonomic support eight out of 10. Their support team has been good. We haven't had many problems, but when we do, they respond quickly. Whenever I've had to reach out for anything, they've been super-responsive, and they'll hop on Zoom call if we need them to troubleshoot something. 

Positive

The deployment process is a little tricky. It wasn't hard for me because I have pretty in-depth knowledge of Kubernetes, and their software runs on Kubernetes. To deploy it or upgrade it, you have to be able to follow steps and use the Kubernetes command line, or you'll need someone to come in and do it for you. We're deploying it to use with our OVA in our VMware environment on-premise, which is a little rough. It's not terrible, and I've had way worse software vendors, but I would say there's probably a little bit of room for improvement as far as upgrades go. We have to schedule a window and then make sure everything's working. With other on-prem services, you just run one command, and everything updates for you. Turbonomic upgrades are a little more involved.

When the guy on our side was going through the install process and setting all of this up, he had to get into the virtual machine environment and do a bunch of stuff, download some things, and then start running scripts. On top of that, he was trying to run these Kubernetes controls, and this other guy was helping install them. So it felt a little more clunky. I don't know how you would improve that unless it was a complete software solution service or a simple installer that you download and run.

The total deployment time depends on some different factors. We've deployed Turbonomic a couple of times. When they come out with a new version, we have to do a complete redeployment. I wasn't involved in the initial setup, so it's hard for me to say. But it took a couple of days to deploy the new version, plus a couple of hour-long sessions. It was around 15 hours total. I remember we tried to download a file, and it took two hours. I think that was because of the internet connection on our side. It's hard for me to quantify it. 

We've seen a great return on investment. Then again, I'm not sure how much we initially paid for it anyway, but we went through renegotiation. I don't have the numbers, but we bought some additional licenses, so we just expanded our use a little bit two or three weeks ago. I'd say that we got a good return on our investment, and we're excited about expanding our use in the future too. 

It has reduced our capital and operational expenditures. It's hard to estimate it, but the cloud savings have been significant. I can't give a percentage. However, there have been multiple times when I've applied something, and it has cut a considerable portion of our monthly spending on AWS — over 5 percent. Sometimes it's just a little, but all of those actions add up over time. If I apply a bunch of changes at once, it can add up. I can say we reduced 5 percent of our monthly spending just once, and that was pretty huge for us because we spent a ton on AWS resources. That was one time I can remember, but I'm sure it's been more than that, especially our other teams using it. We've also seen some savings in human resources costs, especially on the other team. They're not dealing with alarms going off all day anymore.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I have been working with Turbonomic for approximately five years.

This is definitely a stable solution. 

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

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

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

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

We have approximately 12 users.

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

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

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

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

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

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

The initial setup was fairly straightforward.

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

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

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

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

We deployed it ourselves but received assistance directly from Turbonomic.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I would rate this solution an eight out of ten.

Currently, we're doing migrations for older versions of Windows, both in the Azure Cloud and on-prem in our VMware vCenters. We use this tool to do comparisons between the current and future workloads and what would they look like, based on the usage. So, it is kind of a rightsizing exercise or rightsizing, either downsizing or upsizing, depending on the requirements. We just put all that information into Turbonomic, and it builds us out a new VM, exactly the size that we need, based on the trending and analysis. Then, you can also put in some factors, saying, "Look, it was Windows 2008, and we're going to windows 2019, or whatever. We're going to grow the database by X amount." This tool helps you do some of the analysis in order for you to get the right size right out-of-the-box. We love that.

I oversee a lot of stuff, so I don't really get an opportunity to go in there to point and click. We have people who do that.

It is doing Azure Cloud and VMware. Turbonomic understands the resource relationships at each of these layers and the risks to performance for each. You can compartmentalize your most critical workloads to make sure that they are getting the required resources so the business can continue to run, especially when we get hit by a lot of work at once. 

The solution provides us with a single platform that manages the full application stack. In our decision to go with this solution, this was critical. We had so many vCenters and physical clusters out there. We had virtual and physical machines all over the place. Turbonomic was the way we were able to centralize all our vCenters and get a good picture of what is going on in the environment. It was all over the place without it, so there was no way that we could centralize and work on getting off of some of the older hardware platforms that we were on and start moving to converged, then eventually hyper-converged. This tool allowed us to take a good look at our environment and decide how we were going to size those workloads into those new areas, off of the old blade chassis and old standalone systems, to the more modern hyper-converged systems.

In our organization, it is optimizing application performance as a continuous process that is beyond human scale. The reason is because there are times of the year that we have these big hits. It is like if you were Verizon and you were to sell all your cell phones during the Christmas time. Well, we have a very similar thing here at our company, where we have a period of time we basically shut the business down. We have to give critical resources to critical applications, giving them the resources that they need in order to function. In order for us to do that, we are able to take critical workloads and put them off into their own area, then determine how much we have to take from the rest of the resources, which we take from the rest of the systems in order to put it into new clusters or systems. That is super critical for us every year.

We use it for management and rightsizing of our platforms, specifically for migration activities, because we're always doing it. The migration has been the biggest thing that I personally use.

There are a number of tools that we use in it. Some of the things that I request are the data dumps. They write some kind of scripts or something inside there where they are actually able to pull for me CSV files. Then, I can go in, take all that information, and build a master gold list for my migration activities. 

Everything that I ask for, I get. I don't know what they are clicking nor do I know what they're doing, but when I request it, I get it. There are all sorts of different ideas and scenarios that I put forth to the developers.

Turbonomic provides specific actions that prevent resource starvation. While I'm not in there banging around on the tool all the time, I can tell you that I do very much benefit from it. On Monday, I was getting additional information from the Turbonomic guys.

We use the solution’s automation mode to continuously assure application performance by having the software manage resources in real-time. 

There are a few things that we did notice. It does kind of seem to run away from itself a little bit. It does seem to have a mind of its own sometimes. It goes out there and just kind of goes crazy. There needs to be something that kind of throttles things back a little bit. I have personally seen where we've been working on things, then pulled servers out of the VMware cluster and found that Turbonomic was still trying to ship resources to and from that node. So, there has to be some kind of throttling or ability for it to not be so buggy in that area. Because we've pulled nodes out of a cluster into maintenance mode, then brought it back up, and it tried to put workloads on that outside of a cluster. There may be something that is available for this, but it seems very kludgy to me.

I would like an easier to use interface for somebody like me, who just goes in there and needs to run simple things. Maybe that exists, but I don't know about it. Also, maybe I should be a bit more trained on it instead of depending on someone else to do it on my behalf.

There are some things that probably could be made a little easier. I know that there is a lot of terminology in the application. Sometimes applications come up with their own weird terminology for things, and it seems to me that is what Turbonomic did. 

Three years.

I have never had a problem with it. The product is a little over anxious at times.

When we did the rollout in that phased approach, it was not difficult at all to roll in new technologies. They converged and hyper-converged into Turbonomic. So, it's definitely scalable. It moved right into the company pretty easily.

There are quite a few people using it, mostly for operations type of work. There are probably 25 users from operations, support, the performance team, and performance planning.

I have worked personally with Turbonomic, one of their guys, on some of this stuff. I haven't talked to him in a while, but he helped us develop a lot. The support for Turbonomic is incredible. 

Their technical support is excellent. By far, they are probably the best. It's probably why I am sitting here talking today, because I have to give these guys top props. I think the employee enthusiasm about this product is absolutely top-notch. It would probably be a great place to work.

I've worked with the Tier 1 support and their consultants. We had a consultant here for a year who was absolutely a top-notch fellow. He just became part of the team. He wanted to learn how we were doing things and tool the application to do what we needed it to do, which he did. He also left great instructions. A lot of his legacy is still there and being used today. 

We were using a combination of vROps and VMware. We were also using BMC TrueSight, which we still use today. There are a couple of others out there, because the network team uses a few things. There is all sorts of stuff that I think they were kind of hog-tying together to make them work.

Some of these solutions are ingrained in our processes and have been around literally forever. So, there isn't the staff or the resources right now to rewrite a lot of these things. Currently, we do kind of a side-by-side comparison, and I believe some folks have written some ways to integrate the new data from Turbonomic into the old way of doing things. That's just a culture change at the company. It's just a big place that has been around for a long time, which works slowly.

This solution was brought to us by one of our AVPs. She had worked at HPE, and we didn't know about it. She said, "Let's look at this," because apparently she used it at HPE. We looked at it, and said, "Ah, this is great." Then, we went with it.

Turbonomic is more customizable with a lot more features. 

Even though you can turn on automation in VMware, it's not very good. It's kludgy and has a tendency to break things, where the autobalance of workload management that Turbonomic does within VMware is much better than the VMware tools which are designed for this. That may change, because VMware seems to be doing great with this. However, for right now, Turbonomic is the only way to go. 

TrueSight is just straight up what you see is what you get.

I went to the training when they first rolled it out, but I wasn't involved in the setup.

They did the setup in sections. So, they started off with the lower environments and some of the clusters out there that really needed a lot of attention, mostly blade servers and such. So, it was a gradual rollout. I think the entire rollout was somewhere in the area of a year to a year and a half. However, to get it fully running, where we could use this solution to our benefit, that was at least six months.

We use scheduling in real-time for implementing the solution’s actions as well as manual execution, which is when we schedule for a later date to change activities. We have had to enable or disable certain things. It seems to do that just fine.

We used Turbonomic for everything to do with the setup. On our side, it required about five FTEs, who were engineering and operations personnel. There were folks who were creating the design and where it would be rolled out. That design was passed down to the operations folks who were actually implementing everything. So, it was done in phases.

We only have two engineers doing maintenance, a primary and a backup, and this is like their extracurricular activity.

The ROI would be in the return of hardware, specifically for a lot of the older hardware where we start to go into the converged systems. That is where we are seeing our ROI. We are getting rid of that old, junky hardware, starting to integrate and align things into one specific way of managing all our workloads, but not on old hardware. If anything, the ROI is end of life hardware elimination.

Also, we see ROI in extended support agreements (ESA) for old software. Migration activities seem to be where Turbonomic has really benefited us the most. It's one click and done. We have new machines ready to go with Turbonomic, which are properly sized instead of somebody sitting there with a spreadsheet and guessing. So, my return on investment would certainly be on currency, from a software and hardware perspective.

Turbonomic provides a proactive approach to avoiding performance degradation. Our capacity and performance team use this solution as part of other tools that they utilize.

The solution provides application-driven prioritization, with its AppDynamics integration, to show us how top business applications and transactions are performing. If Turbonomic comes back and tells us, "Hey, this application needs more resources. Or, you're coming up onto a period where it will need more resources. Start planning now." We have certainly used it for that and will continue to use it for that. We have actually used it for troubleshooting a couple of times, saving us 25 percent when it comes to performance-based issues.

We have seen a 25 percent reduction in tickets opened for application issues.

Turbonomic has definitely helped to save human resource time and cost involved in monitoring and optimizing our estate. It has automated a lot of things. We have saved 30 to 35 percent in human resource time and cost, which is pretty substantial. We don't have a big workforce here, so we have to use all the automation we can get.

We did an architectural review. We had to look at other options, but I don't know exactly what those were.

Some of the tools which already exist are not that great. They really need to up their game if they're going to keep up with something like Turbonomic.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Positive

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We use it to optimize costs and resource efficiency across our environments and  present infrastructure change requests to the business.

We had a lack of knowledge about things at our product level, and Turbonomic helped us resolve that. From an integration perspective, it also helped us find connectivity between our gateway tool products.

When it comes to optimizing costs and resource efficiency, before Turbonomic, we would add big, expensive storage and scale up across the tenant. Now, we are able to allocate the resources we need. We can also justify to the business, based on usage, why we are going with those resources. We have all kinds of proof to explain to the business how we are scaling down.

The visibility and analytics into our environment’s performance, from the APM down to the infrastructure, help us illustrate and clarify for the business the types of infrastructure changes we are suggesting. And they give us approval. Although we can collect the same information from Azure, Turbonomic is very user-friendly, and we can also automate notifications.

Regarding policy implementation, that can be implemented by a skilled engineer in five to 10 minutes. But if that same task is assigned to a new engineer who is not familiar with Turbonic, he would have to reference the previous document and the previous policy. Implementing the same thing would take that new engineer 15 to 20 minutes.

I like the analytics that help us optimize compatibility. Whereas Azure Advisor tells us what we have to do, Turbonomic has automation that actually does those things. That means we don't have to be present to get them done and it simplifies our IT engineers' jobs.

The platform is continually updated with new features. If they would educate their customers to understand the latest updates, that would help customers be more satisfied with the updates and push them into their environments.

Also, there are a lot of features that are not available in Turbonomic. For example, PaaS component optimization and automation are still in the development phase. If they could provide those enhancements, that would be really great. For example, we are spending a lot of time on Azure Databricks, exploring it and trying to do cost optimization as well as setting up the policies. If Turbonomic could help us understand how much the Databricks CPU is using per instance or workspace, that would help us optimize it, scale it according to our business requirements, and decrease costs.

We have been using IBM Turbonomic in the cloud for the past year.

The stability depends on how you set up the policies and logic. In general, Turbonomic is stable.

It's scalable because we are hosted in the cloud. We can expand it vertically.

I'm an open-source guy, so I used a lot of open-source code to do the cost optimization through scripting. One reason Turbonomic was our first choice was that our on-prem team was already using it.

We have it set up in the cloud and on-premises. I wasn't involved in the initial deployment as it was already on-prem. We just expanded it to the cloud. That operation was very easy. We just opened the access to the cloud. That was it.

We have a test environment, so we apply things on the test environment and make sure our policies are having the proper effects and are working perfectly. We can work on an environment-by-environment basis.

There is not much maintenance involved, other than applying patches.

There are a lot of options available, but compared to other products, Turbonomic has many features. Other products are at a more beginning stage.

When you do your initial assessment, you have to understand your business needs and then choose the product.

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

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

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

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

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

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

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

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

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

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

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

IBM Turbonomic has positively impacted our overall application performance.

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

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

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

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

I have been using IBM Turbonomic for over two years.

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

IBM Turbonomic is highly scalable.

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

Positive

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

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

We have seen a return on investment with IBM Turbonomic.

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

I would rate IBM Turbonomic ten out of ten.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Positive

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

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

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

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

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

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

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

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

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

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

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