¿Amazon deja los MICROSERVICIOS?

Aprende Inglés con la oferta especial de Cambly sólo hasta el 18 de Mayo. Código 50BETTA para un 50% de DESCUENTO 👉 bit.ly/50BETTA
Artículo Prime Video: www.primevideotech.com/video-...
TheCommitShow: • The Commit Show
Conviértete en miembro de este canal para disfrutar de ventajas:
/ @bettatech
👾 Redes sociales 👾
► Twitter: / bettatech
► Instagram: / betta_tech
► Canal Secundario: / @forkdebettatech
► Discord: / discord
👨🏼‍🏫 MIS CURSOS 👨🏼‍🏫
👽 Curso de iniciación a la programación con JavaScript:
► bit.ly/3kr4bTc
👽 Curso de desarrollo backend con NodeJS y Express:
► bit.ly/3n4sirS
👕 MERCHANDISING DEL CANAL:
► Tienda KZbin: / bettatech
► Tienda Teespring: teespring.com/stores/bettatec...
⭐️ AFILIADOS ⭐️
🎵 TODA la música es de EpidemicSound:
► www.epidemicsound.com/referra...
✉️ CONTACTO PROFESIONAL:
► Respuesta no garantizada:
[e-mail]
📚 LIBROS 📚
Design Patterns
► amzn.to/39XuQlq
Head First Design Patterns
► amzn.to/2uq6XUq
Refactoring
► amzn.to/2SQnf2c
Clean Architecture
► amzn.to/3bZVonJ
Clean Code
► amzn.to/32WVKq3
Introduction to Algorithms
► amzn.to/34SyVFP
Cracking the Coding Interview
► amzn.to/2QkdwC6

[@KJImmy26]

Toda decisión tiene su trade off, no existe la mejor solución, sino más adecuada a una situación.

[@alexitox1993]

Denle una cerveza a este hombre, que esta en el lado correcto de la historia

[@mullinslol]

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

[@fernandoaguirre1924]

Todo tiene que estar en equilibrio y muchas veces algo hibrido es mas simple, funcional y economico que tener cientos de microservicios

[@franciscoguerreromorejon3981]

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 ;)

[@robertocarrichi]

Por favor algún día da un curso de infraestructura, contigo lo tomaría SIN DUDARLO. Eres increíble Betta. 🫡

[@cpaez2000]

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.

[@robertoguillen2165]

10:05 Nota: S3 no cobra por transferencias de datos entre servicios de AWS que se encuentren en la misma región

[@encryptedman]

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.

[@rbsnoticia]

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

[@tiyeman7176]

Algún día entenderé todo el Japonés de este señor

[@CarlosWolfram]

😐

[@santiagoarias854]

Jajaja si, con paciencia y un par de libros todo se puede

[@Sebastian_Desu]

Tranqui bro tu con calma lee aprende práctica y verás podrás aprender todo lo que quieras

[@ericjoel3826]

X2

[@wabalubadupdup]

Checa ejemplos nomás y pregúntate un montón

[@johanpalaciose]

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

[@Jocker88]

Muy buena explicación. Gracias por tu trabajo con los vídeos. :)

[@DeoCrespo]

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

[@sanreikaj]

Viene S4vitar al tercer episodio del podcast!! Excelente. Gracias por la info, muy buen video igualmente.

[@cg1192]

Buena explicación, estuve viendo videos del tema en inglés xD aqui lo entendí mejor y tienes razón.

[@alex148m]

Muy interesante el análisis beta, perfecto como siempre!!

[@drilosv13]

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

[@eliyya7374]

definitivamente debe ser el, pista mas obvia no hay

[@betoaguirre6413]

Cada uno de tus videos es una master class

[@SrSergioM]

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?

[@ramiroalegre8183]

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.

[@ramiroalegre8183]

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".

[@adiazwise]

Excelente tu explicación

[@StraightCoding]

Excelente video, muy claro. 👍

[@carlosrios7823]

Gran video, una pregunta que reloj es el que llevas? Sé que no tiene nada que ver con el video pero se ve brutal.

[@ronaldrojasrodriguez375]

Gracias doc

[@CicloKubits]

Sigue subiendo contenido así son muy buenos y didácticos

[@enfierradosRP]

Muy buena explicacion!

[@alexandrohdez3982]

Clarisimo, gracias 👏

[@RicardoGarcia-qk4th]

¿Tendrás un curso de aws?

[@azana1432]

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

[@richardperez8165]

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

[@CicloKubits]

Exelente video me encantó mucho

[@comanshark2332]

¡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.

[@donmacetoalicante3511]

lo que yo decia ....

[@EdwinRebolledo]

Buen video 👍

[@standardio8270]

Bien, buen video objetivo

[@natanaelmanzaneda6523]

Tremendo contenido Betta. Saludos de argentina

[@mariocortez25]

Donde tiene el micrófono?

[@pildoritagalactica7393]

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é

[@dnlsilver]

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

[@FinalHitTv]

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.

[@AlecraftYTMinecraftcomeonGamer]

Con decir se va a tensar que te cagas ya dijiste quién venía jajajajaj, muy buen vídeo sigue así Betta

[@COROLOSTO]

Que tal, pregunta inusual, Donde compraste tu playera?

