Discusión en Panel: Mono-repo Vs. Multi-repo Vs. Híbrido

Y bienvenidos a todos a nuestra masterclass. Hoy tenemos un gran tema. Así que, Monorepo vs. Híbrido vs. Multirepo y tenemos una lista de oradores.

Así que, oradores por favor, adelante, preséntense. Luke. Hola a todos. Mi nombre es Lukande, pero mucha gente me llama Luke. Soy fan de Star Wars, así que también pueden llamarme Skywalker, si quieren. Y soy de Sudáfrica. Mi nacionalidad real es que soy Zambiano. Soy ingeniero de software senior trabajando en una empresa llamada Entelect software en Sudáfrica.

Y sí, principalmente en el sector de servicios financieros y me enfoco mayormente en la nube y el espacio de dev ops. Bien. Y si ustedes son partidarios de uno de los enfoques, por favor díganme cuál, Luke. ¿Eres un partidario? Mira, estoy entre ambos, multi y mono. Pero para ser honesto, la mayor parte del tiempo opto por el enfoque mono, especialmente incluso con mis proyectos paralelos. Pero supongo que me iría con mono. OK. OK. OK.

Encontré el botón de desactivar silencio. Todavía estoy haciendo eso después de tu COVID. Pero sí. Así que hola, soy Julie. Soy ingeniera en Microsoft. Ayudo a los clientes a usar Azure y a integrarse en Azure. Antes de eso, fui arquitecta empresarial en una compañía de seguros y ayudé a muchos desarrolladores a resolver el tema de dev ops y los mentoreé, los molesté porque siempre tenía que hacer la parte de seguridad también, un poco, ser la mala persona que dice que tienen que firmar sus commits.

Y bienvenidos a todos a nuestra masterclass. Hoy tenemos un gran tema. Así que, Monorepo vs. Hybrid vs. Multirepo y tenemos una lista de oradores. Así que, oradores por favor, adelante, preséntense. Luke. Hola a todos. Mi nombre es Lukande, pero mucha gente me llama Luke. Soy fan de Star Wars, así que también pueden llamarme Skywalker, si quieren. Y soy de Sudáfrica. Mi nacionalidad real es que soy zambiano. Soy ingeniero de software senior trabajando en una empresa llamada Entelect software en Sudáfrica. Y sí, principalmente en el sector de servicios financieros y me enfoco mayormente en la nube y el espacio de dev ops.

Genial. Y si ustedes son partidarios de uno de los enfoques, por favor díganme cuál, Luke. ¿Eres un partidario? Mira, estoy entre ambos, multi y mono. Pero para ser honesto, la mayor parte del tiempo opto por el enfoque mono, especialmente incluso con mis proyectos paralelos. Pero supongo que me iría con mono. OK. OK. OK. Encontré el botón de desactivar silencio. Todavía estoy haciendo eso después de tu COVID. Pero sí. Así que hola, soy Julie. Soy ingeniera en Microsoft. Ayudo a los clientes a usar Azure y a integrarse en Azure. Antes de eso, fui arquitecta empresarial en una compañía de seguros y ayudé a muchos desarrolladores a resolver un poco el dev ops y los mentoreé, los molesté porque siempre tengo que hacer la cosa de seguridad también, un poco, ser la mala persona que dice que tienen que firmar sus commits. Sí, probablemente ahora me vas a preguntar mono, multi, hybrid.

OK. Y voy a dar la respuesta de los arquitectos, que depende de la situación. ¿Cuál es el mejor? {{^}}OK. {{^}}OK.

Bien, bien. Me gusta. Viktor, por favor, adelante. Claro. Soy Viktor. Solía estar en Google en un equipo de Angular. Y aquí es donde realmente, no me enamoré, pero comencé a conocer el desarrollo estilo monorepo y cómo se siente. Así que Google, Facebook, Twitter y otros utilizan una configuración muy similar. Y durante los últimos años, he estado liderando un proyecto llamado Annex, que es una herramienta de monorepo estilo Google para las masas. Así que si no tienes Google, pero quieres hacer algo similar, esto es lo que es. Así que, obviamente, estoy en el campamento Mono, pero en realidad no me importa tanto.

Puedes hacer lo que quieras hacer. OK. Gracias. ¿Y Angelo? Sí. Así que mi nombre es Angelo Rivera, Developer Advocate actualmente en CircleCI. Y antes de eso, trabajé prácticamente en el ejército de EE. UU.

, trabajando en el Comando Espacial hasta pequeñas startups en Europa y EE. UU.

, y luego también volví a trabajar para el gobierno de EE. UU. por un tiempo. Así que tengo una amplia gama de experiencias en muchas cosas. Para responder a tu pregunta sobre cuál es el repositorio preferido, soy híbrido, amigo. ¡Guau!

He visto de todo. OK. Y voy a dar la respuesta de los arquitectos, que depende de la situación. ¿Cuál es el mejor? OK. OK. Bien, bien. Me gusta.

Viktor, por favor, adelante. Claro. Soy Viktor. Solía estar en Google en un equipo de Angular. Y aquí es donde realmente, no me enamoré, pero comencé a conocer el desarrollo estilo monorepo y cómo se siente. Así que Google, Facebook, Twitter y otros utilizan una configuración muy similar. Y durante los últimos años, he estado liderando un proyecto llamado Annex, que es una herramienta de monorepo estilo Google para las masas. Así que si no tienes Google, pero quieres hacer algo similar, esto es lo que es. Así que, obviamente, estoy en el campamento Mono, pero en realidad no me importa tanto. Puedes hacer lo que quieras hacer. OK. Gracias.

¿Y Angelo? Sí. Así que mi nombre es Angelo Rivera, Developer Advocate actualmente en CircleCI. Y antes de eso, trabajé prácticamente en el ejército de EE. UU., trabajando en el Comando Espacial hasta pequeñas startups en Europa y EE. UU., y luego también volví a trabajar para el gobierno de EE.

Pueden ver si tienes diferentes servicios en ese único repositorio, pueden ver toda la extensión del terreno, por así decirlo. Esa sería una de las principales razones por las que creo que esos serían buenos escenarios para un enfoque de monorepo. Con multi-repo, creo que si buscas tener un fuerte sentido de propiedad, eso es algo que creo que se está volviendo cada vez más popular, obviamente, debido a los microservicios.

Eso es bastante bueno tener allí, en mi opinión. Si quieres tener ese tipo de fuerte sentido de propiedad y quieres equipos que estén integrados para tener ese enfoque completo de principio a fin, entonces definitivamente. Estoy muy interesado en escuchar más sobre el enfoque híbrido y dónde hay espacio para eso. Esos serían mis pensamientos.

Viktor, ¿qué piensas sobre esto? Sí, es una buena pregunta, en el sentido de que depende de cómo definas el multi-repo. Si defines el multi-repo en el sentido del multi-repo estilo Google o lo que sea, como el estilo Facebook, un super-repositorio grande, obviamente, eso no funciona para todos. ¿Verdad? Y en el otro lado, tienes tres proyectos uno al lado del otro en la carpeta, ¿verdad? Y también es un repositorio de monitoreo. ¿Verdad? Así que si piensas en el primero... Bien, así que muy pocas empresas deberían adoptar el primero, porque requiere mucha energía experiencia para simplemente gestionar la pila. ¿Verdad? Si piensas en el segundo, funciona para cualquier proyecto, incluso si estoy construyendo un blog, ¿verdad? Y el blog tiene dos características, como la lista y los detalles. Puedo pensar en la lista y los detalles como proyectos separados de los que consta mi blog. Por lo tanto, es un monolito. ¿Verdad? Así que realmente depende, ¿verdad? En términos de la regla general que uso cuando hablo con empresas que ayudan a usar monolitos es que si ellos... Básicamente, si cierran la herramienta a un monolito, en la aplicación, como un gran sistema, pueden aún hacer algún desarrollo estructurado particionando seis de los paquetes, ya sabes, y tratarlo como un monolito con múltiples módulos, y ser construidos de manera independiente y luego ensamblados en un sistema más grande. Pero la ganancia no es tan grande. ¿Verdad? Comparado con cuando tienen cosas como microfrontend, los microservicios, porque básicamente, lo que los monolitos hacen bien, creo, y eso es lo que muchas empresas se dan cuenta, es que ayudan con la coordinación. ¿Verdad? Una vez que tienes un sistema, digamos que consiste en 20 nodos.

