The centralization of the administration is what's most valuable for us. We have a larger estate, with a number of servers and different data centers. Because administration for all this is centralized, we can manage everything with a pretty user-friendly system.
We use it for building provisioning servers, installing software, maintaining software, patching, and maintenance. We hope to also use it for deploying apps in our environment.
It's hard to tell what might be some areas of improvement because some of the constraints might be access-based or have role-based access, so I don't necessarily have access to them. Obviously, we have administrators who narrow down the privileges of our use.
But what I would like are more functionalities around code release. We have a lot of people who spend a lot of time manually deploying code into our thousands of environments. So to make all that more efficient and easier, there should be more functionalities.
I'd also like to see more enterprise-level improvements with concurrency and scalability. It should be big enough to work with the state that we have, but I think there are some concurrency issues such that we can only do 10 or 20 things at a time.
It has deployed without issues for us.
We haven't had any stability issues.
For the servers I'm involved with, we have probably 8,000 of them. In total, there's probably thirty to forty thousand servers in our company.
When you get to speak to the right people, they're helpful. But sometimes it's difficult to get to speak to them. The problem is, I think, is that the way we use the products is not that widely used across the globe, so there's not many subject matter experts within HP who can help us. We struggle to find the right person to talk to, though we eventually get who we need.
I wasn't involved in the initial setup.
We considered both Oracle and Microsoft solutions. However, we wanted to have a single, unified system within our architecture, so we stuck with HP.
I'd suggest that you start small and learn the tool set. Once you've put everything into place, then you can grow.
HP Operations Manager has been around a long time in the Enterprise server management space. I first started working with it around 2001, and I’ve always had a soft spot for it, but I’m ready to declare it abandoned. HP has failed to develop the product, and they now seem to be actively working on a viable alternative.
HP Operations Manager (HP OM) is an agent-based server monitoring system. Agents are installed on monitored systems. Monitoring policies are defined at the central server, and pushed to agents. This keeps the bulk of the processing local, as agents only need to raise exceptions. It also makes agents very powerful – they can do anything on a managed node – check processes, monitor logfiles, run actions, etc. HP OM can also act as a Manager-of-Manager, receiving and consolidating events from other systems – e.g. HP SIM, NNMi, Storage Essentials, SiteScope, etc. It has been around in some form or another since 1993. It’s had a few name changes over the years – OpenView Operations, ITO, VantagePoint Operations, and now just Operations Manager. It has Windows and Unix versions (abbreviated to OMW and OMU/OML respectively). The Windows and Unix variants use the same agents, and can share policies, but the administrative and operator interfaces are completely different.
Development for HP Operations Manager appears to have stalled recently. The last update for OMW (9.0) was in September 2010, and the last update for OML/OMU (9.10) was in November 2010. Since then we have seen further releases for the underlying Operations Agent, and some small patches for Operations Manager, but no real enhancements. HP OM has increasingly ill-suited to modern dynamic environments, and unsurprisingly I hear that sales are well down, and crucially support renewals are dropping significantly.
HP OM has not adapted well to modern demands. It does not deal well with VMs being deployed at a high rate. It does not offer service monitoring capabilities. It does not offer any way to connect to cloud provider APIs. The agents have continued to be unstable. The administrative interface for OML/OMU looks like something I wrote over a weekend based on a shopping cart – it does not look like a piece of software that costs tens of thousands of dollars. Or actually maybe it does – Enterprise software in general tends to be ugly. HP didn’t even develop it themselves – they licensed the admin interface from Blue Elephant Systems. The Java GUI for OML/OMU was a disgrace in 2002 – and it hasn’t changed since.
Java GUI circa 2002
Java GUI circa 2012
(OK, so I cheated, those images are the same – but that’s because it hasn’t changed).
I can only assume this lack of development was because they lost out politically, and could not secure the necessary funding and resources. I believe the turning point for HP Operations Manager was the 2006 purchase of Mercury Interactive. This completely reshaped the HP Software division. That portfolio included SiteScope, an agent-less server monitoring system. OM’s design and architecture just didn’t fit into this model. Efforts to integrate them have been derisory – e.g. the system for using HP OM to manage policies across multiple SiteScope servers is the sort of poor code that I might do as a quick hack. It does not meet the marketing message of “fully integrated.”
Also consider this diagram showing how Operations Manager should fit into your overall architecture:
Image from www.softpanorama.net
Note how everything feeds into Operations Manager, which then feeds into Operations Manager i (OMi)? To the uninitiated: OMi is a different product, in spite of the near-identical name. When you look at that, you ask yourself – what’s the point in HP OM there? Why not just feed directly into OMi?
So what’s the future of OMW/OMU? Let’s try reading between the lines – look at the recent announcement by HP about OMi Monitoring Automation. This separates monitoring policies (configuration, thresholds, etc) from implementation (agent-based, agentless). It bypasses the OM server requirement, with agents directly managed by the OMi server. I haven’t seen enough of the implementation details yet to confirm that OM has been completely replaced, but it’s clear enough to me what the future direction is. Development has continued for Operations Agent, but clearly Operations Manager is surplus to requirements. Well maybe it all makes sense – why the hell did they ever have two separate products, one named “Operations Manager”, and another named “Operations Manager i”?
What future for HP OM then? It now only makes sense as a Manager-of-Managers for organisations that are too small to commit to the whole HP BSM suite. Even those organisations need to re-think their use of OM though, as it can’t handle a dynamic environment, and stands little chance of being able to integrate proper APM, or cloud service monitoring. There are other products out there that are better suited to modern medium-sized organisations.
To the HP people reading this: Obviously you can’t publicly confirm any of this. You’ve promised ongoing support to those still paying their annual support fees. But if I’m wrong, then show me the code. Deliver some updates to the product, and show us that it is being actively developed. Vague promises of continued commitment mean nothing without shipping code. To customers using HP OM: My advice is to start planning your migration away from it, if you haven’t already. To customers considering purchasing it: Don’t, unless you’re buying it as part of an overall BSM/OMi implementation, and the salesfolk have guaranteed you can change your licensing over at no cost in future.
Disclaimer: The company I work for is partners with several vendors including HP.
Thanks, what is the currently version are you running?