What is our primary use case?
Tomcat is a cloud-based platform. Previously, deploying applications required setting up a Tomcat instance and then deploying the application on it. However, our solution has streamlined the process by prebuilding and prepackaging multiple services, each equipped with its own embedded Tomcat instance. This simplifies deployment, maintenance, and configuration tasks. Instead of managing separate instances for each application, we can now seamlessly deploy each application with its own embedded Tomcat instance in the cloud environment.
How has it helped my organization?
Tomcat has connectors like REST requests to connect the front end. Also, some parts of the inter-system communication go through REST. External connections with third parties occasionally involve both REST and SOAP protocols. Tomcat is versatile in accommodating these various communication methods.
What is most valuable?
We are using Tomcat primarily as a request blocker. It manages queues and handles routing. The size of these queues can be adjusted to scale the application, accommodating perhaps 50-100 REST connections. Using these tools, we achieve our scalability goals. Tomcat is a highly scalable solution.
What needs improvement?
Tomcat is a polished product that has been around for a long time. It should be simple and high-performing, with the ability to grow and maintain stability. The fewer features it has, the more stable it will be.
Also, there could be more configuration options. It's always lovely to have finely tuned-configurations.
For how long have I used the solution?
I have been using Tomcat for many years.
What do I think about the stability of the solution?
The product is stable. I rate the solution's stability a ten out of ten.
What do I think about the scalability of the solution?
The solution's scalability is impressive. We manage multiple ports for various systems; for instance, one of our systems utilizes eight ports. Consequently, we deploy the corresponding package eight times. Additionally, we employ a load balancer to distribute traffic across these eight ports, effectively managing incoming requests. Scaling horizontally involves utilizing updates, and there's potential for further scalability in this direction.
How are customer service and support?
Which solution did I use previously and why did I switch?
I have some limited experience with JBoss. Tomcat has become the standard now. There are other application servers like JBoss. They offer some excellent features for web projects. However, Tomcat is basic. Other servers provide more on top of that, which can be advantageous in some ways but also disadvantageous in others. They may be harder to support, have some issues, and be more complex.
Additionally, they might not scale horizontally as well. That was my impression maybe ten years ago. However, I believe Tomcat is now the de facto standard, and you'd need solid reasons to choose anything over it, perhaps for specific features that you can't find in Tomcat but might be available in other application servers. On the other hand, Tomcat is simple, quick, and scalable, making it a perfect solution.
How was the initial setup?
The setup process is straightforward. Also, additional fine-tuning options are available in the application setup. Overall, it is a polished product. It has been evaluated over time and effectively meets our needs. Tomcat is pretty packaged together for deployment.
What about the implementation team?
What was our ROI?
What's my experience with pricing, setup cost, and licensing?
The product is free of cost.
What other advice do I have?
We use it locally. It's really fast for development and very easy to deploy in production. We are using all of this with a single distribution. We have the same Tomcat version we use on our local machines, test servers, and production. Having this same deployment allows us to test it locally and on test systems before deploying it to production.
I suggest going with the embedded Tomcat, which is available with Spring. Let's say you use a job framework like Spring, incorporating Tomcat.
We have multiple web services, some accessible internally and others externally. We employ a set of firewalls to protect our internal services. Additionally, we use microservices for functionalities for external access. These functionalities are developed into separate, small web services and secured externally. The security measures, including firewalls and server-to-server access, are implemented independently of Tomcat within our setup.
The product is simple and easy to scale. Overall, I rate the product a ten out of ten.
Which deployment model are you using for this solution?
Public Cloud
Disclosure: My company does not have a business relationship with this vendor other than being a customer.