Nginx to Be Acquired by F5 Networks | Hacker News Reader

Nginx to Be Acquired by F5 Networks

nginx.com

1,057 pointseduren383 comments

So...what is the future of enterprise open source? Is there a future for enterprise open source?

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.

My understanding is that Google has recently deviated from this strategy. The result of the strategy you mention is that the industry standardized on other companies' implementation of ideas that came from Google: Hadoop (MapReduce), HDFS (GFS), ZooKeeper (Chubby, and more. For examples of newer open source projects that see more active maintenance from Google, see Kubernetes and TensorFlow.

But K8s is not a development of Google software. It is developed specifically for the public, it throws out all of the interesting parts of Borg, and Google themselves don't use it, or barely do. As for that other stuff it seems to have worked out fine for Google: they describe obsolete technologies and the outside world develops hideous analogs of those and uses them for decades. Hadoop for example is just an unbelievably bad implementation of map reduce as it was ten years ago and is laughable compared to what Google replaced it with. HDFS is a joke of GFS which Google turned off eight years back. It's really remarkable the way the industry is essentially self-disabling in this regard. Meanwhile Google does not burden itself with trying to adopt every idea they read in a paper, and maintain a significant cost and efficiency advantage by doing so.

> it throws out all of the interesting parts of Borg

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.)

Implementation matters to google, more than to say the average company that uses Hadoop. At "Google-scale" small imperfections become huge imperfections.

What's good for the bottom 90% of tech companies probably isn't for the top 10%.

Google offers their most recent infrastructure as a service in GCP, e.g. Cloud Dataflow, and it hasn't exactly taken the world by storm. Industry standards matter, even if they are inferior implementations; the differential is just not that big.

Can you mention some of the interesting parts of Borg that are missing in k8s?

Well, nobody should be using MapReduce now, and HDFS now is a lot better than 8 years ago.

Without Google using, validating and releasing those design, we might be stuck with MPI and NFS for a lot longer.

