Red Hat JBoss Enterprise Application Platform (EAP) Reviews

The high availability is great. Implementing it is very easy. Sometimes we only have to copy the installation or the house installation and change some parameters inside the host. After that, we run the instance in the console manager, and from the console manager, we can create new servers. It's very easy to implement a high availability installation. For me, that is the most important feature. 

The solution is stable. 

Sometimes the console has a glitch. For example, we might send some commands to stop the servers and we get some logs or some errors from the console. After some minutes the services stop yet the console doesn't refresh the status. 

Sometimes I miss the JDBC resources full administration from GlassFish. In GlassFish, you define the pool and if you have three or more domains you can deploy to each domain. However, in JBoss, you have to define each pool in every configuration. Sometimes you have to do extra work to define this JDBC force and that is something that sometimes is very annoying.

For the last three or four years I have been working as an Application Server Administrator using JBoss.

The stability of the solution has been good. There are no bugs or glitches and it doesn't crash or freeze. It's very reliable and the performance is good. 

The scalability is not always perfect, however, it's very good. For example, maybe sometimes we only have two instances as we don't know how to balance three instances. We have to know how it's working the load balancer of a session data when we lose one instance or one server, for example. Maybe we need to learn more about that. 

I'd like some better documentation to find information about how it's working the load balancer in the high availability. We know that the load balancer is using the name of each instance and, for example, if we are using numbers on the line of each server, we know that from server one that the configuration is supposed to be to server two, and from the server two to server three, or something like that.

With JBoss right now we don't know. Maybe this is due to the fact that we only have two servers. With these two servers, it's enough for working and giving very good services. While we don't need to know that right now, maybe in the future we have to learn more or will have to search the documentation about how we have to configure our web server balancer or implement that load balancer with Jboss.

Before the new JBoss, we were using WebLogic, however, we changed off of that to Jboss. Recently, for the cost of paying one support for WebLogic, it's the same price to get a new subscription to JBoss. We were using the standard version for WebLogic and that version doesn't give us high availability in the future. That's why we decided to move on to Jboss. It's using a standard subscription and we get high availability with JBoss for the same price as we would pay the support for the WebLogic Standard Edition.

The implementation process is very easy.

For deployment, we only need three people. You don't require a big team.

If one person is used to deploy in the morning and then the other person is deploying in the afternoon. The next person is for learning from these two persons, therefore, basically, it's three people you need, however, maybe you could do it with two.

We pay to license on a yearly basis.

We were spending something like $12,000 in the first year. This year it's something close to $16,000.

We don't have additional fees or anything like that. It's a standard subscription.

We are customers. We only consume this product. We don't distribute it or anything like that.

In the last three years, I've been implementing the JBoss application solution. I try to create a high availability implementation, however, sometimes I try to get all the stocks working. We have some dependence on the developers as sometimes they have to implement some special implementation in each class. Basically, we have a full tolerance and in a special application, we have the full high availability.

I use the on-premise deployment due to the fact that I'm working for a government institution. We have some policies for on-premise user data. If we get a new change in our policies, we are considering moving onto the cloud. That said, for us, the cloud is not cheap as we have a lot of data. Sometimes we have maps and a lot of images and that is very expensive due to the fact that on the cloud you have to pay for each legalized transfer. Sometime soon maybe we will implement a small project. We are not thinking about moving all the infrastructure.

We have something like 1,000 users, however, the most important system has something like 500 users. We have two principal systems. One is for the clients and the other one is for internal use. We have something like 500 users on each server.

I'd rate the solution at an eight out of ten. 

We use JBoss mainly for application deployments and application servers.

JBoss is not as reliable and stable as WebLogic.

I have been using JBoss for four years.

Once installed and deployed, the solution is stable and works fine in the production environment.

When we need to scale, we install different instances of JBoss. We don't rely on clustering or specific features in JBoss.

WebLogic is a more reliable and stable tool than JBoss.

The pricing of JBoss is more reasonable than that of WebLogic.

Customers use JBoss instead of WebLogic. Although WebLogic is more feature-rich, its licensing is very high compared to JBoss. I am satisfied with JBoss's management and monitoring capabilities. I would recommend JBoss to other users.

Overall, I rate the solution a nine out of ten.

We use the solution for the installation of the hardware and microservices.

The solution is robust and provides good support.

The solution's documentation could be better.

We have been using the solution for around sixteen years.

I rate the solution's stability a seven or eight. It needs improvement as we need to do the troubleshooting for some instances.

It is a scalable solution. It supports both vertical and horizontal scaling. I rate its scalability an eight or nine.

The solution's technical support is good. Although, it depends on the type of support contract one has purchased.

The solution's setup process is straightforward for me as I have prior experience using it. I rate the process an eight. It takes a day to complete a basic setup.

It is an open-source solution.

I rate the solution an eight. There are better solutions available, like WebLogic, with high scalability.

