How Far Can You Go with Argo?

Coming back from ArgoCon in Chicago left me pondering the future of Argo, especially Argo CD. There are two strong camps: die-hard Argo fans committed to the open source community, and folks who prefer to stay with their current deployment tools and extend their use for deployments to Kubernetes. Both of these approaches have their merits.

Organizations using Argo CD for continuous delivery in Kubernetes praise it for its simplicity. According to Navneet Verma, technical leader at VMware, Argo CD offers an intuitive graphical user interface (GUI) backed by a robust command line interface (CLI) and API. He also values its ability to handle multiple clusters with a single installation.

Simple? Or too Simple?

However, many find it too rudimentary. Diogo Baeder, lead backend developer at DeepOpinion, says Argo CD lacks the ability to allow developers to deploy a specific release. Instead, it depends on whatever has been defined in the application specs. The need to apply proven deployment patterns is the reason companies such as Codefresh see growing adoption of their commercial solutions built on top of Argo.

Nikita Dergilev, senior product manager at Octopus Deploy, shares this sentiment. In his view, Argo CD is great for cluster bootstrapping. It’s easy to configure, and the first deployment will take a little time. However, he sees an issue with using Argo CD when teams need to deploy apps across many environments or clusters, such as cloud regions. The pain comes from the need to manage many Git repositories, branches, or folders and to orchestrate promotions with in-house scripts or manually. It can quickly become a mess.

Another potential issue is scalability. Dergilev says organizations essentially have two options if they have many clusters, apps and teams. The first is a centralized Argo instance, which might be slow and introduce issues with permissions and network traffic. The second is an instance per cluster, which can be hard to manage and doesn’t offer a single pane of glass for observability. He recommends leveraging the capabilities of your existing DevOps tools to deploy your software. For example, Octopus Deploy offers out-of-the-box Kubernetes deployment functionality, including environmental progression and dashboards that provide visibility of Kubernetes deployments across all projects and environments.

Strategic Conversations about Argo

The discussion around using Argo is also taking place on a strategic level, focusing on Argo’s configuration approach. This is illustrated well by Justin Pullen, lead engineer at American Family Insurance. He says that although he is a huge fan of declarative configuration for most things, the one downside he sees with any declarative item is code management after the initial setup.

More and more human hands must get involved to make any sweeping change across all codebases. Pullen points out that this is not unique to Argo or Kubernetes deployment declaration. It is a problem that plagues any system based on declarative syntax.

So, how do you manage mandatory changes at scale quickly? As Pullen summed it up: The answer is not clear, but the conversation needs to take place when planning and executing deployments to Kubernetes in large enterprises, regardless of the solution.

I agree with this statement, as it is yet another indication that it is not about the technology you choose to use; it is how you integrate your current processes and people into this new technological shift toward application containerization.