Arquitecturas de Software Descontroladas

Rate this content
Bookmark

¡Prepárate para un recorrido por el mundo de las Arquitecturas de Software! Todos los que trabajan en software han oído hablar de términos como 'pwa', 'monolitos', 'headless' , 'microservicios' e incluso 'arquitecturas orientadas a servicios'. Todos sabemos lo que son, pero ¿cuánto sabemos realmente sobre ellos? En esta charla, te mostraremos las diferencias, las similitudes, cuándo usarlos, cuándo no usarlos, las historias de éxito y, por supuesto, los fracasos masivos. Prepárate para media hora de comedia tecnológica: ¡la arquitectura va a ser rápida y divertida!

31 min
01 Jul, 2021

Video Summary and Transcription

La charla analiza diferentes arquitecturas de software y sus desafíos. Destaca la tendencia de desacoplar el front-end del back-end y adoptar la arquitectura headless y las Progressive Web Apps (PWA). Se enfatizan los beneficios de una arquitectura orientada a servicios (SOA), incluyendo flexibilidad, confiabilidad y escalabilidad. La charla también explora la descomposición de arquitecturas monolíticas en microservicios y la importancia de abordar primero los puntos problemáticos. Además, se mencionan los desafíos de las pruebas en un entorno de QA y la elección entre microservicios y monolitos según los objetivos del proyecto.

Available in English

1. Introducción a las Arquitecturas de Software

Short description:

Hola a todos. Hoy voy a hablar sobre las arquitecturas de software y va a ser increíble, así que ponte unas gafas de sol. Es 2021 y el tráfico de Internet está creciendo como loco. Todos gastamos un total de 82.5 mil millones en línea en mayo de 2020, lo que representa un crecimiento del 77 por ciento año tras año. Para sobrevivir y básicamente para sobrevivir en nuestro sitio web, vamos a necesitar un sistema de software que sea flexible, integrable, confiable y escalable.

Hola a todos. Mi nombre es Jamie-Maria Schauven y soy cofundadora de Deity. Hoy voy a hablar sobre las arquitecturas de software y va a ser increíble, así que ponte unas gafas de sol.

Antes de comenzar, quiero dar crédito a la obra de arte. Es de James Booker y se llama Random Galaxy Art, es realmente increíble. Si quieres saber más, habla conmigo o síguenos. Mi Twitter se encuentra en la esquina izquierda. Por favor, tuitea y hazme cualquier pregunta que desees.

Ok, empecemos. Primero que nada, es 2021. Y mientras salvábamos al mundo en 1944 yendo a la batalla, hoy lo hacemos quedándonos en casa y usando nuestro teléfono. Y la mayoría de nosotros realmente lo hacemos. Y eso se refleja en el tráfico de Internet. El tráfico de Internet está creciendo como loco. Aquí está el uso de Internet que ocurrió en la primera parte de 2020 hasta abril. Como puedes ver, se está duplicando y es una locura. Y no solo el uso de Internet. Tenemos lo mismo en el mundo del e-commerce. Todos gastamos un total de 82.5 mil millones en línea en mayo de 2020, lo que representa un crecimiento del 77 por ciento año tras año. Si observas el gráfico en la esquina derecha, eso es solo hasta abril. El 27 por ciento de todas las ventas minoristas se realizaban en línea en los Estados Unidos. Y como también puedes ver, el crecimiento ha sido masivo. Hemos estado haciendo esto y dicen que el crecimiento ha sido de casi seis años. Lo que se proyectaba está sucediendo ahora mismo.

Para sobrevivir y básicamente para sobrevivir en nuestro sitio web, ya que muchos sitios web están luchando con esta cantidad de tráfico y esta cantidad de pedidos que llegan, vamos a necesitar algunos fuegos en nuestro sitio web. ¿Qué quiero decir con el principio de los fuegos? Bueno, en realidad, si quieres sobrevivir en estos tiempos y si quieres asegurarte de que tu sitio web esté listo para el crecimiento futuro, vas a necesitar un sistema de software que sea flexible para que puedas construir lo que tu negocio necesita ahora y en el futuro. También vas a necesitar tener un sistema que sea integrable para que puedas integrarte con cualquier fuente de datos, sin importar de dónde provenga. Y también, vas a necesitar ser confiable. Tu sitio web necesita asegurarse de que pueda manejar todo el tráfico a medida que creces y avanzas. Obviamente, también necesitas ser escalable.

2. Introducción a las Arquitecturas

Short description:

Los mercados están cambiando muy rápido y necesitas poder adaptar nuevas características, nuevas tecnologías, nuevos mercados de manera muy rápida. Desafortunadamente, la flexibilidad de la mayoría de los sitios web es realmente, realmente mala. Tenemos tres arquitecturas principales: la arquitectura monolítica, la arquitectura desacoplada y la arquitectura orientada a servicios. La arquitectura monolítica es la antigua y dorada en el monolito. Todo está fuertemente acoplado. La capa de interfaz de usuario, la capa de datos, los procesos y todo está muy entrelazado.

Los mercados están cambiando muy rápido y necesitas poder adaptar nuevas características, nuevas tecnologías, nuevos mercados de manera muy rápida. Y necesitas poder extender tu software sin agregar ninguna complejidad. Y por último, pero no menos importante, necesitas ser escalable para que puedas escalar tu negocio de manera ilimitada tan pronto como tu tráfico aumente o tan pronto como estés creciendo.

Desafortunadamente, la flexibilidad de la mayoría de los sitios web es realmente, realmente mala. Es más como vodka que como yoga. Y todo esto tiene que ver con las arquitecturas. Entonces, ¿cómo se construyen los sitios? Las arquitecturas de software son básicamente el comienzo de cómo construyes tu sistema, y estás haciendo un plano de cada elemento que debe estar en tu sitio y en el sistema en su conjunto. No solo necesito envío, precios y una imagen, sino también cómo se correlacionan entre sí, qué sistema tiene que comunicarse con qué en el backend y en el frontend.

