Primeramente me gustaría aclarar en éste artículo que los términos que usaré relacionados a roles, tecnologías y el glosario en general referente a la materia, estará todo en inglés ahora y en el futuro, ya que creo que la mayor parte de nosotros los que trabajamos con tecnología de una u otra manera incorporamos el glosario de términos directamente del inglés porque es la fuente original. Aclarado éste punto pasemos al tema en cuestión.

Entonces, ¿qué es un Platform Engineer? – la definición ha cambiado con el tiempo, muchos se preguntan si es equivalente a un Software Engineer, a un SRE o a un Operations; la mejor manera de establecer las similitudes y diferencias es talvés establecer sus responsabilidades y compararlas con las de los otros roles.

Hablemos inicialmente del Software Engineer, su principal responsabilidad es la de crear aplicaciones de software, en otras palabras escribe el código de la aplicación y por lo tanto está muy relacionado al negocio, ya que la aplicación es la que el usuario final usará y por la que pagará al final.

Ahora, hablemos del Platform Engineer, éste también escribe código, pero no relacionado a la aplicación sino mas bien relacionado a la infraestructura vale decir todas las cosas que mi aplicación (o la aplicación escrita por los Software Engineers) necesita para funcionar y llegar al usuario final de la manera esperada, a eso llamamos infraestructura.

Si bien, el mismo código escrito por un Platform Engineer puede ser escrito por un Software Engineer, la clave está en el tiempo que ésta actividad toma, además del «Know How», o los conocimientos relacionados al cloud vendor específico (como Amazon Web Services por ejemplo), agreguemos además el conocimiento de las regulaciones a las que está sujeta la empresa o institución en su nicho específico de mercado, los estándares y políticas que debe cumplir el producto y la infraestructura para acreditar su calidad externamente. Todo ello implica una inversión de tiempo igual o mayor a la que el equipo de desarrollo invierte para crear la aplicación.

Más allá de la infraestructura específica para que la aplicación o aplicaciones corran, los Software Engineers también necesitan herramientas internas para probar el código que escriben, probar la integración con otros subsistemas o herramientas de terceros; también necesitan la infraestructura suficiente para que su código se convierta en un artefacto manejable dentro de la propia infrastructura. Los Platform Engineers también estan encargados de levantar la infraestructura suficiente para que los Software Engineers puedan hacer su trabajo apropiadamente, por lo tanto los Software Engineers se convertirían en clientes de los Platform Engineers que crearían la plataforma de acuerdo a las especificaciones provistas por los primeros.

Si bien todas estas actividades se han llevado a cabo a lo largo del tiempo ya sea parte por el equipo de operaciones, otra parte por el equipo de desarrollo, o por equipos de «SREs/DevOps» pero de manera aislada y descoordinada, en tareas individuales, sin una planificación por detrás; lo que propone Platform Engineering es poner el foco en todo lo que significa crear una unica plataforma, aplicar todo el proceso de ingeniería para diseñar una plataforma integrada que todos los equipos internos puedan usar, identificar sus necesidades y transformarlas en requerimientos, los cuales se implementarán en la plataforma, al mismo tiempo se integrarán en la misma plataforma otros conceptos y requerimientos que el enterprise engineering pide cubrir como Observability, manejo del Software Supply Chain y seguridad, usando un unico estándar para toda la organización.

Hay que resaltar además que aplicar Platform Engineering significa olvidarnos de todos los limitantes que podríamos imponer a un equipo de operaciones o SREs debido al tiempo que tomaría implementar la creación de un dashboard completo desarrollado en nodejs y/o usando otras tecnologías ya que la confianza del equipo de management en los skills de desarrollo de éste equipo de operaciones no está garantizada. En un equipo de Platform Engineering, los skills de desarrollo deben ser iguales o por lo menos cercanos que los que tienen los Software Engineers.

Desarrollar una platforma, como hemos mencionado previamente implica diseño, planificación y mucha comunicación con los clientes internos, el ciclo de desarrollo de la plataforma debe ser tomado en cuenta de la misma manera en que se toma en cuenta el ciclo de desarrollo de la aplicación de software, en tiempos y en presupuesto, por lo tanto el equipo de management debe estar implicado en su proceso de la misma manera en que lo está para el desarrollo de la aplicación.

