Excellent value for companies wishing to host Java applications in the cloud. Utilizing hosting tools such as load balancers and network and application firewalls, Tomcat can be part of a powerful system to host web applications to thousands of users. There has been consistency in the development and support of Tomcat since its initial release in the late '90s and the best commonalities have been carried forward. If you host Java web applications, Tomcat is as good as any for an application server.
SolarWinds IP Address Manager is very useful the bigger and more complex the environment. Smaller organizations will have to consider the cost as it provides little benefit over monitoring maybe 2-3 servers. But I have over 24 DHCP servers with on average 15 subnets each so tracking and monitoring all that was very time-consuming. As a result, it was generally ignored until there was an issue. With SolarWinds IP Address Manager, I was able to set alerts to monitor scope utilization and duplicate IP addresses.
With IPAM automated address scanning, we can be confident that we are looking at an up-to-date, accurate snapshot of our network.
The built-in alerts are a great safety net. We know that even if we aren't paying close attention to our IP address space, IPAM is. If a range is nearly full, IPAM lets us know before it becomes a real problem.
IPAM's event logging gives us insight into any and all changes made by our network engineers.
Using tomcat manager to troubleshoot is not very informative. Error messages are vague, you have to dig into log files for more information about the problems.
Is great for simple web applications, but may not work for heavy development which may require a full J2EE stack, might like JBoss better.
Security in tomcat is not straightforward, as I discovered that you have to understand how to set up realms in tomcat in order to hash passwords, which I was not overly familiar with, which is a big deal when setting up users in the tomcat-users.xml file.
The user experience is not as intuitive as other products. We have to be more restrictive around level 1 help desk access compared to NCM or NPM in SolarWinds.
Making and enforcing changes, not just monitoring, has been hit or miss in some instances.
We are heavily invested in SolarWinds. We currently own Network Performance Monitor, Netflow Traffic Analyzer, User Device Tracker, Server Application Monitor and Network Configuration Manager. We have NOC mode setup for deskside support for monitoring any down devices that may effect our network across the globe. This application gives us the information we need when we need it.
Tomcat has a very rich API set which allows us to implement our automation script to trigger the deployment, configure, stop and start Tomcat from the command line. In our projects, we embedded Tomcat in our Eclipse in all of the developer's machines so they could quickly verify their code with little effort, Azure Webapp has strong support for Tomcat so we could move our application to Azure cloud very easy. One drawback is Tomcat UI quite poorly features but we almost do not use it.
SolarWinds IPAM is like what SolarWinds itself says, i.e. easy to use and simple. SolarWinds has really made their orion and non-orion platform products so simple that any newbie can give a try and make the best use out of it. I learned SolarWinds IPAM by myself in a POC environment, and not just IPAM but other modules and now I own 6 certifications. You see how easy to use this product is.
Tomcat doesn't have a built-in watchdog that ensures restart upon failure, so you have to provide it externally. A very good solution is java service wrapper. The community edition is able to restart Tomcat upon out of memories exceptions.
Tomcat support to customize memory used and allow us to define the Connection pool and thread pool to increase system performance and availability, Tomcat server itself consume very little memory and almost no footprint. We use Tomcat in our production environment which has up to thousands of concurrent users and it is stable and provides a quick response.
We do not integrate IPAM into other systems other than the standard Orion integration. The performance is reasonable, however, we are running all the SolarWinds applications on a very large server.
I have not contacted customer support and therefore have no experience in this area. I know we have some issues with our VAR support at this time for Orion, but I don't know if the IPAM falls into the same support structure. Perhaps others in the organization may know more regarding the support area.
Eclipse Jetty is the best alternative for Apache Tomcat because which is also an open-source and lightweight servlet container like Tomcat. A major advantage of this over Tomcat is that Jetty server can easily be embedded with the source code of web applications. Since it requires less memory to operate, you may realize that it is very efficient.
SolarWinds IP Address Manager was cheaper than both alternatives and far easier to manage. Device42 interface is years behind what Solarwinds offers. It is very outdated; BT Diamond required remote management and we constantly had to message support, it reached a point where it was better not to have the product at all.
We have not experienced any scalability issues with this product. However, SolarWinds needs to allow users to scale horizontally without any license restrictions. For example, we would like to separate Netflow and Orion onto different platforms but are unable to due to license restrictions.
Tomcat is cheap and very quick to deploy, so it has benefited much when situation needs applications to be deployed quickly without wasting time on licensing and installations.
Plenty of documentation available so no vendor training is required. Support contract is not needed as well.
IPAM has saved countless hours of running scripts and gathering data to compile reports to plan re-subnetting globally.
IPAM has reduced helpdesk incidents by immediately spotting bad DNSR and IP conflicts.
IPAM has helped eliminate blocks on projects whereas there is not currently enough address space requiring major changes to accommodate more IP'ed servers, gear, etc.