Y Julie, ¿qué piensas sobre esto? Así que voy a bajar la cabeza, me siento viejo cuando hago cosas así. Así que he visto de todo, ¿verdad? Como dije antes. Y cuando era arquitecto empresarial, en realidad comencé como ingeniero. Y la gente habla de, oh, deberías usar esto o aquello. Pero veamos cómo es en la vida real, ¿verdad? Así que teníamos algo que se construyó. Era un monolito distribuido en un monorepo. ¿Y cómo lo separas? Así que estaba bien, creo, comenzar con un monorepo porque no estábamos seguros de lo que estábamos construyendo, ¿verdad? En términos de negocio, dominio, ¿qué necesitamos hacer y ejecutar en términos de características para que este producto sea exitoso para el usuario? Así que cuando estás experimentando, no quieres coordinar todo eso. Sí, te dispararás en el pie en otros lugares, ejecutando compilaciones y demás. Así que, en términos de solo qué es mi producto que el usuario realmente ve, es mucho más fácil en el monorepo. Así que creo que tal vez después de un año, llegamos al punto en el que dijimos, oh, tenemos que separar esto ahora. Porque también los ingenieros habían desarrollado suficientes habilidades que realmente queremos separar la aplicación de una sola página y había una aplicación de múltiples capas, ¿verdad? Así que hay diferentes tipos de capas por las que tienes que pasar. Y de nuevo, esto es empresarial. Así que durante un tiempo, tuvimos un monolito distribuido.

Está bien. Angel. Sí. Así que voy a tomar un enfoque diferente a tu pregunta. Creo que realmente no importa cómo estructures tu código y dónde lo estructures. Quiero decir, estas son básicamente solo ubicaciones. ¿Verdad? Como donde estamos almacenando las cosas. Y creo que el problema que todos tenemos es la herramienta. Creo que Victor ha tocado eso un poco. La herramienta es ineficiente. ¿Verdad? Así que no me importa dónde trabajes. Google, Facebook, CircleCI, Microsoft. Los sistemas de control de versiones que tenemos simplemente no son… No son buenos. Es cierto. Los has ejecutado a gran escala. Es una porquería. ¿Verdad? Simplemente no estamos allí todavía.

Muchas gracias. Sí, tienes razón sobre las herramientas. Y déjame hacerte entonces una pregunta corta, supongo que para escuchar una respuesta corta, solo sobre las herramientas que usas. ¿Cuál es la configuración preferible para ti, si hablas sobre el monorepo, enfoques de monorepo híbrido Julie? Sí, ¿cuál es la lista de tecnologías de configuración preferible que usas? Si eliges monorepo o digamos un enfoque híbrido?

Así que aquí está la cosa, no estoy seguro de estar 100% de acuerdo con Angel. ¿Por qué? Bueno, de nuevo, tengo mi sombrero de arquitecto empresarial puesto y el problema de seguridad, ¿verdad? ¿Quién está trabajando en algo? Cuando tienes un sistema, siempre tienes más carga de gestión para separar a esas personas. Vengo de industrias reguladas y eso siempre es algo que tienes que resolver. Y si no tienes suficientes personas para hacerlo, entonces dices, simplemente dividámoslos, todos los diferentes equipos, incluso si están construyendo un monolito distribuido.

No sé, siento que las herramientas no resuelven problemas de personas. Al final del día, gran parte de esta coordinación, y eso es lo que mencioné en mi charla, asegurando que todo vaya bien desde tu laptop hasta empujar a Git y realmente desplegar, es todo un baile. Es toda una coreografía más que las herramientas. Dame cualquier cosa y sí, una será mejor que la otra, pero lo que realmente duele es trabajar con otras personas, ¿verdad? Si pudiera construir mi propia cosa y full stack, entonces sin personas, sin problemas. Esa es mi respuesta. Me estaría oponiendo a eso. Vamos.

Es muy obvio que tenemos un problema de herramientas. Quiero decir, de lo que hablaste, sí, estoy de acuerdo al cien por ciento en que las personas se interponen en el camino de los demás. Creo que eso es más un problema de DevOps, ¿verdad? Así que estamos hablando de cultura en ese punto. De lo que estoy hablando es de la indexación del repositorio. Los índices se están volviendo astronómicamente grandes, ineficientes. Esa es la razón por la cual Facebook, Twitter, Google tienen todos sus propios sistemas internos construidos porque la indexación lenta inherente de Git es extremadamente dolorosa. Una vez que llega a un punto donde hablas de terabytes de datos, en realidad incluso menos que eso, ¿verdad? En algunos casos.

Así que el otro punto para contrarrestar eso sería que, sí, tenemos un problema de personas, si solucionas ese problema inherente con las herramientas de versionado, ¿verdad? También puedes abordar los problemas de seguridad de los que hablas. Eso es fácilmente abordable a través de la automatización. Yo lanzaría plataformas de CI CD a ese problema de seguridad, ¿verdad? Para colaborar en torno a eso.

Estoy seguro de que eso se convertirá eventualmente en su propia línea de productos, pero ahora mismo lo estás obteniendo gratis. Así que esas preguntas de tipo seguridad están siendo respondidas actualmente. No son perfectas, de ninguna manera.

Pero creo que con DevOps implementando eso para manejar la parte de las personas, es un problema separado de los sistemas de control de versiones y la razón por la que tenemos charlas sobre mono-repo, o esta conversación. Mi opinión. Creo que venimos de grandes industrias, ¿verdad? Me encantaría escuchar lo que Luke, por ejemplo, ve, porque estamos muy sesgados en el gran Microsoft, Google y Facebook. Así que me encantaría escuchar lo que piensa Luke. Eso somos nosotros, ¿no puede Luke? Sí. Sí, así que estoy en la industria de la burocracia, hombre, con el financiero... Sí, así que no es tan pequeño, ¿verdad?

Correcto, y mira, una de las cosas que encuentro realmente desafiantes, y me encantaría escuchar tus opiniones sobre esto, es cuando tienes equipos enormes trabajando en un mono-repo, así que creen en los beneficios que proporcionaría un mono-repo, pero están tratando de hacer cumplir ese tipo de sistema. ¿Y cómo funciona eso en términos de estándares de commit? E incluso estándares en términos de mejores prácticas.

Así que por eso realmente me inclino incluso hacia, definitivamente hay un elemento humano en esto, y tal vez comenzando desde ahí. Las herramientas son, obviamente, un factor importante, pero creo que he visto muchos de los problemas de personas, y que tal vez si comenzáramos desde ahí, y tratáramos de resolver las cosas desde ahí, y construir desde ahí en términos del paradigma que deberíamos estar usando, en lugar de... No todos los proyectos son iguales, no todas las empresas son iguales, y obviamente habrá una tentación con las empresas más grandes de la industria. Lo he visto donde es como, oh, pero Google está practicando esto, por lo tanto, hagamos eso también. Fue como, no somos Google, y nuestro equipo no está estructurado como los equipos que tienen allí. No tenemos el mismo tipo de madurez que tienen en términos de las herramientas adicionales que están usando para hacer las cosas más eficientes. Así que sí, esos serían mis pensamientos sobre esa área en particular. Solo quiero aclarar que mencioné equipos o la pieza de herramientas como el génesis del problema, pero estoy de acuerdo al 100% en que todo se trata de la escala. Así que estoy hablando de ejecutar estos repos a gran escala, pero sí, por supuesto. Y por eso dije híbrido, ¿verdad? Recuerda eso.