Básicamente, tenemos tres arquitecturas principales. Tenemos la arquitectura monolítica. Tenemos la arquitectura desacoplada y tenemos la arquitectura orientada a servicios. Voy a comenzar con la arquitectura monolítica. Bueno, la arquitectura monolítica es la antigua y dorada en el monolito. Todo está fuertemente acoplado. La capa de interfaz de usuario, la capa de datos, los procesos y todo está muy entrelazado. Y se ve así. ¿En mis diapositivas? Sí. En la arquitectura monolítica, como puedes ver, la capa de presentación está muy unida a la lógica empresarial y a la interfaz de datos en el diseño de capas. Encuentras estas diferentes capas, pero aún están muy cerca entre sí. Si algo sucede en el lado de la presentación, tu lógica empresarial va a tener problemas. Y si algo sucede en la lógica empresarial, tu capa de presentación va a tener problemas. Además, cuando quieres cambiar algo en tu sitio web, tendrás que cambiarlo realmente dentro de la capa. Así que dentro de la lógica, todo está ahí. Búsqueda, imágenes, precios, stock. Todo está dentro de esa lógica. Si quieres cambiar tus precios, si quieres cambiar el servicio de stock, tendrás que abrirlo y reconstruirlo desde dentro. Como puedes imaginar, si creces, será una masa muy grande. Será muy, muy complejo tan pronto como agregues más características a eso. Así que hay algunos beneficios de los monolitos. Básicamente, un monolito es muy, muy bueno ya que la aplicación se empaqueta e implementa como una sola entidad.

3. Desafíos de las Arquitecturas Monolíticas

Short description:

Es simple desarrollar, implementar, probar y mantener aplicaciones de software, pero solo si se mantienen simples. Las arquitecturas monolíticas tienen sus inconvenientes, como ser difíciles de ampliar y mantener, carecer de flexibilidad y confiabilidad. Para superar estas limitaciones, la tendencia actual es ir sin cabeza, desacoplando el front-end del back-end y conectándolos a través de APIs.

Es simple desarrollar. Es simple implementar. Es simple probar. Es simple mantener. Pero solo si mantienes esta aplicación muy simple.

Algunos inconvenientes del monolito, y no estoy seguro de por qué hay otro pequeño salto, pero los monolitos pueden fallar en grande. ¿Y qué puede suceder? Por ejemplo, este es un ejemplo de lo que sucedió en Magento. Tenemos un usuario administrador. Y cuando el rol de este usuario administrador estaba haciendo algo, como iniciar sesión o cambiar un producto, etc. Se reconstruía toda la caché. Así que imagina que eres un propietario de negocio y solo estás intentando iniciar sesión. Tu sitio web completo literalmente podría caer debido a este monolito, debido a esta estructura. Pero esta capa de lógica empresarial está muy, muy fuertemente acoplada con la capa de presentación.

Algunos inconvenientes del monolito. Esto me lleva a los inconvenientes del monolito. Es obvio que los monolitos son muy difíciles de ampliar y mantener. Los monolitos no son flexibles y no son confiables. Y aún así, la mayoría de internet moderno es desafortunadamente un monolito. Para evitar esto, tienes que volverte loco. Y esto lo llamamos volverse loco y tienes que ir headless. Eso es lo que está sucediendo ahora. Un gran hype en este momento. Todos están yendo headless. ¿Qué significa eso? Significa que el front-end está desacoplado del back-end y se conecta a través de APIs. La clave aquí literalmente es desmontar el front-end y desacoplarlo del back-end. Se ve algo así, donde la capa de presentación ya no está conectada a la lógica empresarial. De esta manera, la capa de presentación puede funcionar como una aplicación independiente y muchas veces se construye como una aplicación JavaScript. Que renderiza la salida de esta API en HTML. Los data que obtienes de la lógica empresarial, como los datos de stock, las imágenes y todo lo que obtienes de allí. Así que lo único que tienes que hacer es asegurarte de que los data estén disponibles desde la lógica empresarial.

4. Arquitectura sin cabeza y PWA

Short description:

Ir sin cabeza tiene varias ventajas, como desacoplar el front-end del back-end, mejorar el rendimiento, la escalabilidad y la flexibilidad. Sin embargo, existen desafíos, como la recuperación lenta de datos a través de APIs, la necesidad de exponer todos los datos y el proceso de comenzar desde cero, que consume mucho tiempo. Grandes plataformas como BigCommerce, Magento, Shopify y WordPress están adoptando el enfoque sin cabeza. Además, las PWA (Aplicaciones Web Progresivas) combinan los beneficios de las aplicaciones nativas y los sitios web receptivos, permitiendo funcionalidad sin conexión y notificaciones push. El tiempo promedio de carga de una página web móvil en 3G es de 19 segundos, lo cual es perjudicial para la experiencia del usuario.

Sin embargo, tu lógica empresarial sigue estando muy estrechamente acoplada. Algunas ventajas de ir sin cabeza... Los front-ends ya no dependen de los procesos del back-end. Tenemos ventajas de rendimiento en el front-end. Tenemos una alta escalabilidad y confiabilidad en tu front-end, ya que puedes escalar y ser confiable en tu front-end en su totalidad. Y puedes ser muy flexible e integrable en tu front-end. Y los desarrolladores pueden trabajar en equipos separados. Tienes tu equipo de front-end y tienes tus equipos de back-end.

