Cómo la Arquitectura y la Infraestructura Pueden Mejorar (o Romper) la Productividad de tu Equipo

**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.

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.

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.