Oh, sí. Víctor, ¿podrías compartir tus pensamientos? Claro. Eso es en realidad un punto muy bueno, muy interesante. Y creo que realmente depende de, nuevamente, cómo defines un mono-repo. Si miras a una escala de Google o una escala de Facebook, escala de Microsoft, bueno sí, muchas herramientas, por supuesto, no funcionan realmente bien. Tienes que usar como GVFS, hacer muchas cosas interesantes para que realmente puedas recorrer tu repo. Así que nosotros, como, personalmente trabajo con muchas grandes empresas construyendo grandes sistemas, pero no tenemos un uber-mono-repo que ejecute toda la organización. Generalmente es como si tuviéramos diez equipos ejecutando un mono-repo que contribuyen a un sistema. Y una vez que llegas a esa escala, no es que funcione. Así que, tienes que ir más allá de eso. Así que creo que para la mayoría de las organizaciones, un uber-mono-repo no funcionará de todos modos, por razones organizativas. Es como si no pudieras... Ni siquiera pueden pagar por la misma caja de Azure para ejecutar CICD, porque dos trabajos tienen diferentes presupuestos. Así que, ni hablar de herramientas, como solo esas organizaciones no pueden acordar solo por razones comerciales para moverse juntas. Cuando hablo de mono-repos, y los beneficios de esos, no me refiero a la escala del mono-repo de Google en términos de escala. Me refiero al estilo de mono-repo de Google. Tienes el mismo tipo de herramientas, pero un sistema más pequeño, un sistema mucho, mucho, mucho más pequeño. Digamos que tenemos mil desarrolladores trabajando en ello, donde tienes tal vez decenas de millones de líneas de código. No estamos hablando de un sistema masivo que ha ejecutado el mundo, más bien tenemos diez aplicaciones que comprenden esta experiencia con la que la mayoría de los clientes, quizás, como, digamos, de un banco, interactúan con. Así que, en ese punto, las herramientas son menos un problema. Cuando se trata de cómo los equipos deben coordinarse, creo que es cierto que, al final del día, todo termina siendo un problema de personas, y que tienes que trabajar juntos, acordar estándares y cosas. Pero no es como si las personas, no sé cuál va primero. Como, si tomas las redes sociales como un ejemplo y dices, sí, si todos fuéramos personas normales, no sería difícil en las redes sociales. Seríamos amables entre nosotros. Pero no lo somos. Pero es parcialmente porque las redes sociales nos obligan a no ser amables entre nosotros. Como, son los incentivos que están ahí.

Si tienes buenas herramientas que te permiten separar tu código del código de los demás, para hacer cumplir las mejores prácticas de una manera relativamente avanzada, la gente se coordina mejor. Parte del dolor desaparece, y tienes una buena experiencia donde realmente puedes lidiar con las cosas.

Así que, no sé cuál es más primario. Creo que las herramientas... Soy un proveedor de herramientas. Así que, obviamente, no soy un consultor ágil.

Estoy proporcionando herramientas. Estoy más inclinado hacia las herramientas porque siento que eso es algo que puedes... Tienen un costo relativamente bajo, y se pueden integrar relativamente rápido, en comparación con cambiar a, como, la estructura organizativa, o la cultura, o incluso la naturaleza humana, que es mucho más difícil de hacer. Así que, esas cosas... Está bien, yo, ya sabes, dejo que la gente de ThoughtWorks pelee la batalla. No estoy peleando esa batalla. Estoy peleando la batalla. Ciertas cosas deberían ser más simples. Algunas interacciones deberían ser más simples, de tal manera que el costo de una interacción sea menor, y cuando se trata de un punto anterior, en realidad quería agregar un comentario, pero no estaba seguro si debería interrumpir en eso. En realidad, creo que otra cosa sobre los monorepos que encuentro interesante, que la gente a menudo asume que si estás en el mismo repo, estás necesariamente más acoplado entre sí, ¿verdad? Pero no es difícil imaginar con Propa2 y BluBit, no funciona, ¿de acuerdo?

Los repos de Google parecen estar más acoplados entre sí que, como, una organización Polyrepo, ¿verdad? Como, puedes tener límites dentro de un monorepo que son tan estrictos como si tuvieras un Polyrepo. Así que hay algunas cosas en las que tienes que ponerte de acuerdo, ¿verdad?, por supuesto, pero no significa que estés necesariamente construyendo un monolito enrevesado donde puedes trazar límites organizativos. Puedes trazar límites organizativos, puedes hacer todas las cosas que la Ley de Conway requeriría que hicieras, ¿verdad? Así que no es realmente un solo pensamiento porque hay muchos puntos que se hicieron antes, ¿verdad? Así que solo para aclarar, las herramientas son una base de cosas que puedes comprar o integrar de manera económica, en comparación con muchas otras cosas, ¿verdad? Y luego, una vez que las tienes, necesitas resolver los problemas de las personas, porque al final del día, eso es lo que resulta en que tu código sea un poco suelto y cosas así, ¿verdad? Suena como si estuvieras en mi campo con el híbrido. Quiero decir, creo que la palabra híbrido también, como si tuvieras un repo para una suborg, es más que un repo para esa org, ¿verdad? Si no interactúa con otro monolito, si estás en una isla y tienes un solo barco yendo de un lado a otro, no es realmente un híbrido. Sigues estando solo, ¿verdad? Así que no lo llamaría un híbrido. Pero si así es como definimos híbrido, entonces sí, ¿verdad? Creo que la mayoría de las organizaciones deberían optar por un enfoque híbrido, teniendo uno sobre un gran repo para toda la organización.

Eso simplemente no funciona, ni hablar de las herramientas, ¿verdad? No podrán comprar máquinas o cualquier recurso para pagarlo porque no podrán ponerse de acuerdo sobre el presupuesto, ¿verdad? Así que hay muchos problemas allí para la mayoría de las organizaciones.

Sí. El híbrido para mí es la capacidad de simplemente, como dije, introducir las bases de código que necesitas introducir para tu automatización, ¿verdad? Tus procesos, tus procesos de construcción cuando los necesites. Así que para mí, no importa dónde vivan estas cosas y cómo vivan. Si están separadas o si están acopladas, no me importa siempre que mis herramientas puedan, tú sabes, completar y ejecutar las tareas que necesito que completen cuando necesito que las completen. Sí. No, lo entiendo. Tengo otro punto que sé que quieres decir. Voy a interrumpir porque he tenido mi mano virtual levantada por un tiempo y ahora tengo mi mano física. Solo quería preguntarte, por favor. Sí. Así que retrocedamos un poco, ¿verdad? Como, solo, me preocupa a veces, ¿quién es nuestra audiencia? Estamos lanzando tantas cosas por ahí, ¿verdad? Hagamos esto un poco más concreto. Seguimos hablando de herramientas y obteniendo cosas y repos, ¿verdad? Así que, haciéndolo más concreto, ¿qué tenemos para herramientas? Tenemos protección de ramas, tenemos solicitudes de extracción, ¿verdad? ¿Cómo quieres encajar todo eso?

