F5 states that the "brain" of the BIG-IP platform, Local Traffic Manager (LTM) intelligently manages network traffic so applications are always fast, available, and secure.
N/A
NGINX
Score 9.2 out of 10
Enterprise companies (1,001+ employees)
NGINX, a business unit of F5 Networks, powers over 65% of the world's busiest websites and web applications. NGINX started out as an open source web server and reverse proxy, built to be faster and more efficient than Apache. Over the years, NGINX has built a suite of infrastructure software products o tackle some of the biggest challenges in managing high-transaction applications. NGINX offers a suite of products to form the core of what organizations need to create…
Obviously NetScaler, because we had that functionality, we just turned it on. We were only using it for our Citrix farms and we migrated all of our F5 uses over to the NetScalers. So simply because that was, other than buying the product, which the actual NetScaler themselves …
F5 is doing its specialized function. There is no other product that can beat them. We are extremely happy with the product. Especially on load balancing, traffic redirecting TLS encryption, and SNI modification. We will continue to explore F5's product, especially on the …
We combine the AWAF and F5 BIG-IP Local Traffic Manager to not only deliver high performance apps but also secure the apps against so many kinds of threats.
The F5 LTMs integrate great with the F5 DNS appliances and makes on the fly decisions using iquery. We have two HA data centers that the F5 LTMs are used in and integrate great with teh F5 DNS servers.
As far as I know, F5 BIG-IP Local Traffic Manager (LTM) from F5 is the best and the number of features is unmatched compared to its competitors. The first-time setup is also quick and easy and the product behaves as a full proxy which is rarely seen. The support is good and …
How does it compare? We use Apache ATP server and we also use Tom Cat also owned by Apache, but both Apache, ATP, and MKA. They are relatively older than GX and so they're one problem for Apache and MKA they need more power, more memory, and more space.
NGINX have higher market share which obviously show to us it is the preferred choice of most of the customers. Both of platform competes in the Web and Application server areas, but due the security features of NGINX be more flexible this in my opinion makes more sense.
Apache is a market leader but NGINX is new and has new features. Lightweight and can handle static requests. We use EC2 and I believe NGINX is more suited when it comes to scalability.
MS IIS and Apache HTTP server both provide many similar services. However the configuration simplicity, and performance characteristics helped us choose NGINX above the other 2 products.
I have found that [NGINX] seems to perform better throughout the years with less issues although I've used Apache more. I would definitely recommend [NGINX] for any high volume site and I've seen this to usually be the case from most provided web hosts who will pick [NGINX] …
NGINX Stacks up at the top for me because it's fast, reliable, and secure and apache is also usable but not so good in comparison to NGINX and since I and my organization have switched to NGINX I also don't want to look back at apache as NGINX works the best for our use case …
NGINX's footprint is much smaller than Apache, and it's great for serving up static content. The URL rewriting was not as familiar as Apache, but just as powerful once configured correctly. As a load balancer, it's much more affordable than Citrix ADC. We used the load …
Compared to Apache, NGINX is much lighter on resource consumption, and also far faster as a server, serving static content over twice as fast in most benchmark tests. NGINX doesn't offer as much potential configuration and customization as Apache, however, so if these advanced …
Nginx's cache mechanism is better than Apache and HAproxy. Also Nginx is very light weight and works for multiple sites with much less work. i.e. As front end proxy server configuration is very easy as compared to other applications. Apache sometimes crashes and is not able to …
There was a need to have the DR environment to be available actively but not to send the traffic unless the production is down The F5 BIG-IP Local Traffic Manager (LTM) priority feature helped achieving it. It was well suited in handling the HTTP headers using polices and iRules. It was less appropriate from the application security perspective in the current version. But after attending the AppWorld 2024, I see a lot of ways to protect the network and the application with several features.
Nginx is well suited for serving any static content - whether that be images, JS files, HTML files, CSS files, videos, etc. If you have a high-traffic website, Nginx will be a great fit because it handles large number of requests extremely efficiently. Nginx has full support on Unix systems, but only has limited support on Microsoft Windows machines.
Sure. It does load balancing fantastically. I mean, it's an industry standard product for that. We also use it for TLS offload for applications. Those are the two main use cases for that. We do also use some of the I rules for traffic filtering. We've used that in some of the external facing services. It does a really nice job with that. It's a little bit complicated sometimes and some of the Cipher Suite stuff is interesting.
Straight-forward configuration format that users of all skill levels can learn, and yet is powerful enough for the huge breadth of features that Nginx provides.
Massive scale right out the box. We've never had a Nginx instance overwhelmed by requests, and if we did it would be trivial to spin up more Nginx instances to handle the load.
SSL termination means that we can deliver content over HTTPS without needing our individual services to require TLS support. This saves us a lot of time and headache while keeping us secure.
Nginx is open-source and free, meaning that anyone can use it to power their services, from individual projects to billion-dollar websites.
Some of the stuff you have to dive into the CLI to really use, I'm going to reach back to the previous employer for this. So I had a much greater degree of involvement with it at that point in time for, I was the crypto guy at the company and I had to design all the cipher suites that we actually implemented on our front end banking products. So in order to do that, I had to dive into it, download all the Cipher suites, figure out the actual order of operation for them, how they were selected because I wanted to design the Cipher Suites to actually provide a specific customer experience for the types of connections that our customers were likely to initiate. Getting at that information was a giant PITA. It was poorly documented at the time. I'm not sure if it's documented any better now. Every time the software changed or got upgraded, made your version, I'd have to do it all over again because the upgrades to the stack, which looked like it was based on open SSL, but it was heavily modified with a different syntax. Oh yay. That's fun too. So I had to write giant documents describing all of the ciphers that I was designing for this because it just kept changing all the time. So I didn't care for that aspect of it. Traffic management does a great job for that.
Nginx often requires some initial configuration. It's worth doing, because you'll end up with great results, but it can be slightly daunting for someone to get started using it. Apache might have a leg up in that regard--When you install Apache, typically it's just about ready to do what you want already. But the issue with Apache is that most people skip the extensive tuning phase required after that, and with nginx it becomes more just a part of the configuration process.
Sometimes, the configuration syntax, even though it's powerful and terse, isn't the most intuitive. Luckily there's plenty of documentation about what things mean and how to accomplish certain things. There may not be much that can be done about this--to have a powerful web server, you need a powerful-enough configuration language.
The nginx brand is somewhat fragmented, and it can be confusing. There's the open source nginx web server, which I've primarily been referring to. But then there's NGINX Plus, a premium subscription-based service which works with a range of other NGINX products (NGINX WAF, NGINX Amplify, NGINX Controller). I've met a number of people who weren't very familiar with nginx, and instinctively went to nginx.com first, and from there it seems like everything costs money. It's only when they realize there's a different site, nginx.org, that they find what they went looking for.
F5 has always been one of the best products we have in the data center. We had few issues with the BUG and Code upgrades but the main use cases for F5 was always top notch. From High availability to Globally load balancing applications across multiple data centers and muti cloud environments.
F5 BIG-IP Local Traffic Manager is a very good product. It is used in our company widely. So far we are very happy with the product. Esspecially on the load balancing and TLS encryption and Traffic redirecting based on HTTP path and http query. iRules is very easy to use as well.
Front end proxy and reverse proxy of Nginx is always useful. I always prefer to Nginx in overall usability when you have application server and database or multiple application servers and single database i.e. clustered application. Nginx provides really good features and flexibility which helps the system administrator in case of troubleshooting and also from the administration perspective. Also, Nginx doesn't delay any request because of internal performance issues.
Community support is great, and they've also had a presence at conferences. Overall, there is no shortage of documentation and community support. We're currently using it to serve up some WordPress sites, and configuring NGINX for this purpose is well documented.
Obviously NetScaler, because we had that functionality, we just turned it on. We were only using it for our Citrix farms and we migrated all of our F5 uses over to the NetScalers. So simply because that was, other than buying the product, which the actual NetScaler themselves were cheap. I mean it cost us like $60,000 for all of them for the hardware. We were already licensed for it, so it was a no-brainer. We didn't have a choice. Definitely a superior product. A lot more functionality, particularly in corner cases where you might need to make some specific traffic tweaks. I would say that the NetScaler doesn't do nearly as good a job with that traffic filtering. You only really get URI filtering with NetScaler. You don't have the flexibility, the eye rolls or the complexity of the eye rolls, so that's a negative too.
I have found that [NGINX] seems to perform better throughout the years with less issues although I've used Apache more. I would definitely recommend [NGINX] for any high volume site and I've seen this to usually be the case from most provided web hosts who will pick [NGINX] over alternatives
We use these for 600+ applications and we are able to manage all of them remotely and provide security across every application in one single platform.
We are able to provide an amazing customer experience load balancing across multiple nodes and this increases traffic on our websites and ultimately increases orders and traffic.
When we first migrated our primary bidding environment architecture to Nginx, it was under duress due to Apache's inability to keep up when we consolidated away from an HAproxy model to a central HTTP proxy. So we even when we did not know what we were doing, we were able to make it work in a bad situation, and everyone was quite happy.
The biggest complaint I have is that I find the module compilation requirements for nginx+ rather burdensome. If we pay for Nginx+, I'd love to see then have pre-built modules for ready for each release of more modules. We are spending our own time engineering an in-house solution for module testing for nginx+ releases, which is disappointing.
I've also, as the primary Nginx person at my organization, inserted my expertise into other projects, and have saved our company lots of money getting rid of big $$$ appliances for general SSL proxying.
Speaking of Nginx replacing SSL appliances, we had an instance where we had to suddenly enable elliptic-curve SSL ciphers and our big $$$ appliances (you know who they are), were falling over. Even their SSL accelerator cards, after all, are just a few extra cores to process SSL. But in an environment of our size, we use DNS to spread the load to hundreds of frontend proxies with dozens of cores each to spread this load out, all at a lower price than ONE of the appliance pairs running Nginx. We couldn't even tell the change in load in our Nginx architecture when we enabled the ciphers.
