Nginx to Be Acquired by F5 Networks
nginx.com
nginx.com
If you start a company and open source your core/clients, your product becomes part of AWS, and AWS runs you into the ground. If you mix in proprietary licenses to protect yourself, AWS forks your core, adds in open-source licensed clients, then runs you into the ground (and you lose open-source contributors/supporters as a bonus who may fork your core themselves).
I remember from a undergrad class reading Google's system design papers, that they publish only the top-level architecture for core systems they use, and only after 3-5 years of use when they have moved on to a better system. After all this (Docker/Redis/Elastic/Nginx), I think that might be the best path forward. You can provide the benefits of open-source and recognition for the architects, but not lose your competitive advantage. Open-sourcing your core product seems too idealistic.
I'd imagine that the challenge with the AGPL is catching and suing the non-compliant services.
I am curious whether there are any practical observations, one way or the other, about the AGPL’s enforceability.
Nobody is suggesting that an AGPL licence violation would result in a criminal penalty, but if you got caught you may be forced to release any changes you made to the source code. And you could lose the ability to use the software in future—if your business relied on it you might be screwed.
Personally I think the AGPL is stupid, but people are free to pick whatever license terms they like for their copyrighted works. Whether I like it or not is irrelevant.
Personally, I find “you are licensed to use the software without releasing your modifications on your internet connected computer, however if you open a port and offer it as a service, you are not” to be entirely ridiculous. It seems to me that a license can’t (or at least shouldn’t) hinge on what other software I am or am not running on my computer (eg a webserver).
That is why I asked. I’m all for copyleft (despite the fact that its validity hinges on an inherent affirmation of the validity of the concept of intellectual property), but I passionately hate the AGPL because I think it is an unjust infringement upon my freedom as a user. It’s like saying “you have a license to use this software as long as you don’t run a browser that accesses porn on the same machine”. I think it oversteps the boundaries of copyright-as-designed.
I don't think many developers are aware that Ghostscript has an AGPL license, and I've heard that the commercial license costs $25k per year. It's very easy to just `apt-get install ghostscript` when you want to work with PDFs (e.g. with imagemagick), but this violates the AGPL license when you are running a SaaS application.
There are some permissively-licensed libraries (Apache 2.0) that provide similar functionality, such as PDFBox [2], or PDF.js + Node.js.
[1] https://www.fsf.org/blogs/licensing/update-on-artifex-v-hanc...
Also, it's 2019 - Artifex, it's OK, you can publish your prices (https://www.artifex.com/licensing/)
Only if you modify the Ghostscript source code.
But I also know that the AGPL license is usually adopted because they want to sell a commercial license, even if the source has not been modified. Artifex is very explicit about their intention on the licensing page of their website.
It depends on the definition of “modification” and “derivative work”. Artifex is adamant that any software using Ghostscript is a derivative work, and the copyleft will apply, so all of your source code must also be released under the AGPL license. This is especially true if your software cannot function without Ghostscript.
If you are only distributing your application (i.e. not a SaaS app), then you could make Ghostscript an optional plugin that people can manually install (like LAME for Audacity.) But a SaaS app provides access to the application over the network, so you cannot use Ghostscript without a commercial license, or without releasing your application’s source code.
I didn’t see anything about Hancom modifying the Ghostscript source. It was the fact that they distributed Ghostscript along with their own application, and their application depended on Ghostscript for some functionality. That was enough to trigger the GPL copyleft, so they were violating the terms of the license and had to settle out of court. The AGPL means that you would be violating the license by providing access to your app over a network.
A company invests money and engineers in building commercial tooling, which you then pay for because there is added value. You are not paying for the open source - which is freely available. How is that scummy?
The "comply with the license" part is the problem you're not seeing, using open source as SaaS is a loophole not a license feature.
An example being, I license something as open source which means if you don't pay for it (assuming there's an option for that), you are bound to follow the license I provided which means all further work has to be open source (the same license I used) and source has to be provided with the product. In an ideal world this would mean either:
1. We both get paid
2. We both contribute to open software which is available to anyone
But in our world it means, technically I'm not selling software but a service so I don't have to do shit. so the result (with scummy companies) is the following:
1. I don't get paid for software critical to your business
2. No one gets the benefit of the new product created despite my license
Hence, scum.
This is entirely untrue. If it were the case that 'I don't have to do shit', then why doesn't someone else do it too? Running a service takes a WHOLE LOT of work, and writing the software is, in many cases, the easy part.
We know this is true because whenever there is a conflict with a software license, the big cloud vendors just re-write it themselves.
I'm still wary, though. I could imagine if the resultant fines or source code releases from violating a GPL license weren't a strong enough deterrent, you could win by using a GPL-licensed product enough, then parry off attacks from EFF/FSF until you do a complete rewrite of the product underneath, then pay the fine/contribution to EFF/FSF while toppling the original company. If the company is big enough, and can afford enough good lawyers, there may be legal ways to get around laws.
This is a copyright license at its heart. It is a contract between the copyright-owner and the service owner. The end user is just 3rd party.
A copyright holder can't get anything more from you by using the GPL. Infringement is infringement. The difference is that a company is usually happy to settle in exchange for a properly paid license, and an open source hacker instead is happy to settle in exchange for complying with the license. You're always free to take it to court and pay the damages from infringement, but you're not going to end up with a valid license in either case, so you'll have to stop distributing the software.
The actual difference, probably, is that you're a (moral) competitor of the open source hacker, and if you're not a competitor of the proprietary company, they have no interest in undermining the secrecy of your code or causing you to go out of business, even if the could potentially force that if they went to court. They're likely to consider "pay us a percentage of revenues" as a win condition.
Also, lawyers are not like Pokemon. You cannot beat the opposing team's lawyers by having more stronger lawyers. You can certainly lose by having bad lawyers, but you can only be guaranteed to win by being in the right.
> You can't actually be guaranteed to win by being in the right. You can be in the right and lose.
What he's obviously saying is that there is a seriously decreasing marginal benefit to more expensive (and presumably competent) lawyers.
It's better to have competent lawyers and be right than have amazing lawyers and be wrong.
Obviously there are shades of grey, nuisance lawsuits are a thing, etc.
It's probably best stated like "lawyers are not _always_ like Pokemon". Sometimes they very definitely are.
Without Google using, validating and releasing those design, we might be stuck with MPI and NFS for a lot longer.
Sure, MPI might blow MR out of the water in term of number-crunching, but it is also way harder to use.
What's good for the bottom 90% of tech companies probably isn't for the top 10%.
Exactly. Instead of having something so simple that scales for 90% of everyone's needs. We have solution that Most enterprise wants and filter down from top to bottom. And it is true in almost all Tech things related.
Implementing the whole "DevOps" idea just becomes a whole lot easier when developers don't even have the concept of their snowflake server anymore. And yes - k8s has a ton of overhead and is pretty complex to get into at first, but it all makes sense. There are many points that could be criticised about it, it's far from perfect, but having a standardised way of deploying whatever application has been a massive game changer in the development environments I've been thrown in.
Source/disclaimer: I'm a consultant that has seen quite a few k8s/openshift fuckups and success stories, both on large and small scale.
https://adamdrake.com/command-line-tools-can-be-235x-faster-...
When all you have is a hammer everything starts to look like a nail.
Google open sourced dataflow as Beam - https://beam.apache.org
Think of Autopilot as an automation that tweaks a pod's request/limits according to what it actually needs in order to reduce waste and thus improve cluster utilization.
(I _think_ this no longer qualifies as secret after https://github.com/kubernetes/kubernetes/issues/44095)
That said, k8s is quite extensible and it would definitely be possible to add such a component as a controller.
This is not true. It throws out the Google-specific parts of Borg (like integration with Google's service discovery, load balancing, and monitoring systems) and improves a number of things compared to Borg. For a good reference on the evolution of Borg into Kubernetes, I recommend the recent Kubernetes Podcast interview with Brian Grant: https://kubernetespodcast.com/episode/043-borg-omega-kuberne...
> Google themselves don't use it
This is not true, and the reasons why it hasn't replaced Borg are related to the integrations I mentioned above (which will take time to integrate or replace) and the zillions of lines of borg config that have built up over the years, rather than concerns that people outside of Google would have (production-worthiness, reliability, etc.)
(Disclaimer: I worked on Borg at Google, and now work on Kubernetes at Google.)
I don't think there is a future in open source enterprise software where trade secrets are hidden from the public.
So anyone that refuses to pay for their tools will eventually either loose them, or contend to be happy to use lesser ones.
It is certainly not confusing it you learn it by rote and remember the rule. It is burned into my brain, but I see the mistake a lot so I assume it is hard to remember for some people. For me its vs. it's is something I still have to keep looking up.
Open source software is clearly a net positive overall. However is it a net negative for the industry when enterprise developers rely on open source software without demanding their company provides financial support for that software? How is that different than the company relying on free labor from something like unpaid internships?
Speaking for my own open source projects; There are already better, cheaper, and easier alternatives to my software. I'm already paying out the ass for something I could just download. I'm doing it for reasons that I can't, or won't, buy. And I know that sounds cliche because it is cliche, but passion is cliche.
We're programmers and hackers here. Just like a hot rod enthusiast spends $200k and 3 years building a car he could buy in a catalogue for $75k; we don't pay as much attention to cost/benefit relationships as we'd like to think.
Not every piece of open source software is diminishing the value of enterprise software developers just like not every unpaid internship is reducing the value of entry level labor, however both systems can easily (and even unintentionally) be abused by businesses.
In my company an intern conducted research on scalability - creating tools to measure and monitor the software in the mean time. So not only does the company have some neat monitoring tools now, the intern actually found a bottleneck and improved the product. The company is now offering her a contract...
Caring about eachother doesn't have much to do with it.
Where they make open source software for enterprise and provide services to support.
It's probably one of the next companies to be acquired in the coming years.
So here we are slacking postman collections back and forth on our current year mac books.
(I have no affiliation with HashiCorp.)
The only source I found was https://www.hashicorp.com/blog/2017-year-in-review which just says the company "can be successful", not that it is making money.
From Mitchell himself - at the very least they are growing very quickly. For all the complaining about "pricing pages", I think hashicorp is doing the right thing. Focus on selling to the big dogs who can give you a sustainable business and don't cloud your pipeline with smaller shops who wish to shop around.
I can't prove any of this, you'd have to take my word for it! I guess if we ever go public in N years (not saying we are, but _if_), you'll see for yourself on historical results. :)
Why?
I don't want to be the subject of a constant dripping of emails, calls, and missings from a sales person who is constant to get their numbers and puts me in their sales automation pipeline.
Give me a ballpark estimate, I can go to whomever is needed, and we can go from there: I've never ran into a case where "I don't know" how much this costs is an appropriate answer to give a manager.
The polar opposite of this would be Atlassian, who publishes every price and doesn't negotiate at all. At least it's easy to deal with...
survivorship bias
Untrue if you license multiple products from them at scale.
"How much you got?"
I understand we might be too small to matter for them if we aren't ready to dump thousands of dollars per month into their bankaccount, but it does makes me cautious about what is going to happen with them when their investment money runs out.
It seems not obvious to everyone, but you don't have to use a license, that allows AWS to run you into the ground. Take a look at API Copyleft License: https://github.com/kemitchell/api-copyleft-license
Also, it's not clear this would prevent AWS from running you into the ground. Amazon is more than happy to publish the source code of what they run internally; they make their money off operations and not software, so they're perfectly happy to commoditize software. The copyright holder is the one trying to make an "open core" business. AWS can just reimplement it.
> you must contribute all software that invokes this software's functionality..
So that rules out all proprietary operating systems, databases, 3rd party services, but why stop there? give us your CPU microcode.
This was 2011, so I'd hope newer F5 gear has gotten past that.
I hope NGINX doesn't suffer too much under this new ownership.
As somebody, who has no knowledge about that part of the business (Amazon Web Services in production), could you elaborate on that with a few lines or point me to some articles? Thank you.
A few months ago, AWS launched a MongoDb fork
(There's also https://aws.amazon.com/corretto/ , a long-term-support version of the JDK, because Oracle is getting more aggressive about Oracle JDK licensing.)
Open source strives where different entities develop the software together to the mutual benefit without a single company trying to push their roadmap, without a single company trying to grab all revenue.
See Linux, see different Apache projects, see PHP etc.
Running a service on AWS requires two goods. High-margin computing resources that Amazon really wants to sell, and the software to turn those computing resources into solutions to business problems. Solving the business problems has a fixed dollar amount to be split between the two, so the cheaper the software is the more money Amazon's customers can afford to spend on AWS.
So the final equilibrium is that Amazon ends up funding open-source solutions, and profits off it from increased AWS margins.
But they also figured out that making their free-as-in-beer tools also free-as-in-freedom open source, they'd lift all clouds and not just their own.
As the dominant player, Amazon loses from anything that reduces vendor lock-in. That's why precious little of Amazon's cloud tooling is released on Github.
With Kubernetes, Google made the the opposite calculation. As a challenger, it's to Google's benefit to open-source cloud tooling like Kubernetes. Even though their competitors benefit, Google benefits more from standardized tools that reduce switching costs.
AWS still beats gcp in most other ways though (imho), so it’s far from a slam dunk. But it has opened up a door for Google.
The benefits of FOSS are largely non-monetary. I know as entrepreneurs and professionals that might be a hard line-of-thought to default to, but I think it is extremely short-sighted (and borderline ignorant) to judge the merits of free software by its profitability.
They did open-source HHVM, React, GraphQL, and Cassandra, which are the closest things I can see to a secret sauce.
Well, looks like you just have to assemble known parts in specific order to make something users like.
That situation is so rare someone meeting those criteria could be tracked by the lack of that data
But when such projects take on tens/hundreds of millions of funding, it is inevitable that the technology becomes secondary to paying back the investors 10x, no matter what. Ironically most of that kind of funding seems to go towards sales and marketing rather than R&D. Usually core committers are only a minority of employees in such companies and things get worse when that no longer includes the C-level executives.
This creates a lot of friction when inevitably somebody else undercuts such projects in terms of quality, features or price. This is inevitable because all software eventually becomes a commodity. Your fancy pants DB clustering solution might be shit hot this year but you can bet there will be half a dozen projects imitating what you did within years.
This is basically what is happened to mongodb. It's all about diversifying, "adding value", proprietary extensions, etc. for their paying customers instead of doing what they were good at for all their users. And courtesy of the license, copyright transfers and outside contributions dry up and it's all on the company to do everything in house. Great, as long there's money but when that dries up it creates problems. Meanwhile projects like postgresql and others provide more or less drop in replacements, because they can and because there are users and developers in having that. Apparently they are still doing fine in terms of share price. Best of luck to them but I probably won't be using it.
Most healthy OSS projects out there have licenses that are well understood from a legal point of view and battle-tested in years/decades of use. Some have quirks that need working around (e.g. the classpath exception for GPL v2), others are fine as is (e.g. Apache 2.0). They also have a plurality of copyright holders spread over many companies that makes re-licensing impractical. Most such projects have a core of developers that are typically employed by a big company taking an interest in the project. Having key people in key projects is of strategic importance to them and ensures their interests are taken care off.
The whole point of OSS is commoditization and pooling resources between otherwise less likely to collaborate companies and individuals to get things done better than each of them would be likely to achieve by themselves. That's why most operating systems these days are largely made up of open source software, much of which has had multiple generations of developers working on it. Most of the build tooling around that, same thing. Apple, MS, Google, they all ship mixes of proprietary code and OSS code. Quite a lot of this stuff can be traced back to the early days of unix. Almost every big fortune 500 software company out there pays people to contribute to and represent them in OSS projects that are vital to their business. Even the less popular ones like Oracle actually contribute a lot. That's not charity; it's key to their success.
MS just retired two generations of their in house browser in favor of an open source project primarily backed with Google and with significant portions of Apple contributions from back in the Webkit days. If you'd have to choose two competitors for MS, those would probably be at the top of your list. Why did they do this? Browsers are a commodity and they were negatively differentiating with their in house efforts (as demonstrated by world + dog installing something else). They tried to fix it (Edge) and it didn't work out. All of the surviving browsers are now built around open source projects. I think Edge is probably going down as the last non OSS browser to be widely used.
I use open source components, libraries, and tools for almost everything I do. I love Github. I share code there myself. Most of the stuff I depend on has neither VCs nor much corporate funding behind it and its fine. Some of it does have VC funding and its also fine. My life would be hell if I had to reinvent all those wheels.
I agree funding OSS development is key but I don't agree that that needs to primarily come from companies that own the software and sell licenses+support. That's not how most OSS software I use works; it instead thrives on companies using and paying for people to contribute. Nginx is one of many software packages that I use. I don't think I'll ever pay for licensing or support; because frankly they are relatively unimportant to me. As for the dozens of npm dependencies and their hundreds of transitive dependencies, nope. Not a cent. I would probably consider SAAS solutions when it makes sense; as I have done with e.g. Mariadb and Elasticsearch. But mostly OSS works because it is free as in speech and beer.
In the case of nginx, there are dozens of OSS web servers out there. It's just one of many moving parts I need to worry about. I'll pick whatever is cheap and convenient.
If your worst nightmare is that a big company like Amazon uses your software then perhaps your business model wasn't really for the cloud era. Selling licenses is to the VC crowd what sequels are to Hollywood, comfort food that everyone knows how to handle but simultaneously knows isn't going to be the future.
Linux isn't worse off because it is used by AWS and Google. Quite the contrary.
Look at Confluent/Kafka. The PMC is stuffed with Confluent employees and they behave that way. They aren't acting like an Apache project, they are only acting in their own self interest. Any new ideas get the run around, and only their ideas see the light of day. I don't even know why they bother being open source, except maybe to get the free development and bug fixes.
In the world I live in, far more commercially supported open source runs outside of AWS, then runs ON AWS, then AWS has copied and usurped.
But apparently, Oracle is a bad guy for doing this, and Google is applauded for stealing Java.
Can't have it both ways.
Isn’t this a great win?
Had all the volunteers' impact being so big? Nginx was created by single developer who is NGINX, Inc CTO now, and then developed pretty much by Nginx employees only.
Search through the change log for "thanks to" http://nginx.org/en/CHANGES and you'll see a lot of contributions. Two people who stand out as frequent contributors are Piotr Sikora and Maxim Dounin (who went on to actually work at Nginx!).
And this does not show the mailing list discussions and bug investigations or the documentation maintained by the community in the early days.
[This post is not intended to mean this sale is bad, just to highlight some of the awesome community contributors]
I can recommend having a look at https://varnish-cache.org/ - while its performance might not be 100% up to par with nginx in some (very, very high-end) scenarios, it has many other fortes that nginx (at least in its FOSS release version; I've never used nginx plus) just cannot match in my experience. Having seen `varnishlog` and `varnishtest` in action alone are worth spending a day or two exploring it.
nginx is fine, but there are now other options that work just as well.
I'm sure that's not the only feature it's missing compared to nginx. Envoy is not very comparable to nginx, in my opinion... but I also wouldn't reach for varnish as an nginx alternative either.
Edit: sorry, I should have just checked your profile.
Which only means that NGINX will get even better over time.
But yeah, hopefully the community around it is solid enough to make that a possibility. I'd really prefer to not go back to Apache...
[1]: https://www.f5.com/content/dam/f5-com/page-assets-en/home-en...
proxy_pass for example will only resolve a hostname at the time the configuration is parsed, unless you use a convoluted variable hack. This was a serious issue requiring you to restart your fleet if a backend server changed IPs. The bug fix for this was implemented only in Pro and sold as "DNS for Service Discovery."
What are the contractual consequences if they don't keep that commitment? If the answer is "none", then it's not a commitment.
I don't have the wherewithal to get at these arguments from any angle (and I'm certain I'm missing many others).
Studious maintenance of the base code and branches/PRs besides build tried/true code bases and I hope that we're not being torn of that practice from this buyout; but only time will tell ...
"There is more to life than increasing its speed."
No. Memory safety is a vanishingly small subset of all bugs and security problems. PHP is memory-safe, for example. Where has that gotten us?
> "There is more to life than increasing its speed."
Not if you're a computer.
The number of security vulnerabilities due to PHP's crappiness is two orders of magnitude greater than all of nginx vulnerabilities combined.
Yet PHP is a memory-safe language.
Memory safety won't fix anything by itself, it will just shuffle the shit into some other place.
Now if you're claiming that if you take nginx developers and force them to use Rust they'll somehow start writing better code, then that's a valid point. Although I'm in extreme doubt that it is realistic or even true.
Interesting to also see what aws is doing in response to some of the more complicated licensing agreements and specifically elastic search: https://aws.amazon.com/blogs/opensource/keeping-open-source-...
The challenge for nginx was they raised VC capital so they were in a forcing function. Either grow revenue or get acquired. Could have remained an independent oss product for ever but alas no more.
https://www.nginx.com/blog/nginx-plus-vs-f5-big-ip-a-price-p...
The long version is, "varying degrees of horror"
Here's the super versatile Colm Mac explaining what AWS does at L4: https://www.youtube.com/watch?v=8gc2DgBqo9U
---
Google has been very open about their network infrastructure, here's a nice summary from 2015: https://ai.googleblog.com/2015/08/pulling-back-curtain-on-go... and not mentioned in that blog... their NetworkLoadBalancer, Maglev: https://cloud.google.com/blog/products/gcp/google-shares-sof... (AWS equivalent of which would be HyperPlane: https://atscaleconference.com/videos/networking-scale-2018-l... allegedly based on S3's load balancer).
L4-L7 load balancing, distributed DNS, SSL offload, WAF, DPI, data centre firewall and other things. With a nice WebUI to configure all that.
The Tcl iRules allow you to hook into pretty much any stage of the request or the response L4-L7 at FPGA speeds to do whatever you wanted to the request / response data.
It's a very powerful product.
I challenge that assertion!
For simple things it's adequate, but the fact that one can SSH is also helpful as there's a RHEL/CentOS base to work on. We're able to get Let's Encrypt working with a bash-only ACME client (dehydrated) is short order.
Heck, run Ansible on it:
* https://www.ansible.com/integrations/networks/f5 * https://github.com/F5Networks/f5-ansible
I also work at F5, and used to work on the FPGA. This is unfortunately not true for TCL iRules. The FPGA basically only operates on L2-4, L7 is all software.
There was some talk about doing L7/iRules in an FPGA but prototypes never produced compelling enough performance gains to make it worth it.
load balancing? check.
stateful load balancing? check.
ssl-termination? check.
HSM-enabled ssl-termination? check.
hardware accelerated ssl-termination? check.
firewall? check.
NG firewall? check.
compiled Lua/tcl (i forget which) scripts so you can program something insanely complicated? check.
SAML? check.
ISP sized NATs? check.
etc.
Plus, way more configuration knobs and options than you'd ever want at each network layer. Like, come up with a load balancing scheme where Tls1.2 clients using Poly1305-chacha20 get sent to a specific pool of servers while everything else goes to another pool, except for clients trying to use QUIC and who are coming from a specific range of IP. They go to another set of servers.
Maybe a better way to think of it is that it's a single device for tweaking anything L3-L7 for your server and parts of your network.
(used to work for f5, too, but i'm not sure how specific i can get with the nda).
As the industry [0] continues to put its weight behind NFV [1] and SDNs [2] along with the rise of IDNs [3], do you see network-appliances keeping up the share of the market against those solutions? I believe @Edge network might continue to require these appliances for WAF, Firewall/DPI (and other things I don't know about)... but that'd be a niche?
Obviously they won't go away, but network appliances definitely won't keep their share because not everyone needs them as SDNs get better. I see the SDN and IDN as mostly solving multivendor integration issues and making it easier to configure at least semi-complicated networks, which doesn't make them a drop-in replacement for many of the problems f5 is trying to solve. For certain network loads they might achieve performance parity, too.
One of the draws for an f5 box for a large customer is that instead of having like 5 vendors or OSS technologies that they have to maintain for load balancing, ssl-termination, hardware-accelerated/-hardened encryption/decryption, SAML, firewalls, etc. you have one company's product (that hopefully has been designed to work well with itself) to do all of that that's configured from one location. If you don't have to worry about that multivendor orchestration headache, then massive network appliances like BIGIP aren't a value add over having a couple vendors.
Another draw for BIGIP is doing things at the speed of packet flow or nearly so even for VM containers and even for fully encrypted SSL. If you don't have to care about making sure to squeeze every last microsecond of latency or bandwidth out of you 10Gbs or 100Gbs fiber connection, BIGIP isn't a value add over SDN. If you only care a little bit, than an SDN could be way cheaper than BIGIP because you can configure things to do what you need for lower hardware and support costs.
For the people who care about that multivendor issue and performance, they're always going to have hardware dedicated to networking, even if they use SDNs or IDNs, because they need that dedicated compute to achieve their goals. Sustained 10Gbs connections are no joke, let alone 40Gbs or 100Gbs. Same with tens of thousands of simultaneous SSL connections. All of a sudden you need dedicated ASICS/"Raw Compute" and RAM to keep up with the firehose of packets. Plus, network appliances will begin to integrate with SDNs and IDNs, so for customers on the border between needing an appliance and a getting by with an IDN or SDN and more manpower, the form of the network appliance will change, but they're still going to have hardware down in their server room or compute instances in their cloud dedicated to networking infra. If you want SSL-termination? You need compute. Hardware accelerated or hardened SSL termination? You need specialized hardware. Firewalls? Compute. SAML? Compute. Complicated NATs? Compute. If you've got a couple BIGIPs in your server room, your network's complicated enough and/or bandwidth heavy and/or low latency enough that you're going to have nearly as much racks dedicated for your SDN so that it has enough compute as you do for network appliances.
BIGIP isn't valuable because it's great a router or switch. It's great because of how much it does on top of that in a single server/VM, and how well it does it. And most of what it's great at are not things that an SDN will solve. Sure, the configuration tweaking will have parity and maybe load balancing performance (but having seen how BIGIP achieves it, especially for complicated setups, i kinda doubt it). But if BIGIP integrates with SDNs or with IDNs even just a little, then what could happen is that people on the borderline are just going to get slightly smaller BIGIPs and offload some of the tasks where BIGIP overlaps with SDNs/IDNs and the BIGIP will just be another node in the SDN. If BIGIP goes in on SDN and IDN, then you might even see people buying larger BIGIPs to orchestrate their overall SDN and IDN.
If it weren't for the need for remote backups, email and such would be hosted there as well, and you could run a company on one of these with no access to the public internet at all. Accounting, finance, etc: all of it.
Or maybe that’s Citrix.
Way way back they used to be on BSD. Then they moved to centos for cough cough cough (possibly NDAed) cough cough.
It's not a huge deal which because the host OS isn't anywhere in the dataplane.
The earlier versions were based on FreeBSD 2.2.6.
You know, Cisco's IOS XR is built on Linux, but all the real parts are behind their private kernel modules running on ASICs and FPGAs, traffic doesn't even touches the TCP/IP stack of the OS. Cisco ASAs have Celeron/Atom CPUs which obviously couldn't hold the specified loads.
The data plane is where you have high speed logic and data traveling. That's where you do the multiple 100GBps software defined networking, and its crazy fast chips doing it.
And the control plane has interconnects to program the data plane chips to the rules you want. So the data never hits the control plane at all. Its kind of like a water faucet where the knob doesn't touch the water but controls the floodgates.
We were getting slammed on duty for the product and we were looking at ways of getting the appliances built locally using licensed F5 software, as the software itself wasn't as heavily taxed as the physical hardware. Everything in it seemed fairly commodity, except for the big F5 logo on the front.
It was an appliance that worked fantastically well. One deployment had an uptime of over ten years.
when visiting Taiwan and then Hong Kong in the late 1990's, a local said "there are no software companies here" .. everything with money had a hardware sale associated, software was just pirated as much as possible, end of story.. no one would pay for software if they did not have to.. It may be a "western" thing to have companies and people that can live from writing only software
What exactly is going on with open source licencing? Is anybody violating open source licences?
https://www.f5.com/company/news/press-releases/f5-acquires-n...
On another note, F5's poorly written code is the reason TLS 1.0 is considered insecure (using a variant of the POODLE attack), among other major security lapses.
That's one of the best parts of OSS code - You don't just have to follow them to the next version they release.
(One example is Tengine - It is really nicely setup and a lot of people prefer it to core nginx already)
It's generally something around 20-50ms extra last time I did some benchmarks
[1] https://help.dreamhost.com/hc/en-us/articles/215945987-Web-s...
i would end up paying twice as much for caddy as i do for server
I think caddy and nginx are both great pieces of software that have overly expensive commercial pricing.
Apache is really struggling on resource consumption. It's still living in the world of one process or one thread per connection.
Operationally it always ends up in a clusterfuck of rewrite rules and there are many gotchas with undocumented and misbehaving directives.
Not exactly - you choose the event MPM (mod_http2 won't even run with prefork MPM).
It hasn't lived in that world for a decade or so. It's great to give advice, but at least make it valid and factual. With the Apache 2.4 event MPM, httpd is async and event-driven and is just as fast as nginx.
It's still creating multiple processes that get recycled periodically, each with a fixed number of threads. Every active request holds a thread.
Apache quickly runs into troubles when having long lived requests (slow API calls or large file downloads) or when using websockets (hold a thread permanently).
The tuning to balance processes, threads, connections, requests and resource consumption is extremely complicated and it doesn't get very far.
HAProxy and nginx can both handle 10k concurrent connections out of the box. Apache requires extensive tuning before 1k.
- PHP under apache is faster - Small config files per site - .htaccess at the folder level when required
I usually use both and serve php from apache and serve static content over nginx. Best of both worlds.
With nginx the config is centralized in a specific location. With Apache, configs are all over the place.
- Provides HTTP caching (via mod_cache)
- Simplifies the deployment stack by providing built-in interpreters for dynamic languages. e.g. mod_php (i.e. you don't need php-fpm), mod_wsgi (i.e. you don't need gunicorn)
- Load-balancer upstream affinity ("stickiness") based on HTTP cookies
- Load-balancing based on upstream's connection count (via mod_heartbeat)
- Built-in Let's Encrypt integration (via mod_md)
tl;dr provides a lot of features out of the box -- some people may see this as "bloat" or overly tight coupling, but this provides simplicity.
I feel that the let's encrypt CLI clients are plenty good for nginx, to the point that installing a new module for apache (let alone nginx) is more work than just running a CLI client.
If you want TLS automation, Caddy is superbly good at fetching its own certs, and you don't have to fiddle with installing an additional module to do it.
Apache has improved and now has things such as Event MPM inspired by nginx. Nowadays most of us would run applications behind a proxy, not by running mod_php or mod_python directly - which made old school apps very slow.
Also Apache is notoriously easy to configure. And Nginx still absolutely rules when delivering static content. There is also Varnish Cache which is very good.
NGinx has had a commercial version of their code for a long time. Now it will be under new management. I could see the branding for the commercial version of nginx change.
1) You can't export and re-import a config. Just doesn't work.
2) For the Virtual Appliance (not a recommended scenario by F5, to be fair) it's temperamental about its host and doesn't like to be migrated or moved, and will stop functioning.
3) Upgrades sometimes corrupt/wipe parts of the config, sometimes not.
4) Reboots sometimes corrupt/wipe parts of the config, and sometimes changes to the config are not actually applied until a reboot, even though there's no warning of this behavior.
5) Latest release notes for 12.x (last version I worked with) has a lengthy page detailing known issues. https://support.f5.com/kb/en-us/products/big-ip_ltm/releasen... Why? Why are there so many? Why are most of them critical? Many just shouldn't make it to release.
-edit- It's important to be hopeful. I'd rather land on the side of "nginx makes F5 better" rather than "F5 makes nginx worse".
Besides normal archives (that are just tgz files) or manual config changes and re-loading, try "(tmsh) load sys config merge from-terminal (or file)". It is going to be a gamechanger. ;-) Takes any config snippet from "(tmsh) list..." or the bigip.conf files without rewriting into create/modify statements and add/replace-all-with blocks. No problem to import even large configs like 100KB at once, all as an atomic transaction.
1) You can, if you are careful about what your doing. UCS archives are only intended to be restored on the same machines, restoring them on a different machine requires considering the master key for secret encryption and omitting the license from the UCS. If your restoring it on another model F5, you might be going about things in a sub-optimal way.
2) This typically relates to how stuff like VMWare deals with disk issues or migration. In (some versions) VMWare if there is a disk IO operation thats taking too long, it will pause the VM. It also pauses the VM when you use DRS or live migrate. IF your using a failover pair or cluster this will cause a failover because well, the other device went away for a period of time.
3) Ive only ever seen ASM config lost after an upgrade, and its usually because the unit was not relicensed before upgrading and wasnt licensed for the new version as a result.
4) Ive seen this happen an it was usually because something was in a bad state and rebooting just poked it into failing. Also, always save sys config after making changes in tmsh, it doesnt auto-save (same behavior as Cisco).
5) Because F5 has a policy of publishing a bug in the release notes and in bug tracker if it was ever seen by a customer. Contrast this with some other vendors who very selectively publish bug information.
I agree on 5, too - I'd rather have the bug published and at least know that it's been seen and is being worked on, but still, it's a little disheartening to look at an update you're about to install and see its list of breaks is longer than its list of fixes.
I believe this has improved in recent releases.
It used to be that if you tried importing a config, and you were not properly licensed, the import would bomb out in annoying ways.
In newer versions the import will at least pull in and save everything (AFAICT), but anything not licensed will simply not be active. Once you cut the proper cheques then things should work.
4: In over 10 years of using F5 never seen a reboot break a config. The part about needing reboot to make a config change apply might be https://support.f5.com/csp/article/K13253. In short F5 keeps the old config in RAM and applies it to existing connections. when the latter expire, the old config is gone. Can be very annoying indeed when you are not aware of it. You can delete connections manually though. No need for reboot.
3/5: Yes, all their releases have a list of all known issues. It's a bit odd indeed, but I think it's a good thing. Plan your upgrades carefully.
nginx is an excellent high performance webserver, which is something F5 don't really have. It is (or was, at least) at best a mediocre load balancer, with all sorts of limitations at the sort of scales you'd usually use an F5 box for. While it's probably fair to wonder how much more work will be put into the LB feature-set of nginx, I hope that this will be counterbalanced by increased funding for the core feature of being a superlative webserver.
NGinx is first and foremost a web server with excellent controls around caching. Haproxy is a load balancer with some caching as of version 1.9. F5 has always provided a web server in their load balancer via apache, but that is for management of the device itself. It can also serve up static web pages (primarily meant for error and landing pages).
Interesting how recently nginx was continuing this campaign. I wonder how effective the "replace F5 with NGINX" marketing push was at increasing the price and urgency for the acquisition.
For the curious, the big headline at the top of the message was "Modernizing Applications by Replacing F5 with NGINX Application Delivery Controller and Signal Sciences"
Then the text of that top section was:
"F5’s rigid and centralized approach to load balancing and web application firewall (WAF) prevents enterprises from modernizing their applications. In this recent webinar we describe how replacing or augmenting your F5 deployment with the NGINX application delivery controller and Signal Sciences WAF helps reduce costs and improve agility."
As an engineer (so I can't speak to business strategy), I always thought of Avi Networks as market validation for ancillary software services like Amplify and Controller rather than a competitor with NGINX+. But that was just my thinking.
Of course, this also means that you could expect any sort of future development that overlaps with their higher end products to vanish.
The world of economists has no idea how to value technology beyond narrow ad-based business models.
BPF allows to run user code in kernel modules, so things like packet rewriting and traffic shaping are possible. [2]
[1]https://news.ycombinator.com/item?id=18337429
[2]https://facebookmicrosites.github.io/bpf/docs/bpf-docs#tools...
People don't buy individual pieces of technology, they want packaged solutions that come with support. Tech almost matters less than good support
Up next is likely HaProxy....
The connection with end users and ideology has been broken as everything from the kernel to major projects are corporate funded and driven.
And most inadvertently acknowledge this when they raise concerns about the sustainability of projects without financial or corporate backing. The exploding complexity of things like browsers and projects like Systemd make the idea of individuals and smalls team developing alternatives without corporate backing a non stater.
Most open source projects in the last 10 years would see this kind of acquisition as an ideal outcome and for vc funded ones a necessary one. Even a 'fork' of Nginx at this time would most likely be driven by commercial motives so the 'vague discomfort' expressed in this comment itself is perhaps misplaced.
I recall my first two F5 box purchases...
Tore it apart with the engineer installing it for us at Decide.com in ~1999 and each box was ~$35,000
After asking about and being shown what the box was, a low end machine with a custom linux distro with a custom LB logic that was complex... I was really turned off by their implementation....
Dont get me wrong, it was revolutionary as a product and what not - but from an engineer, I was kicking myself as to how much they could charge for the thing....
Now ELBs are "free" for same functionality in cloud...
So what is F5 doing - and Who is buying them, aside from governments? (I am not hating on them - trying to understand them)
In any case, I'm glad that Nginx is still available for free and the project will continue to have funding in the future from what looks like a cashed-up company. Besides, if it doesn't work out, it can always be foked. Hooray for open source software!
To be fair, it might just have to do with our company's implementation, our IT department pretty hit or miss when it comes to implementing new stuff, it only rolled our 6 months ago and we do have 30,000+ employees/contractors so I'd imagine it's headache getting everything just right, but still.
As for performormance, my experience is that haproxy outperforms nginx in the load balance cases. You have to go out of your way to configure nginx to get close.
Here's an interesting comparison:
https://www.loggly.com/blog/benchmarking-5-popular-load-bala...
So depending on what you are doing, varnish, lighttpd, apache, or haproxy (and likely more) might be used alone or in combination to match functionality.
Can you explain more? (Serious question, as a long-time httpd user who hasn't used nginx)
It is a very bad choice for critical sites that can't go down.
AWS's application load balancer with SSL is much more reliable.
> user-hostile behavior
Which behaviour is user-hostile? Perhaps we could address it?
> outright dangerous behavior in the way it fetches SSL certificates
For reference, Caddy uses https://github.com/xenolf/lego/ for its ACME interactions with LetsEncrypt. Could you elaborate on what part of Caddy's behaviour is _dangerous_?
> very bad choice for critical sites
What makes it a bad choice, exactly?
Caddy used to put non-removable advertisements in the response headers. (That one got such a bad backlash that they backed away...)
Caddy refuses to cooperate with OS packaging teams. It reeks of self-importance. It's questionable whether caddy is really FOSS with its odd licensing arrangement.
I've seen a number of backward-incomptatible updates that break config files from point-upgrades.
Caddy EXITS with error on boot if any of its HTTPS enabled sites fail to get certificates.
Which puts your webserver in a fragile state: the server may serve happily for months (with a hidden cert error) until you restart the service. Then all your sites are down.
Migrating a live website from one server to another is (or was, until recently) quite un-supported and hard to do with zero downtime. See caddy needs DNS pointed at it before it can get the cert -- but it can't start serving pages until it has the cert.... Just not acceptable story in a high availability environment.
I understand that now caddy can share its certs with a pool of other workers which may help migration processes moving forward.
I may be bitter about this as it caused a lot of damage and downtime for my business. Not inclined to ever touch Caddy again if I can help it.
That header thing was indeed a bit of a fiasco; a misguided attempt to honour the few that stepped up to support Caddy monetarily. Once the depth of the issue was made clear to the developers, it was indeed walked back.
Regarding OS packaging teams - it's not the dev's responsibility to become approved package maintainers for individual distros; it's generally not done, either. The distro maintainers themselves decide which packages to make available, and how to package them. Caddy doesn't offer repos for the individual popular package managers because of the nature of Caddy's third party plugin architecture - none of the package managers allow arbitrary downloads from a build server (rightly so - the package maintaining process is intended to provide much higher assurance of security), and they don't allow for the package to be built to request either. Not only that, but those plugins may or may not be trusted by the user themselves; the usefulness of anyone being able to extend Caddy and publish their own plugin at any time comes with that downside.
The licensing arrangement was born out of a simple need - Caddy devs gotta eat. The code itself is Apache 2.0 - the Caddy project is as FOSS as it gets. The commercial part is the build server, which isn't open source - if you use it to build your binaries, those binaries are considered either commercial or personal in nature. I can tell you that the devs would like nothing more than to have a different method that would satisfy their monetary requirements so they could make the build server binaries free, too.
The idea behind exiting on start with an error is to ensure that when the user starts the server, they know straight away that there's a problem and Caddy can't do what you're asking it to (which is manage your HTTPS certificates). There are ways to get Caddy up, even with out a valid HTTPS certificate, and get your site online regardless - they're just not _automatic_.
The fragile state concept is one we come across frequently. The truth is that when people say they're restarting the server, the meaning of restart is "shut down, then start", instead of "reload". Caddy has graceful reload capabilities; you can swap the Caddyfile and even the binary itself out without interrupting the server (this isn't true on Windows, though, where varied signaling of the Caddy process is not possible in the same way as it is on *nix based systems).
I myself have posted working solutions to full live server migrations (for the entire set of websites), between two fully working and secured (HTTPS) Caddy instances, accounting for DNS propagation. It's not unsupported or difficult, just not _automatic_; it requires some specific configuration and a careful hand (like most live site migrations). The somewhat-recent filesystem clustering Caddy does isn't even related to migration - it's actually supportive of distributed fleets solving challenges for other instances. You've always been able to share the TLS assets between Caddy instances and have them be used.
I wish I (or the developers) had been given a chance to offer some guidance - I believe we would have been able to help avoid some of the downtime and losses suffered by your business.
Obviously hard to complain too much about a free product - I'm sharing my personal experience for others.
So the thing I like about AWS is that they can give you a cert before pointing the DNS A record at your site. Really fool-proof and excellent. Much better than the let's encrypt flow by design.
In fact on some of my sites I now run Caddy on AWS behind a load balancer with the AWS load balancer providing HTTPS. Works much better and I can sleep at night with less fear.
I believe AWS can do this because they have proof that you own the domain (effectively DNS validation) before handing out certs. Caddy can do similar with DNS validation - fetching your cert without needing to be publicly accessible. It needs you to hook into the API of one of the supported DNS providers though, because validation is still done on a per-request basis (but it has been able to do wildcards for a while). I understand that AWS is more validate once, sign certificates many times, which is quite convenient - and it all hooks into their systems fairly automatically.
See this benchmark for some inspiration: https://www.techempower.com/benchmarks/#section=data-r17&hw=...
https://medium.com/runa-capital-collection/nginx-and-runa-st... (from idea in 2002 to exit in 2019)
Hmmm... like Apache httpd?
Their main buisness, hardware loadbalancing is rapidly diminishing, so buying in NGINX seems like a sensible move.
After all, its much easier to sell support to people who are actually _using_ your product.
In 2014 we had two, then I moved company to where we had 6 loadbalancers, in the four years we were there we killed them off with a mix of AWS and k8s
At most recent place, I'd no even consider installing them.
Let's see what follows.
After reading what they do I am not sure whether I should have heard of them.