Usa nombres, no uses comida y bar, frutas y verduras, ¿cómo trabajan juntas? Y de nuevo, tal vez le pregunte a un compañero panelista sobre otras herramientas que piensen, pero las que siempre me vienen a la mente primero son las solicitudes de extracción y la protección de ramas. Bueno, esos elementos de las solicitudes de extracción, ¿verdad? Esos están fuera de, como, las herramientas de versionado centrales, ¿verdad? Así que eso es un producto de GitHub, sabes, lo llaman de otra manera en otro producto. Así que creo que, sabes, mirando las herramientas de manera nativa, entonces estoy de acuerdo al 100%, hay un elemento humano, obviamente, en eso. Pero creo que es una conversación que debe tenerse fuera del monorepo, porque una vez que resuelves las partes de integración continua de tus procesos, ¿verdad?, esa es la, en mi opinión, la parte de las personas desarrolladoras donde están colaborando alrededor del código, ¿verdad? No creo que importe dónde viva el código y cómo se integre en tus procesos. ¿Verdad? Así que para mí, son dos cosas separadas, aunque están relacionadas.

Okay, gracias a todos. Siguiente pregunta sobre estadísticas. Así que acabas de decir muchas cosas interesantes sobre estos enfoques. Pero, ¿qué pasa con las estadísticas? ¿Podrías compartir algunas estadísticas como la velocidad de desarrollo, nuevamente, el proceso de CI, CD, aplicaciones de código y así sucesivamente, indexación, Angel. Entonces, Luke, ¿qué piensas sobre esto? Sí, supongo que podría hablar un poco sobre el despliegue, un poco y solo si estoy entendiendo correctamente. Quiero decir, así que tienes, nuevamente, esto es un poco volver a la situación de que depende o caso por caso, ¿verdad? Así que con MonoRepo, dependiendo de cómo lo hayas estructurado, podrías tener un flujo de despliegue relativamente rápido en ese sentido, si está estructurado correctamente nuevamente, y luego dependiendo de las herramientas adicionales que estés utilizando. Y esto va a variar. La norma de lo que encontrarás es que cuanto más grande y más complejo se vuelva, más lentas pueden volverse las cosas. Pero incluso eso sigue siendo un poco subjetivo, porque al final se reduce a, bueno, ¿qué herramientas estás utilizando?

Así que sí, esos serían mis pensamientos sobre eso. Angel, ya dijiste sobre indexación, seguridad, ¿qué más puedes mencionar aquí? Sí. Así que tienes que. Estoy 100% de acuerdo con Luke y todos los demás que mencionaron esto. Esto es caso por caso, ¿verdad? Los equipos de todos son diferentes, y creo que Julie incluso tocó un poco esto también. Pero tienes que entender, para volver al punto de Julie. Nos movimos un poco por todas partes, y probablemente sea mi culpa, pero tiendo a hacer eso. Pero para volver a enfocar todo esto, tienes que entender qué estás heredando, ¿verdad? Como desarrollador, he estado en muchas organizaciones, heredé el código de otras personas. Todos heredamos, ¿verdad?, en algún momento, algún código. La mayor lucha que he tenido fue exactamente de lo que estamos hablando hoy, es, como, está bien, ¿qué hago con esto, verdad? Así que, es un monorepo, ¿cómo... Vengo del mundo de, desacoplaré las cosas, porque me gustan los fragmentos más pequeños y manejables, ¿verdad? Pero no puedes entrar a una empresa como, no quiero decir el nombre, pero hay un cliente nuestro que es enorme, una empresa enorme, ha estado alrededor por un tiempo, tienen un monorepo que es inmenso, ¿verdad? Si lo rompieran, solo les costaría millones, probablemente miles de millones de dólares. No vamos a hacer eso, así que tenemos que operar dentro de nuestro contexto. Y ese es mi punto, ¿verdad? Como, primero evalúa qué está pasando con tus equipos, tu base de código, ¿se pueden desacoplar las cosas, verdad? Lentamente, tal vez, pero ¿deberías desacoplarlas, verdad? Como, si tu monolito está funcionando y es increíble, genial, no veo ninguna razón por la que debas desacoplarlo. Pero si hay mejoras que puedes hacer que hagan las cosas más eficientes, al punto de Luke, bases de código más pequeñas funcionan más rápido. Estoy totalmente a favor de la eficiencia, haciendo que la duración de mis compilaciones sea lo más pequeña posible. Así que, mira las cosas desde esa perspectiva. ¿Cómo puedes optimizar? Pero también tienes ese costo, ¿verdad? Como, ¿va a costarle a la empresa o a la organización millones de dólares implementar un cambio?

Está bien, veo. Gracias. Víctor, ¿te gustaría compartir algunas estadísticas? Claro, así que creo que es… Si quieres argumentar a favor de Polyamore, siempre puedes presentar algunos números para probar el caso. Así que la forma en que… lo que mediría, ¿verdad? Como el rendimiento de las herramientas y luego el rendimiento de la organización. El rendimiento de las herramientas sería cosas como CICD, tiempo promedio, tiempo en el peor de los casos, cosas así, ¿verdad? Y luego, quiero decir, dependiendo de cómo midas, puedes hacer que más de un repo sea más rápido. Por ejemplo, si tienes un sistema que consiste en 40 repos o 4 módulos que pueden estar en un repo, múltiples repos, forman una, digamos, una forma de diamante, ¿sí? Harán un cambio en el de abajo. ¿Me importa verificar el de abajo o me importa integrar el de abajo como a través del de arriba, ¿verdad? Y ¿básicamente cuento esta ejecución de CICD en caso de poly-repo o todas las ejecuciones de CICD? Eso será necesario, ¿verdad? Cosas así. Así que, si comienzas a hacer eso, entonces, ya sabes, dependiendo de lo que elijas hacer, ¿verdad? Creo que al final es lo mismo, ¿verdad? Y eso, por supuesto, puedes, como, todos distribuyen CI, ¿verdad? Incluso si tienes un repo pequeño que distribuyes CI, no ejecutas en un solo agente. Una vez que comienzas a distribuir CI, realmente no importa si tienes monorepo o poly-repo en que aún ejecutas tu CI en como 30 cajas al mismo tiempo, o 50 cajas, sea cual sea el tamaño de tu repo, ¿verdad? Así que, siempre puedes hacer que tu monorepo o poly-repo sea lo suficientemente rápido. Lo que sea lo suficientemente rápido depende... ¿Quieres decir que es como 20 minutos en el peor de los casos, ¿verdad? Eso se puede hacer para un repo de prácticamente cualquier tamaño, ¿verdad? A menos que tengas un nodo grande que no se puede dividir, en cuyo caso, de nuevo, es un punto irrelevante entre poly- y monorepo, porque tienes el mismo nodo que se puede dividir en cualquiera de los casos, ¿verdad? Así que, creo que realmente no importa. Así que, en términos de, como, el rendimiento de las herramientas se puede hacer funcionar con cualquiera de los dos. El rendimiento de la organización es una cosa diferente, ¿verdad? Entonces comienzas a medir cosas como, ¿qué pasa si quiero compartir un código, como esta es mi intención como desarrollador, como, ¿cuánto tiempo me lleva compartir un código entre, como, yo mismo y otro miembro del equipo, o como, de un proyecto diferente, por ejemplo, ¿verdad? ¿Toma una hora, un día, una semana, un mes, ¿verdad? Y en un monorepo, eso es mucho más pequeño. Ese es el beneficio del monorepo, ¿verdad? Compartir es más fácil, ¿verdad? Pero si mides cosas diferentes, entonces puedes hacer que poly-repo parezca mejor. Realmente depende de lo que te importe, ¿verdad? La mayoría de las organizaciones con las que trabajo quieren compartir más, no menos, ¿verdad? Están demasiado divididas en líneas de negocio y cosas así, ¿verdad?, así que para ellos, buscan compartir como algo para optimizar, ¿verdad? Así que el monorepo es bueno en ese caso, ¿verdad? Pero si tienes uno, ya sabes, pegado, o si quieres dividirlos más, quizás quieras compartir menos, ¿verdad? Por razones organizativas, en cuyo caso, aún podrías usar un monorepo para hacer eso, pero polyrepo te da una especie de, de una manera más natural, ¿verdad? Sí, casi nos estamos quedando sin tiempo. Me gustaría preguntar a Julie, Julie, esa es tu última respuesta. ¿Qué piensas sobre esto? Todo depende. Creo que podemos continuar en el chat espacial para las personas que quieran debatir con nosotros. Está bien, creo. Gracias a todos. Eso fue muy interesante. Gracias. Adiós.

Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye.