I know some people who develop on top of Tensorflow; from my conversations with them, Tensorflow's moat is Google making a lot of breaking changes by incorporating a lot of new functionality. I've also heard complaints that the online documentation isn't terribly great for triaging not-happy paths, to the point where you kind of have to just dig through the source code to figure out what's going on. Also, if you want to poach the maintainers, you would somehow have to poach them away from Google (which isn't happening, since ML at scale is something Google does best, and is an ongoing field of research). You can't become as good at using Tensorflow as Google is by simply forking the project.

Does that deviation lineup with Google's entry into offering cloud computing?

Pretty much. That's when it became clear that Google would have to support whatever is popular outside Google.

Gonna just chime in and mention Yahoo for Hadoop (yes I know Big Table was Google), and Zookeeper. Great tech started at Yahoo, but they didn’t (unlike today) make too much of a fuss/self-pat-on-the-back about it

Those projects were initiated by Yahoo, but the designs are taken directly from Google papers. Hadoop (HDFS and Map/Reduce) was based on the GFS and Map/Reduce papers. ZooKeeper was based on the Chubby paper.

Note that none of the successful large companies are actually open sourcing their 'secret sauce'. There is no open source version of Google's search engine, Facebook's social network etc. It's only supporting tools and infrastructure they release (i.e. commoditization of their complements or dependencies.) A product company open sourcing their core product is committing suicide on the product front. Sure, there will be services companies who may benefit (Red Hat or providers like AWS etc.) but the company that actually produces the software rarely will.

I don't think Facebook has any "secret sauce". The integration and scale is certainly impressive, but there's no part of the functionality which is at all mysterious to me. Unlike, say, Google Search, everything on Facebook appears pretty straightforward.

They did open-source HHVM, React, GraphQL, and Cassandra, which are the closest things I can see to a secret sauce.

Their ad-targeting infrastructure likely has some secret subtleties to it.

Meh, not really. Cookies all the way down.

To expand on this, these companies are not open sourcing their data. Facebook no longer gives you access to the social graph. Google doesnt have an open API for their search results or search volume.

Providing an API doesn't mean open sourcing the data. Because the API provider can very well restrict who can use it, and how it is used, and throttle it.

There absolutely is a future for enterprise open source. It's not through direct monetization, but rather driving down the price of complements for existing product lines.

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.

Amazon figured this out and surrounded their high-margin computing resources with a dizzying array of free-as-in-beer tools.

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.

This! Kubernetes in some ways was a shot in AWS’s direction. It gives companies a reason to switch to Google. GKE is still far more stable and mature than EKS.

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.

Interesting read on this topic by Stratechery - https://stratechery.com/2016/how-google-cloud-platform-is-ch...

> If you start a company and open source your core/clients, your product becomes part of AWS

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

This is not a FOSS license in the sense of the Debian Free Software Guidelines or Open Source Definition: it compels you to publish your changes, even if you're only making internal use. Free software / open source licenses do not require that. Most obviously, it fails the "desert island" and "dissident" tests of https://people.debian.org/~bap/dfsg-faq.html . (There are plenty of perfectly fine licenses that are not DFSG/OSD licenses, but it's not what most people mean by "open source," and importantly it will be impossible to get this software into a mainstream Linux distro, so you won't have the sort of adoption that actual open source licenses get you.)

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.

Oh boy, just skimming through that license and I can see a bunch of lawyers having a good giggle and a field day over 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.

Enterprise open source is bleak. There aren't very many enterprise open source projects with pure intent anymore, they are all looking for the big payday, which unfortunately companies like Google and Facebook have encouraged.

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.

Obviously open source isn't going away. It's just that VC struggles to understand the implications, still, and the past half a decade has been imprinted deeply by all the cheap money.

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.

I agree. Open Source software is not a good way to build a moat, and investors should take this into account. It's good for companies that focus on building employees, teams, and customer relationships, and keeping them strong at all times. They can't fall back on exclusivity of their code, hosting, or support offerings. The ideal Open Source company would probably be something like Red Hat.

You could AGPL and sell proprietary exceptions. Amazon won't touch AGPL code.

Others are happy to provide AGPLv3 code as SaaS, look at MongoDB's issues. You can build a ton of tooling around said code to enhance performance, adding features and billing, all while not modifying the core AGPLv3 code and thus avoiding the need to contribute back. This is a scummy business practice, but technically legal.

Why is it a scummy business practice?

Because your core business feature is done by someone else and you just take it and use it for your own profit without giving anything back. Do you need a definition of what scummy means?

So there's "Server Side Public License" based on GPL.

Maybe. At least our company won't touch GPL code; as one colleague described to me, if you violate a proprietary license, a company will come after you for money, while violating a GPL license gets the EFF involved who will come after you for your source code.

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.

https://news.ycombinator.com/item?id=7572332

(Usually not the EFF; more likely Software Freedom Conservancy or someone. EFF is more digital rights and privacy stuff, not copyright.)

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.

The only claimants to your source code are those to whom you've distributed binaries built from GPL sources. Anyone else can pound sand.

You actually can't magically lose your rights to code you created. You could rewrite your code so it doesn't depend on gpl code if you found you had included code you had no right to.

I mean if you're planning to violate the license then does it really matter what the license is? Your company sounds shady if you evaluate software icenses based upon how much it will hurt when you violate them.

Well, most enterprises wouldn't: https://blog.dgraph.io/post/relicensing-dgraph/

Has the AGPL ever successfully held up in court?

Yes, Artifex sued Hancom over their use of Ghostscript [1]. (The article says GPL, but Ghostscript has an AGPL license.) The judge denied a motion to dismiss the claims, and they reached a settlement for an undisclosed amount.

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...

[2] https://pdfbox.apache.org/

[3] https://mozilla.github.io/pdf.js/

$25k seems a bit on the high end - https://ironpdf.com/licensing/

Also, it's 2019 - Artifex, it's OK, you can publish your prices (https://www.artifex.com/licensing/)

> but this violates the AGPL license when you are running a SaaS application

Only if you modify the Ghostscript source code.

Surely it doesn't need to—either you accept the license or you don't accept the license. If you don't accept the license, you can't use the software.

I'd imagine that the challenge with the AGPL is catching and suing the non-compliant services.

If the source is available, I absolutely can use the software—regardless of license. The only thing preventing me from doing so would be either criminal or civil law, and while IANAL, I don’t believe there are criminal penalties for license violations. The copyright holder would have to sue me, and prove that I violated the license, and then they might be able to get a court to force me to stop, pay them, or both.

I am curious whether there are any practical observations, one way or the other, about the AGPL’s enforceability.

agpl will not save you if they choose to re-implement the solution.

Nor will anything else, I reckon.

That's basically how the first GPL software came into being -- as a (partial) reimplementation of commercially licensed unix.

keeping the system proprietary will make it harder for them to understand what you are doing; but that will also be very limiting move - in the enterprise software space.

But will anyone else?

What happened is the realisation that FOSS developers also have to pay their bills and idealism only takes so far.

So anyone that refuses to pay for their tools will eventually either loose them, or contend to be happy to use lesser ones.

“Loose” is the opposite of “tight,” “lose” is the opposite of “find.” Easy to remember because the opposites have the same number of letters.

It always amazes me how often I see this spelling error.

Given that lose is pronounced looze and loose is pronounced looce I can see why it’s confusing.

In fairness it feels rather arbitrary and counterintuitive of a spelling rule.

Thank you for this public service.

Thanks.

What is interesting is that we are seeing people in other industries shamed for hiring people in unpaid or underpaid jobs and even people shamed for taking those jobs. I wonder if that is something that will ever happen in the software industry.

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?

I think a lot of it truly is passion. Interns have goals that typically don't align with the company they go to work for. That's why they take crap pay. They get to not care and in return the company doesn't have to care about them! Everybody wins, and it's a choice all around. So it's mutually agreeable that the intern will put in some effort and get some reward.

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.

How is having a passion for a particular piece of software different than having a passion for a specific job or company? Plenty of people have enough passion for an internship that they are willing to take it for free. However society has been discouraging that over recent years because that route is only available to people who have outside financial support and it can easily be abused by employers. Open source software has the same potential drawbacks.

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.

The interns' goal is to learn the trade. The companies goal is to attract talent and/or get a ROI.

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.

Exactly right. Its amazing thing in software industry that developers want to be highly paid themselves along with free work from other software developers.

I guess it's the "eat or be eaten" attitude. Give someone a chicken that hatch golden eggs, and they will kill the chicken.

I think Hashicorp[0] has nailed down the open source enterprise model perfectly.

Where they make open source software for enterprise and provide services to support.

[0]: https://www.hashicorp.com

I love Hashicorp products, however, all of their pricing behind "Contact Sales" is a major turn off.

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.

I agree, but since so many companies still do this, the math must work out such that having sales staff work out the prices results in higher profits even including lost sales to people like yourself who won't jump through the hoops.

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...

> Atlassian [...] doesn't negotiate at all.

Untrue if you license multiple products from them at scale.

It is quite hard to A/B test. And the sales people making the bonus is often part of setting the strategy.

> since so many companies still do this, the math must work out

survivorship bias

"How much is it?"

"How much you got?"

Pretty much this. Not Hashicorp, but another vendor I was speaking to initial gave me a $10,000 a month quote that we got knocked down to $500 a month after some negotiating.

It’s likely because they give different pricing based on who’s asking, which is normal for products that aren’t commodities.

Have to agree with you. At least their site says "Get Pricing" vs just "Pricing" and it says "Contact Us".

Hashicorp is one of those companies I want to support, but all of their pricing and enterprise details are behind a "Contact sales" button, so it is really hard to get to know their offerings and their pricing.

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.

I really dislike when companies don't put pricing on their website. 1. I need to spend hours or days just to understand if I should consider it or walk away 2. Feels like they may give different price to different customers and we have to negotiate price like on asian market 3. If price is kept in secret who know what else is hidden from us

They barely have any revenue and they're struggling.

It's probably one of the next companies to be acquired in the coming years.

I'm one of the founders of HashiCorp. We don't publicly talk about exact numbers, but we broke through 9-figures last year, and a very low % of that is support (its mostly enterprise software). That also isn't using any accounting tricks (such as a ton of multi-year deals). We're doing very well. We're in no talks to be acquired, either.

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. :)

Congrats on the success! Given your enterprise traction, though, how do you guys intend to avoid the problem Elastic is facing from AWS?

Fantastic to hear you’re still crushing it.

HashiCorp is doing VERY well revenue-wise. They are not struggling. Where did you hear they are struggling?

(I have no affiliation with HashiCorp.)

Instead of taking either of your words for it, are there any actual direct sources on Hashicorp's earnings?

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.

Do you have inside knowledge of this? I wouldn't be surprised; open-source enterprise software is incredibly hard, but Terraform Enterprise for example is a really solid offering and not to expensive. It is actually very doable even for small (< 5 people) startups.

I have always wondered what this enterprise support means? So if a big company starts using vagrant, they would dole out 100k for a support contract? I find this hard to believe but what do I know.

When developing an open source product and trying to do a business around this is a tough ride, as competitors who do less development can do services cheaper.

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.

I'd say this is more of a problem with VC funded OSS companies treating a commodity as an investment that needs to be milked where a few individuals working efficiently might otherwise be able to make a very comfortable living doing e.g. support and consulting. Many smaller projects are surviving just fine like this.

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.

Yeah, it's almost as if it makes sense to copyright the API to prevent unlicensed usage of decade long investments.

But apparently, Oracle is a bad guy for doing this, and Google is applauded for stealing Java.

Can't have it both ways.

Gitlab and Hashicorp are going pretty strong. Maybe they get acquired though.

I think the issue here is that you're viewing the merit of open-source entirely based on the immediate profitability of the software.

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.

This is incredibly deft on F5's part. What are the alternatives to F5's products? Cloud products, and home rolled Nginx configs.

I imagine haproxy might get more popular if F5 does anything to hobble the open source part of nginx.

haproxy is amazingly functional and has done a fine job of evolving over the years. At a particular $DEFUNCTCLOUDVENDOR we implemented a haproxy based ELB-ish solution with home grown control logic to replace a F5 installation whos configuration size grew unwieldy (the F5 config parser was falling over in their LBs) while we were nowhere near the F5's touted connection/throughput numbers. F5 wasn't really willing to work with us on licensing, so we implemented a system based on haproxy VMs that worked because we were more than a bit overprovisioned on switching capacity and were able to shard that configuration base more effectively over more VMs.

This was 2011, so I'd hope newer F5 gear has gotten past that.

18 months ago I was in a shop that used F5 and it was a nightmare. Some of the best network admins I've ever worked with and they couldn't nail down why the load balancer did the things it did, when it did them. It was bad enough that the config had more exceptions than rules just so that we could try to eliminate anomalies.

I hope NGINX doesn't suffer too much under this new ownership.

* If you start a company and open source your core/clients, your product becomes part of AWS, and AWS runs you into the ground. *

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.

> your product becomes part of AWS, and AWS runs you into the ground.

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.

Just today, AWS announced a fork of Elasticsearch: Open Distro for Elasticsearch - https://news.ycombinator.com/item?id=19359602

A few months ago, AWS launched a MongoDb fork

For context, Elasticsearch merged their proprietary add-ons into the main repos https://www.elastic.co/blog/doubling-down-on-open and MongoDB relicensed to a not-quite-open-source license that compels you to release code for your entire infrastructure if you're running MongoDB as a servie https://www.mongodb.com/licensing/server-side-public-license... . If you make your money on support and not open core, it's difficult for Amazon to do anything to you, e.g., Red Hat is doing just fine despite Amazon Linux being a thing.

(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.)

The company sold for 650 million so it isn’t a bad outcome. They took open source code made better by tons of volunteers, added their proprietary bits and were successful and sold the company.

Isn’t this a great win?

> They took open source code made better by tons of volunteers

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.

Very big yes! No doubt Igor deserves the majority of the honour for Nginx, but volunteer contributors were a big part earlier on, both in patches, investigations and community support.

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]

