Archive for DevOps

Network Big Iron f5 Acquires Software Network Vendor NGINX

I woke up last Tuesday (March 12, 2019) to find an interesting announcement in my inbox. NGINX, the software networking company, well known for its NGINX web server/load balancer, was being acquired by f5. f5 is best known for its network appliances which implement network security, load balancing, etc. in data centers.

The deal was described as creating a way to “bridge NetOps to DevOps.” That’s a good way to characterize the value of this acquisition. Networking have begun to evolve, or perhaps devolve, from the data center into the container cluster. Network services that used to be the domain of centralized network devices, especially appliances, may be found in small footprint software that runs in containers, often in a Kubernetes pod. It’s not that centralized network resources don’t have a place – you wouldn’t be able to manage the infrastructure that container clusters run on without them. Instead, both network appliances and containerized network resources, such as a service mesh, will be present in microservices architectures. By combining both types of network capabilities, f5 will be able to sell a spectrum of network appliances and software tailored toward different types of architectures. This includes the emerging microservices architectures that are quickly becoming mainstream. With NGINX, f5 will be well positioned to meet the network needs of today and of the future.

The one odd thing about this acquisition is that f5 already has an inhouse project, Aspen Mesh, to commercialize very similar software. Aspen Mesh sells an Istio/Envoy distribution that extends the base features of the open source software. There is considerable overlap between Aspen Mesh and NGINX, at least in terms of capabilities. Both provide software to enable a service mesh and provide services to virtual networks. This raises the question “Why buy NGINX if f5 already has Aspen Mesh?” Sure, NGINX has market share (and brain share) but $670M is a lot of money when you already have something in hand.

NGINX and f5 say that they see the products as complimentary and will allow f5 to build a continuum of offerings for different needs and scale. In this regard, I would agree with them. Aspen Mesh and NGINX are addressing the same problems but in different ways. By combining NGINX with the Aspen Mesh, f5 can cover more of the market.

Given the vendor support of Istio/Envoy in the market, it’s hard to imagine f5 just dropping Aspen Mesh. At present, f5 plans to operate NGINX separately but that doesn’t mean they won’t combine NGINX with Aspen Mesh in the future. Some form of coexistence is necessary for f5 to leverage all the investments in both brands.

The open source governance question may be a problem. There is nervousness within the NGINX community about it’s future. NGINX is based on its own open source project, one not controlled by any other vendors. The worry is that the NGINX community run into the same issues that the Java and MySQL communities did after they were acquired by Oracle which included changes to licensing and issues over what constituted the open source software versus the enterprise, hence proprietary software. f5 will have to reassure the NGINX community or risk a fork of the project or, worse, the community jumping ship to other projects. For Oracle, that led to MariaDB and a new rival to MySQL.

NGINX will give f5 both opportunity and technology to address emerging architectures that their current product lines will not. Aspen Mesh will still need time to grow before it can grab the brain share and revenue that NGINX already has. For a mainstream networking company like f5, this acquisition gets them into the game more quickly, generates revenue immediately, and does so in a manner that is closer to their norm. This makes a lot of sense.

Now that the first acquisition has happened, the big question will be “who is the next sellers and the next buyers?” I would predict that we will see more deals like this one. We will have to wait and see.

Catching Up

My desk with computers, displays, and coffee.

Whew! January was a busy month. In addition to my usual CMSWire columns (my first of the year was about the BDL role in open source), I spent time talking with journalists, working on a new research paper on Service Mesh for container clusters, and finished a paper on Cloud Foundry vs. Kubernetes. Busy busy busy.

At the beginning of the new year, I was quoted in a blog entitled “20 Developers and Kubernetes Experts Reveal the Biggest Mistakes People Make During the Transition to Kubernetes” It’s nice to be called a Kubernetes expert but I wouldn’t call myself that. Kelsey Hightower is an expert; I’m an observer. Still, I stand by my quote about one of the big mistakes when adopting Kubernetes which was “From our vantage as outside observers, it’s trying to apply Kubernetes to all applications.”

An article that I was previously quoted in came out in French. Originally published in mid-December as “Knative project stokes interest in event-driven IT ops” it came out in January in the French language version. I took French in high school and can still read it enough to decipher a wine bottle (shows where my priorities are) but do not speak it. I assume that “Knative : les entreprises montrent un début d’intérêt” quotes me correctly.

More talk about open source later in the month. More accurately, open core. Open core refers to companies that open source their core technology but maintain control over the project while adding “enterprise” features to the product they sell. “Uncertain future of open core software puts companies at risk” talks about the problems these companies have and the advantages of vendor supported open source.

Expect more of me in the press in the coming months.

I also completed a new research paper which compares Cloud Foundry  and Kubernetes as the basis of cloud native platforms. I dispel the myth that it must be one or the other. I expect that to be released within the next month.

And keep your eye out for a major research paper on service mesh technology. A component of microservices architectures, a service mesh is critical to enterprise container clusters and other microservices implementations. Look for it in April just ahead of Cloud Foundry Summit in Philadelphia.

And you wonder why I haven’t been blogging here much.