Bien. Sí. Está bien. Así que la primera pregunta, ¿podrías decirme y pensar en cuál es mejor para diferentes tipos de proyectos y por qué? Luke, por favor. Claro. Así que supongo que solo desde la experiencia personal así como aprendiendo de otros, creo que el enfoque de monorepo es genial cuando se trata de trabajar con proyectos de tamaño pequeño o mediano y es realmente bueno para ayudar con la transferencia de conocimientos en los equipos. Esa es una de las cosas que más me gusta de ello. Puedes tener fácilmente a las personas integradas para obtener una visión general de lo que es todo el proyecto. Pueden ver si tienes diferentes servicios en ese único repositorio, pueden ver toda la extensión del terreno, por así decirlo. Esa sería una de las principales razones por las que creo que esos serían buenos escenarios para un enfoque de monorepo. Con multi-repo, creo que si estás buscando tener una fuerte propiedad, eso es algo que creo que se está volviendo cada vez más popular, obviamente, debido a los microservicios. Eso es bastante bueno tener allí, en mi opinión. Si quieres tener ese tipo de fuerte propiedad y quieres que los equipos estén integrados para tener ese enfoque completo de principio a fin, entonces definitivamente. Estoy muy interesado en escuchar más sobre el enfoque híbrido y dónde hay espacio para eso. Esos serían mis pensamientos. Gracias. Viktor, ¿qué piensas sobre esto? Sí, es una buena pregunta, en el sentido de que depende de cómo definas el multi-repo. Si defines el multi-repo en el sentido del multi-repo estilo Google o lo que sea, como el estilo Facebook, un super-repositorio grande, obviamente, eso no funciona para todos. ¿Verdad? Y por el otro lado, tienes tres proyectos uno al lado del otro en la carpeta, ¿verdad? Y también es un repositorio de monitoreo. ¿Verdad? Así que si piensas en el primero... Está bien, así que muy pocas empresas deberían adoptar el primero, porque requiere mucha energía y experiencia para solo gestionar la pila. ¿Verdad? Si piensas en el segundo, funciona para cualquier proyecto, incluso si estoy construyendo un blog, ¿verdad? Y el blog tiene dos características, como la lista y los detalles. Puedo pensar en la lista y los detalles como proyectos separados de los que consiste mi blog. Por lo tanto, es un monolito. ¿Verdad? Así que realmente depende, ¿verdad? En términos de la regla general que uso cuando hablo con empresas que ayudan a usar monolitos es que si lo hacen... Básicamente, si cierran la herramienta a un monolito, en la aplicación, como un gran sistema, pueden aún hacer un desarrollo estructurado particionando seis de los paquetes, ya sabes, y tratarlo como un monolito con múltiples módulos, y ser construidos de manera independiente y luego ensamblados en un sistema más grande. Pero la ganancia no es tan grande. ¿Verdad? Comparado con cuando tienen cosas como microfrontend, los microservicios, porque básicamente, lo que los monolitos hacen bien, creo, y eso es lo que muchas empresas se dan cuenta, es que ayudan con la coordinación. ¿Verdad? Una vez que tienes un sistema, digamos que consiste en 20 nodos. ¿Verdad? Necesito trabajar en esos 20 nodos de manera estructurada.

¿Verdad? Comparte código, ya sabes, averigua cómo desplegarlo. ¿Qué es un sistema? {{^}}¿Verdad? Poder generar los 20 nodos en desarrollo e interactuar con ellos. ¿Verdad? Ahí es donde necesitas estas herramientas adicionales. ¿Verdad? Las herramientas de estilo monorepo, que te ayudarán a gestionar ese sistema. ¿Verdad? Cuantos más nodos tengas, mayor será la ganancia. ¿Verdad? Así que si tienes, ya sabes, 100 nodos, bueno, entonces tienes que tener algo que te ayude a gestionar 100 nodos. ¿Verdad? Así que, obviamente, es una especie de cosa de gallina y huevo, si tienes buenas herramientas, crearás más nodos porque es más fácil. ¿Verdad? Así que a veces es un poco difícil de medir. Pero en general, creo que, contraintuitivamente, si tienes microservicios y microfrontends, en realidad te beneficias más del monorepo porque necesitas coordinarlos de alguna manera en desarrollo y en despliegue.

Está bien. Gracias. Y Julie, ¿qué piensas sobre esto? Así que voy a bajar la cabeza, me siento viejo cuando hago cosas así. Así que he visto de todo, ¿verdad? Como dije antes. Y cuando era arquitecto empresarial, en realidad comencé como ingeniero. Y la gente habla de, oh, deberías usar esto o aquello. Pero veamos cómo es en la vida real, ¿verdad? Así que teníamos algo que se construyó. Era un monolito distribuido en un monorepo. ¿Y cómo lo separas? Así que estaba bien, creo, comenzar con un monorepo porque no estábamos seguros de lo que estábamos construyendo, ¿verdad? En términos de negocio, dominio, ¿qué necesitamos hacer y ejecutar en términos de características para que este producto sea exitoso para el usuario?

Así que cuando estás experimentando, no quieres coordinar todo eso. Sí, te dispararás en el pie en otros lugares, ejecutando compilaciones y demás. Así que, en términos de solo qué es mi producto que el usuario realmente ve, es mucho más fácil en el monorepo. Así que creo que tal vez después de un año, llegamos al punto en el que dijimos, oh, tenemos que desarmar esto ahora. Porque también los ingenieros habían desarrollado suficientes habilidades que realmente queríamos separar la aplicación de una sola página y había una aplicación de múltiples capas, ¿verdad? Así que hay diferentes tipos de capas por las que tienes que pasar. Y de nuevo, esto es empresarial. Así que durante un tiempo, tuvimos un monolito distribuido. Los separamos en repos y luego los incorporamos como submódulos de Git, lo cual fue también menos que ideal, pero es un poco ese estado intermedio hasta que llegues al punto, si alguna vez llegas a ese punto, donde tienes microservicios. Y no todos llegan a ese punto. A veces vuelves a un monorepo. Y ahora, y siempre tengo mi sombrero de arquitecto puesto. Digo, no me importa.

Simplemente envía. Lo que funcione para ti. Está bien. Ángel. Sí. Así que voy a tomar un enfoque diferente a tu pregunta. Creo que realmente no importa cómo estructures tu código y dónde lo estructures. Quiero decir, estas son básicamente solo ubicaciones. ¿Verdad? Como donde estamos almacenando las cosas.

Y creo que el problema que todos tenemos es la herramienta. Creo que Víctor ha tocado eso un poco. La herramienta es ineficiente. ¿Verdad? Así que no me importa dónde trabajes. Google, Facebook, CircleCI, Microsoft. Los sistemas de control de versiones que tenemos simplemente no son… No son buenos. Es cierto. Los has ejecutado a gran escala. Es una basura. ¿Verdad?

Simplemente no estamos allí todavía. La industria. Sabes, hemos hecho enormes progresos. Créeme. He estado en este negocio mucho tiempo, pero la herramienta es donde están los problemas. Víctor fue uno que trabajó en Google. Tienen un enorme monorepo. Tuvieron que construir su propia herramienta interna para gestionar el proceso de versionado. Comencemos con la herramienta. Creo que ahí es donde proviene todo el dolor. Y hasta que eso mejore, o evolucione a un estado donde podamos hacer versionado de manera bastante competente, entonces creo que algunos de estos otros problemas serán irrelevantes.

