Tag Archive for containers

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.

Containers Continue on Track for 2019: 3 Key Trends For the Maturing Container Ecosystem

This blog appeared first at the Amalgam Insights blog.

The past few years have been exciting ones for containers. All types of tools are available and a defined deployment pipeline has begun to emerge. Kubernetes and Docker have come to dominate the core technology. That, in turn, has brought the type of stability that allows for wide scale deployments. The container ecosystem has exploded with lots of new software components that help maintain, manage, and operate container networks. Capabilities such as logging, load balancing, networking, and security that were previously the domain of system-wide software and appliances are now being brought into the individual application as components in the container cluster.

Open Source has played a big part in this process. The Cloud Native Computing Foundation, or CNCF, has projects for all things container. More are added every day. That is in addition to the many other open source projects that support container architectures. The ecosystem just keeps growing.

Where do we go from here, at least through 2019? Pretty much on the same path. 2019 will be a year for rounding out and growing container technology to make it more palatable to large enterprise applications. With the basic technology done, the work to make container networks secure, resilient, and manageable will be the primary focus for containers.

That doesn’t mean there won’t be new and exciting technology added to the container ecosystem. Serverless computing, which has been built on containers, will now itself be turned into a container technology. The KNative project to create serverless computing in a Kubernetes cluster is an example of interesting development that needs to be tracked over the coming year. For many developers, having to deploy container clusters is, in of itself, too much work. They would prefer a new level of abstraction that allows them to ignore all the workings of the cluster and just write code. KNative might just do that.

Another area to watch will be hardening containers. While the capacity utilization of containers is better than virtual machines, they also less safe than VMs. Inhibiting the ability of code running in a container to access the host operating system is an interesting way to make containers more secure.

Finally, the emergence of service meshes for containers is an important development for containers and microservices. Services meshes are set of network services controlled by a central controller accessible from the container cluster. This offers the possibility for much more flexible clusters that can access centralized services that compliment the internal components of the system. Service meshes help provide a balance between centralized and localized services.

2019 is not going to be “exciting” for containers in the sense of blockbuster new technology. Instead, this is the year when the container ecosystem grows up, filling holes in container architectures. The refinement of the container ecosystem is critical to long term health in the space. It won’t be exciting but it also won’t be boring.