Sin embargo, aún necesitas asegurarte de que todo sea accesible a través de la API. Algunas desventajas de ir sin cabeza, por lo tanto, son realmente que los datos que vienen a través de la API pueden ser muy, muy lentos. Y necesitas exponer todos los datos a través de la API. Los backends existentes no están listos. Cuando tienes, por ejemplo, Magento o Shopify, son bastante buenos. Pero aún hay mucho trabajo personalizado que debe hacerse para asegurarse de que tus datos se expongan en el front-end. Y comenzar desde cero, comenzar toda esta capa desde cero, llevará mucho tiempo. No solo tienes que construir tu equipo de front-end, sino que también debes asegurarte de que todos los datos estén allí y debes pensar en todos los aspectos de SEO. Como SEO, no estoy seguro de por qué esta diapositiva siempre se salta, pero hay problemas de SEO con aplicaciones de página única, especialmente cuando se utilizan front-ends de JavaScript.

Entonces algunas de las principales plataformas están adoptando sin cabeza. Tenemos BigCommerce, tenemos Magento, tenemos Shopify y también WordPress y otras aplicaciones se están preparando para este movimiento sin cabeza. Se aseguran de que todo el contenido y el comercio estén disponibles a través de la API. Por lo tanto, puedes agregar tu capa de API a eso y puedes comunicarte con esa capa y construir tu propio front-end allí. Hay muchas mejoras importantes en marcha para avanzar hacia esta estructura sin cabeza en oposición a esta estructura monolítica. Pero, ¿qué pasa con PWA? Muchas veces, cuando hablo de sin cabeza, la gente me pregunta sobre PWA. PWA es el matrimonio entre una aplicación nativa y un sitio web receptivo. Puedes funcionar sin conexión, tener notificaciones push, etc., etc. Como todos sabemos, el 53% de los usuarios abandonará una página cuando tarde más de tres segundos en cargarse. Y eso es, obviamente, muy extraño cuando lo pongo en una situación de la vida real, donde veo que cuando estoy esperando en la caja registradora, en 3.2 segundos, me voy. Desafortunadamente, el tiempo promedio de carga de una página web móvil en 3G es de 19 segundos. Y no es mucho mejor en 4G, donde tenemos 14 segundos. Si sabemos que 3.2 segundos hacen que nuestro cliente se vaya, todavía tenemos estos resultados que creo que son realmente malos.

5. PWA y Arquitectura Orientada a Servicios

Short description:

PWA puede mejorar significativamente el rendimiento del sitio web, como lo demuestran Tinder y Uber. Ofrece características como notificaciones push y se puede agregar a cualquier arquitectura. Sin embargo, no proporciona flexibilidad completa, integración, accesibilidad o escalabilidad. Para lograr un mayor crecimiento, debemos avanzar hacia una arquitectura orientada a servicios, que brinda los beneficios de desacoplar tanto el front-end como el back-end.

Entonces, PWA realmente puede ayudar con esto. Tenemos a Tinder que lo ha estado utilizando. Se aseguran de que su sitio web sea 7.22 segundos más rápido que su aplicación cuando usan PWA, y por lo tanto, un 90% más pequeño, y tenían más mensajes, más deslizamientos y sesiones más largas. Además, Uber lo intentó y pudieron cargar en solo tres segundos en redes 2G. Con eso, estaban abriendo un mercado fórmula ya que podían ofrecer sus servicios en una red 3G en tres segundos. Otra cosa genial que puedes hacer con una aplicación web progresiva es enviar notificaciones push, y pronto podremos tener este tipo de cosas provenientes de sitios web.

Entonces, ¿qué es una aplicación web progresiva? Bueno, según nuestros amigos de Google, una aplicación web progresiva es progresiva, receptiva, independiente de la conectividad, similar a una aplicación, fresca, segura, descubrible, recompensable, instalable, y enlazable. Estos son todos tipos de características. Quiero decir, estas son todas cosas que describen un comportamiento, pero no una tecnología. ¿Qué es exactamente una aplicación web progresiva? Bueno, una aplicación web progresiva, básicamente, técnicamente hablando, son tres cosas. Es un trabajador de servicio, es un manifiesto web y es HTTPS. Literalmente, podemos agregar una PWA a cualquier cosa. No tiene nada que ver con la arquitectura, y cuando lo veo en una descripción general, así es como se ve, y no sé por qué la siguiente diapositiva, por qué no se está cargando. Y luego es así. En la arquitectura monolítica, la PWA puede existir, pero también en la arquitectura sin cabeza, la PWA puede existir. Por lo tanto, la PWA es completamente independiente de lo que está sucediendo en tu arquitectura. Desafortunadamente, la PWA no te da flexibilidad. No es necesariamente flexible. Puede ser más confiable, pero no se integra con todo. Debes agregarlo a la capa, pero te brinda un poco más de confiabilidad, accesibilidad, no realmente, y escalabilidad, no realmente. Por lo tanto, PWA no es una solución para estos sitios web que realmente necesitan crecer más.

Entonces, para hacer eso, debemos ir al siguiente nivel. Y para eso, lo llamamos la arquitectura orientada a servicios. Y lo que hacemos aquí es llevar estas características de una arquitectura sin cabeza donde tu capa de presentación está separada. También lo llevamos al backend. Por lo tanto, también desacoplamos el backend. Y eso brindará esta flexibilidad, accesibilidad, escalabilidad y confiabilidad tanto al frontend como al backend. ¿Cómo se ve eso? Se ve algo así. En la arquitectura orientada a servicios, como puedes ver, tenemos un middleware muy sólido. Y luego tenemos capas de presentación en la parte superior puede ser una, pueden ser dos, pueden ser 10.

6. Beneficios de SOA

Short description:

SOA permite servicios manejables con lenguajes de implementación y bases de datos separadas. Es escalable, confiable, flexible e integrable. Permite la adopción rápida de nuevas características y tecnología y permite el uso de servicios existentes. SOA ofrece flexibilidad, integrabilidad, confiabilidad, extensibilidad y escalabilidad.

