I use it to deploy applications built with Spring Boot and Java.
The easiest route - we'll conduct a 15 minute phone interview and write up the review for you.
Use our online form to submit your review. It's quick and you can post anonymously.
I use it to deploy applications built with Spring Boot and Java.
Tomcat is installed on-premises. Then, we expose what we call the management console. Developers can log in to the management console and do deployments from there.
I like the flexible nature of Tomcat. It allows you to deploy so many applications within a single instance of Tomcat.
Moreover, Tomcat's ease of use has positively impacted project timelines. Tomcat already has high availability – it doesn't go down so often and doesn't require a lot of maintenance. As long as your application works, you can depend on Tomcat.
The integration with key databases like Redis and MySQL, as well as tools like RabbitMQ and more, is invaluable. Tomcat is a one-stop shop. You can easily connect to so many other resources that you need for a running system. If I were to summarize it, Tomcat is already a robust, quote-unquote, container for running a Java application.
For now, it fulfills all my integration requirements.
Tomcat could be a little bit more innovative. Tomcat could come up with a framework that's more lightweight and purely targeted at Java applications. Some other solutions are doing better right now, maybe because they have come up with MicroProfile, which I think is moving forward. It may actually beat Tomcat because of the lightweight nature of the framework, the MicroProfile. They're coming up with new solutions.
So, for the future of Tomcat and to maintain the market share they might be looking for, they need to come up with initiatives to ensure that several of us have a lightweight framework to deploy applications on.
I have been using it for four years.
Tomcat has high stability. That's one of the reasons I like it – I build an app, deploy it, and it just runs. That's the kind of independence I want.
It's very scalable. We currently have about a hundred engineers using it.
We've never needed tech support.
The initial setup is straightforward. We can do it in one to two hours.
For the deployment process, you download the zip file from the documentation page, copy it to a server, unzip it, configure certificates, ports, and users, and you're ready to go.
Tomcat is flexible. You can deploy it on-premises with your own server and storage, or you can embed an IP version into your application and publish it on cloud platforms like AWS or GCP.
Tomcat doesn't release upgrades very frequently. Right now, they're working on version 11, but version 10 has been out for over a year. This means I can stay on version 10 for a while, and if I want to upgrade, it's straightforward. I simply download the active apps for the new version, set it up, decommission the old one, and I'm running with the new setup.
The main benefits are scalability and availability. Tomcat offers this.
You don't need a high-end server. A server with 4GB RAM, 24GB storage, and maybe 20GB of additional disk space is enough to set up your Tomcat instance.
This means your infrastructure costs can be low – probably under $100 USD per month if you're starting out.
This means Tomcat won't impact your revenue much, and your return on investment (ROI) can be achieved quickly. With AWS, costs will be based on traffic, memory usage, CPU usage, and so on.
It's open-source. We don't pay for the license.
Overall, I would rate the solution a nine out of ten.
There are several application server options: JBoss, WebLogic, Tomcat, and Payara. I've personally worked with all of them.
I recommend Tomcat for on-premises deployments because I've found issues with WildFly – they have frequent releases and patches, and some become incompatible with existing setups.
My advice is to go with Tomcat for on-premises setups. Also, if you want to move to AWS or GCP, it's easy. You just need to change how you compile your application; the application itself doesn't need to change. It's a matter of moving from a WAR (web archive) file to a JAR (JAVA archive) file.
We use Oracle WebLogic Server to host our Fintech-related applications for our consumers.
What I find most valuable in Oracle WebLogic Server is its flexibility in administering and managing applications, along with the built-in dashboards that offer high visibility into vulnerabilities.
Managing and monitoring the WebLogic server environment has been challenging because most monitoring tools don't support it. However, I have managed by using plugins for observability and logging tools.
Apart from application performance and monitoring, I would like to see improvements in how Oracle WebLogic Server handles logging. In my experience, there have been issues with performance degradation and thread interruptions, often requiring server restarts to resolve. This has been a significant concern across various companies and platforms, particularly in the financial technology sector in Egypt.
Additionally, Oracle WebLogic Server could benefit from incorporating containerization features to align with modern architectural practices seen in Fintech software and other Oracle products.
I have been working with Oracle WebLogic Server for about a year and a half.
Oracle WebLogic Server is not very scalable. We have over 100 key users accessing WebLogic Server daily in our environment, typically using one server with micro server setups.
I have an Oracle support account and have reached out with questions, but I haven't always received satisfactory answers. It could be due to the way I asked the question or the limitations of the support tools. I haven't always found the support to help resolve my issues. Overall, I would rate the support as a seven out of ten.
Neutral
Oracle WebLogic Server has several advantages when compared to other products. Firstly, it offers a user-friendly platform for deployment and management. Secondly, it provides on-premises monitoring through its console portal, eliminating the need for external tools. Additionally, it allows for a high level of customization through the WebLogic console UI. Lastly, the WebLogic scripting tool provides administrators with a powerful CLI for performing security-related tasks and batch operations. Despite some limitations, these features make WebLogic a robust choice for enterprise applications.
Setting up Oracle WebLogic Server initially wasn't straightforward, but I received guidance from my team. It involved multiple steps, such as installing Java, which lacked clear instructions. With experience, I can now set it up in about 15 minutes. Maintenance can be difficult, especially in cases of open constraints or timeouts.
We haven't noticed any significant improvements in application deployment or management with Oracle WebLogic Server. Since our application traffic isn't massive and doesn't require heavy encryption, we haven't encountered any opportunities for business enhancement. However, we still rely on WebLogic for accessing performance data and records.
The clustering feature of Oracle WebLogic Server is the most beneficial for application performance, as it enables handling high traffic without compromising service continuity. In my experience, applications running on WebLogic without clustering struggled with performance issues, particularly in handling high-traffic loads.
I haven't worked extensively with the security features in WebLogic Server, but I have heard it offers powerful security layers with options for network protection, encryption, and server blocking.
I strongly recommend Oracle WebLogic Server as an enterprise solution for applications. Its user-friendly platform, on-premises monitoring capabilities, high level of customization, and powerful scripting tool make it a robust choice for businesses.
Overall, I would rate Oracle WebLogic Server as an eight out of ten.