Skip to main content

Introducción a IDP (Internal Developer Platform)

DevOps no se trata de clouds, contenedores, Kubernetes, monitoreo, service mesh y todas esas herramientas. El objetivo principal es permitir que los desarrolladores sean autosuficientes.

Gestionar todas esas herramientas, sin embargo, no es DevOps. Los equipos de SRE u otro equipo, con la nomenclatura que tu empresa utilice, son los responsables de conocer profundamente esas herramientas y mantenerlas.

No tiene sentido poner a disposición una infinidad de herramientas para todos los desarrolladores, porque, muchas veces, ellos no sabrán usarlas correctamente. Tampoco tendrán tiempo o conocimiento necesario para entender los detalles de Kubernetes, de las clouds o para resolver problemas complejos relacionados con esas tecnologías. Esas herramientas deben ser gestionadas por equipos especializados en operaciones.

El desafío: ¿cómo lidiar con desarrolladores sin conocimiento operacional profundo? Es imposible que todos sepan todo. Los desarrolladores, generalmente, concentran sus esfuerzos en la escritura de código, mientras el personal de operaciones (a veces llamado de DevOps) asume la responsabilidad por las etapas siguientes. La transición de esas responsabilidades se realiza con la ayuda de pipelines, GitOps y otras técnicas que integran el trabajo entre los equipos.

Sin embargo, deberíamos capacitar a los desarrolladores para que fueran capaces de realizar esas tareas solos, como gestionar clusters, configurar la infraestructura, implementar sus aplicaciones, ejecutar integraciones continuas (CI), entre otros. El objetivo es crear equipos autosuficientes que combinen desarrollo y operaciones.

Entregar una cuenta en la cloud y esperar que los desarrolladores resuelvan todo solos no es eficiente. Ellos enfrentarían una curva de aprendizaje enorme y cometerían muchos errores debido a la falta de experiencia.

DevOps significa crear servicios que otros equipos de la empresa puedan consumir para volverse autosuficientes. Los clientes de DevOps son los desarrolladores.

En ese sentido, DevOps está profundamente relacionado con la creación de IDPs (Internal Developer Platforms). El IDP es una plataforma de desarrollo interna destinada al uso por los desarrolladores, que son los consumidores de esa plataforma.

El IDP es una capa que permite que los equipos realicen las operaciones necesarias mediante autoservicio. Esta plataforma es creada y mantenida por los equipos de operaciones, SREs, DevOps y seguridad.

En lugar de sobrecargar al equipo de operaciones con tareas repetitivas para atender las demandas del equipo de desarrollo, podemos enfocarlos en crear servicios reutilizables que aumenten la productividad de ambos lados.

Con un IDP, el equipo de desarrollo no necesita quedarse bloqueado esperando que el equipo de operaciones resuelva una solicitud. Muchas de esas solicitudes son recurrentes y podrían ser automatizadas o estandarizadas. Si el equipo de desarrollo puede resolver esas cuestiones de forma autónoma, eliminamos bloqueos y reducimos la carga de trabajo del equipo de operaciones.

El objetivo es proporcionar una plataforma que posibilite el ciclo de vida completo de las operaciones, incluyendo:

  • Cambio de estados deseados
  • Realizar ciertas operaciones o acciones
  • Converger el estado real al estado deseado
  • Observar el estado real del sistema

Estado Real (Actual State)​

El estado real representa todos los recursos actualmente en ejecución en el sistema. Refleja lo que está operando en el momento para atender las necesidades de negocio.

Podemos dividir el estado real en tres categorías principales:

  • Proveedores: Son los servicios y plataformas que utilizamos como base para el sistema. Ejemplos incluyen:
    • AWS
    • Azure
    • Google Cloud
    • On Premise
    • DataDog, Dynatrace, New Relic
    • Elastic
    • Splunk
    • Entre otros
  • Infraestructura: Representa los componentes que sostienen el sistema, como:
    • Servidores
    • Clusters
    • Bases de datos
  • Aplicaciones: Incluye los softwares que componen y dan soporte al negocio:
    • Nuestras propias aplicaciones, desarrolladas internamente
    • Aplicaciones de terceros, que integran o complementan el sistema

Para garantizar que el estado real atienda los objetivos de la empresa, es esencial definir y gestionar el estado deseado, el cual direccionará ajustes, mejoras y la convergencia hacia el sistema ideal.