Por eso dije que el híbrido es donde estoy, porque cuando hablas de repos y monorepos, ¿dónde se mantiene y almacena ese código? Y luego el problema son las herramientas que usamos para versionar esas cosas, ¿verdad? Así que esa es mi respuesta. Muchas gracias.

Sí, tienes razón sobre las herramientas. Y déjame hacerte entonces una pregunta corta, supongo que para escuchar una respuesta corta, solo sobre las herramientas que usas. ¿Cuál es la configuración preferible para ti, si hablas sobre el monorepo, el monorepo híbrido enfoques, Julie?

Sí, ¿cuál es la lista de tecnologías de configuración preferible que usas? Si eliges el monorepo o digamos el enfoque híbrido? Así que aquí está la cosa, no estoy segura de que esté 100% de acuerdo con Angel. ¿Por qué? Bueno, de nuevo, tengo mi sombrero de arquitecto empresarial puesto y el problema de seguridad, ¿verdad? ¿Quién está trabajando en algo? Cuando tienes un sistema, siempre tienes más carga de gestión para separar a esas personas. Vengo de industrias reguladas y eso siempre es algo que tienes que resolver.

Y si no tienes suficientes personas para hacerlo, entonces dices, simplemente dividámoslos, todos los diferentes equipos, incluso si están construyendo un monolito distribuido. No sé, siento que las herramientas no resuelven los problemas de las personas. Al final del día, gran parte de esta coordinación, y eso es lo que mencioné en mi charla, asegurando que todo vaya bien desde tu laptop hasta empujar a Git y realmente desplegar, es todo un baile. Es toda una coreografía más que las herramientas. Dame cualquier cosa y sí, una será mejor que la otra, pero lo que realmente duele es trabajar con otras personas, ¿verdad?

Esa es mi respuesta. Estaría rechazando eso. Vamos. Es muy obvio que tenemos un problema de herramientas. Quiero decir, de lo que hablaste, sí, estoy de acuerdo al cien por ciento en que las personas se interponen en el camino de los demás. Creo que eso es más un problema de DevOps, ¿verdad? Así que estamos hablando de cultura en ese punto.

De lo que estoy hablando es de la indexación de repositorios. Los índices se están volviendo astronómicamente grandes, ineficientes. Esa es la razón por la que Facebook, Twitter, Google tienen todos su propio sistema interno construido porque la indexación inherente de gets es inherentemente lenta, extremadamente dolorosa. Una vez que llega a un punto en el que estás hablando de terabytes de datos, en realidad incluso menos que eso, ¿verdad? En algunos casos.

Así que el otro punto para contrarrestar eso sería que, sí, tenemos un problema de personas, si solucionas ese problema inherente con la herramienta de versionado, ¿verdad? También puedes abordar los problemas de seguridad de los que estás hablando. Eso es fácilmente abordable a través de la automatización. Yo lanzaría plataformas de CI CD a ese problema de seguridad, ¿verdad? Para colaborar en torno a eso. Y estamos viendo enormes ganancias en seguridad, ¿verdad? Como incluso Azure, GitHub ahora ha comprado lo que era Semmle, los adquirieron. Y ahora tienen un ligero, diría, hacen escaneo de seguridad para ti de forma predeterminada en la plataforma.

Y ahora tienen un ligero, diría, hacen escaneo de seguridad para ti de forma predeterminada en la plataforma. Estoy seguro de que eso crecerá en su propia línea de productos eventualmente, pero ahora mismo estás recibiéndolo gratis. Así que esas preguntas de tipo seguridad están siendo respondidas actualmente. No son perfectas, de ninguna manera. Pero creo que con DevOps implementando eso para manejar la parte de las personas, es un problema separado de los sistemas de control de versiones y la razón por la que tenemos charlas de monorepo, o esta conversación. Mi opinión. Creo que venimos de grandes industrias, ¿verdad? Me encantaría escuchar lo que Luke, por ejemplo, ve, porque estamos muy sesgados en el gran Microsoft, Google y Facebook. Así que me encantaría escuchar lo que piensa Luke. Eso somos nosotros, ¿no Luke? Sí. Sí, así que estoy en la industria de la burocracia, hombre, con el financiero... Sí, así que no es tan pequeño, ¿verdad? Correcto, y mira, una de las cosas que encuentro realmente desafiantes, y me encantaría escuchar tus opiniones sobre esto, es cuando tienes equipos enormes trabajando en un monorepo, así que creen en los beneficios que un monorepo proporcionaría, pero están tratando de hacer cumplir ese tipo de sistema. ¿Y cómo funciona eso en términos de estándares de commit? E incluso estándares en términos de mejores prácticas. Así que por eso realmente me inclino incluso hacia, definitivamente hay un elemento humano en esto, y tal vez comenzando desde ahí. Las herramientas, obviamente, son un factor importante, pero creo que he visto muchos de los problemas de las personas, y que tal vez si comenzamos desde ahí, y tratamos de resolver las cosas desde ahí, y construir desde ahí en términos del paradigma que deberíamos estar usando, en lugar de... No todos los proyectos son iguales, no todas las empresas son iguales, y obviamente habrá una tentación con las empresas más grandes en la industria. Lo he visto donde es como, oh, pero Google está practicando esto, por lo tanto, hagamos eso también. Fue como, no somos Google, y nuestro equipo no está estructurado como los equipos que tienen allí. No tenemos el mismo tipo de madurez que tienen en términos de las herramientas adicionales que están usando para hacer las cosas más eficientes. Así que sí, esos serían mis pensamientos sobre esa área en particular. Solo quiero aclarar que mencioné equipos o la parte de las herramientas siendo el génesis de el problema, pero estoy de acuerdo al 100% en que todo se trata de escala. Así que estoy hablando de ejecutar estos repos a gran escala, pero sí, por supuesto. Y por eso dije híbrido, ¿verdad? Recuerda eso. Oh, sí. Víctor, ¿podrías compartir tus pensamientos? Claro. Eso es en realidad un muy buen, un punto muy interesante. Y creo que realmente depende de, de nuevo, cómo defines un monorepo. Si miras a una escala de Google o una escala de Facebook, escala de Microsoft, bueno sí, muchas herramientas por supuesto no funcionan realmente bien. Tienes que usar como GVFS, hacer muchas cosas interesantes para que puedas realmente atravesar tu repo. Así que nosotros, como, personalmente trabajo con muchas grandes empresas construyendo grandes sistemas, pero no tenemos un uber-monorepo que ejecute toda la organización. Generalmente es como si tuviéramos diez equipos ejecutando un monorepo que contribuyen a un sistema.

Y una vez que llegas a esa escala, no es que funcione. Así que, tienes que ir más allá de eso. Así que creo que para la mayoría de las organizaciones, un uber-monorepo no funcionará de todos modos, por razones organizativas. Es como si no pudieras… Ni siquiera pueden pagar por la misma caja de Azure para ejecutar CICD, porque dos trabajos tienen diferentes presupuestos. Así que, ni hablar de herramientas, como solo esas organizaciones no pueden acordar solo por razones comerciales para moverse juntas.

Cuando hablo de monorepos, y los beneficios de esos, no me refiero a la escala del monorepo de Google en términos de escala. Me refiero al estilo de monorepo de Google. Tienes el mismo tipo de herramientas, pero un sistema más pequeño, un sistema mucho, mucho, mucho más pequeño. Digamos que tenemos mil desarrolladores trabajando en ello, donde tienes tal vez decenas de millones de líneas de código. No estamos hablando de un sistema masivo que ha ejecutado el mundo, más bien tenemos diez aplicaciones que comprenden esta experiencia con la que la mayoría de los clientes, quizás, como, digamos, de un banco, interactúan con. Así que, en ese punto, las herramientas son menos un problema.