Y tenemos servicios empresariales. Y todos estos servicios empresariales ya no están pegados entre sí. Todos son independientes. Se comunican directamente con el middleware con su propia database sin afectar al resto. El secreto de esta SOA es obviamente este middleware. El middleware conecta todos los puntos entre el backend y el frontend, pero también transfiere los data entre diferentes servicios de backend. Ya no es necesario integrarlos entre sí.

A diferencia de una arquitectura de microservicios, como puedes ver aquí, donde los microservicios se comunican directamente con la interfaz de usuario y entre sí. En la arquitectura SOA, hacemos eso a través del middleware. Entonces, en la SOA tradicional, usamos un orquestador de servicios y una herramienta ETL. Pero afortunadamente, ya no tenemos que hacer eso. Ahora tenemos GraphQL, que es perfecto y puede ayudarnos a hacer este tipo de trabajo sin construir algo muy complejo.

Entonces, si avanzo, me pregunto cuáles son las ventajas de adoptar SOA? Tenemos servicios manejables. Tenemos lenguajes de implementación y bases de datos separadas. Es altamente escalable y confiable. Es flexible e integrable, muy extensible sin agregar complejidad, ya que puedes ampliar tus backends, pero también cambiar tus backends y tus frontends sin tener que descomponer el sistema. Es una adopción rápida de nuevas características y tecnología. Y lo mejor es que puedes usar servicios existentes. Hay muchas cosas geniales disponibles para búsqueda, imágenes, stock, pedidos. Ya no tienes que construir todos los servicios tú mismo. Por lo tanto, SOA tiene ventajas. Tiene flexibilidad, integrabilidad, confiabilidad, extensibilidad y escalabilidad.

7. Building a Light SOA

Short description:

Hay ventajas e inconvenientes al adoptar SOA. Sin embargo, construir una versión ligera de SOA puede proporcionar una solución flexible y a prueba de futuro. En nuestro proyecto, nos centramos en construir un middleware, un integrador de datos y servicios básicos. Al aprovechar los servicios existentes y construir los nuestros propios, creamos un middleware sólido que se integra con varios socios de la industria. Utilizando una plataforma web progresiva en el frontend, demostramos cómo los datos pueden fluir sin problemas entre diferentes backends y el frontend. Este enfoque ofrece un tiempo de procesamiento rápido, un corto tiempo de comercialización y flexibilidad ilimitada para agregar servicios.

Obviamente, también hay algunos inconvenientes al adoptar SOA. Tenemos una complejidad para construir desde cero. Se necesita una arquitectura para su diseño y requiere más trabajo de configuración inicial. Pero eventualmente, es muy a prueba de futuro.

Pero ¿qué pasa si construimos una versión ligera de SOA? ¿Y si podemos asegurarnos de tener una versión ligera con la que todos puedan comenzar? Y eso es básicamente lo que hicimos en un proyecto. Y lo que hicimos fue asegurarnos de analizar, ¿qué necesitamos para construir esta versión ligera? Necesitamos un middleware, necesitamos un integrador de datos, una forma de integrar estos datos y necesitamos algunos servicios básicos. Y no sé por qué las diapositivas se están saltando de nuevo, pero necesitamos estas tres cosas para construir la versión ligera aquí. Y eso es lo que hicimos en nuestra empresa.

Entonces construimos un middleware muy sólido, que puede integrarse, como puedes ver en la parte inferior, con todos los diferentes socios de la industria. Por lo tanto, no construimos ningún servicio nosotros mismos. No hay pagos, hemos utilizado BigCommerce para el comercio, utilizamos SAP para los datos de stock, WordPress para el contenido, Algolia, etc. Realmente puedes armar un rompecabezas y utilizar los servicios que están disponibles. Incluso puedes crear tus propios servicios y utilizar lo que has construido. Y luego, obviamente, hay un equipo en el frontend que utiliza una plataforma web progresiva.

Voy a mostrarte un ejemplo de cómo funciona esto. Aquí, a la izquierda, tengo una tienda de demostración donde estoy utilizando BigCommerce y Algolia. No hay una integración directa entre los dos, ni siquiera existe. Luego, a la derecha, está mi backend de BigCommerce, donde voy a cambiar el precio de un producto. En la parte superior derecha, puedes ver lo que voy a hacer. Voy a ir a mi equipo de PWA, pedirle a mi servidor un resultado de búsqueda, que a su vez le pregunta a Algolia. Luego actualizo los datos en BigCommerce, lo cual se hace enviando esta información al servidor, que inmediatamente la envía al otro servidor, BigCommerce o Algolia. Voy a buscar un reloj y el reloj cuesta 89 euros. Y voy a cambiar el precio a 99. Lo guardaré y no necesito reconstruir ningún índice. Ni siquiera tengo que ir a Algolia. Regreso al frontend, que es una aplicación de una sola página, y simplemente vuelvo a realizar la búsqueda y el precio ha cambiado. Por lo tanto, los datos pasan por diferentes backends hasta el frontend de manera muy rápida. Los resultados son que tenemos un tiempo de procesamiento de 300 milisegundos y el tiempo de comercialización para construir cosas así es de solo dos a tres meses. Y podemos tener flexibilidad ilimitada para agregar cualquier servicio allí y construir lo que tu negocio necesite. Entonces, en resumen, tenemos tres arquitecturas principales.

QnA

Choosing the Right Architecture

Short description:

Cuando se elige entre una arquitectura monolítica, una arquitectura desacoplada y una arquitectura orientada a servicios, depende de lo que estés tratando de construir. Para un bloque simple, una arquitectura monolítica podría ser perfecta. Pero si tienes ambiciones de crecimiento y quieres ir hacia múltiples X, necesitarás una arquitectura orientada a servicios. Es importante centrarse en las necesidades y ambiciones de tu negocio, en lugar de solo lo que necesitas hoy. Si estás invirtiendo tiempo y esfuerzo, ¿por qué no hacerlo bien y evitar acumular deuda técnica? Si quieres más información, escribí un blog en dev.to sobre estas arquitecturas y sus diferencias.

