IBM Turbonomic Reviews

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

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

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

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

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

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

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

It has proven to be highly stable.

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

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

Overall, I would rate it eight out of ten.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I have been using Turbonomic for four years. 

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

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

We are monitoring 3,000 workloads with Turbonomic.

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

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

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

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

The initial deployment took a couple of hours. 

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

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

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

There aren't additional costs to the standard license. 

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

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

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

I would rate Turbonomic an eight out of ten.

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 use Turbonomic to gather information that we can archive and review when there are performance issues or other problems. We look at the statistical data and see what was going on at that particular time across the cluster and if there was an issue. I generally look at the underlying resources, IOP utilization, CPU, CPU-ready ballooning, and anything that might cause performance issues.
Turbonomic is better than using the native vCenter to look at that and we didn't have vROps or anything.

Turbonomic helps us right-size virtual machines to utilize the available infrastructure components available and suggest where resources should exist. We also use the predictive tool to forecast what will happen when we add additional compute-demanding virtual machines or something to the environment. It shows us how that would impact existing resources. All of that frees up time that would otherwise be spent on manual calculation.

The solution's analytics are less important today because of changes in our environment. When we started using it, it was essential because we had more performance issues with the technology we had at the time. Turbonomic helps us interpret data alerts and speed sheets, which also isn't as important as it used to be. The solution helped to reduce performance degradation in the past, but it's less of an issue these days because we have optimized our environmental design.

Turbonomic reduced our mean time-to-resolution by about 50-60 percent when I used it for that. I can't say that it has improved our information sharing because our IT team is super small. We've got three people that are on the infrastructure. However, I have some experience with much larger environments, and the information that's in Turbonomic is easier to consume for some IT teams that maybe aren't as familiar with the virtualization environment.

It improved our application response time when we used it a lot more for performance analytics. We could see what consumed more IOPS and put it on the appropriate lens, where memory was not assigned properly. We could increase memory utilization or CPU. 

We can identify what is over-provisioned or if there are too many IOPS going through a particular data endpoint. CPU processor utilization, memory ballooning, etc., impact performance. 

Turbonomic provides many recommendations for right-sizing VMs for the tasks they're doing. That saves us significant time because we don't need to look at all that information and use calculators to figure it out. Turbonomic can tell you. Turbonomic reduced the time spent managing the performance of existing assets, freeing up time to do extra development work. 

I saw improvements in application response times when I used it regularly to look at performance gains. We achieved an improvement of around 20 percent in heavy application performance by right-sizing VMs and ensuring resources were appropriately assigned. 

The sizing information is the most useful aspect of Turbonomic. It helps us know which machines are over-provisioned or under-provisioned. I also like the historical information from the environment about performance metrics, utilization, and the like. It's nice to go back and look at what was happening in it at any particular time.

I do not like Turbonomic's new licensing model. The previous model was pretty straightforward, whereas the new model incorporates what most of the vendors are doing now with cores and utilization. Our pricing under the new model will go up quite a bit. Before, it was pretty straightforward, easy to understand, and reasonable.

I have used Turbonomic for nearly nine years.

Turbonomic is highly stable. We haven't ever had any issues with the product.

Our environment is smaller, and we don't add many resources to what we have. However, it seems to scale pretty well based on what I know about the product.

I rate Turbonomic support a ten out of ten. 

Positive

Setting up Turbonomic was pretty straightforward. You deploy the OVA, answer some questions, and point it at your environment. It's one of the easier infrastructure products to implement. I deployed Turbonomic in one afternoon, so it was a couple of hours max. After deployment, we had to install regular updates, but it was easy to do. Two people are involved in maintaining the product. 

In the past, we've seen a return, but it's currently hard to justify the recurring cost.

We evaluated vROps before selecting Turbonomic. Setting up vROps was much more complex. It required more overhead and maintenance. Getting the information we needed was more complicated. 

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

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

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

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

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

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

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

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

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

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

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

I've been using Turbonomic for about three years.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We are not running any cloud activities right now.

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

We wanted the performance assurance because we have seasonal spikes in our volume. One of the use cases was making sure that we could adjust for seasonal spikes in volume. 

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

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

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

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

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

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

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

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

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

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

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

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

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

The reporting is good.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We are using it mainly to manage the resource utilization for our virtual environment. We are using it for project planning, like the Windows 2008 upgrade with the infrastructure that needs to be built out for that. We are using it to manage our cloud expenses and the utilization within the cloud, which then drives cost reductions there. In the last few months, we started to do the application tagging so we can start to get down to specific application dashboards. This year, we want to start to drive more of the automation to reclaim unused resources, so I can then go ahead and delay further purchases. Our plan is to continue driving up the density of the environment.

Right now, we have certain tasks that get automatically done today. We are working on the piece which does the scheduling, using the change tickets, because we wanted to ensure there was an audit trail so we had an interface with our ticketing system worked out. So, we are getting ready to do that. Adding resources throughout the business day is no big deal, but we want to make sure we don't remove any resources (during the business day). We want to do this during a maintenance window to ensure that there will be no business impact. It is just being ultraconservative and sensitive to the business's needs. As they get more comfortable, we will continue ratcheting up the level of automation that we use. 

Everything is very specific with Turbonomic. We can take manual action throughout the day, if we see that it is necessary. We can have Turbonomic take certain specific actions automatically, then we can decide which ones we want to actually schedule so we can link them to approve change tickets.

It will show application metrics and estimate the impact of taking a suggested action from infrastructure resource utilization. I don't know if it will get down into the transaction level performance. I think the new release does that, but we haven't tested that piece out. However, this is the planning piece, e.g., if I were to remove the CPU, what would the performance and utilization look like? Or, in the case of some stuff that I was recently looking at, if I were to add the CPU, what does that do to the overall utilization metrics? You can then decide: Do I want to take that action?

The biggest lesson learnt is probably that people are afraid of change. Our biggest hurdle was putting their faith in automation versus we have always done it this way. We have always been oversized so the application teams would make sure that we never run out of resources, but they needed to be open to change. My favorite analogy that I like to use with them is, "I understand it is hard because instead of you telling me, 'I want this many CPU or this much memory.' I'm telling you trust me." It's like the gas gauge in your car. Don't look at the gas gauge when you get in your car. Just trust me that I have put enough gas in the car for you to get where you are going. It's a very difficult mindset for application teams who are used to saying, "Okay, I have eight CPUs over here. Don't touch them." But, Turbonomic actually gives us the data to show them, "You have eight CPUs over here. You'll never get above 40 percent utilization, so you are costing us money." So, it is fact-based decision-making.

My advice is, "Go for it." Don't let other teams hold you back because this is how they have always done it. Trust the Turbonomic team because they are great at being able to implement, and they are ready to move fast. Make sure you get all the right stakeholders, because we have had to deal with everything from:

• Engineering
• How do we do an internal chargeback?
• The application team's perception that I can't run with anything less than this. 

Get ready to be able to put some facts on the table and lean on the Turbonomic team because they are just phenomenal at helping put together business cases and doing the implementation. However, also get ready to tell your people to go for it. Don't be saddled with, "This is how we've always done it," because technology changes. I have seen nothing in my infrastructure career that was as great as this product when it comes to resource utilization.

I would give them a 10 (out of 10). The tool does what it says, and the Turbonomic people don't sell it to you, then disappear. They are always there and a pleasure to work with.