For our application to deploy, we used to set up different platforms. We are certifying JBoss support as well for the deployment.

JBoss's configuration is straightforward and easy. It is easy to edit one standalone dot XML file with all the configurations.

The solution sometimes crashed and had some compatibility issues with the DevOps JAR file.

JBoss's next release should include a one-click solution for clustering or straightforward installation.

I have been using JBoss for three to four years.

I rate JBoss a seven out of ten for stability.

JBoss is a scalable product and 100 people were using it in our company.

The initial setup of JBoss is easy. However, the clustering part was a little bit complex.

I recommend people to use JBoss because it is easy to set up and install.

Overall, I rate JBoss an eight to nine out of ten.

JBoss is an on-premises solution we use in a banking setting.  It is used to manage servers and applications. There are two modes: domain and development. We can monitor and control all types of deployments in JBoss.

We have around 20,000 to 30,000 users on the same application and everything is going via the JBoss. We were using JBoss 1.0 when I first installed it, but they've probably included some more security patches in the latest version. 

We can deploy the applications on the JBoss server, so it is easy to manage. It's also easy to add new certificates to the config.

The documentation could be better. When we have questions, we need to check multiple websites. There isn't one place listing a set of common problems and how to fix them. 

I've been using JBoss since I joined the company three years ago. 

I haven't had any complaints in production, but in development and UAT, I've noticed that some of the applications are not deployed properly, and errors need to be fixed.

I used Tomcat when I worked for a cement manufacturer in India. They were a small-scale company, so we preferred Tomcat server. When I started working in finance, the bank suggested we go with JBoss. JBoss is easier to handle, and it can take on a much larger load compared to Tomcat.

Setting up JBoss is more complex relative to Tomcat. We need to follow the set of steps because it's not like we are installing a single system. Several separate systems need to be connected using the common prompt. There will be a common for that. After generating, we need to connect with the other ID with the main deployment controller.

There is one deployment controller, and we need to connect the separate server nodes using that. I use a trial-and-error process for the JBoss installations for the development. We follow the steps and document everything. After we do it once, it's not complex the second time because we know all the steps we need to follow. 

We don't use outside consultants. It's open source, so we do some R&D and a process of trial and error in the development environment. There is no help JBoss or a consultant. The banking team works with the development team to get it done.

I rate JBoss seven out of 10. I would recommend Tomcat for a small-scale use case. It's easy to maintain and deploy, and the UA interface is simple. JBoss is more appropriate for large industries. Though it is complex to maintain, JBoss is well balanced and can handle larger loads.

The product is basically middleware. What we have is several applications running on JBoss. Basically, it is very old and there we have those services exposed. Our target is to move them to ERPC, or something more modern, like REST or ESPC, or a combination of both.

What we currently have here, still, is SOAP services, which is a very old middleware. They also are using it for scheduling some items such as some recurrent procedures. They have a queue manager as well.

I've only been with this client in the last six months, however, the middleware has been the backbone for them for several years. The organization depends on it. The business depends on it.

The solution is stable.

You can scale the solution.

There's good documentation and a pretty good community surrounding the product.

JBoss is too much for what we need. When it was developed, it made sense. I liked having all of these services and all of these applications mounted on vehicles due to the capability. We could have several clusters in one JBoss instance. Nowadays, that solution is kind of too much maybe. We're not using very distinctive capabilities.

If the client decides to keep on JBoss instead of migrating to services, to the different architecture, the next steps would be to take more advantage of the new features, changing the code to a Java 11 style. Of course, they need to modernize the services, and consider migrating to new stuff that is available already for items like REST. Or even the use of stuff like GraphQL.

In general, the support of the ERPC would be really good due to the fact that, so far, I have not seen it. I have not even tried GraphQL, however, having any of these new technologies for exposing services would be really, really good for JBoss, That's what is moving forward in the industry.

I've been using the solution for the last six months. It has been since June. Prior to that, I only had small chunks of time with some JBoss systems. If I would gather them all, it would be about eight months of collective experience with the product.

From what I have seen, the solution is stable. Even when it was migrated to the cloud to AWS, as it was first on-premises, it was capable of dealing with heavy loads. We never saw one of the instances crashing. We haven't seen a problem related to JBoss. The client is more concerned about how old the code is and of course, they want it to move to the cloud. That's why we started to move it to AWS. Now we're dockerizing in JBoss and taking it to GCP due to the fact that the target, at the end of the day, is to modernize everything. Whether if it remains in Google Cloud as a containerized set of applications, or it's split on services or have them both parallel migrating to services, it seems like it will remain stable.

On scalability, we have enough instances in production. I have not heard about any issues with scalability. It should be easy enough to do.

As far as I know, there are three or four applications that are using the middleware. And there are some other applications that use it as well. I have three and they are like portals. 

I haven't really reached out to technical support in the past. If there's technical support needed on the code, typically I can check it out.