Tenemos un monolito, tenemos una arquitectura desacoplada y tenemos una arquitectura orientada a servicios. ¿Cuál es la mejor? Bueno, esa es básicamente una pregunta difícil porque realmente depende de lo que estés tratando de construir. Para un bloque simple, una arquitectura monolítica podría ser perfecta. Para una tienda web, B2C, área de presentación con lógica empresarial menos compleja, está bien. Pero si tienes ambiciones de crecimiento y quieres ir hacia múltiples X, múltiples idiomas, múltiples tiendas, múltiples backends, múltiples ubicaciones de stock, lo que sea, lo que quieras hacer. Para tu tienda web multi-X realmente vas a necesitar tener una arquitectura orientada a servicios para avanzar en el futuro. Si estás utilizando arquitecturas headless para eso, pronto te quedarás atascado ya que tu lógica empresarial estará sobrecargada.

Decidir lo que tu negocio necesita es realmente una de las tareas más difíciles. Tómate tu tiempo para hacer esto y enfócate en tu negocio y en tus ambiciones, no en lo que necesitas hoy. Muchas veces veo a las personas construyendo en base a lo que necesitan hoy y sin pensar en lo que necesitarán mañana. Eso es realmente una lástima porque si estás invirtiendo tiempo y esfuerzo para hacerlo bien ahora, ¿por qué no hacerlo bien? Inmediatamente, no acumularás ninguna deuda técnica.

Esa fue mi presentación. Si quieres leer más sobre estas arquitecturas, sobre estas diferencias, escribí un blog en dev.to al respecto. Puedes seguir el enlace aquí o escanear el código QR y lo encontrarás. Si tienes alguna pregunta, por favor pregúntame. Estoy listo en la sesión de preguntas y respuestas para ti y estaré encantado de responder cada una de tus preguntas. Muchas gracias.

Resultados de la encuesta y preferencias de arquitectura

Short description:

El ganador de la pregunta de la encuesta sobre la arquitectura utilizada actualmente en proyectos recientes es la arquitectura de Microsoft con un 39% de los votos. Sin embargo, también hay un alto porcentaje de arquitecturas monolíticas, lo cual es esperado dada la prevalencia de dichos proyectos. La elección de la arquitectura depende a menudo del tipo de proyecto, con proyectos de comercio electrónico inclinándose hacia arquitecturas monolíticas y proyectos empresariales favoreciendo arquitecturas de microservicios o orientadas a servicios. La audiencia objetivo de la conferencia, que incluye a ingenieros de DevOps, puede influir en los resultados. Sería interesante hacer la misma pregunta en una conferencia de JavaScript o de frameworks frontend para ver resultados diferentes.

Antes de pasar a las preguntas de la audiencia para Jamie, por supuesto, vamos a ver los resultados de su pregunta de la encuesta. Así que si no viste la pregunta o la olvidaste, te la recordaré. La pregunta que Jamie hizo para ti es, la arquitectura que estoy utilizando actualmente para mi proyecto reciente es, y el ganador es la arquitectura de Microsoft con un 39% de los votos. Bueno, eso es mucho. Si aún no has votado, todavía puedes hacerlo, por supuesto. Y Jamie podrá hacer algo con estos resultados.

Entonces, Jamie, hola, gracias por unirte a nosotros. Gracias. ¿Qué piensas? ¿Es algo que esperabas? ¿Como un tercio, 40% de la arquitectura de Microsoft? En realidad no. También veo un porcentaje muy alto de arquitecturas monolíticas. Así que eso es algo que esperaba ya que todavía hay muchos proyectos que son monolíticos. Pero creo que también depende del tipo de proyectos que la gente esté haciendo. Creo que si fuera muy comercio electrónico, por ejemplo, muy orientado al comercio electrónico, entonces sería mucho más monolítico. Si es más orientado a empresas, con más personas de empresas, probablemente más en la arquitectura de microservicios de Microsoft o en una arquitectura orientada a servicios. Perdón, no Microsoft, microservicios. Todos te entendimos. Es un error honesto. No te preocupes. Sí. Y también, supongo que es la audiencia objetivo de nuestra conferencia hoy, ¿verdad? Así que tenemos ingenieros de DevOps a los que les gusta hacer posible esta arquitectura. Sí, diría que sería divertido hacer esta pregunta de nuevo en una conferencia de JavaScript o de React o de Angular. Entonces los resultados serían muy diferentes, supongo. Creo que habría muchas arquitecturas desacopladas. Sí, bueno, solo lo sabremos si te postulas para otra conferencia de Git Nation, Jamie. Y puedes hacer la misma pregunta de nuevo. Genial. Si me lo permites, lo haré de nuevo. Increíble.

Descomponiendo Monolitos en Microservicios

Short description:

Para descomponer un monolito en piezas más pequeñas y eventualmente en una aplicación de microservicios, utilizamos una versión ligera de la arquitectura orientada a servicios. Nos conectamos a los backends actuales o sistemas ERP a través de un middleware y construimos el nuevo frontend. Utilizando un patrón triangular, eliminamos gradualmente las características una por una, lo que permite la escalabilidad y la adición de nuevas características. Este enfoque asegura que ya estés en vivo desde el primer día y puedas seguir descomponiendo el monolito hasta tener tantas piezas como sea necesario.