Estado Deseado (Desired State)​

El estado deseado es la definición de cómo el estado real debe ser. Se crea mediante código, manifiestos, archivos de configuración y otros artefactos. Sin embargo, esta definición puede volverse extremadamente compleja, pues involucra diferentes niveles de conocimiento y áreas de expertise.

Desafíos del Estado Deseado​

  • Configuración de Aplicaciones en Kubernetes

    • Para definir una aplicación en Kubernetes, necesitamos crear múltiples manifiestos para configurar recursos como deployments, services, ingress, etc.
    • Es necesario también hacer build de imágenes de contenedor y gestionar todo el ciclo de vida de la aplicación.
    • Si la misma aplicación se ejecuta en otra plataforma, como servidores físicos u otra nube, las configuraciones pueden ser completamente diferentes.

  • Definición de Infraestructura en AWS (ej.: EKS)

    • Un cluster EKS exige configuraciones específicas, como: Aprovisionamiento del propio cluster EKS, grupos de nodos (node groups), configuración de un Internet Gateway, VPC, subredes, entre otros.

Estos ejemplos muestran que el estado deseado está compuesto por múltiples piezas interdependientes que necesitan ser agrupadas para alcanzar el objetivo. Solo personas con conocimiento técnico sobre esos bloques de construcción consiguen hacer esto correctamente.

Herramientas (Tools)​

No podemos evitar tener herramientas, las necesitamos.

Existen otros grupos de herramientas, sin embargo, para IDP, estos son los tipos de herramientas más importantes que necesitamos usar para habilitar el autoservicio.

  • Pipelines: Herramientas para automatización de las etapas de CI/CD.
  • GitOps: Para sincronizar el estado deseado con el estado real.
  • Infraestructura: Para gestionar la infraestructura.
  • RBAC: Para autenticación y seguridad del IDP.

Interfaz de Usuario (User Interface)​

El IDP es el punto central que conecta todo y permite a los desarrolladores alterar los estados deseados y observar el estado real. La interfaz de este sistema puede asumir diferentes formas:

  • Web: Una interfaz gráfica accesible por navegador.
  • CLI: Una interfaz de línea de comandos.
  • IDE: Extensiones o plugins integrados a las herramientas de desarrollo.

Lo ideal es ofrecer una combinación de esas opciones para atender diferentes preferencias y necesidades.

Simplicidad y Usabilidad​

El principal objetivo de las interfaces de usuario para IDPs es hacer las cosas más fáciles. Para eso, es esencial ocultar la complejidad operacional. Esto significa:

  • Abstraer las herramientas e interfaces individuales detrás de una capa unificada;
  • Crear interfaces simples, hechas a medida, que cualquier persona pueda entender y utilizar.

Para que todo esto funcione, necesitamos una API robusta debajo de la interfaz de usuario. No podemos depender de una interfaz que apenas ejecute comandos directamente en el CLI, porque eso no es suficiente para todos los casos. La API debe:

  • Ejecutar acciones de forma consistente;
  • Proveer informaciones cuando sea consultada;
  • Ser un punto central para interacción con el sistema.

El desafío surge cuando lidiamos con múltiples herramientas. Tener 100 herramientas diferentes significa lidiar con 100 APIs distintas, lo que aumenta la complejidad. Necesitamos una única API central que la interfaz de usuario pueda usar como base.

Hoy, Kubernetes es el principal candidato para esa función. Ofrece una API extensible y universal. Esto no significa que todo necesita ejecutarse en Kubernetes, sino que puede ser usado como una capa de abstracción para gestionar operaciones diversas.

No estoy diciendo que todo debería estar ejecutándose en Kubernetes, ese no es el objetivo. Kubernetes no está intentando ser la única plataforma que debes usar para ejecutar tus aplicaciones, pero está intentando convertirse en la única API que importa. Podemos usar Kubernetes no solo para ejecutar contenedores dentro de un cluster, sino para gestionar todo lo que fue proyectado para ser extensible e interactuar con casi todo.

API Universal (Universal API)​

Kubernetes no se limita a ejecutar contenedores. Es una API universal poderosa con un planificador (scheduler) altamente eficiente, capaz de gestionar cualquier tipo de recurso. Los contenedores representan apenas la primera ola de adopción y son una pequeña parte de lo que Kubernetes puede y debe gestionar.

