EPISODE · Mar 1, 2022 · 11 MIN
PES 23 - Partiendo el monolito
from Programar es simple · host Remus Richard Dumitrache
→ Mi experiencia saliendo del monolito(Episodio anterior, hablábamos de qué approach elegir. https://open.spotify.com/episode/3ErtKuvhTxcHClZebZibCO?si=c9882cf7bd644d46 ) → Es una historia que suelo contar en las entrevistas cuando me preguntan por un fuck up(siguiente episodio) → Esto empezó cuando teníamos que sacar a microservicios cierta parte del funcionamiento del monolito → No se podían perder datos, había que tener las dos opciones siempre disponibles, es decir, ciertos clientes iban a usar una versión y el resto la otra(beta group) → No fue un desacoplamiento 100% del monolito, el monolito seguía recibiendo todas las peticiones, actuando como un api gateway, hacía autorización/autenticación y comprobaba si estabas en la beta para saber qué código ejecutar, si llamar al nuevo mS ó ejecutar el código php(feature flags → [<https://open.spotify.com/episode/4nyU3pzk7SIvtpIVFw71dB?si=MvUdVzOKS-mzAP5Z7o4MdQ>](<https://open.spotify.com/episode/4nyU3pzk7SIvtpIVFw71dB?si=MvUdVzOKS-mzAP5Z7o4MdQ>)) → La información que no se tenía en el microservicio, por ejemplo datos de empleados, se le forwardeaba al microservicio en la petición ó respuesta, ejemplo, si mi mS tuviese un id de propietario de una cuenta de banco, el monolito antes de pasarselo al front end de vuelta, le añadía el nombre y datos del propietario que necesitaba mostrar. El problema de esto es el acoplamiento que se crea. → Siguiente iteración, para quitar esta dependencia con el código de php, cada vez que hacíamos un cambio al contrato ó añadíamos un endpoint, teníamos que modificar el código en los dos lados. Primero, añadimos una conexión directa a la bbdd del monolito(en este caso era una réplica de sólo lectura) y ahí ya sacábamos diréctamente todos los datos necesarios para retornar al front end. → Última iteración, fue empezar a tener las tablas de las que dependíamos, por ejemplo empleados, duplicadas en nuestra bbdd del microservicio para ser autónomos. → Empezar a consumir los eventos de las diferentes entidades, como por ejemplo cuando se crea un empleado, actualiza ó se borra, de esa forma, tendríamos los datos en nuestro lado. Pero aquí faltaban los eventos de antes(SQS y SNS no son event store) entonces había que recrear estos eventos, ir a través de toda la tabla de empleados, y emitir un evento por cada uno para que esos datos se actualicen en nuestro lado. Recordad que podéis contactarme a través de https://remusrd.com . Este episodio fue grabado en twitch: https://www.twitch.tv/remusrichard
What this episode covers
→ Mi experiencia saliendo del monolito(Episodio anterior, hablábamos de qué approach elegir. https://open.spotify.com/episode/3ErtKuvhTxcHClZebZibCO?si=c9882cf7bd644d46 ) → Es una historia que suelo contar en las entrevistas cuando me preguntan por un fuck up(siguiente episodio) → Esto empezó cuando teníamos que sacar a microservicios cierta parte del funcionamiento del monolito → No se podían perder datos, había que tener las dos opciones siempre disponibles, es decir, ciertos clientes iban a usar una versión y el resto la otra(beta group) → No fue un desacoplamiento 100% del monolito, el monolito seguía recibiendo todas las peticiones, actuando como un api gateway, hacía autorización/autenticación y comprobaba si estabas en la beta para saber qué código ejecutar, si llamar al nuevo mS ó ejecutar el código php(feature flags → [<https://open.spotify.com/episode/4nyU3pzk7SIvtpIVFw71dB?si=MvUdVzOKS-mzAP5Z7o4MdQ>](<https://open.spotify.com/episode/4nyU3pzk7SIvtpIVFw71dB?si=MvUdVzOKS-mzAP5Z7o4MdQ>)) → La información que no se tenía en el microservicio, por ejemplo datos de empleados, se le forwardeaba al microservicio en la petición ó respuesta, ejemplo, si mi mS tuviese un id de propietario de una cuenta de banco, el monolito antes de pasarselo al front end de vuelta, le añadía el nombre y datos del propietario que necesitaba mostrar. El problema de esto es el acoplamiento que se crea. → Siguiente iteración, para quitar esta dependencia con el código de php, cada vez que hacíamos un cambio al contrato ó añadíamos un endpoint, teníamos que modificar el código en los dos lados. Primero, añadimos una conexión directa a la bbdd del monolito(en este caso era una réplica de sólo lectura) y ahí ya sacábamos diréctamente todos los datos necesarios para retornar al front end. → Última iteración, fue empezar a tener las tablas de las que dependíamos, por ejemplo empleados, duplicadas en nuestra bbdd del microservicio para ser autónomos. → Empezar a consumir los eventos de las diferentes entidades, como por ejemplo cuando se crea un empleado, actualiza ó se borra, de esa forma, tendríamos los datos en nuestro lado. Pero aquí faltaban los eventos de antes(SQS y SNS no son event store) entonces había que recrear estos eventos, ir a través de toda la tabla de empleados, y emitir un evento por cada uno para que esos datos se actualicen en nuestro lado. Recordad que podéis contactarme a través de https://remusrd.com . Este episodio fue grabado en twitch: https://www.twitch.tv/remusrichard
NOW PLAYING
PES 23 - Partiendo el monolito
No transcript for this episode yet