Entonces vamos a pasar a las preguntas de la audiencia y déjame verlas. Entonces, Jamie, cuando te encuentras con un gran monolito en un cliente, ¿cuál sería tu enfoque para descomponer este monolito en pequeños fragmentos, en piezas un poco más pequeñas, y eventualmente en una aplicación de microservicios? ¿Cuál es un buen enfoque para dividir un monolito? Para mí, eso es básicamente parte de por qué nos metimos en este negocio. Muchas personas estaban luchando con esta misma pregunta y se preguntaban, `oye, ¿necesito empezar desde cero de nuevo?` En muchos casos, la respuesta era sí. Hicimos muchos proyectos grandes donde en realidad la respuesta era sí, pero queríamos hacerlo de una manera mejor para no tener que reiniciar y reconstruir todo desde cero. Por eso llegamos a lo que estamos haciendo ahora. Así que digamos que es una versión ligera, un primer punto de partida de la arquitectura orientada a servicios. Lo que hacemos es utilizar los backends actuales o los sistemas ERP o lo que tengan en ese momento, para conectarnos a un middleware y comenzar a construir el nuevo frontend. A partir de ahí, utilizamos este patrón triangular. Entonces, vamos eliminando todas las características una por una. Por ejemplo, comenzamos primero con la gestión de autos, si es un comercio electrónico o con un blog, si no lo es, si es texto o lo que sea. Así que realmente, basados en este patrón triangular, vamos eliminando todas las características. Entonces, ya estás en vivo desde el primer día. Ya tienes las ventajas. Si agregas nuevas características o si quieres tener más escalabilidad, ya tienes las ventajas desde el primer día y luego comenzamos a descomponer todas las piezas hasta que al final tengas tantas piezas como necesites. Así que agrega un middleware al sistema actual, agrega un frontend y a partir de ahí elimina todas las características del backend.

Comenzando con los Puntos de Dolor

Short description:

Para comenzar con tu arquitectura, es importante identificar tu principal prioridad y puntos de dolor. Algunas personas comienzan con la funcionalidad de pago, agregando diferentes monedas o métodos de pago. Otros se enfocan en proyectos que requieren nuevas características. La elección depende del proyecto específico y sus desafíos. Abordar los puntos de dolor primero es crucial antes de mejorar el sistema en general.

Bueno, entonces, ¿dirías que simplemente lo superes, termines tu arquitectura con una gran característica o comiences con algo de bajo valor comercial o, por supuesto, todo en tu sitio web tiene algún valor comercial, pero menor riesgo que, por ejemplo, la función de pago en comercio electrónico? No creo que la función de pago sea de menor riesgo. Creo que es uno de los riesgos más altos porque obviamente es el camino crítico que debes seguir. Pero definitivamente diría, lo que a menudo vemos es que las personas están luchando con. A veces vemos, que las personas están tratando de obtener un sistema ERP en su empresa actual o tratan de convertir su backend actual en algo que no es, sistema de gestión de almacenes, algo así. Entonces, principalmente comenzamos por cuál es tu principal prioridad? ¿Cuál es tu punto de dolor? También tenemos algunas personas que, por ejemplo, comienzan con el pago porque necesitan diferentes monedas o diferentes métodos de pago que no están disponibles en el sistema actual, o comenzamos con proyectos que realmente quieren agregar nuevas características que no existen. Por ejemplo, el ejemplo que mencioné en la charla, cuando tienes BigCommerce y quieres agregar Algolia a eso, ese es tu primer punto de partida. Te conectas a BigCommerce, agregas Algolia ya que no existe la conexión directamente. Entonces, realmente, por dónde empezar depende del proyecto, depende de en qué están luchando, si es una nueva característica, si es algo con lo que están luchando. Definitivamente abordaría los puntos de dolor primero antes de pasar a hacer que todo el sistema sea más cómodo.

Resources and Differences with Facade

Short description:

Existen muchos recursos en línea sobre arquitectura de software, incluyendo un blog que escribí y la guía de arquitectura de software de Martin Fowler. La forma en que aplicamos y utilizamos la arquitectura está cambiando, con nuevas herramientas que hacen que las arquitecturas complejas sean más accesibles. Es importante tener más discusiones y conferencias sobre este tema para animar a las personas a probarlo y adentrarse en él. Obtener la aprobación para cambiar la arquitectura puede ser desafiante debido a la inversión y los cambios rápidos en el campo. Se planteó una pregunta sobre las diferencias entre el facade y el middleware, y aunque el facade puede enrutar las solicitudes, es posible que no satisfaga todas las necesidades cuando están involucrados diferentes servicios. El enfoque headless puede ser más adecuado en este caso.

Muy bien, genial. Gracias. Tengo una pregunta de Ronny. Dice buen libro, cursos y enlaces para comenzar a leer y adentrarse en este paradigma arquitectónico. Entonces, ¿cuáles son algunos buenos recursos para adentrarse en esto? Hay muchas cosas en línea sobre arquitectura de software, chicos. En realidad, escribí un blog sobre eso, eso es lo que compartí al final. Así que eso es de mi charla, pero también está el de Martin Fowler. No estoy seguro si expliqué bien el nombre. Martinfowler.com slash architecture realmente tiene una muy buena guía de arquitectura de software. Puedo compartir el enlace más tarde en la charla de DevOps.