Support, certifications, and subscriptions all seem to work fine for a number of companies.

I don't think there is a future in open source enterprise software where trade secrets are hidden from the public.

is there such a thing as available source, closed license?

Yes. Source code is copyrighted and you can make it available under any licence you like, including a proprietary one.

Or use copyright licences which the big tech companies are scared of. Affero GPL or some of the more radical "copyfarleft" licences.

can be, I am interviewing quite a bit lately, among start ups there seems to be a renewed interest in doing devices. Probably because it is harder to do the commoditization trick or to re-implement the solution when hardware is involved.

Or keep open source and do enough antitrust that businesses must compete on other axes.

Source-available commercial software might be a more viable route to go.

I guess that signals it's time for nginx users to check out possible alternatives - just in case, if things turn out for the worse.

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.

Given how widely used nginx is, wouldn’t a community maintained fork be the most likely outcome of things changing for the worse?

The problem, of course, when all contributions are "limited" to those within the company, that the talent and expertise required to keep things going exist just in the company itself, and not in the overall open source community. So when the company behind the tech "goes away", all the knowledge does too. It's for that reason that open source that is totally under the control of one company is so dangerous. Sure, you have the ability to fork, but the reality is that such a fork is almost assuredly doomed to fail. You really are beholden to that company.

The antithetic case here has precedence too (node/iojs amongst others) - "org realizes its share of the base tech has outlived its 'welcome' to no real financial benefit". But I guess a more pressing question is: can a corporate entity be "hands-off" enough so that its subsidiary has room to work as effectively as it had prior to its acquisition?

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 ...