Cuando se trata de cómo los equipos deben coordinarse, creo que es cierto que, al final del día, todo termina siendo un problema de personas, y que tienes que trabajar juntos, acordar estándares y cosas. Pero no es como si las personas, no sé cuál va primero. Como, si tomas las redes sociales como un ejemplo y dices, sí, si todos fuéramos personas normales, no sería difícil en las redes sociales. Seríamos amables entre nosotros. Pero no lo somos. Pero es parcialmente porque las redes sociales nos obligan a no ser amables entre nosotros. Como, son los incentivos que están ahí. Lo mismo con las herramientas.

Si tienes buenas herramientas que te permiten separar tu código del código de los demás, para hacer cumplir las mejores prácticas de una manera relativamente avanzada, la gente se coordina mejor. Parte del dolor desaparece, y tienes una buena experiencia donde realmente puedes lidiar con las cosas. Así que, no sé cuál es más primario. Creo que las herramientas... Soy un proveedor de herramientas. Así que, obviamente, no soy un consultor ágil. Estoy proporcionando herramientas. Estoy más inclinado hacia las herramientas porque siento que eso es algo que puedes... Tienen un costo relativamente bajo, y se pueden integrar relativamente rápido, en comparación con cambiar a, como, la estructura organizativa, o la cultura, o incluso la naturaleza humana, que es mucho más difícil de hacer.

Así que, esas cosas... Está bien, yo, ya sabes, dejo que la gente de ThoughtWorks pelee la batalla. No estoy peleando esa batalla. Estoy peleando la batalla. Ciertas cosas deberían ser más simples. Algunas interacciones deberían ser más simples, de tal manera que el costo de una interacción sea menor, y cuando se trata de un punto anterior, en realidad, quería agregar un comentario, pero no estaba seguro si debería interrumpir en eso. En realidad, creo que otra cosa sobre los monorepos que encuentro interesante, que la gente a menudo asume que si estás en el mismo repo, estás necesariamente más acoplado entre sí, ¿verdad? Pero no es difícil imaginar con Propa2 y BluBit, no funciona, ¿de acuerdo? Los repos de Google parecen estar más acoplados entre sí que, como, una organización Polyrepo, ¿verdad?

Así que hay algunas cosas en las que tienes que ponerte de acuerdo, ¿verdad?, por supuesto, pero eso no significa que necesariamente estés construyendo un monolito complicado donde puedas trazar límites organizacionales. Puedes trazar límites organizacionales, puedes hacer todas las cosas que la Ley de Conway requeriría que hicieras, ¿verdad? Así que no es realmente un solo pensamiento porque hay muchos puntos que se mencionaron antes, ¿verdad? Solo para aclarar, las herramientas son una base de cosas que puedes comprar o integrar de manera económica, en comparación con muchas otras cosas, ¿verdad?

Y luego, una vez que lo tengas, necesitas resolver los problemas de las personas, porque al final del día, eso es lo que resulta en que tu código sea un poco suelto y cosas así, ¿verdad? Suena como si estuvieras en mi campo con híbrido. Quiero decir, creo que la palabra híbrido también, como si tuvieras un repo para una suborg, es más que un repo para esa org, ¿verdad? Si no interactúa con otro monolito, si estás en una isla y tienes un solo barco yendo de un lado a otro, no es realmente un híbrido. Sigues estando solo, ¿verdad? Así que no lo llamaría un híbrido. Pero si así es como definimos híbrido, entonces sí, ¿verdad? Creo que la mayoría de las organizaciones deberían optar por un enfoque híbrido, teniendo uno sobre un gran repo para la organización completa. Eso simplemente no funciona, sin mencionar las herramientas, ¿verdad? No podrán comprar máquinas o cualquier recurso para pagarlo porque no podrán ponerse de acuerdo sobre el presupuesto, ¿verdad?

Así que hay muchos problemas allí para la mayoría de las orgs. Sí. El híbrido para mí es la capacidad de simplemente, como dije, introducir las bases de código que necesitas introducir en tu automatización, ¿verdad? Tus procesos, tus procesos de construcción cuando los necesites. Así que para mí, no importa dónde vivan estas cosas y cómo vivan. Si están separadas o si están acopladas, no me importa siempre que mis herramientas puedan, tú sabes, completar y ejecutar las tareas que necesito que completen cuando necesito que las completen. Sí. No, lo entiendo un poco. Tengo otro punto que sé que quieres decir.

Voy a interrumpir porque he tenido mi mano virtual levantada por un tiempo y ahora tengo mi mano física. Solo quería preguntarte, por favor. Sí. Así que retrocedamos un poco, ¿verdad? Como que solo, a veces me preocupa quién es nuestra audiencia. Estamos lanzando tantas cosas, ¿verdad? Hagamos esto un poco más concreto. Seguimos hablando sobre herramientas y obteniendo cosas y repos, ¿verdad? Así que haciéndolo más concreto, ¿qué tenemos para herramientas? Tenemos protección de ramas, tenemos solicitudes de extracción, ¿verdad? ¿Cómo quieres encajar todo eso? Y cuando hablo con los clientes, hablo sobre, ya sabes, unidades de negocio, frutas y verduras. Tengo frutas y verduras, y luego tengo dev, QA y producción, dev, QA y producción, piensa en esa matemática, crece casi, se siente como exponencialmente. Soy terrible en matemáticas, probablemente no sea exponencial. Pero va a ser una combinación de herramientas y personas. Y solo siéntate y planifica eso, ¿verdad? Y es tu negocio el que impulsa cómo necesitas separar tus grupos. Usa nombres, no uses comida y bar, frutas y verduras, ¿cómo trabajan juntos? Y de nuevo, tal vez le voy a preguntar a un compañero panelista sobre otras herramientas, en las que piensan, pero las que siempre me vienen a la mente primero son solicitudes de extracción y protección de ramas. Bueno, esos elementos de solicitudes de extracción, ¿verdad? Esos están fuera de, como, las herramientas de versionado centrales, ¿verdad? Así que eso es un producto de GitHub, ya sabes, lo llaman algo diferente en otro producto. Así que creo que, ya sabes, mirando las herramientas de manera nativa, entonces estoy de acuerdo 100%, hay un elemento de personas, obviamente en eso. Pero creo que es una conversación que debe tenerse fuera del repositorio moderno, porque una vez que resuelvas las partes de integración continua de tus procesos, ¿verdad? Esa es, en mi opinión, la parte de las personas desarrolladoras donde están colaborando alrededor del código, ¿verdad? No creo que importe dónde vive el código y cómo se integra en tus procesos. ¿Verdad?

Así que para mí, son dos cosas separadas, aunque están relacionadas. Bien, gracias a todos. Siguiente pregunta sobre estadísticas. Así que acabas de decir muchas cosas interesantes sobre estos enfoques. Pero, ¿qué pasa con las estadísticas? ¿Podrías compartir algunas estadísticas como la velocidad de desarrollo, nuevamente, el proceso de CI, CD, aplicaciones de código y así sucesivamente, indexación, Angel. Así que Luke, ¿qué piensas sobre esto? Sí, supongo que podría hablar un poco sobre el despliegue, un poco y solo si estoy entendiendo correctamente. Quiero decir, así que tienes, de nuevo, esto es un poco volver a la situación de que depende o caso por caso, ¿verdad? Así que con Monorepo, dependiendo de cómo lo hayas estructurado, podrías tener un flujo de despliegue relativamente rápido en ese sentido, si está estructurado correctamente de nuevo, y luego dependiendo de las herramientas adicionales que estés utilizando. Y esto va a variar. La norma de lo que encontrarás es que cuanto más grande y más complejo se vuelva, más lentas pueden volverse las cosas. Pero incluso eso sigue siendo un poco subjetivo, porque al final se reduce a, bueno, ¿qué herramientas estás utilizando? ¿Cuál es el paradigma que realmente estás utilizando en este enfoque? Mientras que, naturalmente, con un multi-repo, porque las cosas son más pequeñas en una especie de base micro, las cosas serán mucho más rápidas. Creo que en ese sentido particular, puedes esperar que las cosas se muevan mucho más rápido, estadísticamente hablando. Pero incluso entonces, es tan difícil decir que eso es algo universal, porque esto es muy caso por caso, así que decir, a través de proyectos. Así que sí, esos serían mis pensamientos sobre eso. Angel, ya dijiste sobre indexación, seguridad, ¿qué más puedes mencionar aquí? Sí. Así que tienes que. Estoy de acuerdo 100% con Luke y todos los demás que mencionaron esto. Esto es caso por caso, ¿verdad?

