Conecta con nosotros

Noticias

Cómo Google ha conseguido gestionar su flota de equipos con un único ingeniero

Publicado el

Alphabet, matriz de Google, mejora sus ingresos un 41%

Basta pasearse por Silicon Valley para descubrir que Apple y sus productos son los dominadores absolutos en el mundo tecnológico. En pocas manos veremos smartphones que no sean iPhone o portátiles que no sean Macs. Tanto en el sector doméstico pero también en el corporativo (gracias a fenómenos como BYOD y más aún con el teletrabajo), la sombra de los de Cupertino es alargada.

Y sin embargo, hay empresas, que por su propia filosofía y la forma en la que entienden la informática, han sido y siguen siendo si no refractarias, al menos esquivas a los productos de Apple. Como os podéis imaginar, Google es una de esas firmas. Y no solo porque los desarrolladores del buscador de Internet más famoso del mundo también sean los desarrolladores de Android, sino porque incluso en el escritorio de sus empleados siempre han empujado hacia opciones alternativas.

En este sentido, mucho antes de que Google desarrollase su propio sistema operativo de escritorio, Chromebook OS, la compañía utilizaba su propia distribución de Linux: gLinux.Incluso hoy en día, cuando los portátiles de los de MountainView parecen estar «arrasando» en el sector educativo, en Google siguen confiando en una distribución que, como nos cuentan en ComputerWorld, convive en las oficinas de la multinacional con otros equipos basados en Windows, Mac y, por supuesto, Chrome OS.

En realidad, gLinux no es la primera distribución que utilizaron en la multinacional. Durante más de una década, la compañía apostó por un fork de Ubuntu al que bautizó como Goobuntu, que estaba basado en las versiones LTS (long term support) del sistema operativo auspiciado por Canonical.

En 2018 sin embargo, Google decidió abandonar Goobuntu y trasladó sus esfuerzos al desarrollo de un nuevo fork basado en Debian al que bautizó como gLinux. Como explican desde la empresa, el hecho de Canonical lanzase versiones LTS de su Ubuntu cada dos años, «significaba que teníamos que actualizar más de 100.000 dispositivos a la nueva versión del. S.O cada 24 meses, lo cual se había convertido en un absoluto quebradero de cabeza para el departamento de sistemas».

A esto había que añadir que con cada actualización era necesario personalizar los sistemas de los ingenieros y corregir cientos de bugs que se reportaban a nivel interno…un proceso que solía demorarse durante un año completo y que solo dejaba a la empresa un año adicional de testeo antes de comenzar todo de nuevo.

De modo que cuando la multinacional decidió apostar por Debian, lo hizo además con una aproximación distinta. No solo estaba apostaría por una distribución cuyo soporte era más duradero, sino que además lo haría en un modo rolling release: GLinux Rolling Debian Testing (Rodete). La idea era que los usuarios recibieran los últimos parches de seguridad y actualizaciones a medida que se creasen y estuviesen listos para producción, en lugar de tener que esperar a una futura y costosa actualización general del sistema completo. Esta aproximación es la misma que se encuentra en otras distribuciones como Arch Linux y openSUSE Tumbleweed. La diferencia en este caso es que además eran los propios desarrolladores que trabajan en Google los que podían publicar directamente estas actualizaciones, sin tener que esperar necesariamente al trabajo de los chicos de Debian.

Su objetivo era olvidarse por completo de ese ciclo de actualizaciones cada dos años y pasar a un modelo de integración continua/despliegue continuo que tan bien funciona en entornos cloud y que permite revertir fácilmente cualquier cambio si algo sale mal.

Para que todo esto funcionase de forma sencilla, Google creó un nuevo sistema de flujo de trabajo: Sieve. Cada vez que Sieve detecta una nueva versión de un paquete de Debian, inicia una nueva build. Estos paquetes se construyen en grupos de paquetes, ya que a menudo los paquetes separados deben actualizarse juntos. Una vez que se ha construido todo el grupo, Google ejecuta un conjunto de pruebas virtualizadas para garantizar que no se rompan los componentes principales ni los flujos de trabajo de los desarrolladores. A continuación, cada grupo se prueba por separado con una instalación completa del sistema, el arranque y la ejecución del conjunto de pruebas local. Todo este proceso no se demora más de una hora.

Una vez hecho esto, todos los paquetes nuevos se fusionan con el grupo de paquetes de gLinux más reciente. Entonces, cuando Google decide que es el momento de ponerlo en producción, se hace una instantánea de ese grupo y se lanza a distintos grupos usuarios de forma incremental, asegurándose en feedbacks instantáneos que todo esta funcionando como debería antes de lanzar la imagen a un nuevo grupo de usuarios.

Gracias a este sistema, todo el equipo de desarrollo de gLinux ocupa el trabajo de un pequeño número de ingenieros (uno por turno) que ya no necesitan preparar grandes actualizaciones de toda la flota de equipos: desaparecen los lanzamientos alpha, beta, RC, etc. y todo se hace de forma transparente y en una única etapa para el usuario final.

Debido además a este sistema de actualizaciones continuas, Google puede parchear cualquier brecha de seguridad de forma inmediata sin comprometer la estabilidad del sistema y sin tener que re-examinar todo el S.O en cada actualización.

Por supuesto, la compañía sigue necesitando personal dedicado para la gestión de sus dispositivos móviles y los equipos que cuentan con otros S.O…pero en el caso del que es su sistema operativo principal, la batalla está ganada.

Periodista tecnológico con más de una década de experiencia en el sector. Editor de MuyComputerPro y coordinador de MuySeguridad, la publicación de seguridad informática de referencia.

Lo más leído