Then again most nginx users are going to be fine with haproxy/traefik in front of good old apache or lighttpd. Or even just apache.

I've replaced most of my nginx instances with traefik, except those just serving static files. The configuration is more straightforward and the EncryptIt integration is a lot more elegant than in nginx's case.

The last two companies I've worked for used træfik and haproxy, and just this last weekend I converted my home clusters from nginx to træfik.

nginx is fine, but there are now other options that work just as well.

According to the public statements, F5 is committing to maintain the current level of resources NGINX has allocated to their open source programs, to keep the same dev team involved, to keep licensing as it currently is, not change any of the repositories on Mercurial and GitHub and to keep the NGINX brand.

Which only means that NGINX will get even better over time.

Every company that has ever acquired anything says this exact same thing. Then the deal closes and it’s back to bottom line numbers.

In this case how does f5 make or lose money from Nginx?

> committing to maintain the current level of resources NGINX has allocated to their open source programs

What are the contractual consequences if they don't keep that commitment? If the answer is "none", then it's not a commitment.

I’ve seen that a lot of times. What I haven’t seen a ton of is the acquired company still existing 5 years later.

Which is an interesting statement given that everyone I've run into associated with F5 - local reps or users - have been relentlessly hostile to "open source crap".

NGINX was already paywalling bug fixes once they launched Pro.

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."