Quiero decir, la arquitectura cambia, ¿verdad? Quiero decir, la arquitectura en sí no cambia realmente, pero la forma en que la aplicamos, la forma en que la usamos está cambiando. Quiero decir, cosas que al principio, sabes, cuando teníamos, si miras puramente la arquitectura orientada a servicios hace unos años, es muy diferente a lo que estamos haciendo ahora. Realmente tenemos cosas muy, sabes, cosas como buses de servicios empresariales y cosas muy complejas, herramientas de ETL, pero ahora podemos hacer eso con GraphQL. Entonces, estas arquitecturas más complejas se vuelven más accesibles debido a las nuevas herramientas. Así que realmente algunos libros con todas estas cosas nuevas y aún no las he encontrado. Obviamente, Twitter es una muy buena fuente, pero no hay muchas personas hablando de ello todavía, lo cual creo que es una lástima porque hay cosas realmente, realmente geniales ahí fuera. Y realmente ideas geniales para hablar. Y creo que deberíamos tener más charlas y conferencias sobre este tema y hacer que más personas realmente lo prueben y se adentren en él. Sé que es un poco difícil. Muchas personas están luchando, los gerentes de proyecto no cambian realmente la arquitectura tan fácilmente, pero creo que es realmente bueno hacerlo y abrir la conversación sobre cómo puede cambiar drásticamente tu enfoque para el futuro. Sí, por supuesto, obtener la aprobación para cambiar la arquitectura es realmente difícil porque generalmente es una gran inversión, ¿verdad? Así que realmente es un gran esfuerzo probar algo nuevo. Puedo imaginar que es algo grande, y escribir un libro sobre arquitectura cuando algunas cosas están cambiando tan rápidamente en nuestro campo, así que es difícil... Bueno, invertir como dos o tres años de tu vida para escribir un libro, y luego ya está obsoleto. Has escrito un libro obsoleto cuando se publica.

La siguiente pregunta es de Jonathan. ¿Cuáles son las diferencias clave con el facade? Parece que el facade podría actuar como el middleware del que hablaste, y enrutar las solicitudes al servicio apropiado. Bueno, creo que muy a menudo la combinación que estás haciendo son diferentes servicios en el backend, por lo que una sola solicitud, como lo que haces con esto, puede ser manejada únicamente por este servicio. Así que no creo que el facade pueda satisfacer todas tus necesidades. Hay muchas cosas diferentes que suceden desde diferentes servicios. Sí, creo que podría ser, pero lo haría más en el enfoque headless en lugar de realmente incorporarlo como un middleware.

Frontend Middleware and AI

Short description:

En el middleware del frontend, hacemos más que simplemente transportar y transformar datos. Actúa como un middleware inteligente, que nos permite capturar cambios en los datos en tiempo real y utilizarlos para aplicaciones de inteligencia artificial. Los backends tradicionales y los frontends lentos dificultan la introducción de la tecnología de IA en el comercio. Sin embargo, con un middleware que pueda responder rápidamente entre los sistemas backend y frontend, podemos superar estas limitaciones. Un servicio de solicitud única puede no ser suficiente para este propósito.

Es una solicitud única en un solo sentido. Lo que hacemos en el middleware del frontend es mucho más que eso, podríamos decir que es un backend del frontend antes de llegar al backend real. Y también es como un middleware inteligente. Por lo tanto, no solo transporta data y transforma los data, sino que también puede capturarlo tan pronto como se necesite. Cuando hay cambios en los datos en tiempo real, podemos utilizarlos para cosas como la IA, lo cual no es posible actualmente. Ahora lo vemos sucediendo en el comercio. Las personas quieren introducir tecnología de IA. No pueden hacerlo porque sus backends son backends tradicionales y los frontends del comercio son muy lentos. Con un middleware como este, que va en diferentes direcciones, que puede responder muy rápidamente entre los sistemas backend y los sistemas frontend, realmente podemos utilizarlo. Si solo usas un servicio de solicitud única, no creo que funcione. Pero para ser honesto, no lo he probado ni profundizado en eso. Pero desde lo que tengo en mente, esa no sería la dirección que tomaría.

QA Environment and Microservices vs Monoliths

Short description:

Cuando se organiza el entorno de QA con múltiples bases de datos backend, puede ser desafiante probar todo. Simular respuestas es una solución potencial, pero requiere configurar cuentas para cada servicio y backend. En una arquitectura monolítica, puede ser difícil identificar problemas, mientras que en una arquitectura de microservicios es más fácil señalar los problemas. La elección entre microservicios y monolitos depende de los objetivos del proyecto y las necesidades de escalabilidad. Los microservicios son adecuados para tiendas multi-X con múltiples backends, sistemas, lenguajes, monedas y objetivos. Sin embargo, para proyectos simples o para probar ideas rápidas, un monolito puede ser más apropiado.

Genial. La siguiente pregunta es de Mike. ¿Cómo organizar el entorno de QA cuando tienes tantas bases de datos backend? Si quieres hacer una prueba completa, obviamente cada equipo o cada servicio debe ser probado por separado. Pero si haces todo completo, quieres probar todo. Simular las respuestas podría ser una de las soluciones potenciales, pero eso requiere configurar todo el conjunto de cuentas para cada servicio y cada backend.

Creo que, sabes, hacemos QA, por lo que probamos ciertas cosas que esperamos en ciertos puntos. Obviamente no podemos, también tenemos que hacer QA, por ejemplo, ¿cuál sería el tiempo de respuesta de uno de los servicios o si obtengo el tiempo de respuesta esperado de uno de los servicios? Pero tan pronto como encuentres el problema, es bastante fácil de averiguar dónde está sucediendo porque sabes, en el frontend, los data se alimentan, ¿verdad? Viene de una fuente, por lo que sabes muy bien de dónde viene. En la tradición más monolítica, he visto cosas que suceden en el proceso de pago o en los carritos, que están relacionados con algo en la búsqueda o algo así, es muy difícil de averiguar. Así que, sabes, tiene sus pros, tiene sus contras. Quiero decir, obviamente es un poco más complejo porque no es tan fácil de probar como un monolito. Por otro lado, tan pronto como sabes dónde está sucediendo, es muy fácil encontrarlo. Sí, tienes que probar todas las soluciones individuales y obviamente probarlas como un todo y simular los data, simular las respuestas podría ser una de las soluciones que podrías usar. Y a menudo lo usamos.

