The solution has improved our organization by providing the security required to block break-in attempts easily and without overloading the WAF or getting to our servers.

Loadbalancer has improved our organization. When we enable load balance between the two servers and we experience an issue in trying to connect to a specific URL, we can reduce the impact using this solution. One of the servers will be supporting the users so there will be no downtime and no impact on productivity. This is one of the main reasons that we use Loadbalancer.

Since I'm relatively new to the load-balancing scene, my current focus is primarily on data load-balancing.        

We couldn't use our line-of-business software without it. It sits in front of it and it just does its job. It's an unsung hero, I'm afraid. It just does what it does. It plods along everyday, and when it breaks, it gets fixed really quickly.

We had a requirement for these applications to be load balanced. Without a dedicated load balancer, we would have had to use a Round Robin DNS, which does not have any health checking, notifications, etc. We now get notifications when pool members go down, and we eliminate our downtime by not sending traffic to downed pool members.

They balance a lot better than the last set that we had. The previous load balancers made some bad decisions with allocating the load, and they would basically overload one of the single nodes behind. These, from loadbalancer.org, tend to balance it on a much better basis. The two factors, or the two features, you want in a load balancer, mostly, are high-availability and balancing the load. The last ones and these ones are both high-availability, but these ones balance a lot better than the last ones did.

It has relieved the load on our team so we can focus on other aspects of the operation.

When we do load balancing, the customer does not know that this particular node is down because the load balancing hides it from them. So, from a customer point of view, they have what I would call an unbreakable service. The service is continuous. Now, on our end, because of the load balancer, we can actually hide it from them, move to another server and bring the bad server offline. So it does improve our SLA with the customer.

It means that if one of our mail-servers falls over, it's a much more seamless process. Or if we need to do maintenance on one of them, we can take it out of the Loadbalancer in a controlled fashion so that users don't notice that there's been a problem, or that maintenance is going on. They continue business as usual. It's made end-users' experience much better.

It was part of a project that we did where we used to outsource all of the web-filtering to a third party. We weren't very happy with it. We wanted to bring everything in-house, control the system ourselves. This is an absolute key component to being able to allow us to do that. It's enabled us to have much better service to offer at a cheaper price, and much more resilient.

We can more easily set up a test environment, because you can easily configure your forms. It makes it more flexible for us to convert our test environment to a production environment, without having to change DNSs on the outside. You just configure the forms on the inside. So without changing the actual endpoint for the end user, we can create completely different networks in the background. So that's really flexible for us.

It does what it’s supposed to do which is balancing an important intranet site we are using, so if one server dies, the second becomes active straight away. The site is 24/7, so it’s crucial for us to always have it up and running.

This has allowed us to use multiple NATD back end web servers with one single public IP Address and different domain names whilst keeping our services up and running.