Put a load balancer between your reverse proxy and your backends. Problem solved.

How’s Apache doing these days? Haven’t looked in a while

Hopefully if it declines we can have a MariaDB type fork take it's place.

nginy?

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...

Oh boy do I have a bridge to sell to you!

We've had good experiences with https://www.envoyproxy.io.

I really like h2o (https://h2o.examp1e.net) as a nginx replacement, very nice software, lot of features, extensibility using mruby and amazing perf.

h2o is neat, although its next version has sat in beta for something like 9 months.

The same nginx I was using yesterday, I have a license for tomorrow.

You already have a license for it today, too.

Are you the person behind caddy or is your username just a coincidence?

Edit: sorry, I should have just checked your profile.

Curious, why not envoy (https://www.envoyproxy.io/)? Its open-source, used/supported by variety of companies, has more features than NGINX.

Envoy doesn't support static file serving: https://github.com/envoyproxy/envoy/issues/378

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.

Envoy is not the web server, it's load balancer. If you want to serve static files It will be better to use any other software. Furthermore, it is a very complex problem for HTTPS servers, because the Linux kernel doesn’t have full-featured TLS support for sendfile syscall. I implemented daemon which is used as in-memory storage for static files and client for our proprietary web server. Trust me :)

The replacement should be written in a memory-safe language. Including the TLS library.

"There is more to life than increasing its speed."

Does it start with an "R" and rhyme with "repeated-so-often-its-been-ground-into-the-dust"?

Go has the advantage in having a native mature TLS stack.

> The replacement should be written in a memory-safe language. Including the TLS library.

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.

I'm not sure if you are trolling or not. Just in case: all rce vulns in nginx have been memory safety bugs: https://www.cvedetails.com/vulnerability-list/vendor_id-1004...

Idunno, it seems fine to me. There are plenty of HTTP daemons that get the job done though, and if you have exacting requirements, there's nothing particularly difficult about writing your own specialized one (generally you don't have to write every feature of NGINX).

Does varnish support SSL? Last I checked, I had to run nginx in front of it for https.

https://hitch-tls.org/

With everything that is going on with open source licensing this certainly can create a bit of worry down the line.

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.

Could this simply be about losing hardware sales to this newfangled open source? A big F5 rig used to go for $175k, vs $30k-sh for an nginx on plain hardware.

https://www.nginx.com/blog/nginx-plus-vs-f5-big-ip-a-price-p...

A big F5 rig is basically Linux with a CLI/admin interface on top.

(I work for F5.) This is not true - Linux is really just userspace to run our own data-plane code.

Serious question: what does it actually do in non-corp speak, though?

And that userspace is based on a really old version of FreeBSD.

Or maybe that’s Citrix.

It's way more than that. Yeah the base OS on the machine is Linux, but there's a lot of extra stuff they do all the way down to the hardware layer.

So what does the likes of AWS (for example) use for load balancing for data coming into its various private clouds... f5s?

It used to actually a BSD rig with a CLI/admin interface on top.

The control plane can be a raspberry pi. Its what allows you to modify the rules how you route. Its the interface.

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.

It's not about that. FPGAs behind engineering solution to digest packets at big PPS behind interface is what it does.

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.

> everything that is going on with open source licensing..

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

It's also why software as a service has become common everywhere. Like Adobe Photoshop and Microsoft Office. It's harder to pirate plus ongoing revenues.

>With everything that is going on with open source licensing

What exactly is going on with open source licencing? Is anybody violating open source licences?

Acquired for $670 million

https://www.f5.com/company/news/press-releases/f5-acquires-n...

Cash, apparently. I like how Wilson Sonsini advised F5 in the purchase while firm heir Peter Sonsini invested in Nginx corp. Good times for old money in the Valley.

I thought F5 was primarily a Seattle based company? I've known more F5 employees growing up in Seattle than Amazon employees at least.

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.

POODLE was also an issue with other ADC vendors, I think it links back to where those ADC vendors got their initial TLS code, how the industry went about implementing it, etc.

F5 has a few hundred person office in San Jose as well as a decent amount in Tel Aviv as well.

Sure but it's not engineers who are getting paid in this deal, it's VCs and lawyers.

How does a random person become part of this scene?

You can't. You've just got to be good with money, have a small number of children and die with more money than you started with. If the children repeat that then after a few generations they can be part of the "scene".

Plenty of money for (what I understand) essentially a service company.

Service company with very valuable IPR..

Isn't Nginx open source?

I'm nervous about what this means for the future of nginx's built in load balancing. That's been an important and rock-solid part of my infrastructure.

I use F5's at work. The F5's do their job very very well, but are very very touchy. I've always considered nginx to be solid, stable, and low-maintenance. I think the opposite about F5 and am worried about this transition.

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".

1: How did you export? and did you try to import into a different unit?

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.

Existing connections using the config when they were initiated is intended to prevent inconsistencies when changes are being made, these inconsistencies could lead to connections being dropped en mass after a config change.

I use F5s at work, heres some responses:

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.

Thanks for your responses. A good foil to my complaints. My experience is very selective.

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.

> [...] omitting the license from the UCS.

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.

> 1) You can't export and re-import a config. Just doesn't work.

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.

