We use it for application monitoring.
We use it for application monitoring.
The people who monitor the applications, the operations staff, are not typically developers. The operations staff can, by themselves, configure that monitoring to react to an issue they've seen. They get a very short and tight feedback loop where they see an issue and they can incrementally improve the monitoring themselves.
The operations staff have a good understanding of the behavior of the application in real life, so they are best placed to update some of that monitoring and they are able to do that when it doesn't require development skills. You'd normally put highly paid, experienced developers on the call face to monitor it in the middle of the night.
One of the most valuable features is that it can be configured by non-developers. It doesn't require development expertise to configure it.
The ITA, the post-incident analytics, could be improved. They know that. I'm sure they're working on it. That encompasses a whole facet, a whole dimension, of the product.
The stability is quite good. It's what I expect. It's commensurate with a product of that flexibility and price point.
We've used horizontal scaling effectively. Horizontal scaling, by having more of it, more systems, and more processes, works quite well. That horizontal scaling allows us to delegate the administration as well. We've not hit scaling problems ourselves, but if people wanted a big, humongous instance, and they used vertical scaling, I imagine they would.
We've not had problems, but I could imagine some people, if they go the vertical direction, would have problems. That's not uncommon with software technology. I was watching a Google presentation last night and they were saying, "If you go vertical, you will almost certainly hit problems, whereas horizontally, you can just keep scaling forever.
Technical support is excellent, very good. They're very accessible, with them being specifically London-based. Unlike if you went for one of the big providers - which, if you did, you would have to be a very big customer, in a top-tier bank such as ourselves, to have regular meetings with them - we can talk with the product managers, we can get our points across. They're accessible. It's good, we're happy.
In those days we only used home-baked solutions, but nothing commercial. Someone else made the choice to go with Geneos. It was prior to my involvement. We thought, "That looks okay."
The initial setup was straightforward. Just put your head down and do it. We got it knocked off in a day. It's fine. It was a long time ago, but it was fine. Straightforward.
My implementation strategy at the time was roll my sleeves up and get stuck in. With it being a practical product, one that you can improve and make changes to, there's not a long ramp to get value out of it. You can get value very quickly out of it. Then you can incrementally build off that.
You don't need months and years of training to get anything out of it. You can get something out of it, literally, on day one. Then you can increment and improve, as you understand your own requirements, and as you understand the product, and as you mature as an organization.
On all aspects, as you understand more of everything, you can improve your monitoring. So the good thing is you get something out of it day one, you don't need years of training, and then you can build on that.
The deployment was done by just me.
Once deployed and configured, we distributed maintenance, in that people maintain their own areas. It's not that it requires a certain number of people to maintain it, rather, a lot of different people have input into the rule-setting. Currently, it is just me who maintains it. A very small team would suffice for maintenance.
We've seen increasing stability. Given the problems and issues that software invariably has, we've had the ability to quickly react and identify where those faults lie because we've had monitoring. The return has really been our ability to have confidence that things are good and, when things are bad, our ability to work out quickly and focus on where they are bad.
I believe they went back probably another decade. It went back to the very early market-data days. There wasn't much choice at the time, if any. There was open-source software, such as Nagios that we had looked at. There was some open-source software, but nothing really in the sensible commercial space.
It would be sensible to use experienced staff. Although I say you can get up and running with little or zero experience, and then go on the journey yourself, if you want to get up and running quicker, then use experienced staff. It's not essential, you don't have to, but if you have a choice... I don't necessarily mean experienced in terms of the product itself, Geneos.
Use staff that has higher experience in production support and in seeing problems first-hand. They're the ones who will know what to set up and monitor. Use someone who has real-world experience in seeing what those problems are, and maybe even supporting it themselves. They need to be at the call face or inside of the call face, and the daily problems.
Don't use a developer in the back room who just gets a problem ticket every so often, but someone who is involved in the firefighting so they can see the real problems that you're trying to solve. Those real problems include having issues being picked up in a timely manner, and what's needed to quickly focus on where the problem is. Someone in a back room who receives a problem ticket isn't going to understand all the processes that have been followed to raise that problem ticket. You need someone at the call face who sees all the arguments between the different teams, each one saying, "It's not my problem." They need to see people scratching their heads and thinking, "I don't know where this comes from." All those real-world problems.
To sum it up, use someone who has real-world experience in dealing with production support first-hand, or in direct sight of first-hand. I feel that quite strongly.
In our organization, the solution is extensively used, and we're happy with that coverage. It's used across seven business divisions. We have a complex licensing arrangement. The number of users is in the hundreds. We don't have plans to increase nor demise. It's stable, it's serving a purpose, and we're happy with it.
It's always dangerous to give a solution a ten out of ten, because it can strive. And a seven is pretty neutral. It's got an area where it could improve, in the IT analytics, so I'm going to give it an eight because there are two steps for improvement to get that IT analytics done.