Plataforma impulsada: Construyendo una Plataforma Frontend para Escalar tan Rápido como Tú 🚀

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,

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

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

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

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

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.

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.

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.

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.