I would not be worried unless F5 have stated they are going to change licensing. Haproxy have a commercial version of their software, including appliances. Several other open source projects have commercially supported versions.

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.

Throwing out a question to the room: if the worst happens and Nginx gets butchered, would it be so bad to go back to using Apache? I've never used it really, everything I've done has been Nginx, but is there some technical reason why Apache wouldn't be a fine fallback option for an open-source server?

If you like nginx, why would you fall back to apache instead of forking it, or using one of the many existing forks?

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)

Tengine looks pretty interesting!

The main reason I switched to nginx from apache years ago was due to configuration, which was much nicer from my side. If I was to switch away from nginx because something happened, I'd probably find something similar configuration and speed wise. Caddy looks nice.

https://caddyserver.com/products/licenses

i would end up paying twice as much for caddy as i do for server

Yea Apache would be fine for 99% of people those that are pushing a huge number of requests might struggle but there is haproxy amongst others as alternatives

HaProxy does load balancing better, it never was a primary feature of nginx. Varnish can do the caching. Apache/Lighttpd can serve files and CGI, but maybe not as efficiently.

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.

>It's still living in the world of one process or one thread per connection

Not exactly - you choose the event MPM (mod_http2 won't even run with prefork MPM).

"It's still living in the world of one process or one thread per connection."

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.

Apache is a good piece of software, nothing wrong with it. People like nginx because it's low maintenance but I'm not sure it still has the performance edge for _dynamic_ apps.

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 historically been easier to scale up out of the box. Not to say Apache can't be configured to be competitive, but there's at least the perception that it's not as good at concurrency [1].

[1] https://help.dreamhost.com/hc/en-us/articles/215945987-Web-s...

Life is nicer in many ways under apache.

What are some of these "many ways"? because I strongly favor the quality of life under nginx over that of apache. For smaller projects, these days I reach for Caddy which is even more pleasant to use than nginx.

Apache takes a few ms more for ssl termination.

It's generally something around 20-50ms extra last time I did some benchmarks

50ms is huge. I strongly suspect there is something more in play if you get that sort of perf difference between apache and nginx.

I too am worried about this. Thankfully F5 can't just disappear the open source nginx.

I'm still downloading the repo and a few versions just in case.

Not to mention the nginx waf product.

luckily not needed: there is h2o

In the event that F5 pulls an Oracle and horribly mismanages nginx, runs it into the ground, or tries to close it off, I vote we name the community fork "nginy".

Or perhaps a more us-vs-them fork, maybe something like 'ngin-us' (pronounced 'ingenious')

Got to feel lucky Oracle or IBM didn't buy them, definitely would have run them into the ground.

People thought Oracle would run MySQL into the ground, and that didn't happen.

That's because Oracle was too busy suing Java users and pissing on OpenSolaris. There's only so many open source projects a company can eradicate at a time.

Or how about "nginext"

thank u, nginxt

Can’t wait till that forks to “nginz”

Nginx is an incredible product. I've used it at nearly every company I've been at and on multiple occasions its entirely saved us both via its capabilities and its accessible, robust documentation that we had to read at 2 AM while fire fighting. Congrats to the team on a hard fought journey.

"F5 is committed to continued innovation and increasing investment in the NGINX open source project to empower NGINX’s widespread user communities." from https://www.f5.com/company/news/press-releases/f5-acquires-n... what do we know of F5 history in open source?

I think the issue is that there isn't much and certainly nginx could be viewed as competitor to F5. And with everything else going on it's not difficult to imagine that this acquisition isn't a positive sign.

Could it, really? I know that nginx has some builtin load balancing, but unless it's vastly vastly changed in the past few years, it's still a LONG way behind haproxy for load balancing.

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's worse-than-F5-and-haproxy load balancing was great for where I was using it. And from all reports, F5 would have required a full engineer to do configuration, compared to about 1/4 of an engineer for nginx.

I would suggest that haproxy (which has a commercial version and appliance) are more of a competitor to F5.

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).

