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.

Éste post complementa a Cómo clonar ‘informalmente’ una imágen de disco de VirtualBox, en el cuál se me habían presentado dos problemas muy molestosos; el de no poder clonar una imágen (disco duro de VBox) usando su herramienta de clonado y la otra la razón desconocida por la cuál net.eth0 no levantaba el servicio. Gracias a un poco de lectura en los foros de VBox y a la gran ayuda de dos usuarios de #gentoo-es (Chinchorro y ferdy) pude llegar a la solución de ambos problemas.

1. Para clonar una imágen de VirtualBox usando su herramienta (VBoxManage) es obligatorio especificar la ruta completa del archivo fuente y del destino (vaya tontera) sólo si estuviesen fuera del directorio por defecto fijado en Vbox (normalmente ~/.VirtualBox/VDI). Sin ésto dará un error incomprensible. Por ejemplo:
   

   #VBoxManage clonevdi /media/datos/original.vdi /media/trabajo/copia.vdi

2. Si el disco a clonar tuviese información de estado (Snapshots) primero es necesario ‘mezclar’ la información de estado con el disco copia.
   • Si la máquina virtual está corriendo, apagarla.
   • En la ventana del administrador de VirtualBox seleccionar la VM deseada y hacer clic en la etiqueta Instantáneas (Snapshots)
   • Si desea incluir el estado actual, hágalo seleccionando Estado Actual (Current State) y luego ejecute el comando Tomar instantánea (Take Snapshot).
   • Elija la instantánea que desee incluir en ls nueva VM y ejecute Descartar Estado e Instantánea actual (Discard Snapshot). Ésto incluye el archivo de la instantánea dentro de su archivo VDI padre (archivo de instantánea o disco base).
   • Repetir el paso anterior hasta que la instantánea más antígua sea incluida en el VDI base.
3. Referente a net.eth0 tal parece que UDEV crea un conjunto de reglas para cada dispositivo al detectarlos, entonces, la dirección MAC de la tarjeta virtual de la máquina virtual original queda registrada en las reglas, al clonarla obviamente VBox le asigna otra MAC a la tarjeta de red, por lo tanto no coincide con la almacenada en las reglas establecidas por UDEV de ahí que tiene sentido que levante el servicio cambiando el nombre del script a net.eth{1, 2 , 3,…}, la tomará como otra tarjeta ‘habil’ y levantará correctamente. Para reparar éste inconveniente no hace falta nada más que editar las reglas, borrar la información de la tarjeta de red y reiniciar; UDEV la detectará nuevamente y voila! red por net.eth0 nuevamente.

1. sudo vim /etc/udev/rules.d/70-persistent-net.rules
2. Borrar la línea parecida a ésta:  SUBSYSTEM==»net», DRIVERS==»?*», ATTR{address}==»00:15:58:15:0f:75″, NAME=»eth0″
3. Guardar y reboot.

Otra cosa interesante que no había leído son los Snapshots… ¿qué son?, pues un Snapshot toma una ‘imágen’ del estado del sistema virtal en ese preciso momento, es posible regresar a un estado anterior del sistema simplemente borrando la imágen del estado actual (current snapshot). Cuando se crea un Snapshot los cambios realizados en el sistema se acumulan en el archivo de Snapshot actual, los archivos de estado antígüos y archivos de imágen de disco están en modo de sólo lectura. Si no exísten archivos de estado (snapshots) el archivo de imágen del disco acumula los cambios como lo hace un disco normal.

Bueno por ahora ya está 🙂 sigue configurar la red e instalar servidores y clientes, veamos como nos va.

Ok… año nuevo, objetivos nuevos. Luego de probar VirtualBox gracias a sugerencia de David y Boris, y leyendo un poco más de documentación en Internet y algunos documentos es probable que cambiemos de rumbo nuestro actual desarrollo de la Intranet.

Para empezar le he dado un gran vistazo a LDAP (Lightweight Directory Access Protocol – Protocolo Ligero de Acceso a Directorios) que exíste desde hace mucho tiempo ya, entonces si exíste una base de datos jerárquica que nos brinda todos los datos necesarios de los usuarios, nos permita integrar sistemas con una sóla llave de acceso y además integrar plataformas distintas… ¿para qué programar una base de datos nueva que no tiene ni la mitad de la funcionalidad que ésto ofrece?

Debo pedir disculpas por mi ignorancia en éste rumbo, es la primera vez que tengo la oportunidad de probar sistemas en red ya que hasta hace poco no creía que una máquina virtual podría realizar el trabajo completamente, pero, he estado completamente equivocado (vamos que tonto) además LDAP <-> Active Directory era la propuesta más lógica antes de proponer un sistema diseñado completamente de cero. Todos las herramientas  que mencionaré de principio son sólo supuestas, a medida que vaya experimentando sabré cuales son las correctas y cómo organizarlas.

Para la programación:

• Aplicaciones: Ruby On Rails + MySQL.
• Integración de capas: Ruby-Net-LDAP.
• Control de versiones: Git.

Para la prueba, 4 máquinas virtuales conectadas en una LAN simple o usando OpenVPN:

• Gentoo Linux + LDAP servidor + Kerberos + Mongrel o Apache + Aplicaciones [Rails].
• Gentoo Linux + X cliente.
• Windows 2003 Server + controlador de dominio + Active Directory.
• Windows XP cliente.

Principales inconvenientes de momento:

• Hardware, mi pentium D no creo que soporte la carga de las 4 máquinas virtuales así que necesito adquirir una Quad Core lo más pronto posible.
• Tiempo de instalación y configuración de servidores  y clientes.

Esta parte es sólo la de infraestructura, el desarrollo de las aplicaciones tiene iteraciones independientes y tiempos distintos, ya se calcularán en su momento.