top of page
Foto del escritorLuispe Toloy

IDP - ¿Por qué, cuándo y cómo?

Actualizado: 28 nov

Para comenzar me gustaría hablar de la sigla IDP.


Hace unos años, que fue cuando comencé a trabajar a tiempo completo en el “área de infraestructura”, hablábamos de Internal Developer Platform y esto se refiere a la infraestructura y el conjunto de herramientas que automatizan y facilitan el desarrollo, deploy y operación de los servicios y los recursos subyacentes, tiene un enfoque en la automatización y la integración de todas las capas que un equipo de desarrollo de producto necesita, incluye componentes de CI/CD, IaC, orquestación de contenedores, observabilidad, etc.


Con los años comenzamos a hablar de Internal Developer Portal, que es una evolución de una Internal Developer Platform.


Según Gartner, “Para 2026, el 80% de las grandes organizaciones de ingeniería de software establecerán equipos de ingeniería de plataformas como proveedores internos de servicios reutilizables, componentes y herramientas para la entrega de aplicaciones. La ingeniería de plataformas resolverá en última instancia el problema central de la cooperación entre los desarrolladores de software y los operadores.”


Con Internal Developer Portal comenzamos a tener un enfoque de producto en lo que a la plataforma se refiere, puede incluir o no una UI y facilita la tareas de autoservicio con flujos de operación pensados como producto y basado en las necesidades internas de desarrollo y seguridad que necesite la empresa.


Para no aburrir me gustaría que te quedes con los siguientes conceptos:

  • Autoservicio

  • Estandarización

  • Seguridad

  • Reducir la carga cognitiva

  • Plataforma como producto


¿Por qué un IDP?

Hecha la brevísima introducción hablemos del porque.


Akua y como es de público conocimiento es “La plataforma de procesamiento adquirente para todos los rieles de pago en Latam” y desarrollar servicios en este contexto requiere de un cuidado especial en la seguridad sin perder la velocidad en el desarrollo y deploy y teniendo autonomía para la operación/gestión de los servicios y recursos asociados.


Con este contexto formamos el equipo de Plataforma en Akua para desarrollar el IDP, con un desafío agresivo pero motivante por delante, desarrollar el IDP desde el minuto cero para que el equipo de desarrollo de producto pueda deployar y gestionar microservicios y los recursos asociados, todo ello sin perder de vista los conceptos que mencioné anteriormente, Autoservicio, Estandarización, Seguridad, Reducir la carga cognitiva, Plataforma como producto.


¿Fue un capricho? no, hace tiempo conozco a Juanjo y sabemos por experiencia compartida que tener un IDP en una empresa que necesita ser PCI compliance, seguir los más altos niveles de seguridad con una disponibilidad y escalabilidad alta es un beneficio muy muy valioso.