I've recently been getting quite a few marketing emails from nginx pushing for replacing F5 with nginx. Just checked and the last one I received was last thursday, March 7th.

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."

NGINX is upset that AVI networks is winning all major the F5 replacement business. I looked at NGINX in the past and the rep seemed hesitant to talk about AVI vs NGINX. Seems to be true. https://www.businesswire.com/news/home/20190311005876/en/Avi...

Having worked at NGINX, I would be surprised if Avi Networks was at all a consideration for marketing F5 replacement. When I left (not too long ago), most of our enterprise sales of NGINX+ was for F5 replacement deals...which is why the marketing emphasis has always been on replacing F5.

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.

F5 side of the press release: https://www.f5.com/company/news/press-releases/f5-acquires-n...

I think this will all be alright. The open source product will continue to support most use cases the same as it always has. Customers with additional needs or edge cases will opt-in for support. The byproduct of that relationship will be to ascertain which users are growing to a point where nginx may not be able to support more mission critical needs, and that's where F5's commercial products can come in.

Of course, this also means that you could expect any sort of future development that overlaps with their higher end products to vanish.

In what world is NGINX worth so much less than WhatsApp, Snapchat, and some other sites of dubious value?

The world of economists has no idea how to value technology beyond narrow ad-based business models.

One thing I find interesting in this is the valuation: $670MM which means nginx that powers almost the entire web and has a strong monetization model is not a unicorn while some very questionable businesses are if you ask their VCs.

Interesting move. Big IP is a hell of a product on it's own. Curious to see how they add nginx to their product line and what this means for open source usage.

https://techcrunch.com/2019/03/11/f5-acquires-nginx-for-670m... is a much better rationale and details on how it went down

I wonder if Facebook's opensourcing of BPF [1] 4 months ago had negative affects on F5's competitive advantaages.

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...

BPF is 12 years older than Facebook :)

People don't buy individual pieces of technology, they want packaged solutions that come with support. Tech almost matters less than good support

Really sad. NGINX was the cure to F5 proprietary boxes.

Up next is likely HaProxy....

We replaced F5 with Avi Networks and we are a global fortune 500.

This is vaguely discomforting but perhaps inevitable in a world where open source is sponsored, funded or developed by corporate interests.

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.

Man I didnt even realize F5 was still relevant...

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)

How can some of you do balancing, but have never heard of F5? Heck, I knew if f5 10 plus years ago. F5 can be fully automated now from top down, plus the additional security aspects are a major plus. Most people that use Nginx, and have some knowledge of load balancing products use both. It’s often called the best of bread, which Nginx and f5 are IMO. Now, a few years ago could you have automated everything? Probably not, but just look at their gitrepo. It’s pretty transparent at what their aiming at.

First time I heard of this company. Their website is in the highest order of marketing speak, but actually offering nothing much. Note to self: security services are a nice way to milk governments & corporations.

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!

We use their VPN client at where I work...it's a mess. Disconnects all the time, IF you can even get it to connect in the first place, it like's to sit there for up to 20 minutes sometimes before it finally connects. Almost never works with captive portals, and all sorts of syncing issues with our network drives.

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.

F5 is big in its category (software http "router") in a lot of important industries including finance and healthcare. It's the SSL terminator of choice overall for enterprise environments and is a critical part countless L3 toolchains and workflows.

F5 is your standard enterprise software company that big companies end up using while all employees hate using their products.

what are some good alternatives to nginx?

