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.
Douglas (00:00)
Juan, podríamos decir que esto de usar diferentes lenguajes solo sería ventaja tal vez en una aplicación grande donde se necesiten bastantes equipos de desarrollo. De esa manera...
ciertos equipos pueden usar su lenguaje preferido para los servicios que van a usar, pero si solo hay un equipo que se va a encargar de los servicios, tal vez a ese punto no sería recomendable por el manejo usar diferentes lenguajes. sea, tal vez podríamos marcarlo de esa manera.
ahí no se recomendaría.
Juan (00:33)
así
es correcto
Douglas (00:38)
Sean bienvenidos a un episodio más de Dev & Ops. Juan, bienvenido. Hoy arrancamos el episodio 3. Yo con todas las energías. qué tal estás?
Juan (00:51)
Hola Douglas, muy bien, me encuentro muy bien y muy a gusto de volver a este espacio que tenemos para hablar de todos estos temas que son muy interesantes. El tema de hoy creo que va a ser muy interesante para muchos, creo que es un tema que tal vez un poco aburrido para otros, pero muy necesario en general.
Douglas (01:13)
de acuerdo contigo Juan, esa es la actitud, ¿verdad? Me gusta que vengas con energías porque el tema de hoy realmente nos vamos a enfocar en servicios y microservicios y hoy queremos entrar un poco y poner un poco más la carne en el asador hablando un poco más técnico, ¿verdad? Siempre vamos a compartir ideas de cultura, de IT, de nuestras experiencias, pero queremos también entrar un poco en detalle
en cuestiones técnicas que tienen que ver con servicios y microservicios.
En los episodios anteriores vos nos has mencionado que en los últimos años tu rol principal es tanto la arquitectura y desarrollo de servicios y microservicios, tanto en implementaciones como en migraciones. Entonces, como siempre, verdad, y para quienes no han visto los episodios anteriores, aquí abordamos los diferentes temas desde nuestra experiencia, verdad, alrededor
de lo que ha sido trabajar ya sea en algo cultural o en algún aspecto técnico, ¿verdad? Las definiciones de libros se encuentran en chat GPT o en Google, pero Juan, en tu experiencia, en esto que has trabajado en los últimos años, contanos qué son los servicios y microservicios.
Juan (02:39)
Perfecto. Entonces, iniciemos. Y qué buena pregunta para iniciar. Al final del día, ¿qué es? ¿Qué son microservicios? Hay muchas personas que... De hecho, me he topado con personas que tienen altos puestos.
incluso maestros que me daban clases en la universidad. A veces me he topado con ellos, platico y les menciono un poco de lo que hago y se me quedan viendo un poco como qué es eso de microservicios. Y tiene sentido, tiene sentido el por qué no lo sepan. Vamos a ponerlo en palabras muy simples porque me gusta explicarlo de la manera en que yo lo entiendo y luego podemos ir expandiendo si es necesario. Los microservicios no son nada más que pequeñas aplicaciones
pequeños servicios que podemos seguir desarrollando y estas aplicaciones se encargan de una cosa en específico. Para dar un ejemplo más concreto podríamos decir que tenemos nuestra aplicación principal la cual acepta pagos, tiene suscripciones, tiene usuarios, tiene comentarios, cosas así. Podríamos tener entonces un microservicio encargado de toda la parte de pagos. Entonces
este microservicio su única responsabilidad es manejar lo que son los pagos, probablemente tal vez efectuar lo que son los invoices, los recibos y nada más, no tiene que preocuparse, esta aplicación en específico no va a tener que preocuparse por el manejo de sesiones, diferentes reportes y nada de eso. Y así podemos ir seccionando nuestra aplicación en concreto en pequeñas
aplicaciones más pequeñas y aquí vamos a poder empezar a hablar de por qué y para qué este de entrada vamos a dejar claro que no es necesario que todo el mundo haga esto
por eso mencionaba, es normal que muchas personas no sepan porque probablemente en su carrera no se han topado con este patrón de diseño, paradigma y está bien, no pasa nada, no quiere decir que si no estamos utilizando microservicios eso significa que entonces estamos desactualizados y ya no estamos haciendo las cosas como se deben, no, no, para nada es simplemente otra forma de hacerlo que nos brinda muchas ventajas
pero también desventajas. Entonces, hay muchas formas de estructurar nuestra aplicación. Hay muchas formas de crear estos pequeños microservicios. En algunas ocasiones se le llama simplemente servicios. Yo, lo personal, me gusta solamente decirle servicios porque la palabra micro a veces como que nos limita. Cuando decimos microservicios significa que la responsabilidad es muy, muy limitada.
Y al menos en mi experiencia, en la vida real eso no sucede. Muchas veces un microservicio crece bastante. Lo importante aquí es definir cuál es la responsabilidad y tratar de no salir de esos lineamientos, que es la parte difícil y por eso a veces tal vez muchas personas no transicionan a esa forma de estructurar nuestros servicios.
es un poco complejo y seamos sinceros cuando estamos arrancando con un negocio o una idea de software
tal vez empezar con microservicios no sea la mejor opción. Yo creo que a vos te ha pasado Douglas que hemos iniciado algún proyecto y pues lo mejor es iniciar con un par de scripts en PHP nuestra página HTML y listo. O si estamos con una aplicación de Windows
Douglas (06:27)
Sí.
Juan (06:31)
Pues también en la parte del backend como que va integrada, entonces es más difícil separar los microservicios. De esa manera, entonces, por eso considero que a veces es un poco complicado. No sé, desde tu punto de vista, ¿cómo has visto el auge? Porque al menos yo tal vez estoy un poco sesgado.
en el aspecto que creo que inicié en el mundo de los microservicios relativamente temprano en mi carrera.
Pero también he visto el antes, ¿no? He visto cómo antes las aplicaciones, la única forma de hacerlo era a través de aplicaciones monolíticas, más que todo por los recursos, Y creo que, bueno, en tu caso que has estado más del lado de manejar los servidores y los recursos, creo que has visto eso, cómo ha evolucionado el manejo de los diferentes servidores y este tipo de nuevos recursos, Para nuestra aplicación.
Douglas (07:33)
Sí, sí, he visto la evolución, como mencionás, de cierta manera, tanto en lo que me mantengo al tanto de noticias, de lo que hacen empresas grandes, la misma manera en la experiencia propia intentando.
Migrar, entiendo de la misma manera que vos lo que acabas de explicar y tal vez resumiendo los servicios y microservicios es separar en diferentes partes, acorde a su funcionalidad un sistema grande. Monolítico se llama aquella aplicación, aquel como decimos en Honduras, los san pedranos, aquel gran tamal.
Juan (08:11)
Correcto.
jajaja
Douglas (08:21)
que tiene todo
dentro usuarios, sesiones, pagos, inventario, proveedores, etcétera, etcétera, donde está todo en el mismo sistema y va absolutamente todo a la misma base de datos y como todo tiene sus pros y sus contras. Entonces, mi experiencia cuando inicié, realmente que
La simple idea de separar una aplicación monolítica en un clóster era algo que se consideraba delicado, ¿verdad? Era algo que se consideraba que agregaba mucha complejidad al sistema y se recibía muchas veces negativa de parte del equipo de desarrollo.
que eso mantenía siempre la estructura de un monolítico, pero se acostumbraba a hospedar inicialmente dependiendo de la aplicación. aplicaciones que son bien grandes de bancos que tienen diferentes capas, ¿verdad? Por capa me refiero a la base de datos, me refiero al backend, a veces a un frontend. Estamos hablando de principios de los 2000, ¿verdad? 2010. Pero cuando desarrollábamos aplicaciones,
Juan (09:38)
mmm
Douglas (09:42)
el programador estaba acostumbrado a que todo ocurriera en una misma máquina, ¿verdad? e intentar conectarse a la base de datos con algo que no sea localhost se recibía rechazo muchas veces. Entonces...
La idea de servicios y microservicios, definitivamente que ha tenido al menos en por mi parte, por mi experiencia propia, rechazo inicialmente del equipo de desarrollo, verdad. Sin embargo, cuando se logra entrar en esa mentalidad, cuando se logran ver los beneficios que trae, simplemente se crea esa adopción.
Juan (10:12)
mmm
Douglas (10:30)
y se empieza a ver una mejora, una mayor fluidez, más rápido lanzar cambios o nuevos features, nueva funcionalidad. Porque en el monolítico, si quiero cambiar un texto pequeño en el pie de la página, como es un nuevo código, me toca hacer testeo de todas las funcionalidades del monolítico.
porque es una sola base de código, es un solo paquete que se va a deployar en los servidores, entonces toca hacer eso. Pero si lo tenemos separado en secciones, no necesitamos probar los demás sistemas porque su base de código no va a cambiar, solamente probamos el footer, el pie de la página que se va probar. Entonces aquí quisiera llevar tal vez, la conversación a hundar
un poco más en los detalles de pros y contras. ¿Y por qué? ¿Qué lleva a tomar esa decisión al final? vos dijiste algo que me parece a mí clave. No toda aplicación se tiene que separar en monolítico. Y es ahí donde ponemos en la balanza los beneficios contra los retos y tomamos la decisión.
de o migramos un monolítico a microservicios o si cuando lanzamos por primera vez una aplicación vale la pena hacerla en monolítico o microservicios. De tu experiencia a nivel de desarrollo, a nivel de codificación, ¿cuáles son beneficios y cuáles son retos de implementar servicios y microservicios?
Juan (12:15)
Excelente. Sí, bien. Para adoptar esta forma de estructurar nuestros, generalmente yo me refiero a la palabra sistema como el todo, Para que nuestro sistema esté estructurado de una forma en microservicios, yo creo que tienen que cumplirse ciertos requisitos. El primero es que.
la aplicación requiera que tengamos alta disponibilidad. Eso es lo primero. sea, si alguna parte de nuestro código cambia.
y falla eso no debe afectar al resto del funcionamiento. Para dar un ejemplo más concreto, digamos que yo cambié algo en el microservicio que se encarga de enviar notificaciones por correo, es algo de reportería. Entonces, ¿qué pasa si eso tiene un bug, tiene un error? Y ahora el resto de la aplicación, todo mi sistema ya no funciona. Con los microservicios eso no pasaría porque solo
esa funcionalidad estaría caída y el resto estaría bien recordemos que en un sistema que tiene muchos usuarios, muchas transacciones pues que esté caído una hora, varias horas implica mucho dinero entonces una de las ventajas que podemos empezar a ver es eso que nuestro sistema se vuelve más robusto por el hecho de que cada parte es en teoría es independiente
entonces es más fácil que que todo esté estable. Un desafío es el hecho de cómo
¿Cómo definimos estos microservicios? Se habla mucho siempre sobre lo que es el dominio o el contexto de un servicio, de un microservicio. Como mencionaba antes, el ejemplo de pagos, a veces puede ser un poco complicado hasta qué punto podemos llegar, qué cosas corresponden a pagos, qué cosas corresponden a reportes.
y eso sucede con otros servicios que a veces se vuelven un poco más complicados. Si tenemos un servicio que se encarga solamente sobre las cuentas o los perfiles, un perfil es lo mismo que una cuenta, ahí es donde es difícil. Así que ese es un desafío inicial. Luego, una vez que ya tenemos definido esto, a veces las...
Una de las ventajas de los microservicios también se puede jugar en nuestra contra. es que muchas veces las personas mencionan que un beneficio es que cada microservicio podría estar en su lenguaje de programación independiente. Y eso es cierto. Puedo tener un servicio en Go, otro en Python, otro en Node y así. C-Chart puedo tener todo una jungla de diferentes, todo un ecosistema ahí bien extraño. En la realidad eso no pasa.
Douglas (15:13)
Sí.
Juan (15:29)
porque entre más diversidad introducimos es más complejo poder entender todo. Yo, por lo personal, soy una persona que me gusta mucho ver sobre diferentes lenguajes de programación, pero aún así yo no soy experto en todos.
Hay uno en el que me especializo y aún así no me considero experto. Y ahora imagínate ya teniendo cinco lenguajes en un solo sistema, pues es muy complicado. Así que esa es una ventaja, pero a la vez yo lo veo como una gran desventaja si empezamos a abusar de ello. Es muy raro y solo es en ciertos casos donde realmente es beneficioso tener diferentes lenguajes para diferentes microservicios. También tienes que tener.
Douglas (16:15)
Podríamos decir
Juan, podríamos decir que esto de usar diferentes lenguajes solo sería ventaja tal vez en una aplicación grande donde se necesiten bastantes equipos de desarrollo. De esa manera...
ciertos equipos pueden usar su lenguaje preferido para los servicios que van a usar, pero si solo hay un equipo que se va a encargar de los servicios, tal vez a ese punto no sería recomendable por el manejo usar diferentes lenguajes. sea, si es a cierto nivel una ventaja que se puede usar cualquier lenguaje, pero si es el mismo equipo que va a manejar todo, tal vez podríamos marcarlo de esa manera.
ahí no se recomendaría.
Juan (17:03)
exactamente así
es correcto eso es
porque pues no no no conozco cómo funcionan muchas empresas pero por lo general el equipo de desarrollo en back end no no supera los que podríamos decir tal vez 10 desarrolladores ya 10 es una empresa muy grande
generalmente es menos. sí, es donde lo mejor siempre es tener una coherencia. Aparte que es más fácil estructurar un microservicio con todos sus folders y todos los directorios que son requeridos y luego solo copiamos eso a otros microservicios. En cambio, si lo hacemos en otros lenguajes hay que volver a empezar y de nuevo, en lo personal yo lo veo más como una desventaja, más que una ventaja.
Bien, entonces, ¿cuándo deberíamos pasar a microservicios? ¿Cuándo deberíamos afrontar este reto? Hay muchos más retos y ya los vamos a ir viendo poco a Decíamos que tiene que ser una aplicación que requiera que resista a cambios y errores. Tiene que haber muchos usuarios. A veces no es tan así, pero por lo general son aplicaciones que son muy grandes.
lo otro es que
tal vez no tengamos tantos usuarios, no lleguemos a los miles de usuarios, pero sí es una aplicación que tal vez requiere que tenga mucha velocidad. Entonces aquí los microservicios nos dan otra ventaja y es el hecho de poder separar diferentes microservicios, que están enfocados solamente a tener una mayor performance, una mayor ventaja en la velocidad.
otro patrón de diseño que es muy muy útil pero también es un poco complicado es el CQRS entonces esto de nuevo en palabras muy simples es separar las lecturas y las escrituras de nuestra base de datos y esto se puede hacer con los microservicios porque podemos hacer un servicio
donde solamente obtenemos información, donde la información ya está estructurada de una forma y esta estructura es la que nosotros devolvemos, lo cual se vuelve muy rápido, los índices de la base de datos están optimizados para los queries que ya tenemos. En cambio, las escrituras las manejamos con otro microservicio que se empieza a orquestrar con diferentes, por ejemplo, NGINX podríamos tener este tipo de reglas, qué ruta va hacia qué microservicio.
Pero en general empezamos a estructurar nuestra aplicación para optimizar lo más que se puede la velocidad y que la experiencia de usuario sea muy responsiva y que no tenga retrasos en nada. Esto es muy útil. Entonces, aquí los microservicios son totalmente beneficiosos para esto.
Douglas (20:09)
Ahora Juan, con esto que estás diciendo, porque
entiendo que nos estás dando ventajas y desventajas y el que poner en la balanza al momento de decidir si quiero implementar microservicios o si no me conviene microservicios. Y estamos hablando de lenguajes de programación, estamos hablando de diferentes técnicas, ¿verdad?
Y se está mencionando, vos usas la palabra, lo que el sistema quiere, al final como un todo. Pero cuando hablamos de microservicios y dándole seguimiento a lo que estás diciendo, el microservicio como tal es un sistema individual. Lo que me tiene que llevar a tener una vista macro, que es el sistema del cual vos hablás, ¿verdad?
esa vista macro que me lleva a ver cómo el usuario que todo se integre y colabore y hable entre sí y se vea como uno solo, pero también esta vista micro donde agarro ese servicio en el cual estoy trabajando y lo veo como un sistema o una aplicación totalmente individual, por lo tanto lo arquitecto de manera individual. Y aquí viene mi pregunta para vos Juan.
Cuando los arquitectamos, tener un servicio o microservicio, puede tener su propia base de datos. Entiendo que al final hay una base de datos que es la fuente de la verdad, de source of truth, donde está la información final.
pero para su propio funcionamiento un microservicio puede tener su propia base de datos, tener su propia capa de caching, puede tener sus propios servidores y cron jobs y cosas individuales. Entonces, ¿qué tanta libertad?
hay a la hora de arquitectar cada servicio y qué tanto puede aplicar lo que dijimos de que en equipos pequeños no conviene tantos lenguajes de programación, tal vez qué tanto puede aplicar que en equipos pequeños no conviene arquitectar tan distinto cada servicio.
Juan (22:36)
Ok, en día yo considero que la dificultad recae en más que todo en qué punto de la vida del producto o del sistema vamos a hacer los microservicios. Es muy común que empecemos como una aplicación monolítica donde la aplicación en su totalidad es todo y luego transicionemos a microservicios.
Entonces, en esas transiciones es donde ocurre el mayor desafío porque tenemos que empezar a trasladar lógica que ya estaba muy amarrada a otras procesos y aquí es empezamos a ver esta palabra muy conocida, el decoupling, donde empezamos a separar procesos que anteriormente estaban amarrados entre comillas.
que dependía de la sesión, que se manejaba en el servidor y que dependía de que una variable de entorno que se maneja en otra parte del sistema. Entonces, esa es la parte más difícil. Obviamente, la base de datos también es lo que lleva el mayor desafío. Desde mi punto de vista, la base de datos es la que dicta cómo se va a estructurar todo. Entonces.
dependiendo de cómo que también hayamos diseñado la base de datos original eso también nos va a llevar a tener mayor problemas o que la transición sea un poco más fácil
Yo he tenido la experiencia de iniciar diferentes servicios, perdón, diferentes sistemas y aplicaciones. Y en algunos casos, más que todo porque ya he tenido la experiencia, ya he podido identificar dónde, OK, este producto conviene que desde el inicio arranquemos con microservicios. No tienen que ser 100 microservicios.
Pero sí que ya estructuremos todo y que tengamos todos los cimientos desde el inicio. Una aplicación donde ya podía yo marcar todos los cheques que yo puedo ver donde se requieren microservicios.
Y también he podido iniciar otros donde veo el potencial a futuro, que probablemente a futuro podamos transicionar a microservicios, pero que de inicio no es necesario. Porque también tenemos que tener en cuenta que si estamos iniciando un producto, ya sea un startup o sea una idea que tenemos entre colegas o este tipo de productos que están iniciando y el futuro es un poco incierto.
de nada sirve invertir todo este tiempo y todos estos recursos porque en los microservicios porque lleva tiempo y consume recursos si ni siquiera sabemos si vamos a tener usuarios vamos a tener todos estos microservicios con diferentes capas diferentes bases de datos para 10 usuarios como que no no no sale a cuentas entonces yo lo que puedo recomendar es que si tenemos una aplicación que va a iniciar pequeña
lo hacemos como monolítica, no pasa nada de hecho hoy en día yo lo que más recomiendo es un servicio es un framework realmente me cuesta definirlo pero es como un framework que se llama PocketBase
y esto lo que hace es que tenemos todo nuestro backend en un solo binario y nos permite agregar diferentes bases de datos, genera los queries casi automático y nos da ya un SDK que podemos conectarnos desde JavaScript o desde Dart o desde cualquier otra lenguaje y todo es una sola aplicación que de hecho funciona con SQL Lite
Entonces yo recomiendo eso de entrada, a pesar de que mi mi mi área de siempre los microservicios yo yo recomiendo eso. Ahora, cuando son aplicaciones que podemos ver que en un futuro van a transicionar a microservicios, yo considero que lo importante es poder diseñar desde el inicio un sistema de eventos con los eventos. Es donde podemos tener lo que vos mencionabas, el source of truth, donde tenemos un lugar donde tenemos la verdad.
decirlo así. Entonces estos eventos ya puede ser con RabbitMQ o puede ser con Kafka, son los dos por excelencia. Estos eventos podemos guardarlos de alguna forma, mucha ya aquí nos pasaríamos a otros temas, la idea es que tenemos estos eventos y con estos eventos luego va a ser mucho más fácil poder transicionar hacia este cualquier estructura de microservicios. Entonces teniendo eventos, y
algo más, teniendo ya de entrada un proveedor de autenticación. En este caso, lo que recomiendo PocketBase ya viene con uno, así que eso no hay problema, pero puede ser otro. Con tal implementemos OAuth, hay diferentes servicios que ya nos proveen esto. Entonces, con esas dos cosas, la transición a microservicios va a ser muy, muy...
fácil, la palabra fácil es un poco fuerte pero en general va a ser más fácil.
Douglas (27:59)
ser más manejable.
Ahora Juan, para aclarar un poco a quienes no tienen mucha experiencia en esto y vos por favor corregime en lo que no explique de la mejor manera, pero eventos es lo que conocemos como un sistema de cola donde funciona a diferencia de lo normal que son
llamados HTTP, donde se hace un llamado y luego espera la respuesta y manda una respuesta. El sistema de cola simplemente envío el mensaje que quiero enviar, lo pongo en la cola y me desconecto. Y entonces va pasando por orden como entró la cola y así luego es tomado por el siguiente sistema o por el siguiente servicio.
Como ejemplo, si yo estoy creando usuarios, yo soy el servicio que los crea, yo recibo la información, la valido, me aseguro que los que puso su nombre, su password, cumple con los requisitos, el correo, etcétera, etcétera. Y una vez que está, lo mando a la cola en lugar de una recuesta CTP. Y luego cuando le toca su turno, llega al servicio que lo escriba en la base de datos, lo recibe y dice que ya está.
Entonces esto es para cuando hay bastante tráfico o bastante movimiento, no quedan los servicios esperando la respuesta uno del otro, sino que él recibe su función, procesa y manda. Y ahí terminó. Luego al otro le toca el turno.
Entonces eso es lo que vos sugerís que se implemente si se piensa que el sistema que estamos desarrollando ahorita va a comenzar como monolítico pero que si veo que si crece eventualmente lo voy a migrar a servicios. A eso te estás refiriendo. Estoy en lo correcto.
Juan (30:02)
Sí, pero ya ahorita que lo estás explicando creo que tengo que dar un poco más de detalles. Lo que acabas de explicar es, bien y es el funcionamiento entre, digamos, dos servicios que cada uno de ellos está con su propia base de datos y digamos que están aislados uno del otro. Con los eventos no es posible establecer una comunicación entre ellos dos. Pero...
En este caso, yo lo que recomiendo es que lean un poco sobre lo que es CQRS y poder la capacidad de reproducir eventos, replay events. Entonces, la idea aquí es que tenemos nuestra aplicación normal. De nuevo, estoy hablando desde el punto donde tenemos nuestra aplicación monolítica. Todavía no vamos a pasar a microservicios, pero aparte,
podríamos tener un solo microservicio, una sola aplicación que se encarga de escuchar estos eventos y los está guardando. Puede ser en una base de datos, puede ser incluso en un archivo físico, en S3. ¿Qué es lo que hace? Cuando sucede una acción en nuestro sistema, por decirlo así, un usuario se registró. Entonces, ese evento de que el usuario se registró,
podríamos llamarlo user created ese es un evento que lleva su información su payload con todos los datos que nosotros convengamos que son importantes el usuario este la que pues el nombre de correo todo esto ese evento se envía
Lo procesamos con RabbitMQ, Kafka o incluso la misma base de datos. El medio no importa. Lo que importa es que podamos recibir ese evento y lo guardamos. Luego sucede otra acción. Podría ser que el usuario cambió su nombre, el nombre y apellido. Entonces aquí podría ser UserUpdated. Y también mandamos toda la información que representa ese evento, lo que acaba de suceder.
Lo procesamos y lo guardamos. La idea aquí es que más adelante nosotros podríamos volver a reproducir estos eventos en el orden en el que sucedieron. Así otro microservicio con su propia base de datos puede decir, OK, voy a reproducir todos los eventos y así como están llegando, yo empiezo a reconstruir la información que a mí me corresponde.
porque cada microservicio puede tener su propia base de datos con sus propias columnas, sus propias tablas, dependiendo de lo que necesite. Entonces con los eventos, de nuevo, aquí tal vez estoy hablando un poco algo que es un poco complicado si no tenés experiencia con los microservicios, pero si ya más o menos entienden el concepto, creo que esto puede ser algo que nos puede facilitar mucho la vida al momento de iniciar una nueva aplicación.
Porque ya teniendo los eventos, es muy fácil reconstruir la data. Es muy fácil agregar nuevos microservicios con nuevas bases de datos. Porque ahora solo tenemos que reproducir estos eventos y podemos reconstruir nuestra información. Entonces, con ese tipo de infraestructura ya hecha desde el inicio.
Como decía, no es que sea fácil. Lo que estoy hablando tal vez no es que sea sencillo. Pero sí nos va a hacer la vida más fácil y va a hacer que la aplicación pueda migrar a casi cualquier cosa.
Douglas (33:44)
son recomendaciones bien específicas, directas, pero a la vez me parecen recomendaciones de alguien que ha hecho esto antes y creo que eso pesa, eso vale. Tal vez este tema
no logra ser bien entendido por personas que son un poco nuevas en el mundo de informática, ya sea en desarrollo, ya sea en configuración de servidores, como se quiera ver. Pero para estas personas que ya tienen su tiempo programando y que tienen interés en ver si las aplicaciones que están manejando, o parte de sus estudios ya tienen experiencia haciendo, aunque sea aplicaciones demo o monolíticas, quieren llegar ahí. Entonces, creo que esos consejos que nos está dando Juan,
valen mucho, valen mucho y estoy seguro que vienen desde una perspectiva en la que te has topado con aciertos, con errores, con dificultades, con retos que te has tenido que sobrellevar y sobrevazar. Me gustaría, Juan, que entremos un poco en detalles de herramientas a utilizar al momento de arquitectar y comenzar a trabajar en servicios y microservicios.
Y para ponerle, tal vez, un poco de dinámica a la conversación, lo que quiero hacer es mencionar un tópico, un propósito de herramienta o de tecnología, y que vos nos digas, desde tu perspectiva, qué herramienta o tecnología recomendas. Y luego yo, desde mi perspectiva, qué herramienta y tecnología sugiero en base a un tópico específico sobre la implementación de microservicios.
Juan (35:26)
mmm
Douglas (35:36)
Entonces quiero... quiero comenzar con el lenguaje de programación.
Juan (35:36)
Suena bien, suena bien.
mmm
Douglas (35:41)
¿Qué lenguaje de programación recomendas? Y si, y si, sentís que son muchos y que encajan, tal vez si hay algunos lenguajes de programación que vos digas, estos por favor no se metan a hacer servicios o microservicios con estos lenguajes. ¿Cuál es tu recomendación en cuanto a lenguaje de programación para servicios y microservicios?
Juan (36:07)
Ok, ya aquí entramos en temas un poco polémicos porque en internet hablar de lenguaje de programación siempre genera caos. de entrada yo diría que es muy importante tener un lenguaje de programación tipado. Entonces ya aquí tipado, o sea donde tenemos tipos de datos.
Douglas (36:15)
Yo sé, yo sé lo que buscamos.
¿Un lenguaje qué, perdón?
Juan (36:36)
por ejemplo, Python y JavaScript no es que no sirven, no es que son malos, de hecho, mi trabajo actual, hay microservicios que tenemos que están en Python, pero considero que si utilizamos otras alternativas como C-Charp, Java, Kotlin, Go, todos estos que tienen tipos de datos, es mucho mejor y no sólo por la experiencia de desarrollo,
ya que nos dan los tipos, es más fácil saber qué cosa, qué hace cada cosa. Sino que también estos son lenguajes que son compilados. Entonces estos lenguajes compilados, o sea, tenemos que pasar algún proceso y convertirlo a un binario. Hoy en día estos binarios es muy fácil poder hacer un deployment al servidor.
Esto lo que nos da es más velocidad, aprovechamos más los servicios, siempre va a aprovechar más los servicios, un binario que ya fue compilado para el sistema operativo que tenemos en nuestro servidor, que pasar por un intérprete. De hecho aquí entonces tal vez Java incluso podría quedarse un poco relegado porque Java necesita su propio intérprete, pero aún así puede ser una buena opción. Así que aquí estoy sesgado.
debo admitirlo, al menos si es un microservicio, o sea, es una aplicación que vamos a correr en el servidor generalmente para páginas web, para servicios web. Entonces aquí Go creo que es de las mejores opciones. No recomendaría Rust, por ejemplo, para algo como esto.
Douglas (38:16)
Hmm...
Ok.
Juan (38:17)
O sea,
Rust creo que sería bueno para una aplicación, no sé, de la línea de comandos o una aplicación que se va ejecutar en Windows, en Linux, en Mac. Pero ya para el servidor y nuestros servicios web definitivamente. De hecho, Go nació con ese propósito para poder hacer más fácil microservicios y que estén en la nube y todo esto.
Entonces sí, aquí yo recomendaría Go, pero si aún así hay personas que no les gusta Go por múltiples razones. Mi otra recomendación es que busquen un lenguaje que sea compilado, que tenga tipos. Yo consideraría eso. Igual, hay muchas opciones. Yo he trabajado con Node.js, con Python, pero de nuevo, esa es mi recomendación personal.
Douglas (39:06)
Ok, sí, no debería de existir polémica, Juan, porque nos estás aclarando que es tu experiencia, tu recomendación, pero si a alguien no le parece, tómese la libertad de expresarlo. Desde mi perspectiva, Juan, como alguien de operaciones, como alguien de infraestructura y de servidores, voy a comenzar con mi preferencia, cualquier lenguaje que...
Juan (39:20)
Sí.
Douglas (39:36)
corra en Linux o Unix, cualquier lenguaje que no tenga que correr en Windows es mi preferencia y alrededor de esto hay ciertos beneficios también pero mi preferencia es ese lenguaje. Fuera de esa área realmente que por la parte de infraestructura
Juan (39:40)
mmm
Douglas (40:04)
impacto si hay aplicaciones que toma un poquito más configurarlas por ejemplo algo como java hay que compilar el archivo final el punto jar
Juan (40:19)
Mm-hmm.
Douglas (40:19)
luego hay que instalar un intérprete y luego hay que deployar ese YAR en el intérprete y lleva un poco más, pero al final del día las personas que administramos la infraestructura vamos a automatizar esos procesos. Entonces más allá de que nos tome un poco al inicio de tiempo esa configuración en el día a día nos va...
ser relativamente igual. También hay otros sistemas como Java, va a consumir más memoria, que tal vez es un lenguaje compilado, pero de igual manera, se le agregan más recursos, los recursos que necesita y ahí opera. Entonces desde la parte de servidores y de operaciones no hay una preferencia grande marcada y el lenguaje
mejor use el programador para que al momento que exista un problema se le pueda dar seguimiento fácil, el lenguaje que mejor use el programador, ese lenguaje nos adaptamos.
Juan (41:25)
Sí, Una última aclaración es que más allá también de la preferencia personal, esto es algo que yo he notado que normalmente creo que no hemos hablado de cómo hacer el deployment de los servicios, pero pues hoy en día es Docker. Generalmente son imágenes Docker o, bueno, tal vez contenedores. Vamos a hablarlo más, un poco más general.
algo que tenemos que tener en cuenta es que estas imágenes que se generan tienen un peso entonces estos lenguajes bueno por ejemplo Node.js una imagen en Node puede llegar a pesar los 100 megas o 50 megas tal vez si es muy pequeña en cambio en Go podemos tener imágenes de 12 megas 20 megas y esto lo que representa es que la transferencia
de datos es menor. En nuestro servidor estamos descargando menos datos, lo cual muchos servicios nos van a cobrar por esto. Así que es un ahorro para la empresa. ese es otro punto a tener en cuenta.
Douglas (42:36)
Sí, y no podemos tocar todos los temas ahorita porque también el costo y el ahorro al momento de diseñar y detectar sistemas, microservicios incluidos en ello es clave, es importante y es algo que debemos considerar. Pero continuando con las herramientas Juan, te adelantaste un poco en el sentido de cómo hay que...
build the app, build las aplicaciones y cómo se van a publicar estas aplicaciones.
la herramienta para CI-CD, herramienta de CI-CD y probablemente en algún punto dediquemos un episodio única y exclusivamente al arde CI-CD porque eso por sí solo es bastante, pero en pocas palabras es Continuous Integration que es construir la aplicación, instalar sus dependencias y Continuous Delivery que es publicación continua.
Juan (43:20)
Sí.
Douglas (43:35)
¿Qué herramienta sugerís? ¿Cuál es tu preferencia para escoger una herramienta de CI-CD cuando se trabaja con microservicios?
Juan (43:44)
¿Cuál es mi preferencia? Yo diría que hoy en día me gusta mucho trabajar con GitHub Actions. Sí, nuestro código está en GitHub. Creo que es bastante... Bueno, tal vez no he tenido la experiencia de hacer algo muy complejo, pero para el simple hecho de correr un test inicial...
construir la imagen, luego pasar esta imagen al servidor y hacer el deployment y que el servidor haga el... ¿cómo decirlo? este... quita la imagen anterior y ponga la nueva. Para eso yo creo que GitHub Actions me ha funcionado, la verdad. Pero si bien es cierto, a veces hay empresas que no les gusta tenerlo ahí.
y prefieren tener algo diferente o a veces requiere algo más complejo. perdón. Para lo... Creo que la otra alternativa por excelencia es Jenkins. Definitivamente Jenkins es una herramienta que es muy versátil, nos permite hacer muchas cosas. Nos permite tener...
escuchar a cambios en diferentes directorios de nuestro servicio, nuestro repositorio y hacer muchas cosas. Debo admitir que no tengo tanta experiencia en Jenkins, normalmente lo ha hecho otra persona en los lugares que he estado, pero de nuevo, la exposición que he tenido a ello me parece que es una gran herramienta que puede, podemos hacer algo desde muy simple hasta muy complejo, entonces...
si alguien empieza a aprender Jenkins creo que es una gran inversión de tiempo porque el conocimiento que adquirís es grandísimo es muy bueno fuera de esas dos me cuesta mucho pensar en otras sé que hay otros servicios hoy en día que ya te venden una suscripción y que se hace casi todo automático pero no sé creo que aún estoy un poco no sé no sé si
a la antigua de hacerlo yo, los pipelines. Entonces yo recomendaría cualquiera de esas dos dependiendo de la complejidad del proyecto.
Douglas (46:03)
entiendo tu perspectiva de developer alrededor de CI CD, lo cual tiene mucho sentido. Por mi parte, como alguien de operaciones o alguien de la parte de infraestructura, a nivel personal, el que más me gusta en la actualidad definitivamente es GitHub Actions también. Me parece que es bastante versátil y algo de lo que me gusta mucho es la colaboración que existe con los Actions como tal.
Yo mismo he trabajado en algunos actions, GitHub actions públicos, que están actualmente públicos y open source alrededor de escanear sitios de WordPress y alrededor de publicar WordPress a ciertas plataformas.
Pero esa colaboración que existe con GitHub Actions me parece fantástica. No es la única herramienta que lo tiene, por supuesto, pero creo que la comunidad alrededor de GitHub Actions es la más grande. Sin embargo...
Yo creo que hay otros proveedores de CI-CD muy buenos. Tenemos, vos mencionaste Jenkins, de hecho yo empecé, cuando yo entré a hacer CI-CD de una manera automatizada porque antes de que existieran estas herramientas teníamos Scripps.
que corríamos y hacían el instalar las dependencias y que luego copiaban el contenido a los servidores. Teníamos scripts que de cierta manera automatizaban. Cuando yo entré a CI-CD fue con Jenkins y como lo mencionaste es realmente algo muy poderoso.
ha ido mejorando más que todo su interfase, no tanto su funcionalidad, sea, sí ha mejorado la funcionalidad, me refiero a que siempre ha sido muy útil, buenísimo, pero lo que tiene que ver con su interfase ha ido mejorando con el tiempo.
Juan (47:55)
Sí.
hoy en día es como que es más intuitiva
que lo que era antes antes era muy raro de iniciar
Douglas (48:10)
si se ha vuelto más intuitivo, tener razón. Yo aquí lo que puedo hacer con herramientas es dar un par de tips o cosas a considerar. Uno, mantengan su CI-CD como código dentro del repositorio. Si hacemos Jenkins o hay otras herramientas donde podemos crear el pipeline.
con clicks, a eso se le dice click ops, no hagan click ops, pongan sus pipelines en código donde estén los archivos de build y de deploy y las tests y todas las pruebas que quieran hacer que estén como código cualquier herramienta que les permita hacer eso es buena, sirve, funciona
Segundo, si su empresa donde ustedes trabajan tienen requerimientos donde no se pueden usar servidores públicos, herramientas de nube como GitHub, Actions, GitLab y otras, permiten agregar runners, que son servidores donde corren esos procesos de build.
Juan (49:20)
Sí.
Douglas (49:23)
y deploy se pueden agregar runners que estén en su nube privada o en su data center privado y usan el servicio de nube pero al momento que corren los servicios y se comunican lo hacen desde sus runners internos y lo que sí les voy a recomendar
de preferencia no usar son los servicios que vienen con los proveedores de nube grandes como CodeBuild y CodeDeploy de AWS. Son pocos en Azure tenemos Azure DevOps. Se llama el servicio que te da repositorios en Azure y los pipelines.
Juan (50:00)
mmm
Douglas (50:07)
son robustos, nadie está diciendo que no, son muy robustos, pero son poco intuitivos, se prestan al click ops cuando el developer tiene la carrera, le da click y crea un proceso en lugar de hacerlo como código y al final a veces se vuelve muy tedioso estar dando permisos a cosas, eso sobre todo si vienen empezando, no recomiendo.
Juan (50:31)
y menos comunidad me imagino también, ¿verdad?
Douglas (50:34)
Si menos comodidad toca dar permisos a otra herramienta, más a los programadores y a la gente de operación, entonces son robustos, pero de preferencia no los recomendaría. Entonces eso en cuanto a CI, CD, quiero que pasemos ahora, Juan, y vos no mencionaste la preferencia sobre contenedores, y por aquí...
Juan (50:51)
La lista me irá.
Douglas (51:01)
Creo que anticipo cuál va a ser tu respuesta, pero ahora el hospedaje de los microservicios. ¿Cómo recomendás hospedar microservicios? ¿En dónde recomendás que se hospeden estos microservicios?
Juan (51:14)
Ok, ¿te referís en qué proveedor de servidores?
Douglas (51:24)
en todo sentido, que pueda abarcar a todo tipo de personas, empresas, necesidades, cuáles son tus recomendaciones, ya sea proveedores o herramientas.
Juan (51:28)
Ok, ok.
mmm
Ok interesante. Ok, curiosa pregunta. en lo personal, bueno aquí hay que tomar en cuenta que al momento de hablar de microservicios otra de las ventajas es que estos microservicios no tienen que estar en el mismo servidor que todos, Pero, y más cuando tenemos pocos microservicios y tenemos este, pocos recursos.
Podemos tenerlos todos dentro de un solo servidor y dentro de este servidor podemos asignar cada uno de estos servicios por separado.
al final del día va a depender de cuánta disponibilidad queremos porque si tenemos todo dentro del mismo servidor y ese servidor por algún motivo muere entonces todo nuestro sistema se cae y ahí ya perdimos la ventaja que teníamos con los microservicios pero puede ser una buena forma para iniciar y para empezar a meternos a este mundillo entonces en ese caso lo que necesitaríamos es tener una forma de tener estos servicios
y que estén separados y aislados. Así que aquí la forma de... ¿cómo decirlo? El estándar que está hoy en día en la industria es con contenedores. Puede ser Docker, Puede ser Podman, Kubernetes. Aquí a veces se confundan un poco los términos y a veces le llaman de una forma a otro.
Pero si utilizamos uno de estos, ya tenemos una forma para poder aislar los servicios. Con aislar me refiero a que una aplicación, un servicio, no tiene acceso a los recursos de otro servicio, no tiene acceso a los archivos, están cada quien por su lado, a pesar de que están en el mismo servidor.
y en ese sentido pues podemos tener todo en un solo lado y también si lo tenemos en diferentes servidores podemos utilizar estos mismos recursos, estos mismos orquestradores, docker, Kubernetes y podemos enlazarlos en un cluster ya aquí el tema es un poco más complejo pero en general si utilizamos eso yo diría que el proveedor de estos servidores físicos
es un poco, podríamos decir que no es irrelevante, pero podemos irnos con el que nos dé la mejor oferta en cuanto al costo. Hoy en día lo que todo el mundo utiliza es AWS, ahí es donde se alojan casi todos los servidores y gran parte del internet está en AWS.
Pero los demás, los competidores son igual de buenos porque yo he trabajado con AWS, con Google Cloud, no he trabajado con Azure. He utilizado otros más pequeños como este, cómo se llama este Digital Ocean.
no es que sea pequeño, pero no llega al nivel de AWS. También otro que se llama Linode, también muy bueno. Y al final del día, todos me ofrecen este tipo de soluciones para tener alojamiento de archivos, como lo que es el S3 de AWS. Me dan para poder manejar mis servidores y todos ofrecen casi lo mismo. Entonces, en este sentido, sí te diré que no
tengo yo una preferencia más allá de qué tan fácil sea de la interfaz. Por ejemplo, Google Cloud Platform es muy bueno, pero la interfaz es bien complicada de navegar. Pero es muy robusto, es muy fácil de dar permisos, nos permite dividir nuestro equipo. Lo mismo con AWS, es un poco complicado. Nunca he terminado de entender AWS, pero es súper robusto.
Por el contrario, Linode es muy fácil de utilizar, pero al momento de trabajar en equipo creo que es un poco más... flackea un poco. Entonces, en ese aspecto yo diría que tal vez con cualquiera de los tres grandes, AWS, Google o Azure, cualquiera están bien. Siempre y cuando utilicemos contenedores creo que vamos a estar totalmente tranquilos en ese aspecto.
Douglas (56:14)
me llama la atención tu perspectiva como programador porque por mi parte como alguien de servidores, como alguien de operaciones de hecho busco desde el inicio la alta disponibilidad y la separación aún cuando se venga iniciando y tener aunque la arquitectura
Juan (56:34)
mmm
Douglas (56:42)
de servicios y microservicios me permita correr varios desde un mismo servidor, ya sea con máquinas virtuales si es un servidor físico o con contenedores si estamos usando una tecnología de contenedores. Al final yo busco separar, pero está hablando con alguien que solía construir data centers.
y buscaba que el poder de cada servidor viniera cada servidor con dos fuentes distintas y que cada cable fuese conectado a un proveedor diferente de poder y lo mismo con el internet y así hasta llegar a la aplicación arriba. Yo recomiendo...
Juan (57:31)
Pero bueno, ahí
me gustaría tal vez aclarar un poco que a veces, sea, sí, definitivamente, y qué bueno que lo mencionas, tal vez lo estoy simplificando mucho. Creo que es casi necesario que mínimo sean dos servidores, por si uno se cae. Lo ideal sería tal vez de tres en adelante. Pero tal vez a veces lo simplifico un poco porque
Creo que cuando alguien está iniciando tal vez es un poco complicado. Tal vez no conocen estos conceptos. Tal vez ya solo están acostumbrados a trabajar con un solo servidor. Entonces, o a veces no hay presupuesto. No hay presupuesto y esto es lo que nos aprueba. a lo que voy es que la estructura de microservicios.
Nos permite cualquiera de las dos opciones, ya sea todo en un solo servidor o separarlo en varios servidores. Lo ideal es tenerlo separado, pero en sí el paradigma como tal no nos dicta cuántos tenemos que tener. Eso ya va a depender de cuán robusto vamos a tener nuestro, qué tan resiliente va a ser nuestro sistema.
Douglas (58:43)
Claro, claro y en ese sentido mi consejo sería todo esto aplica siempre y cuando estén en una etapa de sandboxing, una etapa de prueba de concepto para demostrar a los jefes que servicios y microservicios es lo que se necesita. Mi consejo sería no inician o no mire a servicios y microservicios.
sino tienen personas, talentos, que conozca lo necesario de cada capa, que conozca lo necesario en cuestión de desarrollo, de base de datos, que conozca lo necesario en cuestión de servidor, hospedaje, configuración, etcétera. Ya al momento de implementar para producción. Y en cuestión de hospedaje, yo recomiendo de igual manera contenedores.
Si están en un servicio de nube, Kubernetes, sin lugar a duda se administra, se maneja fácil, es fácil de agregar instancias, de quitar instancias y si usamos ya sea máquinas virtuales, no digamos servidores físicos, pero si usamos máquinas virtuales, el tiempo en que se agrega una nueva máquina virtual toma más tiempo que el tiempo en que se agrega un nuevo contenedor. Si están...
Juan (59:40)
jajaja
Douglas (1:00:04)
en su data center propio pueden usar, si su empresa tiene dinero, usar Kubernetes con OpenShift, que sería lo ideal, es extremadamente caro, pero es sólido, robusto y con un amplio soporte. O si quieren implementar Kubernetes lo pueden hacer con una herramienta, hay varias, pero Brancher Labs tienen unos servicios para hacerlo, o pudieran hacerlo si están en su propio data center con Docker Swarm.
Juan (1:00:14)
ok
Douglas (1:00:33)
mucha gente le tiene miedo pero en realidad para correr desde data center propios en mi opinión es la manera de iniciar pero mi recomendación es contenedores de igual manera se puede en máquinas virtuales sí pero la recomendación es contenedores entonces Juan para cerrar con esto de las herramientas y esto es algo que no hemos mencionado
de discutir la profundidad tanto, pero me gustaría que hablemos un poco del API Gateway y más que todo qué herramientas se aconseja el API Gateway, es este que está enfrente de todos los servicios y microservicios atrás y es el que lo hace actuar como que si fuese una sola aplicación, el API Gateway es el que responde a tudominio.com
y se responde el API Gateway y si le doy tudominio.com pleca usuarios, él redirige ese tráfico al servicio o microservicio de usuarios que fue escrito en GoLan, digamos, ¿verdad? Y si le doy tudominio.com pleca productos, el API Gateway es el que redirige ese...
Juan (1:01:45)
Sí.
Douglas (1:01:55)
tráfico al microservicio de productos que fue escrito contra la recomendación de Juan en Python y ahí se lo maneja, ¿verdad? Y de igual manera, así se encarga de dirigir el tráfico a los diferentes servicios independientemente de qué lenguaje se usó en el fondo, pero para el usuario que consume.
Juan (1:02:03)
Jajaja
Douglas (1:02:17)
La aplicación final, el API Gateway, perdón, el que hace actuar todo como uno solo, aparte provee la parte de seguridad. Con el API Gateway es donde se autentica de diferentes maneras, pero resumiéndolo, eso es lo que hace. ¿Qué herramientas recomendadas para API Gateway?
Juan (1:02:41)
ok aquí sí voy a ser sincero y creo que este es el tema donde sí estoy no tengo la mayor experiencia porque en los sistemas más grandes en los que he trabajado no he sido yo quien configura y arma todo esto sin embargo las opciones están creo que una de la primera opción que
muchos recomiendan y a veces dicen que no es que sea mala sino que es un poco complicada es NGINX, NGINX tiene diferentes variantes si no me equivoco y versiones y funciona muy bien de hecho donde estoy actualmente en el trabajo utilizan NGINX y funciona muy bien tenemos muchos microservicios
y tenemos rutas públicas y rutas internas y lo administra, de esa forma. De allí podríamos pasar a las siguientes recomendaciones que da la comunidad en general. Creo que con es otro otro gateway que recomiendan mucho.
Aquí tenemos un poco de exposición a esto, pero de nuevo no he podido configurarlo de cero, así que no podía darles mayores tips o recomendaciones. Sin embargo, Kong sí tiene una gran ventaja y es que nos permite agregarle diferente. Tiene integraciones con otros productos, otros plugins que nos pueden hacer la vida un poco más fácil.
y luego la última recomendación que yo podría hacer personalmente, esta si la he trabajado pero en servicios y sistemas un poco un poco más pequeños, no tan grandes a pesar que en teoría debe funcionar tanto para pequeños como grandes, este es Traffic
y Traffic es muy interesante porque está hecho en Go así que de ahí por eso lo conozco por eso empecé a verlo pero es muy interesante porque la configuración de las del enrutamiento viene del servicio del microservicio como tal porque funciona a base de labels por ejemplo en el Compose File, en el Docker Compose File
y también tiene integración con plugins, podemos crear plugins para traffic, incluso
Yo he podido hacer, he utilizado Traffic donde tenemos el rotamiento con subdominios, con rutas, estos subdominios apuntan a un servicio, las rutas apuntan a otro servicio, incluso con, ah, olvido el nombre de esto, pero nos permite tener un SSL gratis. Tal vez vos recordas. No, es...
Douglas (1:05:40)
SSL termination o SSL con let's encrypt.
Juan (1:05:44)
let's
encrit, si, si, si, es bien fácil y de nuevo para una aplicación de mediana tamaño funciona y funciona bien
Entonces, de nuevo, creo que estos de los temas donde no he tenido tanto... No he podido jugar tanto con estas herramientas, con la que más he trabajado es con Traffic. Y una vez que te acostumbras un poco a cómo funciona, yo ya lo veo bastante fácil de utilizar. Pero las otras con... y probablemente estoy olvidando algunas otras porque hay muchas opciones.
NGINX es otra alternativa que creo que no es una mala opción no va a ser una opción errónea si la utilizan entonces si NGINX con O-TRAFFIC esas serían mis recomendaciones
Douglas (1:06:35)
Muy bien Juan, y entiendo, en tu experiencia propia no es una parte de la infraestructura que te toca administrar o manejar. Por mi parte, desde el lado de operaciones, del lado de infraestructura, de manera simple, si estás en la nube yo recomiendo el API Gateway que te brinda tu proveedor de servicios.
AWS tiene API Gateway, Azure, lo grandes lo tienen. Si estás en un proveedor más pequeño, vos mencionaste Slino, mencionaste DigitalOcean.
Juan (1:07:08)
jajaja
Douglas (1:07:18)
que no tienen un servicio de API Gateway, de igual manera, si estás en tu propio data center, donde estás corriendo ya sea Kubernetes o Docker Swarm, porque en ambos se puede implementar API Gateway, yo recomendaría NGINX.
Juan (1:07:35)
Mm-hmm.
Douglas (1:07:39)
Uno solo si es para mediano grande solo si es NGINX Plus que es la versión pagada porque tiene integración con la autenticación y tiene muchas funcionalidades premium o muchas funcionalidades que obviamente vienen incluidas con la licencia. Si se va a usar NGINX la versión open source
lo recomendaría únicamente para sistemas pequeños que no tengan muchos servicios y no se requiera de diferentes tipos de autenticación y cosas más complejas. Por el contrario, yo recomendaría dos que vos mencionaste que son Traffic y Kong. Kong tiene también...
versión de paga. este caso creo que la versión gratis de Kong funciona muy bien para sistemas medianos. Creo que tiene lo necesario para hacerlos funcionar. Kong en el backend desde H.O. Engine X. Ellos tienen Engine X y tienen sus propios módulos que se encarga de las rutas y los diferentes servicios y tienen una interfaz encima de Engine X.
que los hace funcionar, muy fuerte, muy robusto. Traffic, por otra parte, ya mencionaste, es Hechen Golland y él se encarga de hacer el enrutamiento a su propia manera.
Estas serían mis recomendaciones en lo que tiene que ver con API Gateway. Ahora, para que vayamos cerrando Juan, porque nos hemos extendido y realmente que a pesar de que nos hemos extendido, yo siento que nos falta mucho más por hablar, esto es un tema bien amplio. Quisiera que nos des tus comentarios finales.
respecto a microservicios, en cuestión de qué recomendadas, qué mentalidad, cómo querés animar a la gente a explorar lo que son servicios y microservicios.
Juan (1:09:47)
Mi recomendación es que, primero que nada, exploren un poco cómo está la estructura de su empresa.
a ver si es posible que tan abierto están los jefes a adoptar este tipo de cosas. De entrada, voy a mencionar que no es algo que vamos a poder realizar. Me refiero a si ya es un producto establecido, ya nuestra aplicación ya está corriendo y tenemos...
muchos registros en la base de datos no es algo que se va a poder transicionar en un 2-3 meses si requiere mucha planeación y entre más no es que nos tardemos pero entre más planificación le dediquemos va a ser mejor a la larga y vamos a poder hacer una transición más limpia no es algo que hay que tomarnos a la ligera porque cambia todo cambia
cambia la forma en que trabajamos y cambia la estructura de los datos, cambia la comunicación interna de las diferentes capas de la aplicación, cambia todo. Pero creo que es importante, o lo que se podría hacer es empezar con ciertos, vamos a llamarlo módulos de la aplicación, ciertos módulos que nosotros consideremos que se pueden abstraer.
se puede abstraer por ejemplo un módulo que sea de correos, un módulo que se encargue de procesar diferentes reportes y los envíe por correo, eso podríamos tenerlo en un servicio aparte, una vez que eso funcione y todo esté bien, podríamos pasar con otro servicio.
Y así, ir transicionando de a poco. No tenemos que hacer todo de un solo. No tenemos que deshuesar nuestra aplicación desde un inicio. Podemos hacerlo por partes.
creo que una de partes más difíciles va a ser los datos de los usuarios en ese caso yo sí recomiendo que nuevamente busquen un tema que no hablamos de nuevo es mucha tela que cortar aquí pero el hecho de poder tener un sistema de autenticación y que este sistema de autenticación
pueda tener un, uf, lo siento, se me acaba de olvidar el nombre del concepto, pero es poder tener proveedores dentro del sistema. sea, tenemos nuestro sistema de autenticación y esta autenticación puede estar ligado a nuestro sistema de autenticación viejo, a nuestra base de datos vieja. Entonces, segregar, correcto. Podemos federar, perdón, federar.
Douglas (1:12:34)
federar los otros sistemas. Federar, federar. Sí.
Juan (1:12:41)
sistema de federación eso nos puede ayudar mucho a la migración de los datos y hoy en día hay muchos sistemas de autenticación que ya traen incluido esto no tenemos que hacerlo desde cero entonces eso mi recomendación es ir por partes y planificarlo mucho
para poder evitar diferentes errores que a la hora de la hora van a suceder errores pero entre mayor planeación haya va a ser más fácil corregirlo y bueno mantener el
el scope bastante limitado, pocos lenguajes de... no alocarnos con la cantidad de lenguajes de programación, definir estándares, definir estructuras de nuestros proyectos, todas estas cosas, de nuevo, que van en la fase de planeación, entre más estándares yemos todo, entre más tengamos un plan A y B y C, más fácil va a ser esta transición.
Douglas (1:13:45)
Ok, interesante. Muy buenos consejos, como siempre, tu parte, Juan. Por mi parte, yo quiero animar a todos, independientemente de cuál sea el lugar donde trabajen o cuál sea su nivel actual en su aprendizaje, en los proyectos personales de demo que hagan.
que una vez que entiendan el desarrollo y arquitectura de aplicaciones monolíticas, que una vez que entiendan el hospedaje de aplicaciones monolíticas, que dediquen el tiempo a comenzar a pensar en servicios y microservicios,
como algo propio, como algo en lo cual expandir su conocimiento, su mente, abrir su mente a estos estándares modernos de la industria de manera general, como algo que nos permite crecer como profesionales de IT. Ahora, en la implementación real de servicios y microservicios, yo recomiendo si su sistema...
cumple las cosas que mencionaste, si su sistema no cumple los requerimientos mínimos necesarios, no lo muevan a servicios o microservicios, si no lo necesitan, alégense de esa idea mientras no sea necesaria y aparte si
Juan (1:15:17)
Sí.
Douglas (1:15:25)
lo que ustedes manejan o lo que ustedes están haciendo, si tienen la necesidad de servicios y microservicios, nunca se vayan a producción si no tienen a alguien que entienda lo suficiente de cada una de diferentes capas. Aún en esta más de hora, diez minutos que llevamos hablando, no pudimos abordar todos los temas porque no se puede en una cápsula tan corta como esta.
pero no se vayan a producción si no tienen a que entienda lo necesario de cada una de las diferentes áreas cuando se refiere a servicios y microservicios porque a diferencia de un monolítico que de nuevo tiene sus pros y contras, cuando falla es necesario ver en múltiples lugares para tratar de identificar.
donde puede estar el error, si no se implementa de manera correcta, si se implementa de manera correcta es mucho más fácil encontrar dónde está el error porque es un servicio pequeño que está. Entonces, Juan ese ha sido el tema hoy, yo espero que quienes nos escuchan...
Juan (1:16:32)
Sí.
Douglas (1:16:40)
hayan podido llegar hasta el final, yo espero que quienes no lograron entender el tema porque tal vez están en una etapa más verde de su estudio en cuestión de tecnología, ya sea en desarrollo o en infraestructura, pues pudieran haber buscado, al menos aprendido conceptos nuevos y pudiéramos haber despertado ese interés en las personas de que existe este mundo de servicios y microservicios y que esa es la manera de trabajar con
aplicaciones o sistemas como vos dijiste es de gran escala entonces Juan un gusto haberte tenido me despido de vos
Juan (1:17:22)
Igual, sido un placer hablar de todo esto.
no sentí la hora para hacerte sincero, se pasó volando. Ojalá podamos continuar estos temas más adelante porque creo que son importantes para que la gente los vaya integrando y vayan interiorizando todos estos conceptos que al inicio son complejos. Si hay muchas cosas que no entendieron, no se preocupen, eso pasa. La verdad es que es difícil. Debo confesar que incluso yo hoy en día hay ciertos conceptos que todavía me confunden, pero pues sí, como dijo Douglas, espero que los
al menos nos hayamos impulsado un poco a aprender un poco sobre aprender más sobre esto y muchas gracias por habernos acompañado en esta plática en este no en este episodio del día de hoy
Douglas (1:18:12)
Gracias Juan.