IBM Turbonomic Reviews

My main purpose is to provide an assessment for clients, agencies, or the government to help them understand their workloads and what it would take for us to do a migration of their workloads, before we do it. I generate a report based on the client's existing on-prem workloads, and see how Turbonomic optimizes everything and how things would look once they are migrated to either Azure or AWS. I review that report and all the possible savings if they move their workloads to the cloud.

It's deployed on-premises, but we have been using it for public and private cloud.

It provides visibility and analytics at the underlying infrastructure stack level, in the way I use it. That is key. That's what differentiates between an agency saying, "Go ahead and move our workload because we see the value," or "Just decommission everything and we'll find an alternative to keep our workloads going." Most of my discussions are around trying to get things from on-prem to the cloud, and Turbonomic has been very helpful with that.

The visibility and analytics help bridge the data gap between disparate IT teams. They give us a central point around which we can sit down and discuss the savings and how we would actually move the workloads, based on how workloads are truly running today on-prem. That is very important because we want to show the client savings and help them to optimize their workloads, whether a system is on-prem or in the cloud.

In addition, the visibility and analytics have helped reduce our mean to resolution when it comes to identifying places where we can optimize things and getting that to the customer as soon as possible. Instead of having to search and discover all the infrastructure and calculate things based on usage, I have a single pane of glass with Turbonomic. I can look at the graphs because the data is already there.

The solution gives us a single source of truth for application performance management. That is vital because when we migrate workloads for any client. I've been doing migrations for almost eight years now, moving people from data center to data center, and workloads from data center to data center or to the cloud. One of the key factors in doing that is a single point of truth. If you don't have that, you repeat work. You don't know what's truly correct and the migration could fail.

Turbonomic also gives us the ability to review reports with our clients on a monthly basis. It makes us look good. It shows that we're being proactive and that we're looking ahead to ways we can help our clients optimize and save money. And if we're saving them money, they're happy.

From a performance standpoint, we know before we move workloads that we have optimized the performance for that workload. That means that when we migrate it, it shouldn't be a problem. In all the migrations we've done, performance hasn't been a problem, based on the performance readings we got from the Turbonomic reports.

In addition, it helps us meet our SLAs. When many workloads were running on-prem, we could not track our SLAs as well as we can now, thanks to tracking things with Turbonomic in the cloud.

Overall, from our organization's standpoint, the solution has helped to build our entire migration effort. Our migration team can follow a single path and understand how to present the data to our clients and help them in moving from one point to another. It helps the engineers to focus on issues and it really helps them do their migration prep. The smoother the migration prep, the smoother the actual migration will be.

The feature for optimizing VMs is the most valuable because a number of the agencies have workloads or VMs that are not really being used. Turbonomic enables us to say, "If you combine these, or if you decide to go with a reserve instance, you will save this much." That feature gives you an estimate using, for example, a Microsoft cost model, to show clients how much can be saved.

Another key aspect that I really like about Turbonomic is the user interface. It gives you a visual representation of where there might be issues. That stands out. When I'm looking at resources for migrating different workloads, if something is shown in red, that identifies a risk. If it's a risk where it's currently running, it's definitely going to be worthwhile to migrate it. It helps us to mitigate that risk before we do the actual migration.

They have a long road map when we ask for certain things that will make the product better. It takes time, but that's understandable because there are other things that are higher on the priority list.

I've been using Turbonomic for a little over two years.

The customer support is definitely a 10 out of 10, and the training gets a 10-plus.

Positive

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.

We use IBM Turbonomic to automate our cloud operations, including monitoring, consolidating dashboards, and reporting. This helps us get a consolidated view of all customer spending into a single dashboard, allowing us to identify opportunities to improve their current spending.

It can consolidate and amalgamate all the efforts. Before using it, we had multiple reports, tools, and sources of information that we needed to consolidate. With IBM Turbonomic, we can operate everything in a single console and view everything in a unified way. This allows us to address key performance issues and spending concerns that we identify, optimizing our operations to work better for our customers and us.

The overall price, the dashboards, and the FinOps capabilities are important features. The ability to manage all the budgets is also crucial.

The implementation could be enhanced.

I have been using IBM Turbonomic as an integrator for the past year.

50 users are using this solution. As an integrator, we're constantly looking for new logs and trying to make some of our customers for whom we do not provide cloud services part of that new ecosystem.

Initially, it can be tricky as you have to configure everything. The setup requires a significant level of effort. If there were a way to migrate or import some features or have some preconfigured settings, it would greatly help with the initial setup. It takes three to four months as per standard operation.

We have engineers who are certified in the tools. We have a couple of product managers, but the main source of disruption, or at least delays, is the integration and dependency on other areas. For example, if we want to integrate the CMDB with the monitoring tools we already have in place for each of our different customers, it requires time and dependencies not only on the availability of people but also on the ability to make changes to the environments.

The ROI is very good. Although it's expensive, you can fully implement the recommendations from the various tools and dashboards and easily recover the investment within the first year.

It offers different scenarios. It provides more capabilities than many other tools available. Typically, its price is set as a percentage of the consumption of some of our customers' services. The cost will vary depending on the specific scenario, but it is not cheap.

You can easily maintain it once you get into a stable mode with IBM Turbonomic. The operations team that adopted the tool is getting a lot of value from it, making it easier for them to manage and consolidate their work. It doesn't ramp up your AppDV or resource needs but helps improve and optimize them. We are using fewer people now.

It has a lot of capabilities. We haven't encountered any scalability issues. The way we have implemented it has helped us easily incorporate new customer sets.

There weren't many people with the skills to implement and manage IBM Turbonomic, so we had to develop the team's expertise. However, once we overcame that hurdle, managing it became easier.

Overall, I rate the solution a nine out of ten.

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.

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