1. Introducción a la Plataforma de Microservicios de Lyft
Hoy, quería compartir con ustedes algunas cosas realmente geniales en las que el equipo de Lyft ha estado trabajando para crear y escalar nuestra plataforma de microservicios de próxima generación. ¿Alguna vez has sentido los dolores de crecimiento de estar en una empresa? Ahora tienes que escalar la empresa y el equipo a nuevas alturas. Pero ahora estás en un punto en el que es imposible gestionar todas estas arquitecturas y servicios diferentes a gran escala. ¿Qué haces en este punto?
Hola a todos. Mi nombre es Andrew. Soy un ingeniero aquí en Lyft. Hoy, quería compartir con ustedes algunas cosas realmente geniales en las que el equipo de Lyft ha estado trabajando para crear y escalar nuestra plataforma de microservicios de próxima generación. Pero antes de hacer eso, quiero contar una historia para ver si te identificas. ¿Alguna vez has sentido los dolores de crecimiento de estar en una empresa? Tal vez eras una pequeña startup que está creciendo rápidamente y con un nuevo éxito, felicitaciones, ahora tienes que escalar la empresa y el equipo a nuevas alturas. Y ahora, tienes nuevos compañeros de equipo, nuevos equipos tratando de resolver todos estos problemas empresariales diferentes, y todos están limitados por estar en la misma aplicación monolítica. Por supuesto, empoderas a esos equipos, los separas y los envías a hacer su trabajo de manera distribuida en un microservicios. Ahora cada equipo está empoderado para construir una plataforma y resolver sus propios problemas como mejor les parezca. Y esto puede tener éxito durante mucho tiempo. Pero ahora estás en un punto en el que es imposible gestionar todas estas diferentes arquitecturas y servicios a gran escala. Las actualizaciones de seguridad son difíciles de aplicar. Las plataformas comienzan a mostrar algún tipo de desviación, es difícil asegurarse de que todos sigan las mismas convenciones. Y los desarrolladores encuentran muy difícil lograr cosas porque todos buscan soporte de una manera muy específica. ¿Qué haces en este punto? Mientras buscaba temas para investigar para esta presentación,
2. Puntos de inflexión y ventaja técnica de Lyft
La mayoría de las herramientas y procesos admiten un orden de magnitud de crecimiento antes de volverse ineficaces. Los sistemas de software están diseñados para un punto óptimo de entrada. Cambiar la cantidad de entrada o volumen requiere pensar en una arquitectura diferente. Lyft enfrentó puntos de inflexión similares a lo largo de su historia. En los primeros días, funcionaban las aplicaciones web monolíticas. A medida que el negocio crecía, se creó un servicio de segunda generación basado en Node y React. Sin embargo, los servicios de larga duración requieren mantenimiento y actualizar las aplicaciones se vuelve difícil a gran escala. El concepto de ventaja técnica es la capacidad de multiplicar las entradas en resultados desproporcionados. Es importante tener una forma estructurada de pensar en la ventaja técnica. Lyft centralizó la capa inferior de su infraestructura de aplicaciones para empoderar a los desarrolladores.
Me encontré con esta cita del autor Will Larsen. Will Larsen dice que la mayoría de las herramientas y procesos solo admiten aproximadamente un orden de magnitud de crecimiento antes de volverse ineficaces. Ahora, eso no significa que si tu arquitectura no puede escalar dos órdenes de magnitud de crecimiento, esté mal diseñada. No, simplemente significa que tus sistemas de software están diseñados para un punto óptimo de entrada. Y una vez que cambias la cantidad de entrada o volumen o rendimiento que debe manejar, debes comenzar a pensar en una arquitectura diferente por completo.
Y enfrentamos puntos de inflexión muy similares a lo largo de nuestra historia como empresa. En el primer punto de inflexión, probablemente estaban los primeros días de Lyft. En los primeros días teníamos aplicaciones web monolíticas, y en su mayor parte, funcionaban. Ahora, la mayoría de nuestro código front-end en esos días estaba en un monolito de Python Angular, uno o dos de ellos, y a medida que el negocio crecía, necesitábamos crear y empoderar a los desarrolladores. Así que se creó un servicio de segunda generación basado en Node y React, y se podían generar rápidamente con un generador de servicios de aplicaciones, que en realidad es solo un repositorio con plantillas que genera una aplicación, que tiene algunas configuraciones predeterminadas bastante razonables para cómo hacíamos las cosas internamente. Bueno, Lyft también invirtió mucho en microservicios front-end y generales en inversiones de infraestructura, por lo que terminamos con una explosión de microservicios. Pero, por supuesto, los problemas comenzaron a alcanzarnos. Los servicios de larga duración, como sabes, requieren mantenimiento, de lo contrario, comienzan a deteriorarse. Si no actualizas tu aplicación lo suficientemente rápido, te das cuenta de que se vuelve cada vez más difícil avanzar hacia las próximas actualizaciones requeridas. La plataforma se fragmenta si tienes suficientes sistemas a gran escala. Las nuevas actualizaciones de infraestructura son realmente difíciles de aplicar. Y no solo eso, los desarrolladores ven mermada su productividad ya que tienen que aplicar nuevas actualizaciones una tras otra. Entonces, ¿qué hacemos? En el núcleo mismo de lo que quiero hablar hoy se encuentra el concepto de ventaja técnica. La ventaja técnica se define como la capacidad de multiplicar tus entradas en resultados desproporcionados. Entonces, pensemos en las herramientas que podemos aplicar para tener un impacto desproporcionado en la productividad de los desarrolladores, la confiabilidad y la escalabilidad. Pero, ¿por dónde empezamos? Muchas veces, cuando pensamos en la ventaja técnica o en escalar una plataforma, nuestros pensamientos automáticamente se dirigen a centralizar todo en un repositorio o una aplicación o servicio y hacer que eso lo gestione. O pensamos en comprar una plataforma SaaS que gestione x, y o z por nosotros. Pero antes de hacer eso, vamos a tener una forma un poco más estructurada de pensar en las cosas. Así que hay una forma más estructurada de pensar en la ventaja técnica. Y la forma en que pensamos en ello es pensar en nuestra aplicación como un servicio escalonado. Dentro de nuestra infraestructura de aplicaciones, puedes imaginar que hay una capa de infraestructura, la capa inferior, que corresponde tal vez al archivo Docker, o la forma en que interactúas con el proveedor de servicios en la nube, o tal vez es una configuración de webpack. En el medio, tienes tu capa de bibliotecas, que son las bibliotecas de terceros que utilizas para hacer todas tus cosas. Y finalmente, la capa superior es la aplicación o el código de espacio de usuario que contiene todo el código que tus ingenieros escriben día tras día para resolver los problemas en su dominio. Ahora, lo que queremos hacer es poder manejar las dos capas inferiores, queremos aplicar ventaja en estas capas y empoderar a nuestros usuarios para que se preocupen por la capa superior. En Lyft, la capa inferior fue inicialmente lo que pensamos que habíamos resuelto. Habíamos centralizado una configuración de compilación de webpack y muchas de nuestras cosas de virtualización o contenerización, esas
3. Plataforma Next.js de Lyft
Creamos un servicio de Generación 3 llamado Lyft Service, que es nuestra plataforma de próxima generación. Nos apoyamos en Next.js como nuestra plataforma elegida, lo que simplifica nuestro código y nos permite enfocarnos en otras cosas. Las convenciones y el enrutador del sistema de archivos de Next.js nos ayudan a eliminar el código repetitivo y reducir la carga cognitiva. También estandarizamos y automatizamos nuestras integraciones de bibliotecas y migraciones.
y muchas de nuestras cosas de virtualización o contenerización, esas cosas eran administradas para nuestros desarrolladores. Pero esas bibliotecas de la capa intermedia no estaban muy bien hechas. Así que cuando volvimos a la mesa de dibujo, el equipo se puso manos a la obra. Creamos un servicio de Generación 3 llamado Lyft Service. Esta sería nuestra plataforma de próxima generación. Y estos tres principios son nuestros principios rectores. En primer lugar, nos apoyamos en los hombros de gigantes. En segundo lugar, simplificamos el código para entenderlo. Y en tercer lugar, estandarizamos para poder automatizar. Vamos a repasarlos uno por uno.
En primer lugar, nos apoyamos en los hombros de gigantes. Nuestro equipo de plataforma de desarrollo evaluó a varios candidatos para nuestra plataforma de próxima generación y nos decidimos por Next.js. Lo que nos gustó fue que Next.js tenía una gran arquitectura con opiniones y estaba resolviendo muchas de las cosas que queríamos resolver. Cosas como la configuración de compilación, generación de sitios estáticos, renderizado del lado del servidor, páginas AMP, división de código, importaciones dinámicas. Estos eran problemas que ya estábamos resolviendo en cierta medida, pero aún no por completo, ya que los ingenieros en los bordes de la organización lo habían hecho de manera aislada, pero no los habían reintegrado al sistema. Pero cuando construyes sobre un producto orientado a la comunidad como Next.js, puedes aprovechar su impulso. Y ahora, realmente podemos enfocarnos en otras cosas en lugar de tener que mantener nuestra propia arquitectura interna. En segundo lugar, simplificamos para entender. Una cosa que obtuvimos al usar Next.js fue la filosofía de elegir la convención en lugar de la configuración. Esto tiene el efecto de simplificar nuestra aplicación al permitirnos eliminar mucho código repetitivo. Aquí tienes un ejemplo. Con las aplicaciones de Next.js, tenemos un enrutador del sistema de archivos. Es una de las características más distintivas de una aplicación de Next. Y dependiendo de dónde coloques un archivo en el sistema de archivos, su estructura de ruta refleja la estructura de URL de la ruta que sirve. Es una idea realmente poderosa y nos permite eliminar mucho de nuestro código de enrutador de React. Además, hay convenciones en torno a cómo obtener datos del lado del servidor y pasarlos a React. Nos gusta la forma en que tienen esas cosas listas para usar, y pensamos que nuestros sistemas se beneficiarían mucho al adoptar esas convenciones. Al final, tenemos una carga cognitiva más baja al trabajar en estas aplicaciones, lo que significa que nuestros desarrolladores son más productivos al cambiar y cambiar de contexto entre diferentes aplicaciones. En segundo lugar, estandarizamos y automatizamos. Creamos un sistema de complementos que estandariza nuestras integraciones de bibliotecas, y luego tenemos un sistema de migración que hace que las migraciones sean un elemento fundamental de nuestra nueva
4. Sistema de complementos de Lyft
La capacidad de reutilizar código, mantener la pila actualizada y evitar la deriva del código se logra mediante el uso de complementos. Estos complementos son complementos internos de Lyft Service que agrupan e inyectan hooks personalizados, como configuraciones de compilación de webpack, middleware de express y configuraciones de aplicaciones Next.js. Por ejemplo, un complemento de autenticación de cookies permite distribuir el comportamiento de autenticación de cookies a otros micro frontends o servicios dentro de la organización. Los desarrolladores pueden instalar y utilizar estos complementos para acceder a métodos de conveniencia e implementar la funcionalidad deseada sin tener que lidiar con los detalles internos del complemento. Se utilizan hooks de servidor Express y hooks de nextApp para modificar la aplicación Express y el nodo raíz de una aplicación React, respectivamente.
framework. Hablaré un poco más sobre esto, pero el efecto neto de tener estas dos nuevas características del sistema es que tenemos la capacidad de reutilizar código, mantener la pila actualizada y evitar la deriva del código. Veamos nuestros complementos. Cuando hablo de un complemento, no me refiero a un complemento de
Next.js, que en realidad es algo ligeramente diferente. En realidad, me refiero a nuestro propio complemento interno de Lyft Service, que es como un complemento de
framework que te permite agrupar e inyectar varios hooks personalizados juntos. Cosas como configuraciones de compilación de
webpack, middleware de express y configuraciones de aplicaciones de
Next.js. Veamos uno para ilustrar lo que quiero decir. Aquí he desarrollado un ejemplo un poco forzado de un complemento de autenticación de cookies. Digamos que algún equipo en tu empresa ha construido un servicio de autenticación de cookies que básicamente, ya sabes, escribe una cookie cada vez que alguien inicia sesión. Entonces quieres poder distribuir este comportamiento a otros micro frontends o micro servicios que tienes dentro de la organización, así que creas un complemento para esto. Aquí está la experiencia del usuario. Instalan el paquete del complemento y luego crean una instancia de ese complemento y lo pasan a una matriz de inicialización. Nuestro servicio, nuestro
framework tomará esta matriz, instalará e inyectará los hooks en el lugar correcto. Desde el punto de vista de los desarrolladores, ahora son libres de usar los métodos de conveniencia que proporcionas en el complemento a su favor. Aquí he creado un hook que proporciona dos elementos. Proporciona un ID de usuario y proporciona un método auxiliar para verificar si ha iniciado sesión. Estas son herramientas de conveniencia que tu desarrollador podrá utilizar para implementar lo que sea que proporcione tu complemento. Observa aquí que no se menciona los detalles internos de este complemento. No tienes que saber si hay middleware de express involucrado. No tienes que saber si hay análisis de cookies y qué secretos pasar a la cookie y todas estas otras cosas. Eso se abstrae para ti detrás del complemento. Ahora vamos a abrir el capó de un complemento para ver qué hay debajo. Comenzaremos viendo un hook de servidor Express. Este hook de express recibe una aplicación Express como argumento y te permite modificarla. Aquí verás que usamos un middleware de análisis de cookies, un paquete de terceros que nos da acceso a las cookies, y en segundo lugar, analizamos esas cookies. He simplificado la implementación de eso, pero lo más importante es que tomamos ese valor de ID de usuario y lo insertamos en el objeto de variable local en la respuesta. Lo usaremos más adelante en el siguiente ejemplo. Luego tenemos el hook nextApp. Este nextApp representa el nodo raíz de una aplicación
React. Y aquí hay dos cosas sucediendo. Si no estás familiarizado con
5. GetInitialProps y Sistema de Complementos
GetInitialProps se ejecuta en el contexto del servidor, obtiene datos y los pasa de vuelta a la aplicación React. Creamos un complemento que conecta todo y proporciona comodidades para los desarrolladores. Nuestro sistema de complementos permite empaquetar y entregar fácilmente la funcionalidad de la aplicación con una configuración mínima. Tenemos complementos para la gestión del estado, GraphQL, componentes de UI, autenticación, internacionalización, seguimiento de rendimiento y más. Nuestro sistema de migración, utilizando scripts de cambio de código JS, evita la deriva de la arquitectura y proporciona protección.
En este patrón en Next, hay un método estático llamado getInitialProps. GetInitialProps básicamente se ejecuta antes de que la aplicación se renderice y obtiene
data del servidor. El código que proporcioné aquí se ejecutará en el contexto del servidor cuando esté disponible el ID de usuario y el objeto de respuesta esté disponible. Tomará ese ID de usuario y lo pasará de vuelta a tu aplicación
React en las props. En las props verás que proporcionamos un proveedor, básicamente un proveedor de cookieAuthContext, y proporcionamos ese ID de usuario para usar en el resto de la aplicación
React. Esa es básicamente la clave de conexión entre el mundo del servidor y el mundo de
React.
Aquí básicamente conectamos todo en un complemento en el que especificamos los hooks en los que instalar e implementar estas anulaciones y luego creamos comodidades para los desarrolladores. Así que aquí tenemos un hook y ese hook proporciona dos cosas. En primer lugar, obtiene ese ID de usuario del contexto. Y en segundo lugar, hay un método auxiliar simple que te permite hacer algo con eso. Bastante fácil, ¿verdad? Esto significa que hemos creado una forma fácil de empaquetar y entregar la funcionalidad de la aplicación con la menor configuración, casi ninguna configuración posible. Verás el poder de esto, porque internamente tenemos todos estos complementos en marcha. Tenemos complementos para la gestión del estado, GraphQL, componentes de UI como Live Product Language, que es nuestra biblioteca interna de patrones de UI, componentes de estilo de Material UI. Tenemos complementos de autenticación y autorización, internacionalización, seguimiento de rendimiento, activación de funciones, MirageJS y otras utilidades de pruebas, y registro de errores, métricas e informes de errores. Muchas cosas. Incluso tenemos planes muy grandes para proporcionar herramientas de soporte para desarrolladores mejoradas. Nuestro equipo de plataforma para desarrolladores quiere hacer que sea aún más fácil para las personas informar errores, obtener trazas de pila y pedir ayuda. Lo realmente genial de este sistema de complementos es que ha creado un efecto de retroalimentación. Los usuarios están contribuyendo a estos complementos. Nuestros desarrolladores, nuestros ingenieros de desarrollo, en los bordes, están resolviendo problemas en sus sistemas. Están diciendo, hey, voy a construir mi implementación como un complemento y contribuirlo al ecosistema. Ahora, su impacto se multiplica en todos nuestros desarrolladores, en toda la organización. Más del 40% de nuestros complementos han sido contribuciones de ingenieros de productos.
Ahora, volvamos nuestra atención a nuestro sistema de migración. Las migraciones son el ingrediente secreto de cómo planeamos prevenir o trabajar contra los efectos de la deriva de la arquitectura. Son protecciones. Básicamente, las migraciones son scripts de cambio de código JS. JS code shift, si no estás familiarizado, es un framework que te ayuda a modificar JavaScript y reescribirlo de una forma a otra. No entraré en detalles sobre cómo funciona un código mod de cambio de código JS. Puedes buscar fácilmente en línea. Sin embargo, creo que será apropiado ilustrar lo que
6. Migración del Plugin de Registro
Recientemente, un desarrollador cambió uno de nuestros plugins de registro de exportar una instancia de un registrador a exportar una función de fábrica. En lugar de actualizar manualmente todas las referencias a la nueva forma, proporcionamos un script para automatizar la actualización. Esto hace que el proceso de migración sea fluido y garantiza que los cambios disruptivos no sean realmente disruptivos.
se ve desde el exterior. Así que aquí tienes un ejemplo. Recientemente, un desarrollador cambió uno de nuestros plugins de registro. En el antiguo mundo, exportaría una instancia de un registrador, y ahora exporta una función de fábrica. Entonces, en lugar de lanzar una versión disruptiva de esta biblioteca y tal vez escribir en el registro de cambios o en el readme, hey, si lo tienes de esta manera, actualiza todas las referencias para usar la nueva forma, automatizamos eso bajo el capó, por lo que se proporciona un script para actualizar todas las instancias del antiguo mundo al nuevo mundo. Por lo tanto, todos los cambios disruptivos teóricamente ya no son realmente disruptivos. Teóricamente, todo debería funcionar correctamente a medida que migras.
7. Migraciones y Versionado
Nuestras migraciones están versionadas, correspondiendo a versiones específicas de paquetes o plataformas. Almacenamos el estado de la última migración que ejecutas, lo que permite que las migraciones secuenciales te lleven al estado más reciente. El equipo decidió fijar las versiones de los plugins y la plataforma juntas, lo que hace que las actualizaciones sean fluidas. Esto incentiva a los desarrolladores a actualizar a la última versión, manteniendo la plataforma siempre actualizada.
hacia arriba. Otra cosa clave a tener en cuenta es que nuestras migraciones están versionadas. Esto significa que cada migración corresponde a una versión específica de paquete o plataforma en la que se introdujo. Almacenamos el estado de la última migración que ejecutas. Si ejecutas una migración para un paquete en un punto determinado, sabemos que la próxima vez que actualices, solo necesitamos ejecutar la siguiente actualización para la versión siguiente a la tuya. Si omites o actualizas varias versiones, sabremos ejecutar secuencialmente cada una de esas migraciones, lo que te debería llevar teóricamente al estado más reciente con la menor intervención posible.
Una decisión muy audaz, o audaz decisión de diseño, en mi opinión, que el equipo tomó fue decidir fijar las versiones del plugin y la plataforma juntas, lo que significa que se mueven juntas al mismo tiempo. Y esto fue inspirado por las comunidades de Babel y React, donde hacen algo similar. Las extensiones que hacen que la plataforma funcione están fijadas o se mueven junto con la biblioteca principal. Y lo que esto significa es que si quieres la última versión de la plataforma, también debes actualizar todos tus plugins a la última versión. O si quieres la última versión del plugin, debes hacerlo viceversa. Debes actualizar tu plataforma. Y con las migraciones en la raíz del sistema, empoderando todas estas migraciones, empoderando todas estas actualizaciones, las actualizaciones ahora se vuelven algo muy fluido y simple de hacer. Al hacer esto, creemos que hemos diseñado los incentivos adecuados para que los desarrolladores actualicen a la última versión. Y estructuralmente, hablando estructuralmente, la plataforma es
8. Lecciones y Conclusiones
Finalmente, para que este sistema tenga éxito, se requiere la combinación de procesos organizativos y culturales. Se llevaron a cabo talleres prácticos de migración para enseñar a los equipos sobre la nueva plataforma. Los scripts de migración y el evangelismo interno jugaron un papel crucial. El respaldo de los líderes senior y la alta adopción llevaron a que más del 60% de las aplicaciones ahora estén en la tercera generación del servicio de Lyft. Las lecciones incluyen aprovechar el trabajo de otros, simplificar el código, estandarizar y automatizar, y utilizar la automatización para multiplicar el impacto.
diseñado para mantenerse siempre en la última versión. Finalmente, no se puede construir un sistema como este y simplemente dejarlo a un lado. Se requiere la combinación de muchos procesos organizativos y culturales para que esto tenga éxito. Por lo tanto, una de las primeras cosas que hizo el equipo fue llevar a cabo talleres prácticos de migración, donde los equipos que tenían sistemas para migrar se reunían con uno o dos ingenieros del equipo de la plataforma, quienes los guiaban para enseñarles los entresijos de la nueva plataforma. Y una vez hecho esto, el equipo adquiría un conocimiento interno sobre cómo funcionaba esto y podían enseñ
ar a otras personas en sus equipos. De esta manera, podían crear y compartir conocimiento de manera orgánica. Esto también les dio a nuestros ingenieros la capacidad de anticipar, con algunos equipos de prueba, lo que podría salir mal, para poder ajustar el sistema antes de expandir su alcance. Otra cosa importante fueron los scripts de migración, es decir, modificaciones de código, que se escribieron para migrar la mayoría de los sistemas de la generación dos a los sistemas de la generación tres. Esto también facilitó mucho la migración y redujo el factor de intimidación de pasar de la generación dos a la generación tres. Hubo muchas oportunidades para hacer evangelismo interno en reuniones y presentaciones. Y finalmente, no se puede subestimar la importancia de obtener el respaldo de los líderes senior, quienes estaban convencidos de los beneficios en términos de productividad que esto brindaría a toda nuestra organización, y lo respaldaron con una gestión de programas que aseguró el éxito de esta migración. Hoy en día, más del 60% de nuestras aplicaciones están en nuestra tercera generación del servicio de Lyft, y aún hay más por venir. Hemos visto una alta adopción de esta nueva plataforma precisamente porque hemos generado suficiente entusiasmo y productividad para que las personas hablen bien del nuevo sistema a otros desarrolladores. No solo eso, debido a la evidencia de una adopción rápida, estamos convencidos de que esta adopción rápida continuará a medida que sigamos lanzando nuevas versiones de esta plataforma. Entonces, ¿qué puedes aprender de estas lecciones? Mientras piensas en cómo aplicar esto a tus sistemas, queremos hacerte algunas preguntas. En primer lugar, ¿cómo estás aprovechando el trabajo de otros? ¿Cómo estás avanzando con la comunidad? ¿Cómo puedes participar en el impulso del código abierto para aprovechar su impulso? En segundo lugar, ¿cómo estás simplificando tu código? ¿Cómo te aseguras de que el código innecesario se simplifique al máximo? Para nosotros, esto significó optar por la convención en lugar de la configuración. ¿Cómo se ve eso para ti? Y en tercer lugar, estandarizamos y automatizamos. Entonces, ¿dónde ves divergencias? ¿Cómo puedes unificar esas divergencias en un solo lugar, quizás creando una capa de abstracción o centralizando y creando una plataforma? Y finalmente, ¿cómo utilizarás la automatización para multiplicar tu impacto y asegurarte de que, al actualizar, nada se quede atrás? Eso es todo. Eso es lo que queríamos compartir contigo hoy. Esperamos verte en la sesión de preguntas y respuestas y gracias por asistir a esta charla en la Cumbre de
React. Gracias.
9. Scaling Front-end Stack
Gracias por la increíble charla, Andrew. Discutamos cómo las organizaciones están escalando su stack de front-end. La mayoría está centralizando bibliotecas y servicios, seguido de la creación de un equipo de plataforma y aprovechando el código abierto u otras plataformas. Esto se alinea con nuestras expectativas y las experiencias de otros equipos. Extraer bibliotecas y servicios es un primer paso común, seguido de la creación de un equipo de plataforma dedicado. Esto garantiza un ecosistema y herramientas sólidos.
Muchas gracias por esa increíble charla, Andrew. He aprendido mucho. Espero que tú también. Vamos a revisar esa pregunta que Andrew nos hizo, preguntando cómo está escalando tu stack de front-end en tu organización. Voy a invitar a Andrew para que podamos hablar sobre los resultados. Entonces, si miramos, vemos que el 58% dice que sus organizaciones están centralizando bibliotecas y servicios, seguido de la creación de un equipo de plataforma en un 17%, y aprovechando el código abierto u otras plataformas en un 15%. ¿Eso es más o menos lo que esperabas? Sí, eso es exactamente lo que hemos visto, ya que también hemos hablado con otros equipos. Parece que una de las primeras cosas que la gente quiere hacer es, sí, quieres sacar cosas en bibliotecas y servicios y cosas así, cosas que tienen sentido y que se superponen. Está en nuestro ADN como desarrolladores secar todo. Así que saquemos todo juntos. Y creo que lo siguiente es realmente importante, construir un equipo de plataforma. Cuando llegas a cierto punto, necesitas dedicar personas específicas, seres humanos reales, a tiempo completo, para asegurarte de que tu ecosistema y tus herramientas sean realmente sólidos.
Plugin System and Versioning
Me encantan estos tres puntos de apoyarse en los gigantes, simplificar y estandarizar. El sistema de plugins permite a los desarrolladores elegir herramientas que resuelvan sus problemas específicos. Es un proceso orgánico en el que los desarrolladores traen herramientas que funcionan para ellos y las comparten con otros. Contar con herramientas para ampliar la arquitectura de manera segura y escalable es crucial. La versión de los plugins internos en los microservicios puede ser desafiante debido a incompatibilidades y problemas de depuración. La historia de migración tiene como objetivo facilitar el traslado de los sistemas a la última versión.
Estoy totalmente de acuerdo, respuestas geniales. Me encantan estos tres puntos de apoyarse en los gigantes, simplificar y estandarizar, realmente resuenan conmigo. Pero tenemos un par de preguntas de Discord, voy a responder algunas de ellas. Una de Qabs dice, ¿algunas de estas herramientas son de código abierto y tienes algún documento sobre la configuración de la arquitectura de plugins? Gracias por preguntar. Esta pregunta la recibimos mucho, ¿vas a hacer de código abierto esto? La respuesta que puedo darte es que ha habido discusiones internas, pero no hay planes actuales de hacer de código abierto este framework. Sin embargo, como he mostrado aquí en esta charla, la configuración de una plataforma como esta no es demasiado difícil de hacer. Y no dudes en ponerte en contacto ya sea en Discord o en Twitter, podemos conectarnos contigo o programar una charla para ver cómo podemos generar más ideas.
Genial. Quiero decir, aquellos de ustedes que los siguen en Twitter, tal vez lo hagan de código abierto si suficiente gente apoya la idea. Tenemos otra pregunta de Vasili que dice, eso es muchos plugins, ¿cómo deciden los desarrolladores qué merece ser un plugin? Bueno, eso es lo genial de cómo el equipo ha diseñado el sistema de plugins. El sistema de plugins es cualquier cosa que resuelva tu problema, ¿verdad? Como a cierto tamaño, realmente no puedes decir desde arriba, usa este plugin, no uses ese plugin, usa este. Quiero decir, probablemente puedas, si hay problemas de seguridad o cosas específicas que debes cumplir, ¿verdad? Pero al final, cada desarrollador en, lo que yo llamo, el borde, están ahí construyendo y resolviendo problemas en su área de negocio, ¿verdad? Entonces ellos serán los que mejor sepan qué herramientas necesitan, ¿verdad? Tenemos desarrolladores que adoptaron React Query o algo así, ¿verdad? Y eso pudo haber resuelto un gran problema para ellos en su área de la organización. Nadie les dirá, oye, en realidad, deberías estar usando este plugin en su lugar, ¿verdad? Es un proceso muy orgánico. Otro ejemplo de esto es, recuerdo que uno de nuestros ingenieros de productos desarrolladores trajo MirageJS porque resolvió el problema que tenían localmente, y eso realmente resolvió, ya sabes, otros equipos también se dieron cuenta y dijeron, oye, esto es genial. Esto resuelve algo con lo que también nos hemos encontrado. Como tienes que entender que, en una organización de cierto tamaño, es difícil para los desarrolladores encontrarse entre sí, ¿verdad? Y estás asintiendo con la cabeza porque seguro que también te has sentido así. Y cuando me uní por primera vez, la mayor parte de mi carrera, he trabajado en empresas de tal vez 200 personas o menos, tal vez un equipo de ingeniería de 50 personas, todos se conocen entre sí, ¿verdad? Pero ahora estoy en una empresa con más de mil ingenieros. Es muy difícil saber qué está haciendo todo el mundo todo el tiempo, ¿verdad? Por eso es tan importante tener estas herramientas y la capacidad de ampliar tu arquitectura, pero hacerlo de manera segura y permitir que se pueda escalar. Definitivamente. Me encanta esa parte de encontrar personas. La cantidad de veces que he buscado en hilos de Slack tratando de encontrar al responsable de algo. Trae recuerdos oscuros. Otra pregunta que tenemos de Bear Man dice, ¿hay algún dolor de cabeza o has desarrollado alguna regla general en cuanto a la versión de tus plugins internos en los microservicios? Gracias por hacer esa pregunta. Obviamente, no todo es color de rosa, ¿verdad? El desafío, creo, con la versión, ¿verdad?, es que son problemas universales de versionado, ¿verdad? Cuando unes cosas, cuando dices, como, oye, este plugin debe funcionar con esta versión, vas a tener algunas incompatibilidades porque algunas personas no siempre estarán en las últimas versiones, ¿verdad? Habrá algunos problemas de depuración, ¿verdad?, cuando nuestro equipo de plataforma tenga que ayudar a otro equipo y se dé cuenta de que en realidad están usando una versión anterior que tenía este error específico, ya sabes, y llevó mucho tiempo encontrar ese error, ¿verdad? Y por eso hemos desarrollado esta historia de migración. Queremos que sea lo más fácil y sin fricciones posible mover tu sistema a la última versión, ¿verdad?, eso debería ser lo más fácil de hacer, ejecutar algunos comandos y boom, ya estás ahí. En la práctica, obviamente es más difícil. Cada aplicación va a tener alguna parte extraña de su superficie que requerirá un poco de trabajo manual, y por eso diría que muchos de nuestros problemas también están relacionados con la compatibilidad cruzada de sistemas. Tendrás plugins que dependen de otros plugins, y a veces esos plugins tienen ciertas suposiciones sobre cómo funciona el mundo que tienes que resolver, ya sabes, y por eso también fijamos las versiones de todos los plugins juntos, para que podamos garantizar y poner un sello de aprobación de que esta versión está garantizada para funcionar en otras versiones de la misma plataforma.
Handling Different Requirements and Design Choices
Tenemos otra pregunta sobre cómo manejar diferentes requisitos de los equipos de productos. El equipo de experiencia de front-end define la arquitectura de la plataforma escuchando a los equipos de productos y comprendiendo sus problemas. El equipo de plataforma desarrolló el sistema de plugins para resolver el problema de gestionar servicios obsoletos y actualizaciones. Escuchar las necesidades de los desarrolladores, que son los clientes del equipo de plataforma, ayuda a tomar decisiones de diseño.
Eso definitivamente tiene sentido. Es una buena respuesta. Tenemos otra pregunta, porque estás sirviendo a tantos desarrolladores diferentes de tantos equipos diferentes. Esta viene de Poona 777. ¿Cómo manejas los diferentes requisitos que provienen de diferentes equipos de productos? Me gustaría profundizar un poco más. Quiero decir, puedo entender un poco sobre lo que estás preguntando. En primer lugar, el equipo de plataforma de desarrollo, los llamamos equipo de experiencia de front-end aquí. Ojalá los tuviera aquí conmigo también, para que pudieran representarse mejor. Ellos tienen la oportunidad de definir la arquitectura de esta plataforma. Al hacer muchas visitas de escucha con diferentes ingenieros, están en el terreno escuchando o trabajando con nuestros equipos de productos. Simplemente trabajando con tus clientes, para el equipo de plataforma, los ingenieros de productos y sus servicios son sus clientes. Tienen una idea de lo que funciona o lo que está roto y cómo resolver los problemas para diferentes ingenieros de productos.
En ese sentido, nadie le dice al equipo de plataforma cómo construir el sistema. El equipo de plataforma, basado en los problemas que escuchan, piensan para sí mismos, como, hey, aquí hay una gran idea. Quiero llevarla adelante. Así es como los líderes del equipo de plataforma desarrollaron este sistema de plugins porque sintieron el dolor. Entendieron el dolor de tener que saltar de un lado a otro a través de todos estos diferentes servicios y darse cuenta, hey, todo está desactualizado. Todo necesita ser actualizado. ¿Cómo resolvemos ese problema, tanto para este equipo de productos como para nosotros mismos, y reducir la carga de soporte en nuestro equipo? Sí. Una cosa que mencionaste sobre escuchar y cómo son los clientes, a menudo pensamos en los clientes como las personas, los usuarios finales de la aplicación. Pero a menudo son personas cuyos roles, sus clientes son los otros desarrolladores. Y aprender lo que esas personas realmente necesitan te ayuda a informar tus opciones de diseño.
Productivity Improvements and User Research
Vasily Shelkov preguntó ejemplos de las mejoras de productividad de Lyft. Aunque no hay números específicos disponibles, se han medido y documentado métricas como la velocidad de inicio de la aplicación y las líneas de código eliminadas en una publicación de blog. En cuanto a la productividad general de los desarrolladores, hay un aumento notable, aunque no se proporcionan cifras exactas. Se planteó otra pregunta sobre el número de aplicaciones Next.js en Lyft y si se agrupan en una sola aplicación. Lyft tiene más de 100 servicios de front-end, de los cuales más de 60 son aplicaciones Next.js. Sin embargo, Lyft no las fusiona en una sola aplicación para mantener la independencia de los equipos. El equipo de plataforma de Lyft realiza investigaciones de usuarios interactuando directamente con los ingenieros para comprender los puntos problemáticos y probar la efectividad de la plataforma. Aunque no hay un investigador de UX dedicado, se valora la opinión de los desarrolladores durante la fase de diseño.
Otra pregunta de Vasily Shelkov dice, ¿puedes dar ejemplos de lo que Lyft ha hecho para mostrar cuánto puede mejorar la productividad? Por ejemplo, el tiempo dedicado a x se reduce entregando FOSTA en x. No tengo esos números en este momento. Definitivamente están cuantificados en algún lugar. En cuanto a la carga de soporte o la productividad. Hicimos algunas mediciones en bruto de la nueva pila en comparación con la antigua en términos de velocidad de inicio de la aplicación, líneas de código eliminadas y todas esas cosas. Tenemos una publicación de blog en nuestro blog de ingeniería, eng.liff.com, donde cuantificamos algunas métricas y algunos logros de esta plataforma. En cuanto a la productividad general de los desarrolladores, puedo decir que los desarrolladores son más productivos. No tengo números para compartir, exactamente cuánto más productivos. Pero es un gran ejercicio. Nos encantaría compartir eso si podemos. Bonito, bonito. Otra pregunta de Min que dice, ¿tienen muchas aplicaciones Next.js? Y si es así, ¿cómo las agrupan todas en una sola aplicación? Esa es una gran pregunta. Entonces, en primer lugar, sí. Lyft tiene muchas aplicaciones Next.js. En este momento, Lyft tiene más de 100 servicios de front-end, de los cuales más de 60 son aplicaciones Next.js. Así que sí, tenemos muchas. En realidad, no intentamos fusionarlas en una sola aplicación. Aunque puedes hacerlo. Y sé que hay una función de la plataforma Vercel que te permite ejecutar subaplicaciones dentro de aplicaciones principales. Nosotros no lo hacemos, especialmente con el propósito de mantener la independencia de los equipos. Así que definitivamente te remitiría al equipo central de Next.js o a esa comunidad para ver si quieres fusionar aplicaciones en una sola aplicación Next.js, pero eso no es algo que hacemos en Lyft. Genial. Hay tantas preguntas. Una pregunta más que voy a señalar es cómo hace el equipo de plataforma para investigar a los usuarios. Porque recuerda que hablaste de ir y escuchar a esos desarrolladores. ¿Tienen sus propios investigadores de usuarios internos para entenderlos? ¿Y cómo no solo se basan en lo que el equipo de plataforma prefiere? Esa es una gran pregunta. Diría que el equipo mismo está haciendo la investigación. Porque están solucionando problemas en el terreno, realmente salen y hablan con los ingenieros y tienen una idea de los puntos problemáticos. Así que nuestro arquitecto principal me llevó a dar una vuelta por la manzana. Hicimos una caminata para tomar café antes de COVID, y él compartió un poco sobre lo que tenía en mente y probó si esta plataforma resolvería sus problemas. Aquí, habla esto conmigo. Así que hubo mucha aportación en la fase de diseño de esta nueva plataforma. También diría que la investigación de usuarios, sí, en muchos aspectos, es a nivel de base, ya sabes. Sería genial tener un investigador de UX incorporado que piense en la experiencia del desarrollador. Creo que eso sería genial. Genial. Bueno, muchas gracias, Andrew, por responder a todas esas preguntas. Sé que hubo algunas más que nos perdimos, pero ustedes pueden hablar con Andrew ustedes mismos en el chat espacial. Andrew se va a ir de aquí y hablará con ustedes allí. Nos vemos, Andrew.