They have a strong community. I haven't had a need to reach out to them, however. They have good documentation for JBoss. It's available as long as you have an account and you can get the information that you might need for troubleshooting.

The solution already existed. I'm not sure if they had a different solution prior to this.

We arrived at this project. The solution was already set up. We haven't been implementing anything, we've been cleaning up all the projects. We've been making improvements on it. The solution already existed. Of course, there are things that can be leveraged, like the organization or the structure into the project. But no, the solution was already there. We have been dealing with it and parallel. We have been building a proposal to the client for migrating into small services.

I'm not sure of the exact pricing, however, my sense is that it's expensive as the client no longer wants to pay for it and would like to move away from it or onto the cloud.

What is currently being evaluated is what to use to replace this solution. The client is looking for a change.

For splitting the services into small microservices or small services, we are proposing the use of Quarkus which is a modern set of tools and of the same type as Red Hat, or Java. We are proposing Quarkus as the platform for building the services. Of course, we'll be using Java 11 for the services. We already have developed something on GRPC, and there's also the option to use REST. What we have found is less problematic when it comes to migrating, is to do a bunch of code is Quarkus precisely due to the fact that it allows us to use a lot of capabilities from Java's enterprise edition. Quarkus is the more modern technology that we have found for making it easier to make a transition.

We're just customers. We are currently migrating an application that was developed, on JBoss, and we are taking it to the Cloud.

The project was started on JBoss 6.2, however, now that we are mounting it in the Cloud, we're using JBoss EAP 7.3. The client doesn't want to pay more rights to RedHat. Now we're moving JBoss to WildFly, which is really easy. It's just to avoid the licenses. 

The deployment version is on-premises. The productive version is still on AWS on-premises, on some virtual machines that the company paid for. However, when it comes to the cloud, we are installing it in Google Cloud. We are moving it. We have these deployments in parallel.

I could recommend this solution as I have seen that it's stable. There are some things that are still done in an old-fashioned way, however, it's still stable and you can find the connotation for that. You can have the option to use it in the cloud. We are using containers already for tables in the cloud. My advice would be simply to have it really clear why you want to use it. Alternatively, if you are going to have a really heavy application where you need everything together, of course, JBoss is a good option.

I would rate the solution at a nine out of ten.

The use cases include online webshops and any organization doing online business can use JBoss.

It is fast. You can quickly migrate applications to JBoss and create things like webshops.

I have experience with this product. I've worked with JBoss before but without Red Hat. But now, it comes with Red Hat's JBoss.

I would rate the stability a ten out of ten. 

I would rate the scalability a ten out of ten. It is very scalable. 

We have contacted the technical support team now and then. 

The initial setup is straightforward and quick. You can deploy it standalone or with the Red Hat runtime, which bundles JBoss.

Licensing costs are always debatable. While there are free, open-source alternatives like Java EE and WildFly, they lack the support and reliability of a paid, certified product like JBoss. 

With JBoss, you get the peace of mind of premium support and avoid potential issues in production environments. 

So, for production environments, I recommend certified products with support. For testing, free, open-source options are fine.

Overall, I would rate the solution a ten out of ten. 

We primarily use the solution for business processes and mostly from the level of approval, within the organization.

The product integrates well with Java applications.

The software is basically decently placed, commercially as well as for production.

The solution is quite stable. 

It's perfect for the needed usage of the customer.

We haven't come across any missing features. 

The initial setup is a bit complex. 

I'd like the product to move more towards the cloud.

The frequent updates, and the life cycle, should be a little longer. They keep on changing versions and versions should have a longer life.

Even if the client buys an extended life cycle, they should support the customers who are loyal customers and extend all their possible support to the client when a customer is buying a subscription as well as extended life cycle support. The OEM should want to give additional extended support to the customer because.

I've been using the solution for five or six years. 

The stability is very good. There are no issues with bugs or glitches. the performance is good. 

The solution is scalable. It's not locked to any specific server, so the licenses are flexible.

Technical support is okay. The support comes from the GSS, the global support center of Red Hat. The problem is that support is always via email. They do not give support via telephone. Email support takes a bit of a time, however, they do give you some sort of solution. There is no typical SLA.

The solution is a little complex in terms of implementation. It is not a straightforward thing, as there is integration with multiple things which makes it not a straightforward implementation.

In terms of maintenance, it all depends upon the case and the departments. For one implementation unit, you need at least one person.

Licensing is flexible. It comes in a subscription model, so it doesn't actually lock to a specific server. That's one of the good things. Licensing costs vary from company to company. It depends on the requirements and size. Definitely, it is better than the proprietary cost. Everything is included under the license. there are extra fees. 

I don't remember the version we're using, however, it'll be the latest version at that time of implementation. These are on an in-house data center.

It's pretty easy to implement from the Java perspective, however, equally challenging to integrate with other applications or different databases. 

I'd rate the solution nine out of ten.