A good reverse proxy alternative for containerized applications is Traefik (https://github.com/containous/traefik).

Obviously Apache, IIS

https://caddyserver.com/

https://www.lighttpd.net/

https://www.hiawatha-webserver.org/

Probably not that last one...

https://www.hiawatha-webserver.org/weblog/132

Or IIS... yikes!

Depending on what you're doing, haproxy is usually a better choice than nginx.

I've played with both over time, and I was never comfortable with HAProxy's performance.

As a load balancer, haproxy is usually what you want. It has more tools in the bag for those use cases.

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...

I'd rather narrow the problem to "what you really need to achieve".

See this benchmark for some inspiration: https://www.techempower.com/benchmarks/#section=data-r17&hw=...

thanks, for a personal static blog

Nginx does a lot of things today that the erstwhile notion of a 'web server' would never have been tasked to to.

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.

> Nginx does a lot of things today that the erstwhile notion of a 'web server' would never have been tasked to.

Can you explain more? (Serious question, as a long-time httpd user who hasn't used nginx)

Caddy

I found Caddy to have a lot of user-hostile behavior, and outright dangerous behavior in the way it fetches SSL certificates.

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.

I help out a lot at Caddy's community forums. I'd like to know more about your experience with Caddy.

> 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?

Envoy https://www.envoyproxy.io/

depending on what you use nginx for, check out openbsd.

and its httpd

H2O https://h2o.examp1e.net/

We were one of the first three investors in Nginx in 2011 and just decided to share memories about development of the company thought the eyes of its VC shareholder:

https://medium.com/runa-capital-collection/nginx-and-runa-st... (from idea in 2002 to exit in 2019)

Wow. Huge exit for them. Didn’t see this coming.

congrats Nginx team! i've gotten lots of value out of your product

Would be curious to know if employees are able to tap into these profits, or if somehow they are getting screwed?

I am using F5 BigIP 5600 for quite some time now. In one line: I hate it! Can’t rename „objects“. You can’t search properly for something in a DataGroups - at least not within the UI. There is just so much that I really hate about that product. I was about to tell my chef about NGINX - well ...

I wonder if load balancer and API gateway products might eventually converge. Things like Kong, Tyk and Apigee have caching, embedded scripting, basic load balancing, etc. They aren't as good as Nginx or Haproxy at it, but a single product outside the app would be attractive.

"Things like Kong, Tyk and Apigee have caching, embedded scripting, basic load balancing, etc. "

Hmmm... like Apache httpd?

Well, in addition to API gateway specifics, like API keys, counters, etc.

Curious how you think Kong falls short of Nginx. Isn't it built on top of Nginx via Openresty/ngx_lua?

Marco, CTO of Kong here. Kong is not only built on top of Nginx, but also extends it significantly to provide features that Nginx doesn’t do out of the box (dynamic configuration, SRV records resolution, dynamic Plugin based system, data plane API and so on).

Ah, yes. I was generalizing API gateway load balancing, which doesn't make sense for Kong.

I was always under the impression nginx was keeping rather basic stuff(like downstream status) out of core so they could sell plus and that the community deserved a better defacto server.. Maybe this will be the catalyst?

Well it makes sense for F5.

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.

F5 is loosing huge customers to a company called Avi networks. F5 employee told me F5 is scared of Avi. Might have been a move to try to compete.

hey, can you provide a source for their decrease in market share? Or are you assuming based on AWS growth? I tried looking up the Gartner starts but couldn't get past a login.

Sorry based on my own ignorance.

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.

Congrats to them. Grateful for the product they open sourced.

I wonder where that puts Wallarm that sells WAF solutions relying on NGINX and F5's Big IP is a competitor.

I'm guessing this will upset many devs longing for nginx per default. Personally, I never understood why nginx is so popular with a particular demographic, and have always preferred tried-and-true Apache httpd.

nginx had very well performing event driven core from the get-go. Apache event mpm module stabilized only in 2.4, and at that point nginx was already quite popular.

Are we all going to move back to Apache httpd?

Why not? Apache 2.4 with the Event MPM is async and event-driven, just as fast as nginx, lower latency, more fully compliant w/ RFC specs, robust reverse proxy w/ load balancing and dynamic configuration, super-fast caching,... and fully and completely open source.

Hey you're preaching to the converted. Tbh I have no idea why we all moved away in the first place. I was fine with Apache.

Yeah, well, that was fun while it lasted.

Wonder how the other shareholders did.

Terrible news

what happens to A10 now, being in the same market as F5?

lol

I still have hard time believing that commercial merger will result in Nginx remaining available as free and open source without any drawbacks and hidden payments for those requiring fully functional piece of software.

Let's see what follows.

Congratulations to nginx. It could be an acqui-hire or it could be a defensive move by F5.

Is docker up next? Thoughts?

Seems to be too early for an April fool's joke :(

F5 Networks - never heard of them.

After reading what they do I am not sure whether I should have heard of them.

They probably bought nginx because AVI networks has been winning F5s largest customers away one major logo at a time, and are scrambling to compete. F5 already bought a software load balancer in the past and did nothing with it, so they will once again probably do nothing with NGINX and struggle to build something as usual. I replaced f5 with AVI and know of a number of global companies that have done it as well. Interesting times for the ADC space. Bye bye nginx. https://www.businesswire.com/news/home/20190311005876/en/Avi...

Reply on news.ycombinator.com