[@cerm88]

Que bien explica todo Jason Statham

[@tiyeman7176]

Yo tengo el mismo fondo

[@nutexxx767]

Q son Los micro servicios? No entendi nada 😅 pero me encanto El video

[@marcelochinarro7972]

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.

[@josepacco]

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.

[@salazar.focus8]

porque el video esta en 24 fps?

[@unmonje55]

No abanique las manos y brazos , a nosotros no nos preocupa que usted quiera aprender a volar.

[@Fenrir145]

se va a tensar que te cagas jajaja, tito s4vitar un grande!, ya quiero ver ese episodio

[@SneijderLV]

Did you know Veronika? She has a youtube channel, wow, amazing

[@IbanNieto]

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 ;-)

[@devy1451]

cuando veo tus videos me siento parte de la nobleza programadora :v xd no sé por qué

[@ESArnau]

Me encanta tu reloj. Qué modelo es?

[@mariojosechavezferreyra4156]

me pregunto lo mismo xd

[@BettaTech]

Un casio gshock!

[@AC-sj7hu]

El invitado para el 3er episodio será S4vitar.... ya lo veo 😂

[@josemiguelgonzalezayala5957]

Molt bé Martín, contenido de calidad y no las chuflas esas que hay por ahí.

[@migueljurado6783]

👏👏

[@FabianMontoya]

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

[@ErPerezM]

jajaja, te esperamos S4vitar XD

[@random-vd7yy]

entonces a amazon prime le salia muy caro el uso de amazon web services? amazon se cobra a si misma?

[@daniels35]

PS claro no tienes una tienda y consumía tus productos gratis o si ? Si lo haces en algún momento quiebras

[@antonimmo]

Pues no gratis, pero te cobras menos, ¿no?

[@betoruizdev]

En resumen, seleccionaron una arquitectura poco adecuada, porque no estudiaron las métricas del servicio de monitoreo que ya poseían.

[@bryanvillalobos757]

Increíble.

[@falk167]

SE TENSARÁ

[@andryos5145]

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

[@BettaTech]

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.

[@rdlook004]

después de ver las arquitecturas me hace mas pensar de serverless a monolito. que de microservicios a monolito. ósea entiendo que las lambdas no dejan de ser microservicios pero es que estos también los obtienes en los contenedores del ECS igual siguen existiendo ahí.

[@rdlook004]

o mejor, de serverless a contendores

[@kamnibal]

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.

[@ldmarz4860]

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

[@timcesar1]

Netflix es micro servicios

[@romancalderin7966]

te llamas martin?!

[@bryanvillalobos757]

Increíble que la misma empresa no se hable.

[@jimmyroserovallejo]

O sea solo era clic bait ._.

[@nausiac]

azure toma la delantera

[@javierquirozgalindo664]

Que horrar tantas disculpas en un video jeje

[@pablomarianom]

Será que Tito S4vitar se aparezca por estos lados?

[@Fitoxdxd1]

Si es Amazon xq ellos mismos se cobran 🤔🤔🤔🤔

[@neyk]

el proximo commit es con s4vitar se tensó la cosa🤠

[@chiro5533]

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.

[@swator7]

Se ponen de acuerdo con @PeladoNerd para el post?

[@victororellano1921]

Acaso se viene S4vitar a the commit show? o es mi intuición

[@d.g.t.8877]

las fallas?. Entiendo que hay publico latinoamericano pero tambien hay español, Igual que a ellos les "chirria" fallos, a mi me chirria fallas.

[@pablorello]

¿Por qué hablas de los costes por llamada y por hora de servicio como si Amazon no fuera su propio proveedor?

[@d.r1775]

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.

[@encryptedman]

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.

[@calexito9448]

(Está picao)

[@raulsandoval262]

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á

[@SergioGonzalez-yo9dn]

Chapó

[@Zindokar]

Yo pago un vps y meto todo, al carrer

[@Emanuel-yb3qk]

Ptm acabo de terminar un curso de eso joder maldito capitalismo

[@lacasadeacero]

yo simplemente veo que es la mejor decision en base a la estructura global...no por una moda pasajera :v

[@Jo-planet]

Con microservicios es muy fácil de hacer .... ******!!!

[@yevtyurin134]

Tensar... Suena a a S4vitar 🤔😄

[@antonimmo]

Lo que me parece increíble es que se cobren a sí mismos

[@jogonpa]

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.

[@jonathancuellar5107]

Amazon pagandole a Amazon por infraestructura

[@pelochaco]

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

[@millosolo]

Puro ruido

[@BettaTech]

Ruido? 🤔 Si no das mas feedback no sé en qué mejorar 😅

[@eltrolado5764]

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

[@jorgemacias915]

Primer comentario?

[@carlosdeveloper]

Hay que felicitar al equipo que hizo el reactor de eso. Es ingeniería pura

[@CarlosCamargoOchoa]

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.

[@digimortaluis]

Excelente clickbait.

[@unmonje55]

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.

[@ennerlopezz]

@EnglishWithVeronikaMark 1:50??

[@sperformance.96]

Sigue siendo microservicio solo que un poco mas grande

[@DryadRoot]

como desarrollador, los microservicios me parecen una verdadera basura