Además, con el Controller Manager, Kubernetes realiza la reconciliación continua, asumiendo tareas operacionales que normalmente serían hechas manualmente. Esto garantiza que el estado real esté siempre alineado con el estado deseado, proporcionando resiliencia y confiabilidad al sistema.

CR y CRD: La Base de la Universalidad​

Custom Resources (CR) y Custom Resources Definitions (CRD) son la clave de todo y el motivo de que esta API esté buscando volverse universal.

  • CRD (Custom Resource Definition): Es la definición de cómo un manifiesto YAML debe ser estructurado para describir el estado deseado de un recurso.
  • CR (Custom Resource): Son los objetos que siguen la definición del CRD, representando los recursos personalizados dentro del cluster.

Los controladores de Kubernetes utilizan esas definiciones para transformar los manifiestos en realidad, reconciliando el estado real con el deseado.

Podemos crear CRDs para gestionar prácticamente cualquier cosa:

  • Aplicaciones;
  • Recursos en nube;
  • Bases de datos;
  • Monitoreo de estados específicos
  • Pipelines
  • Otros

Todos deberían ser capaces de escribir un CRD para monitorear el estado de lo que quieran.

Con los CRDs, es posible:

  • Definir qué es un recurso de manera estandarizada;
  • Componer y relacionar diferentes bloques de construcción;
  • Exponer esas definiciones como nuevos recursos hechos a medida.

Esto ofrece una oportunidad única para simplificar procesos complejos. Por ejemplo, el equipo de operaciones puede combinar diversos bloques en composiciones, permitiendo que los desarrolladores creen manifiestos basados en esas definiciones simplificadas. Los manifiestos resultantes son convertidos en recursos personalizados, que automáticamente realizan las operaciones necesarias.

Juntando Todo​

Los CRDs (Custom Resource Definitions) y CRs (Custom Resources) son la capa de abstracción que necesitamos para ocultar los detalles irrelevantes para el público general, simplificando todo de forma que cualquier persona pueda atender sus necesidades con facilidad.

Pipelines Integrados​

Necesitamos pipelines que ejecuten acciones específicas (como tests, creación de imágenes, etc.) de forma automatizada siempre que algún evento ocurra. La herramienta de CI/CD elegida debe ser integrada a la API de Kubernetes.

Idealmente, la definición de esos pipelines también debe estar basada en CRDs, creando un modelo declarativo para el flujo de trabajo. Aunque podamos construir nuestros propios recursos, herramientas como Argo Workflows y Tekton ya proporcionan esas funcionalidades listas. Sin embargo, cualquier otra solución de CI/CD puede ser usada, siempre que atienda las necesidades sin añadir complejidad innecesaria. Al fin y al cabo, pipelines son, esencialmente, solo conjuntos de acciones o scripts ejecutados en un orden específico.

Sincronización: Estado Deseado x Estado Real​

Garantizar que el estado real esté siempre sincronizado con el estado deseado es esencial. Herramientas como ArgoCD y Flux, basadas en GitOps, ya desempeñan ese papel de manera eficiente.

Infraestructura como Código en Kubernetes​

Para estandarizar la infraestructura, ella también debe ser declarada utilizando CRDs en Kubernetes. Aunque podamos usar SDKs específicos de las nubes, herramientas como Crossplane ya simplifican ese proceso, permitiendo gestionar recursos de infraestructura como bases de datos, VPCs y mucho más, directamente a través de manifiestos Kubernetes.

Orquestación de Aplicaciones​

La orquestación de aplicaciones, especialmente en modelos customizados, puede ser desafiante. Herramientas como Crossplane y KubeVela permiten crear definiciones de recursos personalizados que representan aplicaciones u otros recursos de forma declarativa y flexible. Lo más importante es que esas definiciones sean accesibles y consumibles por todos los involucrados en el proceso.

Gestión de Permisos (RBAC)​

Con el estado deseado almacenado en el repositorio Git, es crucial garantizar que solo las personas correctas tengan acceso a los repositorios correctos y con los permisos correctos.

La mayoría de los usuarios no necesita acceder directamente a Kubernetes o a la cloud, excepto en modo read-only.

El acceso directo a Kubernetes todavía es necesario, pero solo para el IDP, que necesita observar y monitorear el estado real.

