Revamping ArgoCD: embracing plugins as standalone services

This year, I went to my first KubeCon in Paris, and it was really interesting. One session in particular caught my attention – a proposal to transform ArgoCD’s plugin system by turning them into standalone services. For those of us who are really into Kubernetes, ArgoCD is a familiar face, making deployments easier through its GitOps approach. But the current plugin setup? It’s a bit clunky and could do with some innovation.

Current state of play

ArgoCD is great at keeping your deployments in sync with your Git repositories, so you can be sure that what you code is what you see in production. However, the integration of plugins, which extend ArgoCD’s functionality, could be better. Today, setting up a new plugin involves a lot of manual configuration – tweaking the ArgoCD server itself, which can be both time-consuming and error-prone.

A new way of thinking about plugins: independent and service-based

So, what’s the big idea from KubeCon? Picture this: ArgoCD plugins, but now as standalone Kubernetes services. That means they’re decoupled from the core ArgoCD architecture. This means plugins get to act like any other service, making them way easier to manage and scale. It’s about reducing friction and simplifying the entire process.

Let’s take a closer look at the new setup

Here’s what the new architecture is all about:

1. Automated Discovery: Plugins would be tagged with specific labels, which would let ArgoCD automatically discover and integrate them without any manual intervention.
2. Enhanced Scalability: Each plugin can be scaled independently according to its own needs, without affecting the core operations of ArgoCD.
3. Security and Isolation: With plugins running as separate services, they can be secured independently, which minimises the risk if one were to be compromised.

Why this proposal matters

If we switch to a service-based approach for plugins, we can cut down on the complexity of the current system. It’ll make it easier to deploy and maintain, and it could even set a new standard for developing and integrating DevOps tools.

Technical Details and Thoughts on Implementation

The technical shift is all about making the most of Kubernetes’ capabilities to manage services. This is done by using labels for discovery and employing native features like load balancing and health checks directly for plugins. This aligns with Kubernetes’ principles and makes the most of the ecosystem’s strengths.

What does this mean for the future and how will it affect the industry?

If this proposal takes off, it could inspire similar changes across other tools in the cloud-native ecosystem, promoting a more modular and scalable approach. The potential for broader adoption could lead to more robust, flexible, and user-friendly systems across the board.

Keeping up with the Evolution

Right now, the proposal is just that – a proposal. It’s open for feedback, and as someone new to KubeCon but passionate about making tech work better, I see this as a great chance to get involved. The community’s input will be really important in refining and implementing these changes effectively.

Finally, some thoughts on the matter

This move towards independent service-based plugins could be a game-changer for ArgoCD. It’ll turn a cumbersome aspect of its operation into a streamlined, scalable feature. For those of us navigating the complexities of Kubernetes every day, it promises a smoother, more manageable workflow.

Key Takeaways

• ArgoCD’s plugin system is about to get a big makeover to make it more modular and easier to manage.
• The idea of using service-based plugins could help us to scale the system up and make it more flexible to use.
• This is still a proposal, so we’d love to hear your thoughts. Your input is important!