En Akua bien podríamos haber creado todo a mano, sin perseguir estándares, pero es pan para hoy y hambre para mañana, pensemos que por algún motivo la industria creó el concepto de IaC (Infrastructure as Code https://www.redhat.com/en/topics/automation/what-is-infrastructure-as-code-iac), no por capricho nomás, es una necesidad que surgió casi naturalmente por las implicancias y desafíos en el manejo de la infraestructura.


¿Cuándo un IDP?

Algo anticipé pero lo hicimos desde el minuto cero y fue desafiante, muy desafiante pensar en:

  • ¿Qué herramientas de IaC vamos a usar?

  • ¿Qué vamos a usar para CI/CD?

  • ¿Cómo hacemos para que nuestro IDP no se transforme en un monstruo y sea simple y sencillo de gestionar y escalar?

  • ¿Dónde van a correr los servicios de Akua?

  • ¿Cómo somos seguros por default?


Y puede aparecer una pregunta rondando en el aire, ¿por qué desde una etapa tan temprana?.


Akua necesita tener una velocidad de desarrollo Estandarizada y Segura y mantenerla en el tiempo, y eso sin un IDP es muy complicado de lograr o no se puede, se podría “salir rápido” sin contar con un IDP, pero te aseguro que más temprano que tarde todo se vuelve un caos, para el producto y para la gestión y mantenimiento de la infraestructura y el software.


¿Cómo?

Abordemos el último punto, el cómo.


No hay recetas, perdón, pero si venias a buscar una, esta publicación no es para vos 😂

Lo que sí te voy a contar es lo que al día de la fecha ofrece nuestro IDP.


Peeeero antes de hablar lo que ofrece te voy a contar que usamos para ofrecer lo que ofrecemos:

  • Como herramienta de IaC usamos Pulumi con Typescript.

  • Para CI/CD usamos Gitlab con runners privados para interactuar con nuestro proveedor de nube.

  • Hablando de proveedor de nube usamos AWS (Amazon Web Services)

  • Para la configuración de aplicaciones usamos Helm y desarrollamos un chart que utilizan todos los microservicios.

  • Donde corren nuestras aplicaciones? en kubernetes

  • Para Observabilidad usamos NewRelic



Ok luispi, ¿y entonces?


Anteriormente hable de carga cognitiva y el deseo de que nuestro IDP se mantenga simple y mantenible en el tiempo.

Bueno para cumplir con ese objetivo desarrollamos una librería interna (como comenté con Pulumi y Typescript) que contiene la lógica empresarial y de seguridad para el alta, baja y modificación de los recursos de la plataforma.


Para evitar que nuestro equipo de desarrolladores de producto tengan que aprender una herramienta de IaC sumado a que desde el equipo de Plataforma queremos tener la libertad de poder cambiar de rumbo si es que lo necesitamos, la gestión se hace desde Port (https://www.getport.io/), donde cada equipo responsable de la aplicación puede crear, actualizar y eliminar recursos con un simple formulario, ¿no me crees? te dejo un gif

Cuando se sincroniza la aplicación, debajo del capó ejecutamos un runner privado de Gitlab en aws y apoyándonos en nuestra herramienta de IaC (Pulumi) validamos el estado de lo que se quiere desplegar con lo que existe en la nube.


Debajo de este “simple flujo” hay muchas horas de diseño y desarrollo que tuvimos y tenemos con el equipo de Plataforma, a la fecha de escribir esta publicación desde nuestro IDP se puede gestionar:

  • Como comenté microservicios en Kubernetes y esto incluye: deployment, service account, service, ingress, stateful set, cron job, HPA, light cache (?)

  • SQS

  • SNS

  • S3

  • DynamoDB

  • RDS aurora

  • IAM Role, Security Group, Secret y ECR para la aplicación/microservicio

  • Múltiples environments

  • Single y multi tenant


Todos estos recursos teniendo en cuenta optimización de costos y seguridad.


Antes de continuar quiero hablar del como de los últimos dos ítems de la lista, Múltiples environments, Single y multi tenant.


Múltiples environments

Cuando hablamos de múltiples environments nos referimos a que una aplicación pueda ejecutarse en diferentes entornos en el ciclo de vida hasta llegar a producción.


El enfoque y solución que dimos desde nuestro IDP en Akua es abstraer la creación de recursos entorno por entorno, fuimos a un concepto más abstracto donde se crea o maqueta que recursos va a necesitar el servicio para resolver un problema de negocio y luego poder seleccionar en qué entorno se quiere sincronizar los recursos previamente definidos pudiendo elegir entre un entorno de pruebas y productivo.

a continuación un breve gif:


Single y multi tenants

Nuestra Plataforma y nuestro portal están diseñados y desarrollados para soportar single/multi tenant, y no solo a nivel software de producto, sino también en toda la pila tecnológica que tiene nuestra plataforma, y con esto me refiero a:

  • Cargas de trabajo de las aplicaciones

  • Recursos de nuestro cloud provider

  • Observabilidad (tracing, logs, metrics)

  • etc


Y esta funcionalidad fue desarrollada respetando unos de los mantras que se deben perseguir a la hora de crear un IPD Reducir la carga cognitiva, ¿por qué?. Nuestro equipo de tecnología de producto puede configurar si la aplicación va a correr en 1..n tenants y a la hora de deployar puede seleccionar entorno y tenant, el resto se encarga nuestro IDP de entender cómo, cuándo y dónde configurar todos los recursos subyacentes 😎.


Conclusiones

A lo largo de la publicación intentamos abordar de forma más o menos abstracta todo lo que rodea un IDP, desde que significan las siglas hasta como un equipo de Plataforma y un IDP pueden impactar en el negocio de tu empresa, en nuestro caso en Akua 🫶🏼.


Algunas cosas que me gustaría sintetizar lo que puede brindarte un IDP y son:

 

💸 Reducción de costos: Al optimizar la infraestructura y automatizar los procesos, las organizaciones pueden lograr ahorros significativos en costos operativos y de mantenimiento.


⚙️ Mayor agilidad y velocidad en la entrega: La implementación de una plataforma robusta y flexible permite acelerar el tiempo de comercialización de nuevas aplicaciones y funcionalidades, brindando una ventaja competitiva en un mercado en constante evolución.


📈 Mejora en la escalabilidad y disponibilidad: La arquitectura basada en microservicios y la orquestación de contenedores permiten escalar de forma eficiente los recursos de la plataforma, garantizando una alta disponibilidad y rendimiento.


🛡 Mejor seguridad y cumplimiento normativo: La aplicación de prácticas de seguridad y la utilización de herramientas avanzadas permiten proteger los datos sensibles y cumplir con los estándares de seguridad y privacidad.

 

¿Las decisiones son unilaterales? Claro que no, para construir un IDP si no se escuchan las necesidades “de los clientes” todo se puede hacer cuesta arriba.


Queda mucho camino por recorrer, pero estamos muy orgullosos de lo que construimos estamos construyendo y vamos a construir en nuestro IDP.


Hasta la próxima 👋🏼

168 visualizaciones0 comentarios

Comments


bottom of page