Interacción con el IDP​

Toda interacción con un IDP (Internal Developer Platform) se basa en dos acciones principales:

  • Alterar el estado deseado.
  • Observar el estado real.

Cambio del Estado Deseado​

Las alteraciones en el estado deseado pueden ser hechas de varias maneras:

  • Directamente en el código almacenado en el repositorio Git.
  • A través de la interfaz del IDP.
  • Utilizando el CLI.
  • Vía IDE, con plugins o extensiones.

Independientemente del método elegido, todo DEBE reflejarse en el repositorio Git para garantizar consistencia.

Los pipelines también desempeñan un papel importante en la actualización del estado deseado. Por ejemplo, al construir y enviar una nueva imagen de contenedor a un registry, el pipeline puede automáticamente actualizar la tag de la imagen en un manifiesto YAML en el repositorio. Ese manifiesto define el estado deseado de la aplicación.

Además, los desarrolladores pueden enviar código de la aplicación y crear, modificar o actualizar manifiestos basados en CRDs. Esos CRDs, creados por los operadores, son la base para definir y simplificar lo que cada recurso es.

Observación del Estado Real​

Herramientas de GitOps detectan automáticamente discrepancias entre el estado deseado (definido en los manifiestos) y el estado real (representado por los CRs en Kubernetes). Siempre que hay un desvío, esas herramientas sincronizan los dos estados para mantener el sistema alineado.

Responsabilidades del IDP​

El IDP desempeña un papel crucial en tres áreas principales:

  • Creación de Manifiestos:

    • Facilita la creación de manifiestos basados en CRDs, definidos por los operadores.
    • Realiza el push de los manifiestos al repositorio Git, garantizando que el estado deseado sea actualizado.

  • Visualización del Estado Deseado: Permite observar el estado deseado del sistema, sea como un todo o de partes específicas.

  • Monitoreo del Estado Real: Recoge informaciones sobre el estado actual del sistema para fines de monitoreo, análisis de logs y solución de problemas.

El objetivo del IDP no es solo permitir que los desarrolladores hagan lo que ya hacen, sino también capacitarlos para realizar tareas fuera de sus áreas de especialización, de manera más simple, eficiente y accesible.

¿Qué IDP?​

La mayoría de los IDPs existentes en el mercado funcionan bien para empresas pequeñas, startups u organizaciones que están empezando desde cero y pueden adaptarse a una solución menos customizable. Sin embargo, para grandes empresas, esto se vuelve un desafío debido a la complejidad de los procesos existentes y a la necesidad de una adaptación más robusta a las particularidades del negocio.

Cuando una empresa llega al punto de implementar un IDP, generalmente ya posee una infraestructura consolidada, con activos, herramientas y años de inversión. En ese contexto, es más eficiente y práctico que la herramienta se adapte al negocio, y no al revés. Intentar imponer cambios culturales drásticos y alterar flujos de trabajo bien establecidos puede ser contraproducente, generando resistencia interna y pérdida de productividad.

Por eso, las grandes organizaciones frecuentemente optan por desarrollar sus propios IDPs para garantizar que sean totalmente personalizados a sus necesidades. Este enfoque permite crear soluciones que atiendan las exigencias específicas de procesos internos, conformidades, herramientas ya en uso y flujos de trabajo existentes.

¿Construir o Adaptar?​

Aunque desarrollar un IDP desde cero pueda parecer ideal para garantizar personalización completa, no siempre es el mejor enfoque. Existen IDPs en el mercado que ofrecen alto grado de flexibilidad y pueden ser customizados para atender necesidades específicas.

Backstage, por ejemplo, es una solución ampliamente adoptada que permite crear una interfaz gráfica adaptada, centralizar informaciones y flujos de trabajo, además de integrar diversas herramientas. Su arquitectura basada en plugins es una gran ventaja, permitiendo que equipos adapten y expandan el IDP de acuerdo con el crecimiento y los cambios en las prioridades del negocio.

Por otro lado tenemos Port que es una solución SaaS, obviamente paga, pero bien adaptativa y con muchos recursos.

Además, algunas empresas utilizan un enfoque híbrido: combinan la adopción de un IDP existente, como Backstage, con el desarrollo de herramientas e integraciones propias para complementar sus necesidades. Esto permite acelerar la implementación mientras todavía garantiza flexibilidad y personalización.