DX Infrastructure Manager Review

It's given us the ability to define and isolate where issues are occurring.

What is most valuable?

The most valuable feature is that it allows me to do systemic and additional levels of probe automation on every VM we have in the cloud. We just recently moved from VMware to OpenStack. Our internal cloud infrastructure has changed drastically over the last year. Right now we are scrambling to integrate a lot of other components into OpenStack for cloud.

How has it helped my organization?

It's given us the ability to define and isolate where issues are occurring. We went from a vCenter cloud to OpenStack for all seven systems and our control hosts. A lot of it is a retooling and relearning for us. We're going to an agile development platform. A lot of that is coming through as we're using different development tools. We are going from JS to a Docker component. A lot of things are changing right now. At the ground level, we're reengineering everything.

What needs improvement?

The UIM product is playing catch-up. They are not there yet to do a lot of the next-level things that we need them to do. The auto on-boarding, the customer self-service pieces of it. We are hoping to meet with them in about two weeks to start looking at ways we can get that done. Also, High Availability, the failover capability. For their product, we were going to go with a hardware platform for HA. Two separate blades with a bootable SAN piece. They got a software-driven HA position. I'll take a look at it and see what it has to do. I think there may be a lot more moving parts there than what I want. We will see.

Also, since we went to OpenStack, we have to integrate storage and networking to a certain extent in there. Each of the probes that we use has to be specifically built in the system. Right now, CA is pretty much at ground level with it. I think the next release in Q2 well probably be much more enhanced towards that end.

There are the two more things I want. First, customer self-service where they can go in and make whatever changes they want to make, absent giving them admin access to my consoles, so long as it affects only their applications. You want to make modifications on threshold limits for severities for these things to go out to the service outside, I'm okay with that. How do we get that done? How do I get from RA to the desk station? How do I get there? I don't know.

Second, I'd like an HA variant that isn't going to scare me, and help me do all the on-boarding. I'd rather deal with the blades. I've got two blades out there with a bootable SAN system. Each blade fails, bam, this one comes up. All the VM's come right over. Pretty simple to me. That's what I'd like.

What do I think about the stability of the solution?

It's a very stable platform. We got it, we installed it, we put it inside of OpenStack, and it should not have been. We can't do systemic monitoring inside the hypervisor piece of it. It's resident on OpenStack. There's no routable way to get to that from a guest VM. It's designed that way for security. From a guest site, you can't go out to the community toolbar system. It's not going to allow you that.

The control hosts are the things around the OpenStack piece. Also the control hosts are like the ESI box. For us to launch that from a guest VM off a hypervisor, to try and do systemic monitoring from a hypervisor to a control hosts out there that's handling all of the hardware, or the secondary pieces of OpenStack, it says, "No, I'm not going to allow you to do that." We had to port out a static IP to go out there and do that, which was really not good. It was bad practice. It wasn't always stable. Once we moved it off the control hosts and we start putting blades within the cloud structure, it was fine.

What do I think about the scalability of the solution?

It's really easy to build out as long as you know SQL. On the backend, we put it on Windows in 2008. We’re running 2012 SQL on the back end. It's pretty straightforward.

On the Linux side, we are up to RHEL 7. There is some legacy 6065. We are moving RHEL 7 now. It's already hitting RA. On the Windows side, there's not a lot of Windows out there for us. What is out there, they absolutely are very, very hesitant about it -- if it ain't broke, don't fix it.

How are customer service and technical support?

Really good. Very, very good. I got nothing but nice things to say about them. From a pre-sale side all the way through to the support and logging a ticket. They are very prompt for our purposes. That day you put the ticket in, someone's calling you an hour later. If I chat up one of the engineers I know, let's do a WebEx and we will get on there, take a look what's going on.

Which solution did I use previously and why did I switch?

We had VMware up and running fine. We had an internal cloud on VMware, it was great for five years. It was almost self-regulating. Then we decided to go this other route. You know what VMware had under the hood? You have to script and program on to OpenStack to make it do the RS capability. It was a lot of "holy cow!" going on.

How was the initial setup?

It’s pretty straightforward.

Which other solutions did I evaluate?

The legacy club was already on CA with something called CA 6. It was up and functional. We always used it there. Then we started to go OpenStack, open source. I did seven or eight POC's in four months.

We looked at XenOps, we looked at MagiOS, we looked at Isinga, and we looked at CA. At the time we looked at it, CA wasn't ready. The UIM piece wasn't ready to do the no-JS, it wasn't ready to look at RHEL 7. It couldn't do OpenStack. We pushed it to the side. Same thing with EMC. We had the same problem with them. They were ready to do OpenStack or RHEL 7. We put them aside. We were going to run XenOps. Then we looked at Dynatrace. The APM solution is what we kept. They said to do a whole bunch more, but it fell short to a certain extent. We were pounding a square peg into a round hole. After about six months of playing with that, trying to get it to work, we finally said drop it. CA came back, said, guess what we can do. They met our requirements and our success criteria as well. We didn't have to have a POC on top of it. It's a new version of it. We are on 18 now. Once we put it in play and saw what it can do, it was, this is it.

What other advice do I have?

Define your success criteria very well. Make it pointed to your needs, to your industry, specifically your company. Test against that. Don't let the app teams get involved. They are going to give you 14 or 15 different variations of the same damn thing you're going to be looking at anyway. You've got to look at each one of the systems in the enterprise.

We've got six, seven, 800 applications. Each has an app team. Now, we've got an enterprise environment and IAS environment. Enterprise is running another 500 applications that are coming in through them, for the mobile applications spot. If I tried to get, it's like building an elephant by committee. We have to define 80 percent of what we want to do and monitor in the cloud. The other 20 percent has got to be free to customize. What I'm trying to do is build to the 80. Allow me to do as much automation as I can to that 80, and then leave the customization to the 20.

**Disclosure: I am a real user, and this review is based on my own experience and opinions.
More DX Infrastructure Manager reviews from users
...who work at a Financial Services Firm
...who compared it with Google Stackdriver
Find out what your peers are saying about Broadcom, Nagios, SolarWinds and others in IT Infrastructure Monitoring. Updated: January 2021.
456,495 professionals have used our research since 2012.
Add a Comment