¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
Conoce nuestra marca.
Si algo caracteriza al mundo de la informática es el cambio continuo que rodea a las personas que nos dedicamos a él. Hace años empezamos a acuñar el término DevOps que dio por fin nombre a una gran cantidad de profesionales que en su día a día hacían de Juan Palomo (yo me lo guiso, yo me lo como), siendo capaces de aunar desarrollo y sistemas en un único perfil que fuese autosuficiente para generar software.
Sin embargo, nuestro mundo no para de cambiar, abriendo un amplio abanico de herramientas que aumenta cada día. El hecho de tener tantas opciones y necesidades de conocimiento hace que la carga cognitiva de los perfiles de desarrollo crezca de manera exponencial.
Esta complejidad fue la que dio lugar a la filosofía Platform Engineering, que surgió para promover el cambio de mentalidad donde el equipo de infraestructura trata su trabajo como un producto para (entre otras cosas) mejorar la experiencia del equipo de desarrollo.
Es así como surge la IDP o Internal Developer Platform como producto de la disciplina Platform Engineering. En este post verás por qué es importante este término y cómo puede ayudar a la cultura DevOps a escalar para adaptarse a las necesidades de mercado.
¿Qué significa IDP?
Empecemos por lo básico. IDP son las siglas de Internal Developer Platform y, si nunca habías oído hablar de esto, no pasa nada. Hace tres años yo tampoco sabía lo que era.
Como ya nos adelantaron en su día nuestros compañeros David Morales y Alejandro Cavero en su post “4 elementos clave de Platform Engineering”, IDP es la piedra angular de Platform Engineering. IDP es una arquitectura compuesta por herramientas y servicios ofrecido por un equipo de Platform Engineering con un enfoque de “Plataforma como producto”.
El objetivo de las IDPs es bastante simple: que la persona de desarrollo pueda centrarse solo en desarrollar software dejando que la plataforma se encargue de las labores de operación y despliegue de manera segura y siguiendo los estándares de calidad.
¿Qué tiene que ver IDP con Platform Engineering?
Podríamos decir que IDP surge como respuesta tecnológica a la necesidad que Platform Engineering identifica pero, realmente, IDP fue la respuesta a una serie de cuestiones:
- ¿Cuál es el problema que dio lugar a la filosofía Platform Engineering?
Platform Engineering surgió porque la cosa se nos fue de las manos con las herramientas que las personas de desarrollo debían conocer para hacer su trabajo.
Por ejemplo, hoy no es ninguna locura que cualquier DevOps que se precie conozca, como mínimo, algún orquestador de contenedores (Kubernetes, Docker Swarm, ECS…), alguna plataforma basada en Kubernetes (Openshift, Rancher, Tanzu…) alguna herramienta de IaC (Terraform, CloudFormation, ARM, CDK…) y alguna herramienta de gestión de CICD (Jenkins, ArgoCD, Tekton GitLab CI…).
Los perfiles de desarrollo, en lugar de centrarse únicamente en desarrollar código, necesitan conocer y entender un stack de herramientas para poder desarrollar su trabajo, lo que supone un problema de carga que quita tiempo al equipo de desarrollo de centrarse en lo único que debería importarles: desarrollar. Justo para dar respuesta a este problema de carga cognitiva, se inició la filosofía Platform Engineering.
- ¿Cuál sería la solución ideal al problema de la carga cognitiva?
La solución ideal es tan simple como un cambio de mentalidad: si la infraestructura es demasiado compleja para que los equipos de desarrollo la dominen, ¿por qué no ofrecer un producto-navaja-suiza que les proporcione todo lo que necesiten? En este punto tenemos la respuesta al qué necesitamos, pero ¿cómo lo implementamos?
- ¿Cómo podemos ofrecer a los equipos de desarrollo el stack de herramientas que necesiten sin que les resulte una carga?
En este punto es donde la IDP hace su entrada estelar con la materialización de la idea (Platform Engineering) como un producto a disposición de los equipos.
La IDP es la capa de software que encapsula y abstrae toda la complejidad de las herramientas que usan los equipos de desarrollo. En lugar de interactuar con diez herramientas diferentes, interactúa solo con la interfaz simple de la IDP para lograr el mismo resultado de manera segura y estandarizada.
Hasta ahora, hemos pasado por los puntos que motivaron la aparición de la IDP como un concepto clave para la eficiencia a la hora de desarrollar, pero aún no hemos definido algunos puntos clave de la IDP.
Piezas clave de una IDP
Una IDP bien hecha tiene cuatro componentes que realmente importan.
Primero, un portal de desarrollador decente (normalmente Backstage) que hace de punto único de entrada. Si no lo conoces, te recomiendo que te pases por su página y eches un vistazo a las posibilidades que ofrece.
En segundo lugar, las herramientas que se ofrecen en la plataforma. Aquí se abre el debate: ¿herramientas de pago pero fiables (COTS) o herramientas open source? En este punto (y muy orientado en qué quieres para tu IDP) tienes que tomar decisiones como “¿pago por Datadog o mantengo Prometheus yo solo?” (Spoiler: no hay respuesta correcta. Tendrás que valorar tus necesidades y tomar una decisión al respecto).
En tercer lugar, muy en línea con las herramientas desplegadas se encuentra la cuestión de IaC (Infraestructura como Código). Todos los recursos y herramientas desplegados en la plataforma deben seguir los mismos principios de automatización y resiliencia (que no queremos sustos en caso de que haya que implementar un Disaster Recovery). Por este motivo, los recursos se despliegan generalmente usando módulos y plantillas de herramientas de IaC como Terraform o de gestión de configuración como Ansible.
Y por último, pero no menos importante, templates de CI/CD que hacen que el equipo de desarrollo solo tenga que preguntarse cosas como “¿qué necesito desplegar hoy: microservicios en contenedores o una función serverless?” y que la plataforma se encargue del resto.
¿En qué puede aportar valor una IDP a tu compañía?
Hasta aquí todo suena genial, ¿verdad?. Nos ha quedado claro que, al menos, existen ventajas en cuanto a la seguridad, calidad y descarga de los equipos de desarrollo. Pero ¿qué puede ofrecer una IDP que realmente aporte valor a una compañía?
- Entrega más y más rápido: o, si lo traducimos a la jerga de marketing, “reducción del time-to-market”. La IDP contiene un catálogo actualizado de los microservicios, librerías y componentes configurados desde la plataforma (scaffolding) lo que ayuda a que los equipos sean más eficientes.
- Reducción de la carga cognitiva: la verdad es que, si tuviese que elegir un punto clave para una IDP, sería este. Una IDP permite que los perfiles de desarrollo ya no necesiten conocer ciertas tecnologías, sino que la plataforma las pone a su disposición a través del “portal del desarrollador”. Además, los equipos de calidad y seguridad duermen tranquilos gracias a que una IDP ofrece configuraciones que garantizan despliegues seguros y alineados con la calidad esperada.
- Gobernanza por defecto: si eres un perfil de seguridad sabrás lo que es estar luchando de manera continua para que los equipos adopten las políticas de seguridad en sus desarrollos. Una IDP te libera de eso, ya que incluye de manera automática políticas de cumplimiento, seguridad y hardening que el equipo de operaciones configure.
- Un único punto de entrada para la gestión de los equipos y desarrollos: hasta el momento, hemos hablado de las bondades de una IDP para los equipos de desarrollo, pero una IDP puede incluir herramientas típicas de los equipos de operaciones en una única interfaz “bonita y para toda la familia”. ¡Se acabó eso de vivir mirando 20 pantallas distintas para ver qué se ha caído esta vez!
En resumen, las ventajas que se ofrecen a nivel de desarrollo son inmensas pero, ¿dónde quedan los equipos de operaciones en la foto de IDP? ¿Son simples proveedores?
El rol del equipo de operaciones en una IDP
No hemos parado de hablar de que una IDP está totalmente orientada a facilitar la vida a los perfiles de desarrollo pero ¿dónde quedan los equipos de operaciones en esta foto?
El equipo de operaciones o, si nos ceñimos al término acuñado para IDP, el equipo de Platform Engineering es crucial para que una IDP esté realmente orientada a las necesidades de los proyectos.
El trabajo de los equipos de Platform Engineering no se limita al mero despliegue de infraestructura y configuración de la plataforma, sino que va más allá, orientándose a la toma de requisitos de parte de los usuarios de la plataforma (las personas de desarrollo) para optimizarla de manera continua haciéndola más rápida, eficaz y fiable.
De hecho, una IDP a menudo contiene herramientas como Backstage (a la que hacía referencia al principio) que no solo sirven como frontend para los equipos de desarrollo, sino que también actúan como una herramienta central de observabilidad para los equipos de operaciones, agregando métricas, logs y el estado de salud de todos los servicios en un único lugar.
Si lo piensas, visto de esta manera, los equipos de Platform Engineering se acercan un poco a ese rol de desarrollo cuando en los proyectos necesitan entender y dar respuesta a los requisitos de sus clientes, aunando de nuevo los mundos de infraestructura y desarrollo como cuando hablábamos de DevOps al principio de este post.
Conclusiones
Después de años viendo a equipos brillantes perdiendo tiempo peleándose con YAML y permisos de Kubernetes, puedo decir que las IDPs no son una moda, sino que han llegado para quedarse.
Las IDPs son la evolución natural de DevOps cuando las organizaciones crecen. Eso sí, no intentes implementar una si tu equipo tiene menos de 50 personas desarrollando. Aunque las IDPs estén diseñadas para reducir la complejidad, una IDP mal diseñada puede añadir más aún a la complejidad que ya tengas.
Referencias
Si este post te ha resultado interesante, te recomiendo que eches un ojo a los de mis compañeros, que son unas auténticas rockstars de Platform Engineering:
Alba García
Curiosa desde siempre, me encanta aprender y saber cómo funcionan las cosas. He pasado por diversos roles que me han permitido aprender mucho, empezando por desarrollo de software, siguiendo como administradora de sistemas y finalmente trabajando con infraestructuras en cloud, centrándome sobre todo en Amazon Web Services y Google Cloud Platform.
Ver más contenido de Alba.Más contenido sobre esto.
Leer más.
¿Productos de calidad y sin bugs? Sigue estas 6 claves.
Evalúa la calidad de tu código con Sonarqube.
Podcast - Calidad del software.
¿Por qué el plan de calidad es la piedra filosofal?
Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.
Cuéntanos qué te parece.