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…
N/A
Oracle Dyn Managed DNS
Score 8.8 out of 10
Mid-Size Companies (51-1,000 employees)
Oracle Dyn DNS (domain name system) is an infrastructure-as-a-service that is touted by Oracle Dyne as one of the highest performance global networks existent. It is available as a managed DNS with secondary DNS available for more reliable business continuity on higher service tiers.
As our organization had an ample amount of DNS to manage, it was quite inconvenient when it comes to Amazon Route 53 or any other alternatives as the change propagation time was pretty much high as compared to Oracle Dyn Managed DNS. And when it comes to the huge customer base …
[NGINX] is very well suited for high performance. I have seen it used on servers with 1k current connections with no issues. Despite seeing it used in many environments I've never seen software developers use it over apache, express, IIS in local dev environments so it may be more difficult to setup. I've also seen it used to load balance again without issues.
Oracle managed DNS becomes very heavy when there is an ample amount of DNS being managed. However, the DNS creation and updating takes very less time to propagate and is very easy to use. So, for an organization, where there is a modest amount of DNS to manage, it works very well and gives a splendid experience. So, considering the complexity of managing the DNS for an IT company Oracle Dyn managed DNS is the best option to opt.
Customer support can be strangely condescending, perhaps it's a language issue?
I find it a little weird how the release versions used for Nginx+ aren't the same as for open source version. It can be very confusing to determine the cross-compatibility of modules, etc., because of this.
It seems like some (most?) modules on their own site are ancient and no longer supported, so their documentation in this area needs work.
It's difficult to navigate between nginx.com commercial site and customer support. They need to be integrated together.
I'd love to see more work done on nginx+ monitoring without requiring logging every request. I understand that many statistics can only be derived from logs, but plenty should work without that. Logging is not an option in many environments.
More responsive sales team to provide relevant QBRs to ensure proper and best practice use of the product/platform
Integration of the Dyn ECT Managed DNS with Dyn Domain Registration would be a nice feature as currently I have to manage two consoles and billing accounts.
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.
This is the only real gripe we have with Dyn; their web-UI can be remarkably painful to use. In the "simple" editor, DNS records are arranged in a kind of "node" view, where each record is a node and any records of the same name or longer (i.e. all records called "record.example.com" or "other.record.example.com") fall under it. This creates an odd sort of hierarchical view that's not really representative of the zone file. The "expert" editor doesn't have an actual delete button, just a checkbox. If you want to update conflicting record types (for example, replacing an A record with a CNAME) you have to check the box for the record being deleted, save changes, create the new record, save changes, and finally publish changes. Dyn uses a publish model for changes, where all changes you make are staged and can be reverted or published all at once. This is fine, except that the publish/revert dialog is in a different page. This is nice when you have many changes, but very annoying when you're changing just one or two records across multiple zones. These are relatively minor issues in an otherwise good platform; annoyances more than deal breakers.
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.
The support team at Dyn has always been very helpful and have tried to answer our questions to the best of their knowledge. We have never had any issues from support tickets and they are often resolved in a few hours
We have used Traffic, Apache, Google Cloud Load Balancing and other managed cloud-based load balancers. When it comes to scale and customization nothing beats Nginx. We selected Nginx over the others because
we have a large number of services and we can manage a single Nginx instance for all of them
we have high impact services and Nginx never breaks a sweat under load
individual services have special considerations and Nginx lets us configure each one uniquely
We use both Oracle Dyn Managed DNS and Amazon Route 53. We like having our main DNS provider outside our cloud provider in case there's an issue with Amazon and we need to point things somewhere else temporarily. But for all the smaller stuff and internal stuff, we use Route 53 successfully.
Nginx has decreased the burden of web server administration and maintenance, and we are spending less time on server issues than when we were using Apache.
Nginx has allowed more people in our company to get involved with configuring things on the web server, so there's no longer a single point of failure ("the Apache guy").
Nginx has given us the ability to handle a larger number of requests without scaling up in hardware quite so quickly.
For the law firm its being used for, it keeps their remote users working. For law firms, time is money, usually every 15 minutes lost can be a big deal to them.
Sometimes it has switched when its not supposed to, and causes downtime. No real way to inform users when the switch is happening, it would be great to have an email alert we can not only send to ourselves but a notification to primary and technical partners in the firm so they don't have to yell at us like something is broken, instead they are aware it had to change.
