Tu caja de herramientas en la nube: IDEs, CLIs y extensiones que no te pueden faltar

Piano

Últimamente he estado probando varias herramientas para trabajar con AWS, Azure y GCP desde el mismo entorno, y me gustaría saber qué stack recomiendan. ¿Usan IDE con plugins específicos o prefieren la terminal con CLIs? Por mi parte, estoy usando VS Code con las extensiones oficiales de cada cloud (AWS Toolkit, Azure Tools, Google Cloud Code) y la CLI de cada uno, pero siento que a veces se solapan. ¿Alguna sugerencia para unificar o mejorar el flujo?

Cooking

Yo soy más de JetBrains, especialmente IntelliJ con los plugins de cloud. Pero reconozco que VS Code es más ligero y tiene mejor soporte para múltiples nubes. Lo que sí, no te olvides de Terraform y Pulumi como herramientas multi-cloud. Con el plugin de Terraform en VS Code y la CLI de Pulumi, manejas infraestructura como código sin depender tanto de los CLIs nativos.

Gardening

Para mí la clave es k9s y kubectl si trabajas con Kubernetes, que ahora es el estándar en cloud. Además, uso gcloud CLI para GCP y awscli con session-manager-plugin. Pero coincido en que las extensiones de VS Code son muy prácticas para despliegues rápidos. Eso sí, evito tener todas las extensiones activas a la vez porque consumen mucha memoria.

Piano

Gracias por los aportes. Lo de Terraform y Pulumi lo he probado, pero a veces me lío con los estados remotos. ¿Usan algún backend en específico? Yo uso S3 con DynamoDB para los locks, pero en Azure sería Blob Storage, y en GCP, Cloud Storage. ¿Recomiendan alguna herramienta que abstraiga eso? Lo de k9s no lo conocía, le echaré un ojo.

Finance

Para los backends, Terragrunt es un salvavidas. Te permite manejar configuraciones DRY y usar diferentes backends según el proveedor. Además, con Atlantis puedes automatizar los planes y applies desde Pull Requests. Y si te va el rollo más moderno, Crossplane te deja gestionar infraestructura multicloud con Kubernetes CRDs.

Standup

No estoy de acuerdo con depender tanto de Terraform. A veces es más sencillo usar los CLIs nativos y scripts en bash o Python con las SDKs. Por ejemplo, para tareas rápidas de listar recursos o cambiar configuraciones, prefiero awscli con jq. Las extensiones de VS Code están bien para explorar servicios, pero al final los CLIs son más veloces y precisos.

ArtLover

Algo que no han mencionado: Azure Storage Explorer y Google Cloud Storage Browser son muy útiles para gestionar buckets sin tocar la terminal. Y para bases de datos en cloud, DBeaver con sus conectores nativos (Redshift, BigQuery, Cosmos DB) es una maravilla. En cuanto a IDEs, Cloud9 de AWS está bien si trabajas 100% en su ecosistema, pero es muy limitado para multi-cloud.

Piano

Interesante lo de Terragrunt, lo probaré. Y sí, los CLIs nativos son rápidos, pero cuando tienes que hacer deploy de microservicios en varias regiones, una herramienta de IaC te evita errores manuales. Por cierto, ¿alguien usa NoCode para cloud? He visto Winglang y CloudFormation con CDK, pero aún no me decido. Creo que lo mejor es combinar: IaC para infraestructura, CLIs para debugging rápido.

Sustainable

El debate IaC vs CLIs nativos siempre es interesante. Para mí, la clave está en el contexto: si es un one-off o estás debuggeando, los CLIs con jq son imbatibles. Pero para entornos productivos, la reproducibilidad de Terraform o Pulumi es innegociable. Sobre NoCode, he probado Winglang y me parece prometedor para prototipado rápido, pero en producción prefiero CDK (TypeScript) porque te da control fino sin perder la abstracción. ¿Alguien ha intentado combinar Terragrunt con Terratest para testing? Esa combinación me ha salvado de varios desastres en multi-región.

Snowboard

Yo he usado Terragrunt + Terratest en un proyecto multi-región con Azure y AWS, y es una combinación brutal para validar que los módulos se despliegan consistentemente. Pero ojo, Terratest necesita Go, y si tu equipo no lo domina, la curva de aprendizaje es empinada. Una alternativa ligera es usar terraform plan -out y luego parsear el JSON con jq para assertions básicas. Para NoCode, Winglang me parece más hype que realidad; en producción, CDK con TypeScript y projen para gestionar dependencias es más maduro. ¿Alguien ha probado cdk-nag con reglas personalizadas? Me interesa saber si vale la pena integrarlo en pipelines de CI/CD.

VR

cdk-nag con reglas personalizadas sí vale la pena, pero solo si tu equipo ya tiene cultura de compliance. Lo implementé en un pipeline multi-account con AWS y nos ahorró auditorías manuales. El problema es que las reglas por defecto son genéricas; necesitas escribir las tuyas para tu dominio (ej: tagging, cifrado). Si usas projen, puedes generar las reglas automáticamente desde un modelo. ¿Alguien ha integrado cdk-nag con drift detection? Ahí es donde se pone interesante, porque el nag solo corre en synth, no detecta cambios fuera de banda.

Ski

cdk-nag con drift detection es un tema espinoso. El nag analiza el template, no el estado real. Para drift, necesitas algo como aws cloudformation describe-stack-resource-drifts y luego comparar con el template validado. He visto equipos que usan cdk-nag + taskcat para testing, pero taskcat está descontinuado. Una alternativa: cfn-guard con reglas personalizadas y luego un script que ejecute aws cloudformation detect-stack-drift en los stacks desplegados, parseando el JSON con jq. No es elegante, pero funciona en CI/CD si lo encapsulas en un contenedor. ¿Alguien ha probado el nuevo aws cloudformation drift-detection con recursos de terceros? Ahí el soporte es limitado.