CloudSlash plantea rehacerse con arquitectura agnóstica y plugins para AWS, Azure y GCP
El autor de la herramienta, construida en público, propone una capa común con plugins por proveedor y pide opiniones en el repositorio antes de decidir el rumbo del proyecto.
CloudSlash, la herramienta que su autor, conocido en GitHub como DrSkyle, ha ido construyendo en público durante los últimos meses, puede cambiar de forma. La propuesta sobre la mesa es rehacerla con una arquitectura agnóstica de proveedor y un sistema de plugins que cubra AWS, Azure y GCP, y que deje la puerta abierta a otras nubes. El propio autor lo ha planteado en el repositorio y pide opiniones antes de mover ficha.
Qué hay sobre la mesa
Poco más, y conviene decirlo. El anuncio es un aviso: recuerda que el proyecto nació en público hace unos meses y que se ha ido afinando con las sugerencias y el feedback recibido. Ahora toca decidir hacia dónde va, y de ahí sale la idea de una capa común con plugins por proveedor, un patrón habitual en herramientas de infraestructura que quieren hablar con varias nubes sin multiplicar el código.
No hay fechas, ni versiones, ni un plan de trabajo publicado. Tampoco aparece detalle alguno sobre el modelo de licencia, pese a que el título de la discusión lo menciona junto a la arquitectura y los plugins. Quien quiera saber qué se plantea exactamente tendrá que entrar en el hilo.
El resumen de la propuesta, con las preguntas abiertas que el autor deja para quien quiera responder, está en la discusión del repositorio.
Por qué puede importar
Abstraer varias nubes bajo una misma interfaz es una tentación vieja y un problema difícil. Cada proveedor tiene sus servicios, sus nombres y sus límites, y una capa común acaba filtrando esas diferencias tarde o temprano: lo que hoy es un plugin limpio mañana es una excepción documentada en el README. Si el diseño aguanta esa presión sin obligar a reescribir cada integración, la herramienta gana enteros para equipos que operan en más de una nube. Si no, quedará como una capa más que mantener encima de las APIs originales.
De momento esto es una consulta a la comunidad, no un roadmap cerrado. Lo que falta por ver es si el hilo recoge suficiente discusión técnica como para fijar el diseño, quién acaba escribiendo esos plugins y si el proyecto se abre a colaboradores externos. El autor no ha dado plazos, y el título de la discusión promete una conversación sobre licencias que todavía no ha empezado.