Pero tienes que entender, para volver al punto de Julie sobre eso. Nos movimos un poco por todas partes, y probablemente sea mi culpa, pero tiendo a hacer eso. Pero para volver a enfocar todo esto, tienes que entender qué estás heredando, ¿verdad? Como desarrollador, he estado en muchas organizaciones, heredé el código de otras personas. Todos heredamos, ¿verdad?, en algún momento, algún código. La mayor lucha que he tenido fue exactamente de lo que estamos hablando hoy, es, como, está bien, ¿qué hago con esto, verdad? Así que, es un monorepo, ¿cómo... Vengo del mundo de, desacoplaré las cosas, porque me gustan los fragmentos más pequeños y manejables, ¿verdad? Pero no puedes entrar a una empresa como, no quiero decir el nombre, pero hay un cliente nuestro que es enorme, una empresa enorme, ha estado alrededor por un tiempo, tienen un monorepo que es inmenso, ¿verdad? Si lo rompieran, solo les costaría millones, probablemente miles de millones de dólares. No vamos a hacer eso, así que tenemos que operar dentro de nuestro contexto. Y ese es mi punto, ¿verdad? Como, primero evalúa qué está pasando con tus equipos, tu base de código, ¿se pueden desacoplar las cosas, verdad? Lentamente, tal vez, pero ¿deberías desacoplarlas, verdad? Como, así que si tu monolito está funcionando y es increíble, genial, no veo ninguna razón por la que debas desacoplarlo. Pero si hay mejoras que puedes hacer que hagan las cosas más eficientes, al punto de Luke, bases de código más pequeñas funcionan más rápido. Estoy totalmente a favor de la eficiencia, haciendo que la duración de mis compilaciones sea lo más pequeña posible. Así que, mira las cosas desde esa perspectiva. ¿Cómo puedes optimizar? Pero también tienes ese costo, ¿verdad? Como, ¿va a costarle a la empresa o a la organización millones de dólares implementar un cambio? ¿Y cuál será el retorno de esos cambios? Así que, por eso soy un gran, enorme defensor de, supongo, el híbrido, porque tendrás situaciones donde vas a heredar estos enormes repositorios monolíticos, y luego también tendrás que integrar algún tipo de nuevas tecnologías o nuevos servicios con esa aplicación monolítica, ¿verdad? Así que, ¿acoplas tus nuevos microservicios y los fusionas en esa aplicación monolítica, o simplemente los dejas desacoplados y operas en ese estado híbrido, ¿verdad? Donde tienes este proyecto donde simplemente está funcionando en esta carga, y luego en este repo, donde es mono, y luego tienes estos otros, ya sabes, servicios más pequeños que son quizás recién construidos, y los dejas como desacoplados, ¿verdad? Creo que la respuesta es dejarlos como híbridos, dejarlos desacoplados, si piensas que esa es la forma más óptima. Pero si es más eficiente, ya sabes, acoplarlos y tenerlos en uno, entonces haz eso también. Como, tiene que ser una elección hecha por la organización con sus circunstancias específicas.

Lo dejaré en eso. Está bien, veo. Gracias. Victor, ¿te gustaría compartir algunas estadísticas? Claro, así que creo que es… Si quieres hacer un caso por Polyamore, siempre puedes presentar algunos números para probar el caso. Así que la forma en que… lo que mediría, ¿verdad? Como el rendimiento de las herramientas y luego el rendimiento de la organización. El rendimiento de las herramientas sería cosas como CICD, tiempo promedio, tiempo en el peor de los casos, cosas así, ¿verdad? Y luego, quiero decir, dependiendo de cómo midas, puedes hacer que más de un repo sea más rápido. Por ejemplo, si tienes un sistema que consiste en 40 repos o 4 módulos que pueden estar en un repo, múltiples repos, forman una, digamos, forma de diamante, ¿sí? Harán un cambio en el de abajo. ¿Me importa verificar el de abajo o me importa integrar el de abajo como a través del de arriba, ¿verdad? Y ¿básicamente cuento esta ejecución de CICD en caso de poly-repo o todas las ejecuciones de CICD? Eso será necesario, ¿verdad? Cosas así. Así que, si comienzas a hacer eso, entonces, ya sabes, dependiendo de lo que elijas hacer, ¿verdad? Creo que termina siendo lo mismo, ¿verdad? Y eso, por supuesto, puedes, como, todos distribuyen CI, ¿verdad? Incluso si tienes un repo pequeño que distribuyes CI, no ejecutas en un solo agente. Una vez que comienzas a distribuir CI, realmente no importa si tienes monorepo o poly-repo en que aún ejecutas tu CI en como 30 cajas al mismo tiempo, o 50 cajas, sea cual sea el tamaño de tu repo, ¿verdad? Así que, siempre puedes hacer que tu monorepo o poly-repo sea lo suficientemente rápido. Lo que sea lo suficientemente rápido depende... ¿Quieres decir que es como 20 minutos en el peor de los casos, ¿verdad? Eso se puede hacer para un repo de prácticamente cualquier tamaño, ¿verdad? A menos que tengas un nodo grande que no se puede dividir, en cuyo caso, de nuevo, es un punto irrelevante entre poly- y monorepo, porque tienes el mismo nodo que se puede dividir en cualquiera de los casos, ¿verdad? Así que, creo que realmente no importa. Así que, en términos de, como, el rendimiento de las herramientas puede funcionar con cualquiera. El rendimiento organizacional es una cosa diferente, ¿verdad? Entonces comienzas a medir cosas como, ¿qué pasa si quiero compartir un código, como esta es mi intención como desarrollador, como, ¿cuánto tiempo me lleva compartir un código entre, como, yo mismo y otro miembro del equipo, o como, de un proyecto diferente, por ejemplo, ¿verdad? ¿Toma una hora, un día, una semana, un mes, ¿verdad? Y en un monorepo, eso es mucho más pequeño. Ese es el beneficio del monorepo, ¿verdad? Compartir es más fácil, ¿verdad? Pero si mides cosas diferentes, entonces puedes hacer que el poly-repo se vea mejor. Realmente depende de lo que te importe, ¿verdad? La mayoría de las organizaciones con las que trabajo quieren compartir más, no menos, ¿verdad? Están demasiado divididas en líneas de negocio y cosas así, ¿verdad?, así que para ellos, buscan compartir como algo a optimizar, ¿verdad? Así que el monorepo es bueno en ese caso, ¿verdad?

Pero si tienes uno, ya sabes, pegado, o si quieres dividirlos más, quizás quieras compartir menos, ¿verdad? Por razones organizacionales, en cuyo caso, aún podrías usar un monorepo para hacer eso, pero el polyrepo te da una especie de, de una manera más natural, ¿verdad? Sí, casi nos estamos quedando sin tiempo. Me gustaría preguntar a Julie, Julie, esa es tu última respuesta. ¿Qué piensas sobre esto? Todo depende. Creo que podemos continuar en el chat espacial para las personas que quieran debatir con nosotros. Está bien, creo. Gracias a todos. Eso fue muy interesante.