Los desarrolladores quieren lanzar y crear valor para nuestros usuarios. Entonces, ¿por qué tantos equipos luchan por llevar las cosas a producción rápidamente? En esta charla, Jason Lengstorf analizará el impacto que nuestra arquitectura y nuestra infraestructura frontend tienen en la capacidad de nuestros equipos para construir, iterar y desplegar software, y cómo afecta la calidad y los riesgos del despliegue.
This talk has been presented at JSNation Live 2021, check out the latest edition of this JavaScript Conference.
FAQ
El objetivo principal de una empresa, según Jason Lenton, es entregar valor a los clientes rápidamente.
Una infraestructura y procesos que son frustrantes, frágiles y lentos pueden impedir la productividad de los equipos, haciendo que sea difícil y lento llevar productos al mercado.
La complejidad en los sistemas puede ralentizar el trabajo de los desarrolladores, crear conocimientos aislados dentro de los equipos y generar burocracia que ralentiza toda la empresa.
Los front-ends desacoplados permiten que los desarrolladores de front-end trabajen independientemente de los de back-end, mientras que los precompilados reducen la fragilidad y permiten implementaciones rápidas y seguras.
Las funciones sin servidor eliminan la necesidad de manejar configuraciones complejas como Docker y Kubernetes, permitiendo a los desarrolladores implementar cambios rápidamente con código simple.
Elegir una infraestructura adecuada que se enfoque en la simplicidad y la eficiencia puede permitir a los equipos implementar cambios más frecuentemente, incluso varias veces al día, aumentando así la productividad y competitividad.
La charla de hoy analiza cómo las elecciones de arquitectura e infraestructura impactan la productividad del equipo. Los sistemas complejos pueden generar frustración, fragilidad y lentitud, obstaculizando la eficiencia y creando silos de conocimiento. Los front-ends desacoplados, los front-ends precompilados y las funciones sin servidor pueden mejorar la productividad y permitir un despliegue más rápido. Las arquitecturas de apoyo son cruciales para construir una cultura de lanzamiento y evitar sistemas frustrantes, frágiles y lentos.
Hoy hablaré sobre cómo las elecciones de arquitectura e infraestructura pueden afectar la productividad del equipo. Los sistemas complejos pueden generar frustración, fragilidad y lentitud. Pueden ralentizar a los desarrolladores y crear compartimentos estancos de conocimiento dentro de los equipos. La complejidad también obstaculiza la eficiencia de la empresa y puede generar burocracia.
**JASON LENTON** Muy bien. Hola a todos. Estoy muy emocionado de hablarles hoy sobre cómo ser productivos por defecto. Y lo que quiero decir con eso es que quiero hablar sobre cómo la arquitectura que elijas para tu equipo y la infraestructura en la que lo implementes pueden hacer o deshacer la productividad de tus equipos.
Tengo mucho que cubrir en siete minutos, así que empecemos de inmediato. En primer lugar, nuestro objetivo principal como empresa es entregar valor a los clientes rápidamente. La forma en que tenemos éxito como empresa es producir algo que las personas quieran y entregárselo rápidamente para mantenernos competitivos y para que las personas quieran seguir pagándonos por nuestros servicios. Y los equipos quieren entregar. Por defecto, los equipos quieren sacar las cosas al mercado. Es muy divertido para nosotros ver cómo las cosas se lanzan en vivo.
Entonces, ¿qué impide que un equipo entregue? Hay algunas cosas de las que no vamos a hablar hoy como construir una base de confianza y asegurarse de cuidar a tu gente. Voy a asumir que estás haciendo ese trabajo porque si no lo haces, ninguno de los consejos que te daré hoy tendrá sentido. Pero suponiendo que ya tienes eso en su lugar, hablemos de tu infraestructura. Si tu infraestructura y tus procesos son frustrantes, si son frágiles, si son lentos, si tienes que pasar por un montón de obstáculos y guardianes y controles y diferentes equipos, y solo puedes implementar una vez cada pocos días o incluso cada pocas semanas, eso es muy frustrante, frágil y lento. Es posible que hayas escuchado hablar de esto pero existe una buena probabilidad de que hayan estado usando el acrónimo FFS, frustrante, frágil, y lento. La complejidad es en gran parte lo que lleva a estos sistemas frustrantes, frágiles y lentos. Estamos tratando de hacer cosas muy complejas con nuestro código y nuestras aplicaciones, pero si no tenemos cuidado, esa complejidad comienza a convertirse en desorden y burocracia y esa fragilidad. Hablemos un poco sobre cómo la complejidad puede afectar al equipo. En primer lugar, un sistema complejo va a ralentizar a un desarrollador. Si un desarrollador tiene que pedir permiso para hacer parte de su trabajo, si hay cosas en el front-end que requieren que se mueva al nivel intermedio o al back-end y tiene que pedir permiso a un desarrollador de back-end o esperar a un ingeniero de DevOps o empezar a buscar a otros equipos para que se encarguen de partes del trabajo, eso lo va a ralentizar. Si tienes equipos que trabajan en sistemas complejos, comienzas a desarrollar compartimentos estancos de conocimiento. Tienes este problema en el que un equipo está trabajando en algo y son los únicos que saben cómo funciona. Y peor aún, si ese equipo tiene a alguien que es el único que sabe cómo funciona, eso significa que todo el equipo puede quedarse atascado si esa persona no está. Eso no es divertido. Genera mucha carga de trabajo. Dificulta que las personas se vayan de vacaciones y es difícil crear autonomía.
2. Improving Productivity with Infrastructure Choices
Short description:
Los sistemas frágiles conducen a una velocidad de implementación más lenta y a una mayor fragilidad. Los front-ends desacoplados reducen la complejidad y permiten una implementación más rápida con bajo riesgo. Los front-ends precompilados reducen la fragilidad y permiten deshacer cambios rápidamente. Las funciones sin servidor reducen la redundancia y permiten a los equipos de front-end realizar llamadas privilegiadas a las API. Al elegir una infraestructura centrada en el front-end, los equipos pueden ser más productivos e implementar varias veces al día.
Los sistemas complejos también ralentizan a las empresas. Una causa clave de burocracia es la complejidad. Si tus sistemas son frágiles, comienzas a implementar procesos para controlar eso. Y si implementas esos procesos, puede hacer que toda tu empresa se vuelva mucho más lenta. A medida que las cosas se vuelven más lentas, las personas comenzarán a disminuir su velocidad de implementación porque no quieren pasar por ese proceso. Pondrán más y más cambios en cada implementación. Eso significa que cada implementación se vuelve más grande y, por lo tanto, más frágil, lo que significa que más cosas se rompen. Los front-ends desacoplados reducen la complejidad. Ahora tus desarrolladores de front-end pueden ser solo desarrolladores de front-end. Si estás desacoplado e implementando en la nube, de repente no tienes una gran cantidad de pasos de DevOps y administración de servidores de nodos y descubrir cómo funcionan Docker y Kubernetes para la implementación de front-end. Puedes construir un front-end, implementarlo en Git y CI/CD lo lleva en vivo porque se puede implementar con bajo riesgo en un CDN. Los front-ends precompilados reducirán la fragilidad. Hay menos partes móviles. Se utilizan menos servidores en producción. Hay menos cosas que se pueden romper, lo que significa que puedes controlar ese riesgo. También te permite hacer cosas como crear implementaciones inmutables, donde cada versión compilada del front-end es su propia carpeta. Así que puedes deshacer rápidamente si algo sale mal con un solo clic. Eso es un gran beneficio. Los equipos pueden ir en vivo una vez que obtienen una revisión de PR en lugar de tener que esperar días o semanas para que otros equipos pasen por el proceso. Y las funciones sin servidor reducen la redundancia. Si necesitas hacer algo, como hacer una llamada privilegiada a una API, muchas veces esto caería en esta capa intermedia, donde es difícil asignarlo al equipo de back-end, porque es una API que solo se utiliza para el front-end y accede a datos de múltiples equipos de back-end. Entonces no está claro quién es el responsable de eso, y muchas veces recae en el equipo de front-end. Si usas funciones sin servidor, ahora tu equipo de front-end no tiene que lidiar con Node y configurar proxies y configurar Docker y Kubernetes. Solo pueden escribir un poco de JavaScript e implementarlo y obtener esa llamada privilegiada a la API que necesitan hacer de manera rápida. El gran beneficio de todo esto es que no tienes que pensar en servidores, no tienes que pensar en DevOps, no tienes que pensar en deshacer cambios, no tienes que pensar en escalar, no tienes que pensar en almacenamiento en caché, nada de eso. Todo lo que tus equipos de front-end necesitan pensar es en implementar. Y eso es por qué este modelo, al elegir una infraestructura que les brinde a tus equipos la capacidad de centrarse en solo el front-end, les permite enfocarse solo en la parte en la que son expertos de verdad, y les permite eliminar todas esas dependencias adicionales y esa complejidad adicional que se cuela cuando los front-ends se vuelven demasiado complejos. Eso es lo que hace que los equipos sean realmente, realmente productivos. Y lo que eso significa para nosotros en Nellify, por ejemplo, es que puedes implementar en producción no solo diariamente, sino varias veces al día. Y esto es el 7 de mayo, que fue un viernes.
3. La Importancia de una Arquitectura de Apoyo
Short description:
Nuestro equipo de front-end puede implementar cuatro veces en un lapso de cinco a seis horas después de fusionar una PR. Adoptar Jamstack puede llevar al mismo éxito. Para construir una cultura de implementación, es crucial tener una arquitectura de apoyo. Las arquitecturas frustrantes, frágiles y lentas obstaculizan a los desarrolladores y ralentizan la implementación.
Esta es la aplicación de Nellify, app.nellify.com. No es un sitio de marketing. No es una propiedad única. Esto es el núcleo absoluto de nuestro negocio. Y nuestro equipo de front-end puede implementar tan pronto como se fusiona una PR, cuatro implementaciones en un lapso de aproximadamente cinco horas, seis horas. Esa es una velocidad increíble para un equipo de producción. Y esto no es irregular. Vemos que esto sucede a los equipos que adoptan el Jamstack todo el tiempo. Y creo que es algo que será igual de exitoso si lo incorporas a tu equipo. Si quieres construir una cultura de implementación, necesitas crear la arquitectura que la respalde. Y eso es realmente, realmente importante. Porque si implementas una arquitectura que es frustrante, frágil y lenta, tus desarrolladores se frustrarán. Verán que las cosas se rompen y se ralentizarán. No podrán implementar tan rápido como desean. Si les das la arquitectura que hace de esto lo predeterminado para que puedan implementar rápidamente, sacar las cosas por la puerta, lo harán.
This talk discusses the usage of Microfrontends in Remix and introduces the Tiny Frontend library. Kazoo, a used car buying platform, follows a domain-driven design approach and encountered issues with granular slicing. Tiny Frontend aims to solve the slicing problem and promotes type safety and compatibility of shared dependencies. The speaker demonstrates how Tiny Frontend works with server-side rendering and how Remix can consume and update components without redeploying the app. The talk also explores the usage of micro frontends and the future support for Webpack Module Federation in Remix.
This Talk explores React's internal jargon, specifically fiber, which is an internal unit of work for rendering and committing. Fibers facilitate efficient updates to elements and play a crucial role in the reconciliation process. The work loop, complete work, and commit phase are essential steps in the rendering process. Understanding React's internals can help with optimizing code and pull request reviews. React 18 introduces the work loop sync and async functions for concurrent features and prioritization. Fiber brings benefits like async rendering and the ability to discard work-in-progress trees, improving user experience.
RemixConf EU discussed full stack components and their benefits, such as marrying the backend and UI in the same file. The talk demonstrated the implementation of a combo box with search functionality using Remix and the Downshift library. It also highlighted the ease of creating resource routes in Remix and the importance of code organization and maintainability in full stack components. The speaker expressed gratitude towards the audience and discussed the future of Remix, including its acquisition by Shopify and the potential for collaboration with Hydrogen.
Today's Talk discusses the importance of managing technical debt through refactoring practices, prioritization, and planning. Successful refactoring requires establishing guidelines, maintaining an inventory, and implementing a process. Celebrating success and ensuring resilience are key to building a strong refactoring culture. Visibility, support, and transparent communication are crucial for addressing technical debt effectively. The team's responsibilities, operating style, and availability should be transparent to product managers.
This Talk discusses scaling front-end applications through principles such as tearing down barriers, sharing code in a monorepo, and making it easy to delete code. It also emphasizes incremental migration, embracing lack of knowledge, and eliminating systematic complexity. The Talk highlights the use of automation in code migration and the importance of removing barriers to enable smoother code migration.
This Talk discusses the importance of refactoring in software development and engineering. It introduces a framework called the three pillars of refactoring: practices, inventory, and process. The Talk emphasizes the need for clear practices, understanding of technical debt, and a well-defined process for successful refactoring. It also highlights the importance of visibility, reward, and resilience in the refactoring process. The Talk concludes by discussing the role of ownership, management, and prioritization in managing technical debt and refactoring efforts.
En esta masterclass, discutimos los méritos de la arquitectura sin servidor y cómo se puede aplicar al espacio de la IA. Exploraremos opciones para construir aplicaciones RAG sin servidor para un enfoque más lambda-esque a la IA. A continuación, nos pondremos manos a la obra y construiremos una aplicación CRUD de muestra que te permite almacenar información y consultarla utilizando un LLM con Workers AI, Vectorize, D1 y Cloudflare Workers.
Next.js es un marco convincente que facilita muchas tareas al proporcionar muchas soluciones listas para usar. Pero tan pronto como nuestra aplicación necesita escalar, es esencial mantener un alto rendimiento sin comprometer el mantenimiento y los costos del servidor. En este masterclass, veremos cómo analizar el rendimiento de Next.js, el uso de recursos, cómo escalarlo y cómo tomar las decisiones correctas al escribir la arquitectura de la aplicación.
Transicionar de un rol de contribuidor individual a una posición de liderazgo, especialmente en la industria tecnológica de ritmo acelerado, es enormemente desafiante. La mayoría de los nuevos líderes no reciben ningún tipo de capacitación en los primeros 10 años de sus nuevas responsabilidades.Nuestro completo masterclass está diseñado para ayudar a los nuevos y emergentes líderes tecnológicos a comprender sus nuevos roles y adquirir las habilidades para convertirse en líderes seguros, felices y efectivos.
Una Guía para Desarrolladores sobre Cómo Comunicar, Convencer y Colaborar Efectivamente con los Stakeholders Es una historia tan antigua como el tiempo: la colaboración entre desarrolladores y stakeholders de negocios ha sido durante mucho tiempo un desafío, con una falta de comunicación clara que a menudo deja a ambas partes frustradas. Los mejores desarrolladores pueden comprender profundamente las necesidades de sus contrapartes de negocios, comunicar efectivamente la estrategia técnica sin perder a la audiencia no técnica y convencer al negocio de tomar las decisiones correctas. Trabajando en una consultoría, he fallado y tenido éxito en arquitectar y “vender” visiones técnicas, aprendiendo muchas lecciones en el camino.Ya sea que trabajes en una empresa de productos, seas consultor/freelancer, o quieras aventurarte más allá de ser solo un desarrollador, la capacidad de convencer y comunicar claramente con los stakeholders puede diferenciarte en la industria tecnológica. Esto se vuelve aún más importante con el auge de GenAI y el mercado de desarrolladores cada vez más competitivo, ya que la resolución de problemas y la comunicación efectiva son clave para posicionarte.En esta masterclass, compartiré ejemplos del mundo real, tanto buenos como malos, y te guiaré a través de poner la teoría en práctica mediante dojos.
Integrarse a un nuevo proyecto puede ser difícil, sin importar tu experiencia y antecedentes. Pero puede ser especialmente desafiante para los nuevos desarrolladores recién salidos de la escuela o de un bootcamp de programación. Basándose en su experiencia personal como graduado de un bootcamp y consultor de JavaScript, esta charla discutirá consejos y estrategias para que los gerentes ayuden a los nuevos desarrolladores de sus equipos a familiarizarse con un código desconocido, para que puedan tener un impacto más rápido y efectivo.
Comments