[22/04/2021] A medida que la computación en la nube, la contenedorización, las operaciones de desarrollo y las arquitecturas de microservicios se han establecido como los bloques de construcción para el desarrollo de aplicaciones modernas, la necesidad de una forma sencilla de gestionar esos recursos para los equipos de desarrolladores de software internos se ha vuelto cada vez más importante.
En muchas organizaciones de ingeniería de élite -pensemos en Google, Netflix y Amazon- las plataformas internas de desarrollo (IDP) alivian la carga de operaciones de sus equipos de devops, al mismo tiempo que separan las decisiones innecesarias para los desarrolladores de software.
Al igual que el ex presidente Barack Obama solo vestía trajes grises o azules para aliviar su carga cognitiva, los desarrolladores que trabajan con una buena plataforma interna de desarrollo pueden preocuparse solo de su código, de un repositorio Git y de empujar a una plataforma que se encarga de la infraestructura subyacente.
¿Qué es una plataforma interna de desarrollo (IDP)?
Las plataformas internas de desarrollo son como los copos de nieve, ya que no hay dos iguales. Cada plataforma varía de una organización a otra en función de su pila, su cultura, su base de código y su conjunto de herramientas, lo que hace que encontrar una definición consensuada sea algo difícil.
Como escribió Evan Bottcher, jefe de ingeniería de ThoughtWorks, "parece que las palabras son difíciles. 'Plataforma' es el término más ambiguo que podríamos utilizar para un enfoque que es súper importante para aumentar la velocidad de entrega y la eficiencia a escala".
La propia definición de Bottcher -aunque prefiere el término "plataforma digital" que "plataforma interna"- es "una base de APIs de autoservicio, herramientas, servicios, conocimientos y apoyo que se organizan como un producto interno convincente".
Para Camille Fournier, jefa de ingeniería de plataformas del fondo de cobertura Two Sigma, todo se reduce al lado del software de la infraestructura. "Las plataformas informáticas como Kubernetes, los sistemas de almacenamiento, las herramientas de desarrollo de software y los marcos de trabajo para los servicios forman parte del mandato", escribió en una publicación del blog en 2020.
Una buena plataforma interna de desarrollo debe separar las decisiones de infraestructura, permitir la construcción de entornos de autoservicio, integrarse con los procesos existentes de integración y entrega continua (CI/CD) y de despliegue, y asignar controles de acceso basados en roles, todo ello sin que un desarrollador tenga que aprender YAML.
"Una plataforma interna de desarrollo eficaz compartimenta la complejidad. Cada persona tiene su propia área de complejidad en la que es experta y que todos los demás pueden ignorar sin problema", escribió Chris Stephenson, director de tecnología de Humanitec, que anteriormente construyó plataformas internas en Google, en una publicación del blog.
Stephen O'Grady, analista principal de Redmonk, dice que en el último año ha visto un "claro apetito por tomar las piezas necesarias en una cadena de herramientas y ponerlas juntas en una plataforma donde el desarrollador puede venir y escribir una aplicación, y toda la complejidad subyacente es separada”.
Las ventajas de una plataforma interna de desarrollo
El último informe State of Devops de Puppet y CircleCI identificó las plataformas internas de autoservicio como uno de los tres elementos clave que diferencian a las organizaciones de desarrollo empresarial maduras de sus pares, junto con la gestión de cambios automatizada y la seguridad integrada.
Una plataforma interna en pleno funcionamiento debería aliviar la carga de complejidad de los sistemas de software modernos, acelerando los ciclos de despliegue de software y creando versiones más estables, así como mejorando la felicidad y la productividad de los desarrolladores, todo ello mientras reduce la carga operativa.
¿Quién necesita una plataforma interna de desarrollo?
Una plataforma interna de desarrollado tiene dos grupos de usuarios principales, cada uno con su propia visión: el equipo de plataforma/operaciones/devops y el equipo de desarrollo.
El equipo de plataforma/operaciones/devops configura la plataforma, crea ganchos de API en la infraestructura y las herramientas necesarias, y establece barreras de acceso y cumplimiento. La plataforma en sí suele ser configurada por un propietario de producto individual o, en las organizaciones más grandes, por un equipo interno dedicado a la plataforma.
En las organizaciones con mejores resultados, ese equipo debe actuar como propietario del producto, colaborando con los desarrolladores para recopilar los requisitos, aliviar los puntos conflictivos comunes e iterar la plataforma según sea necesario, todo ello de acuerdo con un conjunto de métricas clave para el usuario. También deben ser hábiles en la evangelización de la plataforma a nivel interno.
"Esa mentalidad de producto es clave para el éxito de una plataforma interna", señala James Whinn, CTO de Expert Thinking, una empresa de consultoría en la nube. "Sin ella, los equipos se centrarán en cosas porque son geniales y no necesariamente en lo que aportará valor al negocio".
Los desarrolladores obtienen entonces una versión básica de la plataforma que debería separar cualquier decisión de infraestructura para que puedan centrarse en el despliegue.
"Tiene que ser flexible para el equipo de devops, pero inflexible para los desarrolladores", anota Kaspar von Grünberg, el CEO de Humanitec, una startup fundada en el 2018 para ayudar a las empresas a establecer una plataforma interna. "Toda la capacidad de personalización debería residir en el equipo de devops, y crear caminos dorados para los desarrolladores que no quieren pensar en la infraestructura subyacente".
Pero al hacer eso, ¿no estamos separando de nuevo a dev (desarrollo) de ops (operaciones)?
Nigel Kersten, field CTO de Puppet, afirma que es fundamental que los equipos responsables de la salud operativa de la plataforma estén entrelazados con las personas que construyen soluciones sobre ella y que, idealmente, sean el mismo grupo. "Si los separa, acaba en el viejo mundo del desarrollo frente a las operaciones", afirma.
IDP vs. PaaS
A diferencia de una plataforma como servicio (PaaS), en la que el proveedor suele dictar cómo debe trabajar un desarrollador, una plataforma interna de desarrollo se construye sobre las herramientas y los procesos con los que los equipos de desarrolladores ya están familiarizados, pero con un mayor nivel de abstracción y consistencia.
Como tuiteó la tecnóloga de Google, Kelsey Hightower, en el 2017, "estoy convencida de que la mayoría de las personas que gestionan infraestructuras solo quieren una PaaS. El único requisito: tiene que ser construida por ellos".
Muchas organizaciones más pequeñas recurren a una PaaS para que su equipo de ingeniería se ponga en marcha rápidamente -con opciones populares como Heroku, que fue adquirida por Salesforce en el 2010, OpenShift, Cloud Foundry o las propias herramientas de los grandes proveedores de nubes públicas-, pero a menudo encuentran que estos carecen de la flexibilidad necesaria para escalar realmente.
Optar por el enfoque IDP conlleva el riesgo de que los ingenieros busquen reinventar la rueda cuando se les da la oportunidad de construir su propia plataforma; o peor aún, que intenten funcionar como Amazon o Google, lo que termina siendo una receta para la distracción y el desastre.
"Incluso cuando esas grandes empresas proporcionan sus soluciones como software de código abierto, a menudo codifican todo tipo de suposiciones sobre el ecosistema circundante de productos disponibles y la cultura y las necesidades de los ingenieros que utilizan el producto que pueden no funcionar bien en su empresa", escribió Fournier. "No es una buena gestión de productos decir: 'Google lo hace, por lo tanto, nosotros deberíamos'".
Kersten, de Puppet, un ex-Google SRE, ve las cosas de manera similar: "Hemos visto numerosas organizaciones grandes intentar adoptar el modelo de pequeños equipos autónomos, que funciona bien en Amazon, porque tienen desarrolladores enormemente capacitados; pero todo allí se construye como un servicio y no están tan regulados o limitados por el software heredado. Sin embargo, [para otras organizaciones] esto crea caos y deuda organizacional".
Por dónde empezar con una plataforma interna de desarrollo
Pasar de un proceso de despliegue monolítico a la entrega continua es un cambio cultural importante que no debe subestimarse. "Creo que en realidad no es tan difícil empezar una organización pequeña con una mentalidad de 'usted lo construye, usted lo dirige', pero hacer la transición requiere valor y continuidad de visión", escribió Bottcher.
Kersten ha visto demasiadas empresas que tratan de renombrar sus procesos existentes como una plataforma interna porque es la última palabra de moda. "Uno de los mayores anti patrones que hemos visto es cambiar el nombre de TI central por el de un equipo de plataforma, pero sin realizar los cambios técnicos o culturales necesarios. A medida que el término gana popularidad, esperamos ver más de esto", anota.
El cambio a una plataforma interna de desarrollo o la decisión de crear una desde cero también puede ser algo difícil de vender a una organización más amplia, desde convencer a la dirección de hacer un cambio tan grande hasta hacer que los desarrolladores se sientan cómodos con una nueva forma de trabajar sobre la que no tienen un control total.
"Tener la capacidad de entender a los usuarios y realizar esos cambios culturales es el mayor problema", afirma Kersten.
Su consejo y el de muchos otros expertos: empezar poco a poco. Whinn, de Expert Thinking, aconseja "crear un centro de excelencia e identificar los casos de uso en los que la plataforma podría ser desarrollada para marcar una diferencia real". Incluso la creación de un entorno de pruebas para una sola aplicación y la creación de las APIs necesarias puede ayudar al equipo de la plataforma a tomar el camino correcto.
Una forma de pensar en esto es como la plataforma viable más delgada o "ser explícito sobre qué de ésta es importante y asegurar que no sea más grande de lo necesario", anota Matthew Skelton, uno de los autores de Team Topologies, durante la Cumbre Devops Enterprise en 2019. "Tenemos que asegurarnos de que lo que construyamos sea convincente de usar, tenga una fuerte experiencia de desarrollador y trate a los usuarios como clientes con los que tenemos que hablar para poder entender sus necesidades y satisfacerlas".
Von Grünberg, de Humanitec, dijo: "Es lo mismo si construye o compra: hay que empezar por la base. Solemos ver que las organizaciones toman un pequeño grupo de sus mejores ingenieros y les piden que sean el pegamento de las cadenas de herramientas segregadas. Luego empiezan a centralizar todo esto en torno a una API común con la que los equipos puedan trabajar y aportar estructura a ese mar de herramientas desestructuradas".
Basado en el artículo de Scott Carey (InfoWorld) y editado por CIO Perú