Subscribe
Share
Share
Embed
Dev&Ops es el espacio donde hablamos de cultura tech, compartimos anécdotas reales y damos consejos prácticos para todo entusiasta del mundo del desarrollo y la tecnología. Acompáñanos a descubrir las últimas tendencias, aprender de nuestras experiencias y recibir tips que te ayudarán a destacar en este entorno digital en constante evolución.
Juan (00:00)
los microservicios
pueden llegar a amplificar, los problemas culturales que ya existían en la empresa. si teníamos una cultura muy pobre en cuanto a Code Review, con los microservicios va a ser peor. Si tenemos una cultura muy pobre en cuanto a testear, con los microservicios va a ser peor.
los parches temporales se vuelven la norma y eso es un gran problema porque
dejamos de hacer las buenas prácticas, ya que las buenas prácticas toman mucho tiempo o las buenas prácticas requieren que hagamos muchos cambios en diferentes partes del sistema y eso se vuelve complejo. Entonces, definitivamente los microservicios pueden llegar a amplificar la cultura que teníamos en nuestra empresa.
Sean todos bienvenidos a un nuevo episodio de Deben Ops. El día de hoy vamos a tener un tema interesante, creo yo que es un tema que puede ser muy útil si estás empezando o si ya tenés cierta experiencia con lo que son los microservicios. Los microservicios es de esos temas que creo que son muy, muy interesantes y pueden ser potenciadores para un sistema ya que dependiendo de las necesidades de cada quien puede llegar a
darte muchas ventajas. Pero también hay muchas cosas que se vuelven más complejas o que tienen ciertos pequeños truquitos por ahí, que creo que no se dicen por ahí, no se dicen en los diferentes tutoriales. Así que el día de hoy voy a tratar de compartirte un poco cómo ha sido mi experiencia, cuáles son esas cosas con las que vas a tener que tener cuidado al momento de implementar o al momento de darle mantenimiento a un sistema como este.
Así que bien, vamos a empezar y voy a empezar hablando con algo que creo que puede ser bastante obvio. Sin embargo, creo que vale la pena mencionarlo y es que la complejidad, la complejidad operativa explota de manera significativa. Con la complejidad operativa me refiero a cómo vamos a operar nosotros los developers junto con todo el resto del equipo.
para poder darle mantenimiento y poder agregar nuevas cosas, quitar cosas, etcétera. Todo lo que tiene que ver con esto en nuestro sistema se va a ver realmente incrementado en cuanto a complejidad. Eso probablemente ya lo esperabas, probablemente si ya has leído y te has empapado del tema de los microservicios, es algo que vas a haber notado desde la primera vez. Pero creo que aún así no es claro.
qué tanto puede llegar a llegar a complicar. Ojo, debo aclarar que tampoco significa que es algo que no podemos manejar, que es algo que se vuelve imposible de trabajar en ello. Simplemente comparado con lo que un sistema monolítico tradicional, donde tenemos el sistema de Model View Controller, realmente sí, la complejidad es muy muy grande comparado con eso.
aún así hay formas de mitigar esto y vamos a ir hablando un poco más adelante de cómo cuáles son las buenas prácticas que tenemos que tener en cuenta para que no tengamos estos problemas, para que podamos mitigar esto. Pero bueno, de antemano, eso es lo primero que probablemente no te dicen cuando te venden la idea de los microservicios y es que sí, la complejidad realmente incrementa, realmente es complicado y bueno, sólo como para terminar de mencionar esto, no me refiero sólo a la complejidad.
en cuanto a escribir el código. Me refiero a la complejidad general, los pipelines que tenemos, cómo vamos a monitorear los diferentes sistemas, los diferentes servicios, el hardware que tenemos, cómo vamos a planificar diferentes interacciones entre estos servicios, cómo la información del usuario va a estar guardada en diferentes partes de diferentes bases de datos. Todo esto...
incrementa la complejidad y es necesario que entendas cómo funciona todo en muchas partes del sistema, aun cuando tal vez no te corresponde. Me refiero a que a veces, dependiendo del equipo, puede hacer que estemos divididos. Yo tengo mi equipo que tiene que ver con todo lo que es las las cuentas de los usuarios, los perfiles, etc. Y hay otro equipo que se encarga de los pagos, de los cobros, etc. Aun así, cada uno de estos equipos va a tener que saber un poco de lo que hace el otro.
Y eso, como decía, incrementa la complejidad. También, ahondado con la complejidad, o enlazado con la complejidad, mejor dicho, creo que es necesario tener en cuenta que van a haber muchos fallos en la comunicación entre servicios. Y es que ya no es como antes, ya no es ejecutar una transacción, al finalizar esta transacción ejecuto la otra.
y así podemos ir orquestando todo lo demás. Ahora es más complejo porque cuando necesito llamar la ejecución número dos, probablemente esta ejecución se va a realizar en otro microservicio. Y aquí es donde entra todo este tema de cómo lo vamos a hacer, las diferentes arquitecturas, diferentes estrategias que hay para esto.
te van a beneficiar y te van a dar pros y contras dependiendo de cada una de ellas. No voy a entrar en detalle en todas estas, pero sí tenés que tener en cuenta que va a incrementar de nuevo la complejidad, pero más allá de que incrementen la complejidad, ya vamos a tener que tener en cuenta que van a ocurrir fallos. No se trata de si es posible que falle. No, van a ocurrir fallos. Y algo muy...
muy fácil, algo que puede llegar a pasar en la cuenta o en la transacción de pagos, probablemente necesitamos obtener cierta información del usuario que no se encuentre en ese microservicio, sino que se encuentre en otro. O tal vez no solamente extraer la información, sino hacer un segundo llamado en otro servicio que se encarga de calcular los puntos que tiene el usuario dentro de nuestra plataforma, algo así. Se me ocurren cosas al azar. Bueno, en ese caso,
van a ocurrir fallos en algún punto ya sea que esté relacionado con la red ya sea que esté relacionado con algún bug o simplemente alguien actualizó un servicio en ese preciso momento y pues dio la casualidad que en el momento que hizo el llamado pues no estaba disponible así que en ese en ese punto pues son cosas que suceden y es necesario empezar a pensar en ok cómo puedo volver a intentar los famosos retries no de
si falló vuelvo a intentar pero no intentó inmediatamente espero un poco vuelvo a intentar volvió a fallar ok ahora espero un poco más y vuelvo a intentar y podemos hacer ese orchestración de retries porque bueno tenemos que tener esto en cuenta y el punto con esto o lo que no se dice esto es mi experiencia lo que no te advierten
que estos problemas luego se desembocan en fallos en cascada. Así que falló el primer servicio, por ende, falló el segundo y este, como este segundo falló en una etapa intermedia, ahora otros servicios que dependían de él, pues tienen información errónea, tienen información incompleta y se vuelve todo un caos. Así que, de nuevo, te anticipo que estas cosas pasan. Así que es necesario...
desarrollar una estrategia que te permita mitigar estos problemas o más allá de mitigar, bueno, si sucede, ¿cómo puedo recuperar el estado deseado de la información sin tener que comprometer toda la infraestructura y todos los procesos que ya tenemos hechos? Luego, enlazándolo nuevamente con esto.
el hecho de que fallan y como mencionaba puede haber ocasiones donde tenemos la información está como corrupta por decirlo de alguna forma es cuando tenemos que empezar a pensar en tener la información descentralizada y esto es algo que por experiencia propia puedo decir que es bien complejo de asimilar al inicio porque venimos de pensar bueno tengo mi sistema y este sistema tiene una base de datos
Y bueno, esta base de datos puede estar replicada y hay muchas, varias instancias, pero conceptualmente es una sola base de datos. Y pasar de eso a un sistema de microservicios donde vamos a imaginar un caso donde hayan 20 microservicios, 10 microservicios, pues eso significa que serían en teoría 10 bases de datos.
He trabajado con diferentes estrategias al respecto, donde cada uno de los microservicios representa realmente una base de datos extra y también con otras estrategias donde cada base de datos representa un esquema dentro de la base de datos. Es como una subdivisión lógica dentro de la base de datos física. como varias bases de datos. Si has trabajado con Postgres...
pues esto se vuelve bastante fácil, creo que como María debe también y casi todas, ¿no? Tienen una forma de hacerlo. Pero el punto al que quiero llegar es que no importa cuál sea, el punto importante aquí es que nosotros empezamos a ver la información dividida y eso, como dije al inicio, es complejo, si bien pareciera que no es tan difícil.
si llega un punto donde estamos trabajando con tres microservicios al mismo tiempo y tenemos que tener en cuenta de, esta información pertenece a este microservicio y esta información pertenece al otro y ya es un poco complejo porque a nivel de programación tal vez tenemos un objeto que representa todo, pero realmente ese objeto está compuesto por diferentes llamados de diferentes bases de datos y eso, bueno, definitivamente es complejo.
Lo otro que tiene que ver con esto y que realmente hasta que estamos trabajando en este tipo de paradigma empezamos a notar que es un desafío, no diría que es un problema, es más como un desafío comparado con cómo solíamos trabajar tal vez, es el hecho de el famoso eventual consistency, básicamente consistencia eventual significa que en cierto momento
la información va a estar incompleta. Temporalmente va a estar errónea y eso de nuevo te lleva a pensar de otra forma porque ahora tenemos que tener en cuenta que en nuestro sistema vamos a imaginar algo simple. Tenemos un dashboard de nuestra página web y este dashboard muestra datos analíticos de la plataforma para el usuario.
tenemos que tener en cuenta que esos datos analíticos por X o Y motivo tal vez no estén actualizados en tiempo real, aun cuando todo, todo nuestro sistema está pensado para que sea en tiempo real. Pero debido a estos casos de consistencia eventual, tenemos que tener en cuenta que eso no, no puede que no sea el caso en ciertos momentos. Y eso lo menciono porque a veces
suele pasar que creemos que tiene que estar una información y no lo está y empezamos a confundir con que puede ser un bug y realmente no es un bug como tal es simplemente que es la naturaleza de este sistema así es pero pero bueno no es el fin del mundo no pasa nada en teoría debería ser algo temporal algo muy pequeño en escala de tiempo tal vez unos cuantos segundos unos cuantos minutos en el peor de los casos
Ya cuando toman más de eso, ahí sí, tal vez tenemos que tener en cuenta cómo mitigarlo, cómo podríamos solucionarlo y cómo no presentar información errónea al usuario. También depende del sistema como tal. Hay sistemas donde, pues, por la misma naturaleza del sistema, como dije, a veces la información se tiene que actualizar un día después, un día antes. Recuerdo trabajar con...
sistemas que tienen que lidiar con lo que son las zonas horarias. En lo personal eso es algo de lo más tedioso que he trabajado en toda mi carrera. Trabajar con pagos, trabajar con las cuentas de los usuarios, todo representa desafíos, pero trabajar con las diferentes zonas horarias en todo el mundo, eso es realmente un tema muy, muy complejo. Porque ahora tenemos que tener en cuenta que si el usuario tiene una diferencia horario de seis horas,
Pero qué pasa si el evento sucedió en una ubicación donde la diferencia horaria es de más 20 horas, más 10 horas. Es todo un lío. De nuevo, como dije, depende del sistema, del rubro, etcétera. Pero, son cosas que pasan y es hasta que estamos ahí que nos damos cuenta que, bueno, la información a veces tarda en que se actualice. Y...
A veces no pasa nada, pero si necesitas que sea lo más rápido posible, ahí es donde la implementación se empieza a complicar porque vamos a tener que estar replicando cosas, el llamado Edge en internet, por eso es muy popular, porque tenemos la información lo más cerca del usuario posible, pero aún así, aún en esos casos, tarda.
tarda porque tenemos que esperar a que el sistema se sincronice. Siguiendo con los diferentes puntos que tengo por aquí, tengo anotados algunos para que no se me olviden. Algo que también me gustaría, de lo que me gustaría hablar, es de los unit tests, bueno, de hecho no, unit tests no, sino las pruebas en general. Creo que podríamos llegar a hablar de lo que son los integration tests. Con integration tests,
Bueno, no quiero llegar a la definición más exacta, pero hablamos de las pruebas entre servicios. Generalmente, a me gusta tener diferentes pruebas que involucren múltiples servicios a la vez porque eso te da un mejor panorama de cómo está tu sistema, de si realmente un cambio que hiciste en un lado no va a...
a tener una implicación más grande en otra parte del sistema. Los unit tests son más simples, porque los unit tests ahora, por la misma naturaleza de los microservicios, como está todo simplificado, está con un dominio en específico, en un contexto en específico, pues los unit tests ahora se centralizan o se especifican, esa no es la palabra, se especializan.
en una sola cosa. Los unit tests no son un problema, los integration tests, eso sí. Imaginemos un caso simple, vamos a imaginar que quiero probar el sistema de pagos que estábamos hablando anteriormente. Bueno, para hacer un pago necesito loguearme, así que necesito hacer que en mi prueba incluir un paso donde el usuario se loguee. Obviamente todo es automatizado.
Ese logueo o inicio de sesión va a ir al servicio de cuentas, de auth o como esté llamado. Pero es algo aparte. El de pagos es otro microservicio. Entonces tengo que probar que mi inicio de sesión funcione y luego tengo que probar que con la sesión del usuario que está logueado pueda yo hacer la ejecución de los pagos.
Y luego, si el sistema de pago se involucra a diferentes pasos, ¿no? Hacer el pago, tal vez revertir el pago si algo falló, enviar un correo, y qué tal si este correo se envía desde otro sistema, otro microservicio especializado en correos. Bueno, entonces tengo que probar que eso también se ejecute y se vuelve toda una cadena de diferentes microservicios que son un poco complejas. De nuevo, son cosas que tal vez...
no estaban contempladas incluso en la planificación inicial. Nuestra planificación muchas veces se basa en, tengo que agregar un endpoint, tengo que agregar un repositorio de la base de datos y listo. Pero realmente tenemos que hacer más de eso. Tenemos que asegurarnos que las pruebas funcionen, asegurarnos que diferentes casos de pruebas estén siendo testeados. Entonces, hacer eso realmente es complejo. Y luego, incluir esto en el pipeline también
lleva su grado de complejidad y se vuelve más tedioso. Porque ahora tenemos que no solamente se trata de hacer un llamado, bueno, tenemos que levantar toda nuestra infraestructura. Eso implica, bueno, levantar las diferentes bases de datos, levantar todos los microservicios involucrados. Y si estamos teniendo conexiones a AWS S3 o correos,
Bueno, ahora tenemos que tener soluciones fake que hagan eso. No voy a estar haciendo pruebas con un bucket de AWS real, porque eso implicaría mucho costo. Más si estamos ejecutando múltiples tests durante el día, pues eso significa que vamos a estar haciendo un gasto innecesario. Entonces, tenemos que levantar una solución alternativa. Se me viene a la mente este contenedor o este servicio llamado Minio o Min.io, no sé cuál es la pronunciación.
que bueno levantamos un contenedor, levantamos múltiples contenedores y todos se comunican entre sí. Como dije, se vuelve complejo, se vuelve bastante tal vez no tan frágil. Yo creo que el mayor problema es olvidar actualizar estas pruebas o tal vez olvidar incluir las pruebas porque esto me ha pasado a mí. Trabajo en uno o dos microservicios a la vez, pero no agregué la integration test.
Y funciona, ¿no? Funciona, es la ventaja, funciona porque todo está bien. Pero la idea es que probemos no solo los casos buenos, también los casos malos, y esto nos va ayudar a detectar pues mayores problemas a la larga. Así que sí, los integration tests se vuelven más complicados, pero paradójicamente también se vuelven tu mayor utilidad, mayor arma en contra de posibles fallos en este ecosistema de microservicios.
Así que encarecidamente recomiendo que desde el inicio tengamos una solución para o incluyamos los integration test en el pipeline. Porque bueno, estos problemas son bastante técnicos, incluirlos, como dije, tal vez olvidé incluir los integration test, pero creo que los microservicios tienen una desventaja tal vez o no sé cómo llamarlo, pero es que
pueden llegar a amplificar, diría yo, los problemas culturales que ya existían en la empresa. Con esto me refiero a que si teníamos una cultura muy pobre en cuanto a Code Review, con los microservicios va a ser peor. Si tenemos una cultura muy pobre en cuanto a testear, con los microservicios va a ser peor. Porque ahora tenemos más cosas que tener en cuenta, más.
pequeñas piezas de nuestro sistema que necesitan atención y debido al tiempo, esto ya lo sabemos, los que trabajamos en este rubro sabemos que todo siempre es para ayer, siempre es con prioridad muy alta y eso a veces nos obliga a realizar cosas que no serían las más indicadas, ¿no? Creo que muchas veces se convierten los parches temporales se vuelven la norma y eso es un gran problema porque
dejamos de hacer las buenas prácticas, ya que las buenas prácticas toman mucho tiempo o las buenas prácticas requieren que hagamos muchos cambios en diferentes partes del sistema y eso se vuelve complejo. Entonces, definitivamente los microservicios pueden llegar a amplificar la cultura que teníamos en nuestra empresa. No voy a decir si buena o mala, yo creo que...
Como sea tu cultura, se va a amplificar con este tipo de arquitectura. Otra cosa que tengo pensado hablar y esto es como algo muy anecdótico. Aún no me he decidido si es algo bueno o es algo malo, pero el cómo gestionamos nuestros microservicios es complejo. ¿Qué quiero decir?
Bueno, cuando vemos tutoriales, cuando vemos diferentes artículos sobre microservicios, vamos a notar que nos dicen, hacemos un microservicio aquí, lo levantamos con Docker, con Kubernetes, con todo. Pero ¿dónde lo guardamos? ⁓ bueno, lo vamos a guardar en un repositorio en Git. OK, y lo vamos a guardar en un monorepo o múltiples repos. Y allí es donde todo se divide. Ahí es donde la comunidad, unos dicen que múltiples, otros dicen que monorepos, otros...
Otros dicen que es una mezcla, no sé, hay inventos de todo. Y creo que ese es uno de los puntos más complejos de cómo vamos a organizar nuestro código porque tanto un lado como el otro tiene pros y contras. Eso ya lo sabemos siempre. Lo que yo te puedo decir es que realmente hay diferentes... ¿Cómo decirlo? Si bien hay pros y contras, actualmente estoy más a favor de los monorrepos.
porque creo que los contras no son tan malos como o mejor dicho los pros opacan los contras creo que tienen mayores ventajas un monorepo que múltiples repos van a ver perdón van a ver diferentes casos donde pues sí vamos a empezar a quitar un servicio y lo vamos a poner aparte por x motiva pero en general
siento que trabajar, al menos en el campo de microservicios, trabajar con un monorepo trae más ventajas que tenerlo dividido en múltiples repos. Y se lo digo porque he trabajado con ambos, sigo trabajando con ambas estrategias y realmente cuando me toca actualizar diferentes repositorios de Git y luego tengo que actualizar uno para regresar al otro y cambiar la versión, lo vuelve más...
tedioso, no es malo, simplemente es más tedioso que con un monorrepo donde está todo junto y al final empezamos a... ya es todo el proceso CI-CD quien se encarga de crear los diferentes containers dependiendo del proyecto como tal. Pero bueno, esa es otra cosa que creo que nadie lo menciona y creo que sí vale la pena tomarlo en cuenta cuando estamos pasando a este tipo de arquitectura.
Otra cosa que tenemos que tener en cuenta, hay que tener en cuenta que esto va a suceder y por eso mismo hay que tener en cuenta que tenemos que mitigarlo. Me refiero a que vamos a tener muchas veces logs, o sea, logs son los mensajes que dejamos en el sistema que probablemente vayan a estar incompletos o no nos den una información útil.
realmente no es una información que sea útil al momento de debuggear que pasó algo malo. Esto me ha pasado a mí múltiples veces realmente porque cuando estamos haciendo un feature agregamos logs muchas veces que no son útiles o creemos que va a ser útil y resulta que no. Resulta que lo que estábamos agregando realmente no vale la pena. Mi consejo aquí es
Dos cosas, número uno, aprender a identificar qué cosas son útiles. Hay que imaginar, yo esto lo que hago, me imagino, en este flujo de datos vamos a decir, recibo un request y voy a procesar ese request. En todo este camino de que va a recibir esta información, que va combinar esta información, ¿qué datos serían útil en cada uno de los pasos si es que falla?
y empiezo a tratar de logear eso de la manera que sea posible. Hoy en día es fácil apagar o encender diferentes niveles de logs, así sea necesario. Me refiero a, bueno, ahora quiero ver solamente logs de error, solamente logs de error y también debug, logs de error y también trace, y así vamos controlando eso. Creo que es bastante bueno tener...
logs de diferentes tipos para diferentes cosas que estamos debugging. También eso por un lado. Y por el otro lado, quiero mencionar que desde el inicio es necesario, esto es más que todo para las personas que están pensando en implementar una arquitectura de microservicios, desde el inicio es necesario tener ya listo cuál va a ser nuestra estrategia de observabilidad.
cómo vamos a recolectar estos logs porque como mencionaba al inicio tenemos 10 o hasta 20 o hasta 50 o más microservicios a veces un request del cliente va a impactar a múltiples microservicios y tenemos que poder rastrear esas peticiones tenemos que rastrear todos los logs en diferentes partes del sistema, diferentes microservicios
Así que desde el inicio siempre es necesario tener muy claro cuál va a ser nuestra estrategia de observabilidad. Y bueno, definitivamente no es una tarea fácil, no es algo tan simple como activo una variable y listo. Pero por eso mismo vale la pena dedicarle el tiempo necesario para que más adelante no tengamos problemas con esto.
Con esto mismo, bueno, me gustaría ir cerrando también ya estas ideas que Algo que también suele suceder con los microservicios es que, como mencionaba, no, al inicio hablaba yo de hacer una petición desde un servicio a otro y este a otro y se hace una cadena. A veces no es lo mejor. A veces, o mejor dicho, en mi experiencia, por lo que he notado,
el 90 % de las veces lo mejor es utilizar una arquitectura o una estrategia de eventos. Me refiero a... Se hizo una petición en un microservicio, este microservicio hizo lo que tenía que hacer, dispara un evento. Ese evento lo va a procesar al microservicio al que le toque. Ese microservicio lo procesa y si es necesario dispara otro evento. Y así se van disparando eventos...
y lo vamos a ir procesando en diferentes partes de nuestro sistema. En mi opinión, y bueno, tal vez aquí estoy un poco zazgado porque esta es la manera que yo prefiero, pero creo que es la mejor forma para trabajar en microservicios. Por la misma naturaleza, como decía, de los microservicios, el hecho de que están separados, tienen diferentes bases de datos y que la red y que vamos a tener fallos en comunicación, creo que lo mejor es esto. Esto es lo que nos garantiza
de una manera más simple el poder procesar la información eventualmente. Bien, habiendo dicho eso, creo que los eventos o el event driven architecture es un arma de doble filo. Creo que a veces esto puede llegar a complicar las cosas y bueno, más que advertirte de qué hacer o qué no hacer, simplemente quisiera decirte que va a pasar, que cuando empezamos a...
arquitectar todo nuestro sistema en base a eventos va a llegar a un punto donde todo parece que está sucediendo por arte de magia y ya ni sabemos qué servicios son los que controlan o que consumen un evento. Se puede llegar a salir de control, definitivamente puede llegar a salir de control y nos vamos a ver tentados a regresar a una metodología más simple donde nada más guardamos en la
una base de datos y listo. O a veces nos vemos tentados en no voy a seccionar esta información, lo voy a procesar en este microservicio y ahí voy a hacer todo. No voy a llamar a otros microservicios. Eso puede ser, como dije, un arma de doble filo. Así que hay que estar atentos. aquí mi mayor recomendación es definir estándares, definir cómo se va a orquestrar todo esto.
y no salirnos de ello a pesar de que sea aburrido, pesar de que sea tedioso, estos estándares nos van a ayudar. Los estándares no solamente son para cómo vamos a nombrar las variables, cómo vamos a destructurar nuestras carpetas, sino vamos allá de eso, de todos los estándares de decir, un microservicio tiene que llamarse así, un microservicio tiene que llamar a una base de datos Sasa, un microservicio tiene que tener mínimo estas pruebas, mínimo estas comunicaciones.
Todo, todo, todo tiene que estar estipulado. no se basa solamente en escribirlas y decir, bueno, estas son las reglas y listo. No, me refiero a realmente que el equipo apunte al mismo lado y que todos sigan estos estándares, que se quede grabado en la cultura de la empresa, que estos son los estándares para los microservicios y hay que seguirlos.
Los estándares creo que es de nuevo, es otro tema que muchas veces no se habla y muchas veces no lo tenemos en cuenta. Pareciera que es algo simple, pareciera que es algo trivial, que no vale la pena o se va a ir haciendo sobre la marcha. A veces sí, pero creo que definitivamente vale la pena estructurar todo incluso antes desde el inicio. Dependiendo de las empresas puede que te den más o menos tiempo para prepararte si estás...
pasando de monolítico a microservicios y si te están dando tiempo creo que realmente vale la pena aprovecharlo al máximo y tratar de tener una estructura base. Ni siquiera es importante que sea la mejor estructura o que sea bueno estos son los estándares que sigue Google, sigue Facebook, no se trata de eso. Realmente lo más importante es que no importa a qué microservicio estemos viendo
No importa en qué lenguaje esté el microservicio, cada uno de los involucrados en el equipo va a poder ir a cualquier microservicio, a cualquier parte del sistema y poder identificar qué está pasando, poder identificar qué debería ser, cómo debería suceder y poder saber cómo se comporta la información dentro de nuestro servicio. Creo que esa es la gran y la mayor ventaja de tener los estándares.
es que ya ni siquiera vamos a tener que tener una capacitación en todos los microservicios porque si seguimos los estándares, no importa donde estemos en el sistema, vamos a poder salir de ello y vamos a poder trabajar en equipo. Bien, por ahora creo que lo vamos a dejar hasta aquí. Estos son los puntos que yo me he encontrado a lo largo de mi carrera trabajando en microservicios.
algunos pareciera que son bastante simples, tal vez no los hayas escuchado. Aun así, creo que todos y cada uno de ellos en mi experiencia han sido relevantes al trabajo y creo que han sido en cierto momento ha sido necesario definirlos, corregirlos, etc. Así que por eso te los comparto para que puedas tomarlos en cuenta al momento de trabajar con ellos.
Y bien, eso ha todo por esta ocasión. Antes de irme, me gustaría nuevamente mencionarte que tenemos diferentes redes sociales en las que podrías seguirnos, y es que no es así. Si nos estás viendo en YouTube, en Facebook, bueno, te comparto que tenemos redes sociales en TikTok, en Instagram y bueno, en estas diferentes redes sociales. También estamos en Spotify, Apple Podcast, en estas plataformas para podcast, por si quieres escucharnos.
mientras vas en el coche, en el carro, mientras estás caminando por el parque, no lo sé. Muchas gracias por seguir hasta este punto, muchas gracias por acompañarnos y apoyarnos en este precioso proyecto. Nos vemos a la próxima.