De acuerdo, genial. Gracias. Así que tenemos tiempo para una pregunta rápida con una respuesta rápida. Y la pregunta es de Cesar. ¿Cuándo no elegirías una arquitectura de microservicios en lugar de un monolito convencional? Bueno, depende obviamente del objetivo. No hay una cosa que sea mejor que otra. Realmente depende de qué estás tratando de construir. Definitivamente no elegiría una arquitectura de microservicios o una arquitectura orientada a servicios cuando estoy construyendo algo para mostrar a mi familia cómo está creciendo mi hijo o cómo está mi perro. Quiero decir, definitivamente no es algo que haría. También cuando estás probando cosas rápidas, si estás en la fase de inicio, solo quieres ver, ya sabes, construir algunas páginas de destino y probar cosas. Esta no sería la primera dirección que tomaría. Optaría por el enfoque orientado a servicios tan pronto como tenga ambiciones más grandes. Y eso es lo que llamamos las tiendas multi-X. Las tiendas multi-X son muy buenas para lo que hacemos para el enfoque de microservicios como una arquitectura orientada a servicios. Si tienes múltiples backends, múltiples sistemas, múltiples lenguajes en el frontend, múltiples monedas, múltiples objetivos que quieres lograr desde tu sistema. Eso es lo que llamamos multi-X. Esa es la dirección a seguir. Si no eres un multi-X y no tienes mucho de eso, no tienes problemas de escalabilidad, como solo tienes a tus padres viendo cómo crece tu hijo, entonces definitivamente no optaría por el enfoque de microservicios.

Genial. Bueno, como dije, tenemos tiempo para preguntas en vivo, pero para todos los que quieran continuar la conversación con Jamie, Jamie estará en su sala de conferencias en SpatialChat. Encuentra el enlace a continuación en el horario. Jamie, muchas gracias por unirte a nosotros y por reírte. Muchas gracias. ♪ Música animada ♪ ♪ La música animada se desvanece ♪

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
React Advanced Conference 2022React Advanced Conference 2022
29 min
Understanding React’s Fiber Architecture
Top Content
We've heard a lot about React's Fiber Architecture, but it feels like few of us understand it in depth (or have the time to). In this talk, Tejas will go over his best attempt at understanding Fiber (reviewed by other experts), and present it in an 'explain-like-I'm-five years old' way.
React Advanced Conference 2021React Advanced Conference 2021
19 min
Automating All the Code & Testing Things with GitHub Actions
Top Content
Code tasks like linting and testing are critical pieces of a developer’s workflow that help keep us sane like preventing syntax or style issues and hardening our core business logic. We’ll talk about how we can use GitHub Actions to automate these tasks and help keep our projects running smoothly.
DevOps.js Conf 2022DevOps.js Conf 2022
33 min
Fine-tuning DevOps for People over Perfection
Demand for DevOps has increased in recent years as more organizations adopt cloud native technologies. Complexity has also increased and a "zero to hero" mentality leaves many people chasing perfection and FOMO. This session focusses instead on why maybe we shouldn't adopt a technology practice and how sometimes teams can achieve the same results prioritizing people over ops automation & controls. Let's look at amounts of and fine-tuning everything as code, pull requests, DevSecOps, Monitoring and more to prioritize developer well-being over optimization perfection. It can be a valid decision to deploy less and sleep better. And finally we'll examine how manual practice and discipline can be the key to superb products and experiences.

Workshops on related topic

DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Featured WorkshopFree
In this workshop, we discuss the merits of serverless architecture and how it can be applied to the AI space. We'll explore options around building serverless RAG applications for a more lambda-esque approach to AI. Next, we'll get hands on and build a sample CRUD app that allows you to store information and query it using an LLM with Workers AI, Vectorize, D1, and Cloudflare Workers.
React Summit 2022React Summit 2022
50 min
High-performance Next.js
Workshop
Next.js is a compelling framework that makes many tasks effortless by providing many out-of-the-box solutions. But as soon as our app needs to scale, it is essential to maintain high performance without compromising maintenance and server costs. In this workshop, we will see how to analyze Next.js performances, resources usage, how to scale it, and how to make the right decisions while writing the application architecture.
DevOps.js Conf 2022DevOps.js Conf 2022
152 min
MERN Stack Application Deployment in Kubernetes
Workshop
Deploying and managing JavaScript applications in Kubernetes can get tricky. Especially when a database also has to be part of the deployment. MongoDB Atlas has made developers' lives much easier, however, how do you take a SaaS product and integrate it with your existing Kubernetes cluster? This is where the MongoDB Atlas Operator comes into play. In this workshop, the attendees will learn about how to create a MERN (MongoDB, Express, React, Node.js) application locally, and how to deploy everything into a Kubernetes cluster with the Atlas Operator.
React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
WorkshopFree
Deploying React Native apps manually on a local machine can be complex. The differences between Android and iOS require developers to use specific tools and processes for each platform, including hardware requirements for iOS. Manual deployments also make it difficult to manage signing credentials, environment configurations, track releases, and to collaborate as a team.
Appflow is the cloud mobile DevOps platform built by Ionic. Using a service like Appflow to build React Native apps not only provides access to powerful computing resources, it can simplify the deployment process by providing a centralized environment for managing and distributing your app to multiple platforms. This can save time and resources, enable collaboration, as well as improve the overall reliability and scalability of an app.
In this workshop, you’ll deploy a React Native application for delivery to Android and iOS test devices using Appflow. You’ll also learn the steps for publishing to Google Play and Apple App Stores. No previous experience with deploying native applications is required, and you’ll come away with a deeper understanding of the mobile deployment process and best practices for how to use a cloud mobile DevOps platform to ship quickly at scale.
DevOps.js Conf 2022DevOps.js Conf 2022
13 min
Azure Static Web Apps (SWA) with Azure DevOps
WorkshopFree
Azure Static Web Apps were launched earlier in 2021, and out of the box, they could integrate your existing repository and deploy your Static Web App from Azure DevOps. This workshop demonstrates how to publish an Azure Static Web App with Azure DevOps.