Archive for Software vendors

Docker Enterprise 3.0 is the Docker We’ve Been Waiting For

DockerCon 19

This blog post was originally published on the Amalgam Insights website.

For the past few years, one of the big questions in the software industry has been what direction Docker would take. Much of their unique intellectual property, such as Docker images, had been open sourced and many of their products have underperformed. Docker Swarm is an excellent example of a product that was too little too late. While loved by Docker customers I spoke with, Docker Swarm simply couldn’t surf the swell that is the Kubernetes wave.

With that in mind, Docker has been moving away from the commodity business of container infrastructure and reinventing itself as a developer tools company. With the upcoming Docker Enterprise 3.0, Docker will have taken an important step in becoming a developer automation and toolchain company.

Docker E3.0, which is slated for general release in Q2 this year, provides a complete set of tools for packaging code into container images, moving that image down the developer pipeline, and deploying it to production in a repeatable fashion. These are new tools for modern developers. The ability to package code for different clouds, architectures, and OS’s is a serious advantage in the emerging multi-platform, multi-cloud world.

The real value of Docker E3.0 is in simplifying developer pipeline activities through automation. Instead, of writing endless YAML and then stitching together different CI/CD applications to form the pipeline (usually with more YAML), and endless CLI commands, Docker E3.0 makes this happen in a few simple commands and templates, generating all the command files necessary to create the whole pipeline.

This addresses one of the largest problems in DevOps today – the complexity of the DevOps pipeline. The whole purpose of DevOps and Agile is to push code out more quickly. In speaking to developers, we find a real fear that they will be overwhelmed with this new pace of releases. It’s not the writing of code that is at issue though; It’s the mountains of YAML and CLI commands necessary to take new code through the DevOps pipeline to production. Packaging code for deployment to different platforms and environments can take a tremendous time and effort. For some, this has meant going backwards to slower deployment cycles. Others have added more cost by hiring more people to handle all the packaging and moving of code to get it to production. Making software slower or more costly are antithetical to the goals of DevOps and Agile.

Docker Enterprise 3.0, especially Docker Desktop Enterprise and Docker Apps, are designed to directly address these issues. Docker Desktop Enterprise provide the tools to autogenerate Docker Compose and CI files, vastly simplifying the work to package code and move it down the DevOps pipeline. Instead of writing YAML, developers can now spend more time writing actual code. Docker Apps, which is bundled with Docker E3.0 but also available as a CLI plugin now, goes a step further. A CNAB implementation, Docker Apps creates a bundle of containers, making it easier to move whole microservices applications around. These tools plug right into common IDEs, such as Visual Studio Code, and work with common DevOps software such as Jenkins and GitHub, to make a developer’s life much easier.

Docker didn’t talk much about what would come after Docker E3.0. That would provide the community more confidence that Docker had learned to read the tea leaves better. Docker E3.0 addresses problems of the here and now and should provide a major boost to the company. Let’s hope they can keep the momentum going.

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.