Me prepare el Cloud Practicioner y pensaba que me servia de poco, pero realmente gracias a ello he podido entender todo lo que cuentas en el vídeo. Siempre un ejemplo en la vida real hace mas fácil la comprensión de los conceptos nuevos
Gracias por tan concienzudo análisis. Al final, tenemos más herramientas disponibles cada vez y es parte del trabajo encontrar la adecuada para cada caso. Por ello tenemos tantos lenguajes de programación, tantos tipos de bases de datos, tantas arquitecturas.
excelente video, tal vez podrias hacer videos de algunos ejemplos de los proyectos en los que si viene bien los microservicios para saber cuando usarlos, algo mas ejemplificado saludos!!!
Esta es la mejor explicacion acerca de esto. Es un cambio partiendo en la comercializacion de servicios por parte de AWS. Mas que un cambio a partir de la ingenieria.
uno de los problemas de usar lambda y los eventos en algunos procesos que hace un lambda que demora mas de 15 minutos este muere por timeout y el step function nos puede ayudar a entrar en un bucle hasta que ese lambda termina su tarea por ejemplo si ese lambda tiene que registrar comercios en BD si recibe un archivo de mas de 600k comercios se demorara mas de 15 min y no procesara los 600k comercios con el step function se puede apoyar de otro lambda q verifique q este proceso haya terminado o no si no entrara en bucle hasta que termine de procesos los 600k comercios
Muy interesante la noticia 👍 fue muy grata la manera en que lo explicaste, el 17:18 si lo considero como una pista del próximo invitado creo que ya se quien puede ser jaja
Que buen aporte, todo lo que había visto era echar mierda a los microservicios, pero realmente es lo que tu dices y explicas muy bien, han encontrado un caso de uso que inicialmente se adaptaba pero que al momento de escalar han visto que se les iba de madre, lo bueno de AWS es que siempre tienes otra forma de plantear la solución sin menospreciar a la que inicialmente montaron ya que tambien tiene su caso de uso. Buen video ;)
Cuando algunos developers aprendan exactamente lo que es un microservicio y como funcionan, entonces podremos hablar de ésto. La triste realidad es que se ven por ahí muchos "microservicios" que realmente son monolitos. Ahí tenéis las cientos de miles de "APIs" que se conectan a mil sitios, te meten el login, la auth, la conectividad con mil DB, una UI buah (seguro que muchos sabéis de qué hablo)... Como bien se ha dicho en los comentarios: a veces un monolito es mejor que un microservicio, pero depende del caso. No son la solución a todos nuestros problemas (desde el punto de vista de un sysadmin o de un operador). A ver cuanto extirpan de una vez el REST que ya hay sistemas mucho más eficientes y va pasando el tiempo ;-)
Excelente video, nos hace reflexionar que no debemos usar siempre lo mismo para solucionar un problema, sino que debemos abrir nuestra mente a alternativas que puedan funcionar mejor
Hola betta tech, soy estudiante de 2o de ingeniería informática. Me gustaría saber por qué en el ámbito de computación está tan mal visto usar variables globales, atributos de clase y break en los bucles. Es algo que siempre me ha interesado, los profesores de la rama son bastante serios al respecto, todos los métodos tienen que estar super parametrizados etc... Gracias con antelación.
esto es lo que te dicce chat gpt En el ámbito de la computación, el uso de variables globales, atributos de clase y la declaración de "break" en bucles puede ser considerado una mala práctica por varias razones. A continuación, te explicaré las razones más comunes por las que se desaconseja su uso: Variables globales: Las variables globales son aquellas que se declaran fuera de cualquier función o método y pueden ser accedidas desde cualquier parte del código. Su mal uso puede llevar a problemas de mantenimiento y legibilidad del código, ya que cualquier parte del programa puede modificar su valor, lo que dificulta el seguimiento y la depuración de errores. Además, suelen dificultar la reutilización del código, ya que introduce dependencias ocultas y acopla diferentes partes del programa. Atributos de clase: En el contexto de la programación orientada a objetos, los atributos de clase son variables que pertenecen a una clase y son compartidas por todas las instancias de esa clase. El mal uso de atributos de clase puede llevar a problemas similares a las variables globales, ya que su modificación puede tener efectos secundarios inesperados en diferentes partes del programa. Además, dificultan la encapsulación y el mantenimiento del estado de los objetos, lo que puede llevar a errores difíciles de detectar y corregir. "Break" en bucles: El uso de la declaración "break" en bucles puede dificultar la legibilidad y el razonamiento lógico del código. Aunque en ciertos casos puede ser útil para salir de un bucle de manera prematura, su uso indiscriminado puede conducir a un flujo de control poco claro y a la creación de bucles infinitos o parcialmente ejecutados. En general, se considera una buena práctica utilizar estructuras de control más claras y predecibles, como el uso de condiciones en el bucle o el uso de una variable de control para controlar la salida del bucle. En resumen, estas prácticas son desaconsejadas debido a que pueden llevar a problemas de mantenibilidad, legibilidad, depuración y reutilización del código. Es importante seguir buenas prácticas de programación, como minimizar el uso de variables globales, utilizar atributos de clase con precaución y evitar el uso indiscriminado de la declaración "break" en bucles, con el fin de escribir un código más estructurado, modular y fácil de mantener.
Hola betta saludo quiero aprender a programar en el backend soy novato pero con muchas ganas de aprender , alguna recomendacion estaba aprendiendo python acepto consejos gracias
S3 se cobra por capacidad y no por transferencia siempre que sea en la misma zona de disponibilidad Aún así, el coste computacional será mucho menor, aparte de que lo único que guardan ahora son resultados y no videos completos. Gran video, aunque un poco amarillista también el título, no?
Me gusto la ultima refleccion, las balas de plata NO EXISTEN, no hay un santo grial, depende del requerimiento que herramientas, metodologias vamos a usar :3
Me viene perfecto este video, hace unos días vi el articulo y justo hoy vi un video de un "Ben Awad" de hace 2 años que dice que los Serverless no tienen sentido, probablemente va por ahí este video.
Pues sí me deje llevar por los titulares, las lambda no eran el problema, sino cómo estaban implementadas en su situación. Una aclaración que dijiste en el video (Dicho con mis palabras) es "¿Para qué utilizar serveless para una situación en donde se tienen muchisimas peticiones?, para eso mejor contratar una maquina EC2 que cobra por hora a una lambda que cobra por peticiones".
La verdad es que el uso de step functions me tira para atrás, y la alternativa sería tirar de eventbridge para disparar lambdas mediante eventos. Esto lo he hecho y ya no sabes qué llama a qué
Umm tengo una duda que no es de nivel técnico, entiendo que Prime Video le pertenece a Amazon (no lo sé), por lo cual ... ¿Por qué se cobran a si mismos por usar su propia infraestructura? o se refiere a otro tipo de costes que se han ahorrado? entiendo que los servicios y funciones de AWS nos lo cobren a terceros
No es tan raro que un subproducto de amazon (prime video) le cobre a otro (aws). Puede que ambos tengan sedes fiscales distintas, por ejemplo. A parte de eso, el coste de electricidad y energia se ha de pagar igual. Lo que consuma Prime Video, si amazon no lo cobra, son recursos que NO pueden vender a un cliente que si pague. Por lo tanto, le cobren o no, el coste es que estas perdiendo dinero igual pqe ese computo no lo vendes a otro.
Todo seguramente fue publicidad algo quieren vender, fue una mala practica de uso de microservicios, estuvo mal pensada desde el inicio y siguen usando microservicios.
Genial ver una experiencia de vida de los propios de AWS, para entender que siempre el mismo mundo nos fuerza a adaptarnos y cambiar la implementación de los servicios :D
Igual me queda la duda como hacen con la resilencia ahora tienen un proceso grande sin “checkpoint” que es otra forma de interpretar cuando cada step function terminaba su trabajo
Solo diré una cosa, Clean Architecture, hasta que la raza no entienda realmente como el polimorfismo nos ayuda a desacoplar las capas, seguirán habiendo desarrolladores que piensan que la infraestructura es la solución a todo.
¡Gracias, Martin, por compartir! La forma en que veo los microservicios es así: 1) Si la aplicación no es tan grande y consta de un único servicio o los servicios son interdependientes, uso un monolito modular. 2) Si tengo más servicios, separo los servicios que no son dependientes y los junto entre los que sí repitiendo el paso 1; tendría varios monolitos, que en sí, son microservicios. 3) Comunico todos los microservicios dependiendo de su sincronidad/asincronidad, o los conecto por la intefaz.
El problema de las personas es que creen que para todo hay una formula mágica, y no siempre es así Jaja, hay momentos donde una arquitectura que a algunos no les gusta, sea la mejor alternativa, y otras donde eso va a ser la peor idea del mundo, todo siempre depende de tu caso y lo abierto que estes a pensar en esas ideas
porque si un departamento no es rentable debes cerrarlo, lo mismo aplica para amazon. es más, ellos al tener ventaja deben ser mucho más rentables y si no, lo reestructuras o lo cierras.
Que pertenezca a la misma empresa no significa que no se debe facturar independiente lo que hace un departamento con los recursos de otros. Al final, los servicios de AWS cuestan recursos, si los pueden reducir siempre será mejor.
Buen vídeo pelado... mmmm pues he trabajado usando el monolitos con el servicio de Fargate y Microservicios en eks y te digo que me quedo con los microservice, así también los de amazon estan ofrecen instancia SPOT a %90 de descuento, en si son una mierda, se rompen en los microservice cuando quieren escalar, lógico todo esto desplegado con Don Pulumi o Go. Bueno también la latencia influye mucho de la región donde estas desplegando y a donde se consumirá
Certified fulano here, tengo un papel digital que dice que se supone que sé de lo que hablo El principal problema aquí es mantener el estado. Como bien dices, es un sistema distribuido basado en lambdas que no dejan de ser stateless (es un poquito mentira esto, eh? Pero ojo cuidao con el estado que mantienes ahí). Compartir información entre lambdas es trivial cuando tienes una Step Function ya que para cada ejecución tienes un estado que se va modificando conforme distintas tareas (en este caso lambdas) se van ejecutando. Eso sí, dicho estado es un JSON sencillito En el momento en que empezamos a hablar de un volumen grande de datos (un o varios frames) el JSON se te queda corto ("lo puedes encodear en base 64 mi mi mi" cállate subnormal), así que la solución más fácil, sencilla y directa es usar S3 como almacenamiento intermedio. Ahora bien, al romper el proceso en muchas lambdas pequeñitas (poco código por lambda => lambda más mantenible) hay muchísima transferencia de datos, que era el principal cost driver La forma de quitarse S3 es que todo se ejecute en el mismo proceso. Por poder poder se podrían juntar todas las lambdas en una una única, pero aquí probablemente tuvieran limitaciones en cuanto a memoria y/o tiempo de ejecución (recordemos que el límite máximo es de 15 minutos), así que el workaround es meterlo en ECS. Técnicamente, se podría haber refactorizado las lambdas para tirar de EFS en vez de S3 y mantener la arquitectura actual, pero ya que te pones a revisar el sistema... Claro, a posteriori es muy fácil decir esto de "Para volúmenes grandes de datos casi mejor meterlo todo en un mismo proceso". Así que lo metieron De cara a la implementación, pasar de muchas lambdas a un único proceso es trivial. Toda lambda expone un handler, sólo tienes que poner todas juntitas en un mismo ejecutable y picarte tú la orquestación que hacía antes Step Function
Eso de los microservicios era absurdo en el sentido de que era carisimo, un cluster te cuesta una fortuna. Ahora imaginate que usas 3 clusters entras en quiebra
Los recursos de las divisiones de una empresa se manejan por separado, si no lo hacen de esa manera, no van a tener proceso optimizados, es decir, para este caso no se hubiesen dado cuenta de que estaban perdiendo recursos. En una empresa cobrarle a otra división de la misma empresa permite obtener recursos extras para esa división, ya que al final del cierre te van a pedir cuentas, además si llegases a necesitar recursos para mantener tu división, la otras divisiones no te van a dar esos recursos, para estos casos se usan transferencia de fondos internos y los clientes se denominan clientes internos. He trabajado para varias compañías grandes y así se maneja.
Enormes vicios de la retórica por parte del locutor. No se entiende lo que habla. Cree que le esta hablando a niños de primaria y que les cuenta un cuentito. Somos adultos, hable pausado y pronunciando bien cada palabras. No necesitamos ver 20 minutos la cara de alguien hablando y escupiendo palabras luego comiendose la mitad de cada palabra al final de cada oración.
No pienso ni siquiera que fuera una mala decisión, simplemente los requerimientos evolucionan. Un día llegas a una empresa para mascotas y decides montar las solicitudes de atención medica para canarios en un Lambda, acto seguido un año después Disney saca una película, pone los canarios de moda y estalla el servicio hasta las nubes. ¿quien tiene la culpa?, nadie, ni siquiera la tecnología, simplemente las cosas cambian y ya.
Me prepare el Cloud Practicioner y pensaba que me servia de poco, pero realmente gracias a ello he podido entender todo lo que cuentas en el vídeo. Siempre un ejemplo en la vida real hace mas fácil la comprensión de los conceptos nuevos
10:05 Nota: S3 no cobra por transferencias de datos entre servicios de AWS que se encuentren en la misma región
Toda decisión tiene su trade off, no existe la mejor solución, sino más adecuada a una situación.
Denle una cerveza a este hombre, que esta en el lado correcto de la historia
Todo tiene que estar en equilibrio y muchas veces algo hibrido es mas simple, funcional y economico que tener cientos de microservicios
Gracias por tan concienzudo análisis. Al final, tenemos más herramientas disponibles cada vez y es parte del trabajo encontrar la adecuada para cada caso. Por ello tenemos tantos lenguajes de programación, tantos tipos de bases de datos, tantas arquitecturas.
excelente video, tal vez podrias hacer videos de algunos ejemplos de los proyectos en los que si viene bien los microservicios para saber cuando usarlos, algo mas ejemplificado saludos!!!
Esta es la mejor explicacion acerca de esto. Es un cambio partiendo en la comercializacion de servicios por parte de AWS. Mas que un cambio a partir de la ingenieria.
uno de los problemas de usar lambda y los eventos en algunos procesos que hace un lambda que demora mas de 15 minutos este muere por timeout y el step function nos puede ayudar a entrar en un bucle hasta que ese lambda termina su tarea por ejemplo si ese lambda tiene que registrar comercios en BD si recibe un archivo de mas de 600k comercios se demorara mas de 15 min y no procesara los 600k comercios con el step function se puede apoyar de otro lambda q verifique q este proceso haya terminado o no si no entrara en bucle hasta que termine de procesos los 600k comercios
en ese caso tambien podrias hacer un bulk save hybrido si optimizas la ram que usa el lambda, ahi reducirias muchisimo los ciclos de guardado
Por favor algún día da un curso de infraestructura, contigo lo tomaría SIN DUDARLO. Eres increíble Betta. 🫡
Muy interesante la noticia 👍 fue muy grata la manera en que lo explicaste, el 17:18 si lo considero como una pista del próximo invitado creo que ya se quien puede ser jaja
definitivamente debe ser el, pista mas obvia no hay
Algún día entenderé todo el Japonés de este señor
😐
Jajaja si, con paciencia y un par de libros todo se puede
Tranqui bro tu con calma lee aprende práctica y verás podrás aprender todo lo que quieras
X2
Checa ejemplos nomás y pregúntate un montón
Que buen aporte, todo lo que había visto era echar mierda a los microservicios, pero realmente es lo que tu dices y explicas muy bien, han encontrado un caso de uso que inicialmente se adaptaba pero que al momento de escalar han visto que se les iba de madre, lo bueno de AWS es que siempre tienes otra forma de plantear la solución sin menospreciar a la que inicialmente montaron ya que tambien tiene su caso de uso. Buen video ;)
Cuando algunos developers aprendan exactamente lo que es un microservicio y como funcionan, entonces podremos hablar de ésto.
La triste realidad es que se ven por ahí muchos "microservicios" que realmente son monolitos. Ahí tenéis las cientos de miles de "APIs" que se conectan a mil sitios, te meten el login, la auth, la conectividad con mil DB, una UI buah (seguro que muchos sabéis de qué hablo)...
Como bien se ha dicho en los comentarios: a veces un monolito es mejor que un microservicio, pero depende del caso. No son la solución a todos nuestros problemas (desde el punto de vista de un sysadmin o de un operador). A ver cuanto extirpan de una vez el REST que ya hay sistemas mucho más eficientes y va pasando el tiempo ;-)
Excelente video, nos hace reflexionar que no debemos usar siempre lo mismo para solucionar un problema, sino que debemos abrir nuestra mente a alternativas que puedan funcionar mejor
Hola betta tech, soy estudiante de 2o de ingeniería informática. Me gustaría saber por qué en el ámbito de computación está tan mal visto usar variables globales, atributos de clase y break en los bucles. Es algo que siempre me ha interesado, los profesores de la rama son bastante serios al respecto, todos los métodos tienen que estar super parametrizados etc...
Gracias con antelación.
esto es lo que te dicce chat gpt
En el ámbito de la computación, el uso de variables globales, atributos de clase y la declaración de "break" en bucles puede ser considerado una mala práctica por varias razones. A continuación, te explicaré las razones más comunes por las que se desaconseja su uso:
Variables globales: Las variables globales son aquellas que se declaran fuera de cualquier función o método y pueden ser accedidas desde cualquier parte del código. Su mal uso puede llevar a problemas de mantenimiento y legibilidad del código, ya que cualquier parte del programa puede modificar su valor, lo que dificulta el seguimiento y la depuración de errores. Además, suelen dificultar la reutilización del código, ya que introduce dependencias ocultas y acopla diferentes partes del programa.
Atributos de clase: En el contexto de la programación orientada a objetos, los atributos de clase son variables que pertenecen a una clase y son compartidas por todas las instancias de esa clase. El mal uso de atributos de clase puede llevar a problemas similares a las variables globales, ya que su modificación puede tener efectos secundarios inesperados en diferentes partes del programa. Además, dificultan la encapsulación y el mantenimiento del estado de los objetos, lo que puede llevar a errores difíciles de detectar y corregir.
"Break" en bucles: El uso de la declaración "break" en bucles puede dificultar la legibilidad y el razonamiento lógico del código. Aunque en ciertos casos puede ser útil para salir de un bucle de manera prematura, su uso indiscriminado puede conducir a un flujo de control poco claro y a la creación de bucles infinitos o parcialmente ejecutados. En general, se considera una buena práctica utilizar estructuras de control más claras y predecibles, como el uso de condiciones en el bucle o el uso de una variable de control para controlar la salida del bucle.
En resumen, estas prácticas son desaconsejadas debido a que pueden llevar a problemas de mantenibilidad, legibilidad, depuración y reutilización del código. Es importante seguir buenas prácticas de programación, como minimizar el uso de variables globales, utilizar atributos de clase con precaución y evitar el uso indiscriminado de la declaración "break" en bucles, con el fin de escribir un código más estructurado, modular y fácil de mantener.
Excelente video, muy claro. 👍
Hola betta saludo quiero aprender a programar en el backend soy novato pero con muchas ganas de aprender , alguna recomendacion estaba aprendiendo python acepto consejos gracias
Muy buena explicación. Gracias por tu trabajo con los vídeos. :)
S3 se cobra por capacidad y no por transferencia siempre que sea en la misma zona de disponibilidad
Aún así, el coste computacional será mucho menor, aparte de que lo único que guardan ahora son resultados y no videos completos.
Gran video, aunque un poco amarillista también el título, no?
Viene S4vitar al tercer episodio del podcast!! Excelente. Gracias por la info, muy buen video igualmente.
Gran video, una pregunta que reloj es el que llevas? Sé que no tiene nada que ver con el video pero se ve brutal.
Me gusto la ultima refleccion, las balas de plata NO EXISTEN, no hay un santo grial, depende del requerimiento que herramientas, metodologias vamos a usar :3
Donde tiene el micrófono?
¿Tendrás un curso de aws?
Me viene perfecto este video, hace unos días vi el articulo y justo hoy vi un video de un "Ben Awad" de hace 2 años que dice que los Serverless no tienen sentido, probablemente va por ahí este video.
Pues sí me deje llevar por los titulares, las lambda no eran el problema, sino cómo estaban implementadas en su situación. Una aclaración que dijiste en el video (Dicho con mis palabras) es "¿Para qué utilizar serveless para una situación en donde se tienen muchisimas peticiones?, para eso mejor contratar una maquina EC2 que cobra por hora a una lambda que cobra por peticiones".
La verdad es que el uso de step functions me tira para atrás, y la alternativa sería tirar de eventbridge para disparar lambdas mediante eventos. Esto lo he hecho y ya no sabes qué llama a qué
Muy interesante el análisis beta, perfecto como siempre!!
Umm tengo una duda que no es de nivel técnico, entiendo que Prime Video le pertenece a Amazon (no lo sé), por lo cual ... ¿Por qué se cobran a si mismos por usar su propia infraestructura? o se refiere a otro tipo de costes que se han ahorrado? entiendo que los servicios y funciones de AWS nos lo cobren a terceros
No es tan raro que un subproducto de amazon (prime video) le cobre a otro (aws). Puede que ambos tengan sedes fiscales distintas, por ejemplo.
A parte de eso, el coste de electricidad y energia se ha de pagar igual. Lo que consuma Prime Video, si amazon no lo cobra, son recursos que NO pueden vender a un cliente que si pague. Por lo tanto, le cobren o no, el coste es que estas perdiendo dinero igual pqe ese computo no lo vendes a otro.
Buena explicación, estuve viendo videos del tema en inglés xD aqui lo entendí mejor y tienes razón.
Que tal, pregunta inusual, Donde compraste tu playera?
Bueno y el tema que nos preocupa de verdad. ¿Qué marca es esa camiseta de la intro? Tiene pinta de tener una calidad increíble.
Todo seguramente fue publicidad algo quieren vender, fue una mala practica de uso de microservicios, estuvo mal pensada desde el inicio y siguen usando microservicios.
Tremendo contenido Betta. Saludos de argentina
porque el video esta en 24 fps?
Cada uno de tus videos es una master class
Excelente tu explicación
Clarisimo, gracias 👏
entonces a amazon prime le salia muy caro el uso de amazon web services? amazon se cobra a si misma?
PS claro no tienes una tienda y consumía tus productos gratis o si ?
Si lo haces en algún momento quiebras
Pues no gratis, pero te cobras menos, ¿no?
Muy buena explicacion!
Genial ver una experiencia de vida de los propios de AWS, para entender que siempre el mismo mundo nos fuerza a adaptarnos y cambiar la implementación de los servicios :D
Con decir se va a tensar que te cagas ya dijiste quién venía jajajajaj, muy buen vídeo sigue así Betta
Igual me queda la duda como hacen con la resilencia ahora tienen un proceso grande sin “checkpoint” que es otra forma de interpretar cuando cada step function terminaba su trabajo
las fallas?. Entiendo que hay publico latinoamericano pero tambien hay español, Igual que a ellos les "chirria" fallos, a mi me chirria fallas.
Sigue subiendo contenido así son muy buenos y didácticos
Gracias doc
Solo diré una cosa, Clean Architecture, hasta que la raza no entienda realmente como el polimorfismo nos ayuda a desacoplar las capas, seguirán habiendo desarrolladores que piensan que la infraestructura es la solución a todo.
Exelente video me encantó mucho
¡Gracias, Martin, por compartir!
La forma en que veo los microservicios es así:
1) Si la aplicación no es tan grande y consta de un único servicio o los servicios son interdependientes, uso un monolito modular.
2) Si tengo más servicios, separo los servicios que no son dependientes y los junto entre los que sí repitiendo el paso 1; tendría varios monolitos, que en sí, son microservicios.
3) Comunico todos los microservicios dependiendo de su sincronidad/asincronidad, o los conecto por la intefaz.
lo que yo decia ....
Did you know Veronika? She has a youtube channel, wow, amazing
Bien, buen video objetivo
El problema de las personas es que creen que para todo hay una formula mágica, y no siempre es así Jaja, hay momentos donde una arquitectura que a algunos no les gusta, sea la mejor alternativa, y otras donde eso va a ser la peor idea del mundo, todo siempre depende de tu caso y lo abierto que estes a pensar en esas ideas
Buen video 👍
No abanique las manos y brazos , a nosotros no nos preocupa que usted quiera aprender a volar.
Que bien explica todo Jason Statham
Me encanta tu reloj. Qué modelo es?
me pregunto lo mismo xd
Un casio gshock!
se va a tensar que te cagas jajaja, tito s4vitar un grande!, ya quiero ver ese episodio
El invitado para el 3er episodio será S4vitar.... ya lo veo 😂
Si es Amazon xq ellos mismos se cobran 🤔🤔🤔🤔
En resumen, seleccionaron una arquitectura poco adecuada, porque no estudiaron las métricas del servicio de monitoreo que ya poseían.
Increíble.
¿Por qué hablas de los costes por llamada y por hora de servicio como si Amazon no fuera su propio proveedor?
porque si un departamento no es rentable debes cerrarlo, lo mismo aplica para amazon. es más, ellos al tener ventaja deben ser mucho más rentables y si no, lo reestructuras o lo cierras.
Que pertenezca a la misma empresa no significa que no se debe facturar independiente lo que hace un departamento con los recursos de otros. Al final, los servicios de AWS cuestan recursos, si los pueden reducir siempre será mejor.
O sea solo era clic bait ._.
Acaso se viene S4vitar a the commit show? o es mi intuición
Yo tengo el mismo fondo
te llamas martin?!
Increíble que la misma empresa no se hable.
Buen vídeo pelado... mmmm pues he trabajado usando el monolitos con el servicio de Fargate y Microservicios en eks y te digo que me quedo con los microservice, así también los de amazon estan ofrecen instancia SPOT a %90 de descuento, en si son una mierda, se rompen en los microservice cuando quieren escalar, lógico todo esto desplegado con Don Pulumi o Go. Bueno también la latencia influye mucho de la región donde estas desplegando y a donde se consumirá
Se ponen de acuerdo con @PeladoNerd para el post?
Molt bé Martín, contenido de calidad y no las chuflas esas que hay por ahí.
jajaja, te esperamos S4vitar XD
azure toma la delantera
Certified fulano here, tengo un papel digital que dice que se supone que sé de lo que hablo
El principal problema aquí es mantener el estado. Como bien dices, es un sistema distribuido basado en lambdas que no dejan de ser stateless (es un poquito mentira esto, eh? Pero ojo cuidao con el estado que mantienes ahí). Compartir información entre lambdas es trivial cuando tienes una Step Function ya que para cada ejecución tienes un estado que se va modificando conforme distintas tareas (en este caso lambdas) se van ejecutando. Eso sí, dicho estado es un JSON sencillito
En el momento en que empezamos a hablar de un volumen grande de datos (un o varios frames) el JSON se te queda corto ("lo puedes encodear en base 64 mi mi mi" cállate subnormal), así que la solución más fácil, sencilla y directa es usar S3 como almacenamiento intermedio. Ahora bien, al romper el proceso en muchas lambdas pequeñitas (poco código por lambda => lambda más mantenible) hay muchísima transferencia de datos, que era el principal cost driver
La forma de quitarse S3 es que todo se ejecute en el mismo proceso. Por poder poder se podrían juntar todas las lambdas en una una única, pero aquí probablemente tuvieran limitaciones en cuanto a memoria y/o tiempo de ejecución (recordemos que el límite máximo es de 15 minutos), así que el workaround es meterlo en ECS. Técnicamente, se podría haber refactorizado las lambdas para tirar de EFS en vez de S3 y mantener la arquitectura actual, pero ya que te pones a revisar el sistema... Claro, a posteriori es muy fácil decir esto de "Para volúmenes grandes de datos casi mejor meterlo todo en un mismo proceso". Así que lo metieron
De cara a la implementación, pasar de muchas lambdas a un único proceso es trivial. Toda lambda expone un handler, sólo tienes que poner todas juntitas en un mismo ejecutable y picarte tú la orquestación que hacía antes Step Function
cuando veo tus videos me siento parte de la nobleza programadora :v xd no sé por qué
SE TENSARÁ
👏👏
Que horrar tantas disculpas en un video jeje
Netflix es micro servicios
Con microservicios es muy fácil de hacer .... ******!!!
Será que Tito S4vitar se aparezca por estos lados?
el proximo commit es con s4vitar se tensó la cosa🤠
Tensar... Suena a a S4vitar 🤔😄
yo simplemente veo que es la mejor decision en base a la estructura global...no por una moda pasajera :v
Eso de los microservicios era absurdo en el sentido de que era carisimo, un cluster te cuesta una fortuna. Ahora imaginate que usas 3 clusters entras en quiebra
(Está picao)
Puro ruido
Ruido? 🤔 Si no das mas feedback no sé en qué mejorar 😅
@EnglishWithVeronikaMark 1:50??
Amazon pagandole a Amazon por infraestructura
Ptm acabo de terminar un curso de eso joder maldito capitalismo
Yo pago un vps y meto todo, al carrer
Lo que me parece increíble es que se cobren a sí mismos
Los recursos de las divisiones de una empresa se manejan por separado, si no lo hacen de esa manera, no van a tener proceso optimizados, es decir, para este caso no se hubiesen dado cuenta de que estaban perdiendo recursos. En una empresa cobrarle a otra división de la misma empresa permite obtener recursos extras para esa división, ya que al final del cierre te van a pedir cuentas, además si llegases a necesitar recursos para mantener tu división, la otras divisiones no te van a dar esos recursos, para estos casos se usan transferencia de fondos internos y los clientes se denominan clientes internos. He trabajado para varias compañías grandes y así se maneja.
Chapó
Hay que felicitar al equipo que hizo el reactor de eso. Es ingeniería pura
Primer comentario?
Enormes vicios de la retórica por parte del locutor. No se entiende lo que habla. Cree que le esta hablando a niños de primaria y que les cuenta un cuentito. Somos adultos, hable pausado y pronunciando bien cada palabras. No necesitamos ver 20 minutos la cara de alguien hablando y escupiendo palabras luego comiendose la mitad de cada palabra al final de cada oración.
No pienso ni siquiera que fuera una mala decisión, simplemente los requerimientos evolucionan. Un día llegas a una empresa para mascotas y decides montar las solicitudes de atención medica para canarios en un Lambda, acto seguido un año después Disney saca una película, pone los canarios de moda y estalla el servicio hasta las nubes. ¿quien tiene la culpa?, nadie, ni siquiera la tecnología, simplemente las cosas cambian y ya.
Excelente clickbait.
Sigue siendo microservicio solo que un poco mas grande
como desarrollador, los microservicios me parecen una verdadera basura