Al introducir el desarrollo de la plataforma formalmente al ciclo de desarrollo del proyecto, estamos asegurando la implementación de las prácticas de DevOps en la organización de una manera formal y estructurada, dándole el valor que corresponde y asegurando el éxito de su consecusión ya lo que implementará un equipo especializado y no será sólo un ideal abstracto como ha sido hasta ahora.

A menudo cuando las personas escuchan el término DevOps no saben lo que es, solo tienen una vaga idea, y no las culpo, la definición es muy ambigüa para alguien que no tiene experiencia en el área y menos aún en el manejo de proyectos de desarrollo de software (en la nube). Lamentablemente la mayor parte de la literatura hace una mezcla malsana de conceptos, revuelve conocimientos de infraestructura y operaciones con prácticas de desarrollo y una pisca de filosofía, de ahí que la mayoría piensa que hacer infraestructura/IT es hacer, o peor aún, que esto es «ser» DevOps.

La verdad es que el concepto detrás de DevOps es sólo filosofía, una base o marco para extender Ágil a la infraestructura, haciéndola parte del proceso de desarrollo, algo que las miríadas de cursos de desarrollo Ágil olvidaron y a larga impacta al rendimiento del negocio, por la baja calidad de sus resultados.

Este cambio de mentalidad indica que todos los equipos, incluidos los de management, tienen que compartir responsabilidades tanto técnicas como administrativas, la información debe democratizarse por lo tanto todos los procesos han de integrarse en un sólo flujo al cual todos contribuyen, podemos llamarlo un «pipeline» común; mientras menos situaciones repetitivas existan mejor, por lo tanto la automatización de procesos (ojo digo procesos, no sólo tareas) es crucial.

Si aumentamos un poco el lente y observamos los roles propios de un proyecto de desarrollo de software, no encontramos lógicamente hueco para un IT con capacidades organizacionales y de desarrollo, y es que no debe existir porque se le relegará a su ámbito primario que es el de IT, y es lo que comunmente pasa; todo ingeniero que desarrolle aplicaciones y/o infrastructura debe tener una base sólida en programación y conceptos claros de desarrollo de software, luego obviamente concentrar su energia en lo específico de su trabajo.

Gracias a que los conceptos evolucionan independientemente de las organizaciones, de la misma manera el concepto y la implementación de aquello que mal llamamos DevOps también está evolucionando en algo tangible y coherente hablando en términos de ingeniería de proyectos. Desde hace un tiempo atrás la gente dedicada a divulgar temas referentes a nuestra área, incluyó entre sus tópicos charlas acerca de las Plataformas de Desarrollo Internas o «IDP» por sus siglas en inglés; el contenido de éstas charlas hablan acerca de que los ingenieros dedicados a la infrastructura ya sean DevOps o SREs, etc., deben concentrar sus esfuerzos en desarrollar una plataforma de trabajo para los otros equipos, ésto significa dotar de herramientas integradas de fácil acceso y uso a los usuarios internos como desarrolladores de lo suficiente para que hagan su trabajo de manera más eficiente. Ésto implica integrar otros sistemas tanto internos como de terceros y brindar un producto a éstos desarrolladores para que completen sus tareas sin demasiado trámite, por ejemplo pipelines de ensamblaje y despliegue de las aplicaciones en ambientes temporales de desarrollo para prueba y validación. Los enlaces que pongo a continuación hablan acerca de qué es una plataforma interna de desarrollo, quiénes la utilizan y del porqué deben construirse:

Estando ésta tendencia en boga, hablamos de 1 o 2 años atrás, la cosa no se quedó quieta y evolucionó a algo mucho más concreto, más estructurado y mejor, hablo de la ingeniería de plataforma o «Platform Engineering» en inglés, que expresa realmente lo que un ingeniero que aplica DevOps al máximo debe construir en un proyecto de desarrollo de software, y asigna el rol correcto al nuevamente mal llamado DevOps como un desarrollador de infrastructura o «Infrastructure Developer» o «Platform Developer» con sus hábilidades bien definidas.

No me extenderé más hablando de la ingeniería de plataformas porque lo haré en varios otros posts, ya que requiere minuciosidad y especificidad.

Debo decir que estoy muy emocionado al respecto, es una forma de ver las cosas más clara y diluirá la sombra que se cierne sobre todos aquellos que trabajamos en la plataforma de desarrollo de nuestros proyectos.