Richard Stallman nos advirtió de estos peligros hace casi como 15 años. No le prestamos atención, dijimos y bueno, que puedo hacer, etc. Ahora luego del lunes negro y la probable recesión que se avecina en general, pero sobre todo en el sector tech... seguro volveremos a decir, y bueno, que puedo hacer yo, etc.
naaaa en el peor de los casos algunos ceos se retiran con menos dinero de lo planeado (es problemas de ellos no pasa nada es como ser boxeador y sentirse ofendido cuando te cae la trompada) lo que se malogra es la evaluacion de las empresas no es que se malogre la producion es como si tuvieras una vitrina de precios de productos y pasa un acidente que hace que le bajen los precios los productos malogras la venta del dia pero no malograste la producion en las fabricas
Los viejos administradores de sistemas no dejan de clamar a los 4 vientos que la nube debe bajarse a tierra en cuanto la empresa logre el suficiente capital, pero la gente no les hace caso.
Es que es muy cómoda la nube, eso tira mucho y te olvidas de tantísimos temas como refrigeración, cortes de luz, obsolescencia de equipos etc. A cambio sacrificas la sensación de seguridad que te da el datacenter propio.
Como les gusta el Saas y que ostia se van a meter, por esternalizar esa parte de negocio. Folladita de beneficios, de independencia y de todo, y encima lo suelen dejar en manos de grandes empresas monopolisticas como microsoft, amazon, etc.. que puede salir mal?
y tu eres de los nuevos administradores que paga cientos para lanzar un servicio y que despues te cierran el servicio y te vas a otro. Mientras la empresa pierde usuarios por andar jugando a las nubes? xd
@@AneudysAmparo bueno en realidad no tan baratas, porque en AWS nunca vas a tener el problema de "uy se quemó un disco uy se apagó la única instancia que tenías uy el raid falló" osea para pequeños clientes el cloud es un musthave, para quien ya tiene parametrizado su consumo obviamente un dedicado puede que sea mejor, pero no tan así de económico porque ya estarias hablando de que tenés 3000 usd o hasta 7000 usd al mes para pagar a un empleado que mantenga todo, mínimo...
@@joel6672 soy devops para una empresa que le trabajamos a múltiples empresas de telecomunicaciones. Tenemos múltiples postres con diferentes versiones, contenerizados. Problemas de postgres como tal, ninguno.
De ahí la importancia de la programación basada en abstracciones (interfaces), como ports and adapters (arq Hexagonal). Si cloud9 te falla, sólo has de cambiar el adaptador.
Las abstracciones no te salvan de tener que migrar a otro servicio, si no hay una especificación estándar y abierta para un servicio ( como muchos servicios cloud) estarás creando abstraccciones que solo funcionan con el servicio en cuestión.
y sin contar que tener servicios asi de rápidos de montar, hace que la empresa requiera menos personas en el área de desarrollo, que a lo mejor ese mismo grupo podría migrarlo si , pero habría de verse que proyectos se van a parar para que ese mismo grupo lo migre, y la dimensión de el problema en cada empresa, complicadito
Bueno, eso pasa tambien con software que no esta en la nube. Me ha pasado con librerias que dejan de tener soporte. O la nueva actualización cambia de licencia y ahora no puedes usarlo, etc. Por esto mismo siempre digo que el software no está "Hecho" nunca, es un ser vivo que hay que cuidarlo desde que nace hasta que muere.
Para eso hay tácticas, como en el empaquetadora dejar los paquetes en una versión definida, ya con el tiempo vas actualizando paquetes y veas que no se rompa, si es un caso de licencia, pues funciona igual dejando tal tecnología en esa versión cuando era gratuita, en cuestión de servicios no hay nada que hacer, te tienes que adaptar si o si
@@alexisduenas3179 Si, se pueden hacer parches para intentar seguir usando una librería obsoleta, pero siempre van a venir problemas con vulnerabilidades críticas, incompatibilidad con otras dependencias que necesitas, etc. Es cierto que con un servicio es más evidente, pero también estoy seguro que AWS se encargará de ofrecer ayuda para la migración en caso de que cierren definitivamente el servicio, cosa que con las librerías no pasa.
hay software legacy que realmente ya está hecho para siempre, como en algunas fábricas y algunos sistemas de ticket, medicina, pueden llevar 30 años funcionando sin problemas.
@@dieglhix si, si no se conectan a internet o no usan librerías open source, no hay problema. En embeded software no hay tanto problema como en sistemas que están conectados a internet y ofrecen un endpoint en la red
@@spanishcrab asi es, el internet ya es otro tema... generalmente se dejan en lo que se llama "Air gapping" o sea sin conexion fisica a internet, algunas veces hasta unos dispositivos diodos de datos que permiten fisicamente solo salir informacion (por ejemplo logs) pero es fisicamente imposible enviar datos a éstos sistemas
Le pasa a la gente que usa la nube sin medir los riesgos, una empresa muy grande no debería estar en la nube por que realmente puede pagar sus recursos , recordemos que la nube inicia para pymes con la promesa de que una pyme compita con las grandes, pero la avaricia, cuando pudieron debieron tener su propio hardware
@@lastdragonmx el problema es que a los CEOs se les paga para recortar gastos y mantener el precio de la accion alta y un servidor propio es un gasto bastante alto.
el problema no es la nube, el problema es no tener un plan de contingencia para cuando pasan estas cosas y poder cambiar a otro servicio en el menor tiempo posible.
@@MiguelReyesDeveloper 30 dolares. A ver... en un país ORDENADO no es mucho. Pero estoy en Argentina y eso si es muchisimo para nosotros. Mas para mi que no tengo trabajo y solo queria hacer mi proyecto de portfolio hajaja 😭😭😭
Para proyectos a pequeña escala lo mejor es un VPS barato. Con la computación en la nube te puedes despertar una mañana con una factura de 1000€ o que hayan eliminado algunos de los servicios que usas
nos pasó con Cloud Foundry de IBM, tocó migrar a Code Engine, se nos introdujeron problemas de performance y nos tocó costear cosas porque se nos podía ir el precio bastante. Se supone que Code Engine es elastico pero a veces simplemente no responden a tiempo las cosas y el producto aparenta no responder al usuario (un chatbot). IBM sí avisó con tiempo cuándo se iba a deprecar, a diferencia de AWS, pero en ese caso nunca entendimos qué pasó, porque Cloud Foundry era super económico y funcionaba super bien.
Lo más seguro era eso, como era económico, con ellos no les ha deber salido las proyecciónes de ganancias como esperaban, muchos de estos servicios aún no se saben que tanto rendimiento les darán a las grandes empresas, ya que estos servicios hay que observarlos por años para saber si tendrán frutos o no, me imagino estan empezando a cerrar servicios por que ellos les estan dando numeros rojos
Yo soy usuario de AWS desde hace muchos años y una vez me paso algo similar con quicksight, hicieron un despliegue y quitaron features, cuando le pregunte a soporte me dijeron ah si eso lo quitamos, al final me canse de preguntar donde estaba el changelog, y me toco migrar.
En mi empresa estan migrando los servicios a Azure Functions y yo no estoy deacuerdo con esta practica, el negocio se vuelve dependiente de la plataforma
Si crees que tu software sobrevivira a Azure y sin ninguna remodelacion de tu trabajo, es que no estas utilizando debidamente la nube. La contante evolución de la nube hace que se abaraten los costes, pero si sigues con miedo a la nube, aun asi puedes montarte kubernetes en ec2 con aws.
Yo igual hice unas apis rest como servicios para lambdas de aws con proxy inverso, gracias al proxy que agregue a las apis, un día me pidieron pasarlas a azure functions, ya que más arriba decidieron cambiar la arquitectura, y no tuve problema, usando terraform como preparaba el entorno de la lambda, solo hice cambios en ese script y vuala sin problemas para que funcionara en azure, gracias a esas buenas prácticas me ahorre trabajo, obviamente las bds estaban en servidor privado, pero las apis en la nube junto las interfaces (front-end), la verdad para usar la nube si se necesitan ciertos conocimientos para que te funcione, y si diria que hay que tomarnos la nube con pincitas, por estas cuestiones y otras...
Yo soy un humilde Instructor de soporte tecnico de Nivel Tecnico ,pero con no han pensando montar servidores base de datos,aplicaciones,correo en hardware propio en sistemas operativos como FreeBSD ,NetBSD o el sistema operativo Seguro llamado Open BSD o quizas en derivado open Source de Solaris Unix llamado Open Indiana que son open source y se llevan bien con el codigo cerrado por su licencia liberal pragmatica ,no soy un experto pero no es factible tener un servidor propio alterno por si acaso con BSD o un OpenIndiana
Yo pense lo mismo xd el problema es que si, ahora es con Code Commit que es una mierda y seguro no era de los servicios mas usados, pero que pasa cuando le toque a un servicio que si es mas popular? La cuestión es que no hay garantias, en cualquier momento por decisiones del proveedor te pueden dar de baja los servicios donde montaste toda tu infra y si no estas preparado te vas a quedar en la mierda
Por eso realizo Backup a otros proveedores externos Digital Ocean) y uno local. Siempre que activo servicios en proveedores externos, pienso lo malo: y si un dia cierran o eliminan mi cuenta..... Por cosas como esa, acciones para prevenir por si llegan a ocurrir.
Lo bueno de depender de sistemas externos es que te aligeran la implementación, lo MALO es que esta a MERCED de estas empresas sumado a que estos SE CAIGAN y te carguen la el día...
Es curioso, creo que ne ha tocado que me manden notificaciones empresas con las que tengo servicios. Algunos si son medio ambiguos con las decisiones que fueron tomadas para ello. Otros si te avisan, con algo de tiempo de anticipación, estos cambios. Bastante triste en este caso que no se les avisó como es deseado a las personas que tenían este tipo de servicios.
solo indicar que solo cuentas nuevas de AWS no podrán tener acceso al servicio. Cuentas existentes con el servicio activo/en uso, podrán añadir repos, usuarios, politicas, etc relacionado a codecommit. Lo anterior lo comento ya que en el video se hace alusión de que "ningun usuario nuevo..." pero en realidad es a nivel de cuentas nuevas. Solo eso gran Midu!
Con estas cosas te muestran la profesionalidad y poco respeto que tienen a sus clientes, yo si usara aws desde ya buscaria alternativas, no me podria quedar tranquilo de que mañana me cierren mas servicios y encima me tenga que enterar por twitter
Trabajo para una partner premmiun de aws. Lo que sucede es que los servicios suelen deprecar servicios. Anteriormente se ha hecho pero con algunos componentes o versiones. Pero sucede cuando son servicios que no suelen usarse mucho y no dan rentabilidad. Otra cosa que dices que te obliga a usar los servicio es mentira. Vos si hacias algun pipeline no necesariamente debes usar codecommit podrias usar lo que quisieras podias irte a usar github y github. Los architect de aws te va a recomendar pero la compañia es la que decia. Tambien si vos migras a aws como compañía aws aplica funding para ayudarlos a migrar ahi es donde es importante usar los servicios de aws. A nosotras tambien nos dio un poco de sorpresa mas que anda la ida de codecommit. De cloud9 no porque habia poco uso. Pero siempre aws te notifica a tu cuenta main dueña de toda la organización deben siempre estar atento a las notificaciónes
Siempre he tenido conflicto con los colegas que apuestan al server less y cloud coputing directo, siempre se debe de programar de forma de que se puedan montar servicios locales y wrapper de servicios y no directo al servicio, el problema se pone peor cuando tu código depende de la infra por que si se da un caso así, por un lado tiran tu infra y tu código ya no sirve para nada.
Amazon no es nada serio, yo me di cuenta por algo bastante tonto, había una skill de Alexa que se integraba con la API de listas, llamada AnyList, que era buenisima, y un día decidieron deprecarlo. Así por qué si. Desde entonces ya no me da confianza, toman decisiones con mucha irresponsabilidad.
El problema es cuando diseñas tu software muy acoplado para alguna infraestructura particular, tu software debe ser agnóstico a esto y tolerante a cambios, para que no sea tan traumático migrar a otro tipo de servicio.
acabamos de hacer un analisis respecto a donde centralizar los repositorios de una empresa donde había legacy de la empresa, desarrollo interno y desarrollo externo. CodeCommit nos resultaba la mejor opción para el proyecto, tanto por costos y por experiencia de las partes involucradas con la herramienta. Imagina que ahora tengo que explicarle al cliente que no vamos a poder crear esto, yo en su lugar desconfiaría de mi proceso, de la manera de proceder de AWS. Saludos Midu, amo AWS pero lo que no está bien, no está bien.
Hey terraform salvó mis apis en lambdas de aws, cuando me pidieron que las mirara a azure functions, solo cambie un poco el script de terraform y con eso me ahorre días de trabajo, solo fueron unas hrs
@@ricardoaliasno al 100, es muy similar, solo cambias valores y algunos parámetros, al menos a mí no me tocó cambiar tantas cosas, solo roles, promovedor, entre otras cosas banales, y de ahí no tuve que tocar codigo en mis apis, la verdad saber usar terraform si te salva de mucho cuando trabajas en la nube
Pero que esto no es una lección de que como empresa no puedes confiar en código(como Jquery en su momento), funcionalidad, soporte, bases de datos de terceros?, a menos que sea por contrato no puedes confiar a menos si es gratis.
La nube no es infinita, creo que puede ser una crisis de espacio, esto va a ser grandes movimientos de datos a otras nubes, al parecer la nube, va a tener que ser una sesión a un almacenamiento, en casa, y permisos de acceso solo con una sesión online, que permita el acceso desde cualquier parte de internet, un celular antiguo, o un raspberry con un ssd, y una especie de sistema operativo de servidor de aws code commit para raspberry pi(bajo consumo).
Lo malo de darle tanto poder a esas empresas, por desgracia somos esclavos de "nuestras decisiones", porque tal cual lo muestras, toman decisiones sin pensarlo o sin importar qué puede pasar, y la solución no está en tener los mismos servicios en otras empresas (Azure, GCP, Heroku, etc.), porque el coste sube dependiendo de tu "redundancia". Como bien dicen allí en X (antes Twitter), el problema es la falta de comunicación, y como bien dices, ¿Por qué no avisar con tiempo? Mal, mal, mal...
Yo como devops en una teleoperadora española durante 6 años migre entre 4 soluciones git más de 600 repos solo por falta de presupuesto y tacañería de jefazos, lleva meses algo asi
No lo hará, mejorará la documentación, pero veo muy poco probable que cambie ya que amplify o la validacion de las APIS siempre pasa a traves de OAuth ante cognito user pools
Verás las risas el día que un proveedor de cloud, de los muchos que salieron como setas en los últimos años, cierre por completo y deje tirados a sus usuarios.
Por qué son similares pero tiene sus diferencias, deprecado por qué aún se usa pero se está recomendando migrar, descontinuado es que ya no se dará soporte, ni parches, bla bla, aquí no es descontinuado por que aws apenas está avisando y por lo tanto aún hay soporte para los usuarios existentes, pero obviamente pasara a descontinuado en un futuro cercano, obsoleto es que de plano ya existen mejores alternativas y se usan mas que el que esta obsoleto (este ya no se usa, ya es un porcentaje mínimo quien lo usa)
sin dudas el servicio más NEFASTO que aws ha decidido sacar es, fue y será CODE COMMIT, no se pueden cerrar prs, no se pueden agregar reviews a las prs, no se puede poner protección de branch, y no sigo porque me hace acordar lo mal que la pasé trabajando con esa tecnología. ¿Porqué elegimos code commit? Porque al ser la empresa partner de aws nos exigian utilizar cierta cantidad de servicios en los proyectos de nuestros clientes (a cambio de beneficios obvio). Me pone muy contento que lo manden con odin.
En todos los cloud providers discontinúan distintos servicios, es normal, parte del ciclo de vida tecnológico. Pasa en on-premises, y en todos lados. La única solución es migrar y ya.
Por lo que tengo entendido, con que estudies uno, no es complicado agarrarle el truco a los demas, si quieres por demanda laboral, los mas populares son aws, azure y gcp, en ese orden
Claro, yo creo que Cloud Commit no lo usa ni Dios, ni los de AWS jaja. Por cierto, van a cerrar AWS QLDB, una base de datos inmutable tipo blockchain, aunque en este caso, me mandaron varios correos anunciando el fin del soporte para Julio de 2025 y una posible alternativa, migrar a Aurora PostgreSQL.
CodeCommit era muy malo, asi que me parece bien que le den de baja. Solo que algunos servicios de aws te obligaban a usarlo porque disque tenia mejor integracion.
Tu plataforma deberia ser cloud agnostic y si las cosas que tienes en la nube son muy importantes tu DRP tiene que soportar migraciones y estas se tienen que testear con frequencia. Al menos eso opino yo :)
Me dio por realizar un scrip, no lo he testeado, pero lo voy a pasar por si alguien quiere hacer su aporte, ¿cómo podría pasarlo Midu o gente? Gracias!
menos temas para estudiar para la certificación xd
Cierto jajaja, aunque no he visto preguntas de codeCommit en Practitioner o en SAA
@@benjaminch6292 en la de practitioner si me ha venido aunque debe haber sido solo una.
esas preguntas sobre (CodeCommit y/o Data Pipeline) solia venir en el examen para Developer Associate xd
jajajaja
Estos eran los fáciles del examen😂
Richard Stallman nos advirtió de estos peligros hace casi como 15 años. No le prestamos atención, dijimos y bueno, que puedo hacer, etc. Ahora luego del lunes negro y la probable recesión que se avecina en general, pero sobre todo en el sector tech... seguro volveremos a decir, y bueno, que puedo hacer yo, etc.
lol
Ai tienes a Richard Stallman como argumento, apaga y vamonos
El Hombre oso cerdo. La mas ingeniosa metafora de Southpark del c**!talismo
naaaa
en el peor de los casos algunos ceos se retiran con menos dinero de lo planeado (es problemas de ellos no pasa nada es como ser boxeador y sentirse ofendido cuando te cae la trompada)
lo que se malogra es la evaluacion de las empresas no es que se malogre la producion
es como si tuvieras una vitrina de precios de productos y pasa un acidente que hace que le bajen los precios los productos malogras la venta del dia pero no malograste la producion en las fabricas
Los viejos administradores de sistemas no dejan de clamar a los 4 vientos que la nube debe bajarse a tierra en cuanto la empresa logre el suficiente capital, pero la gente no les hace caso.
Es que es muy cómoda la nube, eso tira mucho y te olvidas de tantísimos temas como refrigeración, cortes de luz, obsolescencia de equipos etc.
A cambio sacrificas la sensación de seguridad que te da el datacenter propio.
lol estas loco hijo, no que fueras META para que eso valiera la pena
Como les gusta el Saas y que ostia se van a meter, por esternalizar esa parte de negocio. Folladita de beneficios, de independencia y de todo, y encima lo suelen dejar en manos de grandes empresas monopolisticas como microsoft, amazon, etc.. que puede salir mal?
y tu eres de los nuevos administradores que paga cientos para lanzar un servicio y que despues te cierran el servicio y te vas a otro. Mientras la empresa pierde usuarios por andar jugando a las nubes? xd
Algunas empresas ya lo están haciendo de hecho.
Siempre recuerden que la nube es la computadora de otra persona.
El agua moja
por ello me monte mi propio server xd.. Mi google privado. :>
a veces la gente se olvida de eso también
Exacto!, Sabes, lo peor de todo es que existen muchisimas alternativas mas economicas, pero "necesitan el Cloud".
@@AneudysAmparo bueno en realidad no tan baratas, porque en AWS nunca vas a tener el problema de "uy se quemó un disco uy se apagó la única instancia que tenías uy el raid falló" osea para pequeños clientes el cloud es un musthave, para quien ya tiene parametrizado su consumo obviamente un dedicado puede que sea mejor, pero no tan así de económico porque ya estarias hablando de que tenés 3000 usd o hasta 7000 usd al mes para pagar a un empleado que mantenga todo, mínimo...
Por eso siempre ee buenos aprender y priorizar usar contenedores y linux. Asi no haces vendorlocking y puedes usar cualquier hosting sin problema.
Usa contenedores y Linux para correr un Postgres a ver si no vas a llorar
@@joel6672 soy devops para una empresa que le trabajamos a múltiples empresas de telecomunicaciones. Tenemos múltiples postres con diferentes versiones, contenerizados. Problemas de postgres como tal, ninguno.
@@joel6672 yo lo hago, tengo justo lo que has dicho, cual es el problema?
A ver si GCP saca partido a este error de AWS.
Es increíble la falta de profesionalismo de una empresa tan monstruosa com AWS.
De ahí la importancia de la programación basada en abstracciones (interfaces), como ports and adapters (arq Hexagonal). Si cloud9 te falla, sólo has de cambiar el adaptador.
Las abstracciones no te salvan de tener que migrar a otro servicio, si no hay una especificación estándar y abierta para un servicio ( como muchos servicios cloud) estarás creando abstraccciones que solo funcionan con el servicio en cuestión.
y sin contar que tener servicios asi de rápidos de montar, hace que la empresa requiera menos personas en el área de desarrollo, que a lo mejor ese mismo grupo podría migrarlo si , pero habría de verse que proyectos se van a parar para que ese mismo grupo lo migre, y la dimensión de el problema en cada empresa, complicadito
Bueno, eso pasa tambien con software que no esta en la nube. Me ha pasado con librerias que dejan de tener soporte. O la nueva actualización cambia de licencia y ahora no puedes usarlo, etc. Por esto mismo siempre digo que el software no está "Hecho" nunca, es un ser vivo que hay que cuidarlo desde que nace hasta que muere.
Para eso hay tácticas, como en el empaquetadora dejar los paquetes en una versión definida, ya con el tiempo vas actualizando paquetes y veas que no se rompa, si es un caso de licencia, pues funciona igual dejando tal tecnología en esa versión cuando era gratuita, en cuestión de servicios no hay nada que hacer, te tienes que adaptar si o si
@@alexisduenas3179 Si, se pueden hacer parches para intentar seguir usando una librería obsoleta, pero siempre van a venir problemas con vulnerabilidades críticas, incompatibilidad con otras dependencias que necesitas, etc. Es cierto que con un servicio es más evidente, pero también estoy seguro que AWS se encargará de ofrecer ayuda para la migración en caso de que cierren definitivamente el servicio, cosa que con las librerías no pasa.
hay software legacy que realmente ya está hecho para siempre, como en algunas fábricas y algunos sistemas de ticket, medicina, pueden llevar 30 años funcionando sin problemas.
@@dieglhix si, si no se conectan a internet o no usan librerías open source, no hay problema. En embeded software no hay tanto problema como en sistemas que están conectados a internet y ofrecen un endpoint en la red
@@spanishcrab asi es, el internet ya es otro tema... generalmente se dejan en lo que se llama "Air gapping" o sea sin conexion fisica a internet, algunas veces hasta unos dispositivos diodos de datos que permiten fisicamente solo salir informacion (por ejemplo logs) pero es fisicamente imposible enviar datos a éstos sistemas
Le pasa a la gente que usa la nube sin medir los riesgos, una empresa muy grande no debería estar en la nube por que realmente puede pagar sus recursos , recordemos que la nube inicia para pymes con la promesa de que una pyme compita con las grandes, pero la avaricia, cuando pudieron debieron tener su propio hardware
@@lastdragonmx el problema es que a los CEOs se les paga para recortar gastos y mantener el precio de la accion alta y un servidor propio es un gasto bastante alto.
Deliveroo ,Lego, Vercel y Netflix no piensan igual
Me recordó a cuando Heroku decidió quitar la capa gratuita
@@AmigurumiVerse lloré un rio :(
Y perdió sus usuarios
Q servicios hay de servidores siempre encendidos, gratuitos?
@@avila176 Render, aunque si no hay actividad en más de 72 horas, la velocidad de respuesta se reduce hasta en 100 segundos.
Después de Heroku muchos otros cerraron el tier gratuito también: Fly .io, Railway, etc...
Siempre lo he dicho, la nube es el diablo.
Yo por no saber usarlo o no entender bien las cosas que ofrecia "gratis" terminé pagando una bill enorme por un PROYECTO DE PORTFOLIO 💀💀💀💀
@@daniiespinoza1 ¿Cuánto pagaste?😵
@@daniiespinoza1 aws suele ser bastante misericordiosa para nuevos usuarios, he visto a gente perdonarle 80K dolares de factura
el problema no es la nube, el problema es no tener un plan de contingencia para cuando pasan estas cosas y poder cambiar a otro servicio en el menor tiempo posible.
@@MiguelReyesDeveloper 30 dolares. A ver... en un país ORDENADO no es mucho. Pero estoy en Argentina y eso si es muchisimo para nosotros. Mas para mi que no tengo trabajo y solo queria hacer mi proyecto de portfolio hajaja 😭😭😭
Estados Unidos está colapsando. Yo sugeriría no usar mucho los servicios en la nube al menos mientras dure la reseción
Para proyectos a pequeña escala lo mejor es un VPS barato. Con la computación en la nube te puedes despertar una mañana con una factura de 1000€ o que hayan eliminado algunos de los servicios que usas
Ahora la noticia de AWS de que dio baja esos servicios porque le vino muy cara la factura de vercel si que va a ser una sorpresa.
nos pasó con Cloud Foundry de IBM, tocó migrar a Code Engine, se nos introdujeron problemas de performance y nos tocó costear cosas porque se nos podía ir el precio bastante. Se supone que Code Engine es elastico pero a veces simplemente no responden a tiempo las cosas y el producto aparenta no responder al usuario (un chatbot). IBM sí avisó con tiempo cuándo se iba a deprecar, a diferencia de AWS, pero en ese caso nunca entendimos qué pasó, porque Cloud Foundry era super económico y funcionaba super bien.
Lo más seguro era eso, como era económico, con ellos no les ha deber salido las proyecciónes de ganancias como esperaban, muchos de estos servicios aún no se saben que tanto rendimiento les darán a las grandes empresas, ya que estos servicios hay que observarlos por años para saber si tendrán frutos o no, me imagino estan empezando a cerrar servicios por que ellos les estan dando numeros rojos
Yo soy usuario de AWS desde hace muchos años y una vez me paso algo similar con quicksight, hicieron un despliegue y quitaron features, cuando le pregunte a soporte me dijeron ah si eso lo quitamos, al final me canse de preguntar donde estaba el changelog, y me toco migrar.
Por eso es que, digan lo que digan, confiar 100% tu infraestructura y servicios empresariales en terceros, siempre es y será un error, en mi opinión.
Google cierra un servicio: 🫵🤣
AWS cierra un servicio: 💀
En mi empresa estan migrando los servicios a Azure Functions y yo no estoy deacuerdo con esta practica, el negocio se vuelve dependiente de la plataforma
Si crees que tu software sobrevivira a Azure y sin ninguna remodelacion de tu trabajo, es que no estas utilizando debidamente la nube.
La contante evolución de la nube hace que se abaraten los costes, pero si sigues con miedo a la nube, aun asi puedes montarte kubernetes en ec2 con aws.
Yo igual hice unas apis rest como servicios para lambdas de aws con proxy inverso, gracias al proxy que agregue a las apis, un día me pidieron pasarlas a azure functions, ya que más arriba decidieron cambiar la arquitectura, y no tuve problema, usando terraform como preparaba el entorno de la lambda, solo hice cambios en ese script y vuala sin problemas para que funcionara en azure, gracias a esas buenas prácticas me ahorre trabajo, obviamente las bds estaban en servidor privado, pero las apis en la nube junto las interfaces (front-end), la verdad para usar la nube si se necesitan ciertos conocimientos para que te funcione, y si diria que hay que tomarnos la nube con pincitas, por estas cuestiones y otras...
Y normalmente usan esas functions para lo que no es
Yo soy un humilde Instructor de soporte tecnico de Nivel Tecnico ,pero con no han pensando montar servidores base de datos,aplicaciones,correo en hardware propio en sistemas operativos como FreeBSD ,NetBSD o el sistema operativo Seguro llamado Open BSD o quizas en derivado open Source de Solaris Unix llamado Open Indiana que son open source y se llevan bien con el codigo cerrado por su licencia liberal pragmatica ,no soy un experto pero no es factible tener un servidor propio alterno por si acaso con BSD o un OpenIndiana
ahora se ríen los que si hicieron el patrón repositorio, "que tan seguido cambias una base de datos"
Pero quien coño va a usar Cloud Commit cuando existe Github o Gitlab, es un titular muy exagerado, me asuste pense algo peor😅
Yo pense lo mismo xd el problema es que si, ahora es con Code Commit que es una mierda y seguro no era de los servicios mas usados, pero que pasa cuando le toque a un servicio que si es mas popular? La cuestión es que no hay garantias, en cualquier momento por decisiones del proveedor te pueden dar de baja los servicios donde montaste toda tu infra y si no estas preparado te vas a quedar en la mierda
Yo conozco empresa que usan code commit, y otros servicios de devops de aws, además, si ves el video no es lo único deprecado.
Que no lo uses , no significa que nadie lo usa.
Mano en la empresa de mi primer trabajo usaban mucho simpleDb y S3 select. No quiero imaginar la que se debe estar armando
Más empresas de las que imaginas.
Por eso realizo Backup a otros proveedores externos Digital Ocean) y uno local. Siempre que activo servicios en proveedores externos, pienso lo malo: y si un dia cierran o eliminan mi cuenta..... Por cosas como esa, acciones para prevenir por si llegan a ocurrir.
Lo bueno de depender de sistemas externos es que te aligeran la implementación, lo MALO es que esta a MERCED de estas empresas sumado a que estos SE CAIGAN y te carguen la el día...
Yo, apunto de hacer mi Certificación Cloud Practitioner
Midu:
Es curioso, creo que ne ha tocado que me manden notificaciones empresas con las que tengo servicios. Algunos si son medio ambiguos con las decisiones que fueron tomadas para ello. Otros si te avisan, con algo de tiempo de anticipación, estos cambios. Bastante triste en este caso que no se les avisó como es deseado a las personas que tenían este tipo de servicios.
solo mirar tu codigo de hace años da miedo imaginar un proyecto entero para migrarlo
solo indicar que solo cuentas nuevas de AWS no podrán tener acceso al servicio. Cuentas existentes con el servicio activo/en uso, podrán añadir repos, usuarios, politicas, etc relacionado a codecommit.
Lo anterior lo comento ya que en el video se hace alusión de que "ningun usuario nuevo..." pero en realidad es a nivel de cuentas nuevas. Solo eso gran Midu!
Con estas cosas te muestran la profesionalidad y poco respeto que tienen a sus clientes, yo si usara aws desde ya buscaria alternativas, no me podria quedar tranquilo de que mañana me cierren mas servicios y encima me tenga que enterar por twitter
Por eso el principio SOLID y la inyección de dependencias!! xD
SIEMPRE hay que desarrollar portable! Agnóstico de cloud, os, db (en lo posible).
Enterarse de algo así por twitter es como enterarse por la TV de que se te quema la casa
el peligro de fondo es que los progrmadores no saben nada de programacion
Con la mayoría salido de bootcamps sin educación formal pues...
Yo, programo para Big data, y aprendi solo y programo muy básico :(
El problema del panadero es que no sabe hacer pan :(
x2 y eso que trabajé en el desarrollo de automatizaciones
Lo bueno es que todos podemos aprender algo y nadie nació sabiendo nada en la vida.😊
Trabajo para una partner premmiun de aws. Lo que sucede es que los servicios suelen deprecar servicios. Anteriormente se ha hecho pero con algunos componentes o versiones. Pero sucede cuando son servicios que no suelen usarse mucho y no dan rentabilidad. Otra cosa que dices que te obliga a usar los servicio es mentira. Vos si hacias algun pipeline no necesariamente debes usar codecommit podrias usar lo que quisieras podias irte a usar github y github. Los architect de aws te va a recomendar pero la compañia es la que decia. Tambien si vos migras a aws como compañía aws aplica funding para ayudarlos a migrar ahi es donde es importante usar los servicios de aws. A nosotras tambien nos dio un poco de sorpresa mas que anda la ida de codecommit. De cloud9 no porque habia poco uso. Pero siempre aws te notifica a tu cuenta main dueña de toda la organización deben siempre estar atento a las notificaciónes
Al final vamos a terminar donde empezamos cada quien con su propio vps creando su propia tecnologia
Que cerraran cloudcommit es lo de menos, imaginen que tenian pegado aese servicio todo el pipeline de cd/ci, tremendo trabajo de migración
Siempre he tenido conflicto con los colegas que apuestan al server less y cloud coputing directo, siempre se debe de programar de forma de que se puedan montar servicios locales y wrapper de servicios y no directo al servicio, el problema se pone peor cuando tu código depende de la infra por que si se da un caso así, por un lado tiran tu infra y tu código ya no sirve para nada.
Uno haciendo el curso AWS de midu y pasan esas cosas😢
tiene su. curso?
Amazon no es nada serio, yo me di cuenta por algo bastante tonto, había una skill de Alexa que se integraba con la API de listas, llamada AnyList, que era buenisima, y un día decidieron deprecarlo. Así por qué si. Desde entonces ya no me da confianza, toman decisiones con mucha irresponsabilidad.
Entonces para DevOps si estoy empezando desde cero me conviene mas certificarme en Azure? xd
Los clientes que ya están utilizando algunos de los servicios que fueron discontinuados no se les quitara acceso ni soporte. Solo a usuarios nuevos.
El problema es cuando diseñas tu software muy acoplado para alguna infraestructura particular, tu software debe ser agnóstico a esto y tolerante a cambios, para que no sea tan traumático migrar a otro tipo de servicio.
acabamos de hacer un analisis respecto a donde centralizar los repositorios de una empresa donde había legacy de la empresa, desarrollo interno y desarrollo externo. CodeCommit nos resultaba la mejor opción para el proyecto, tanto por costos y por experiencia de las partes involucradas con la herramienta. Imagina que ahora tengo que explicarle al cliente que no vamos a poder crear esto, yo en su lugar desconfiaría de mi proceso, de la manera de proceder de AWS. Saludos Midu, amo AWS pero lo que no está bien, no está bien.
Esto es una locura, ¿cómo pueden cerrar servicios tan importantes sin previo aviso? ¡Necesitamos más transparencia, AWS! 😠
Por eso viene genial saber Terraform, así luego no es tanto trabajo cambiar de infraestructura
El código de Terraform es diferente ya sea para Azure, AWS, o GCP, así que si son muchos los recursos a migrar es trabajo...
@@ricardoalias Hombre pero tienes una imagen de todo clara.. es sencillo de migrar, cuestion de dias
Hey terraform salvó mis apis en lambdas de aws, cuando me pidieron que las mirara a azure functions, solo cambie un poco el script de terraform y con eso me ahorre días de trabajo, solo fueron unas hrs
@@ricardoaliasno al 100, es muy similar, solo cambias valores y algunos parámetros, al menos a mí no me tocó cambiar tantas cosas, solo roles, promovedor, entre otras cosas banales, y de ahí no tuve que tocar codigo en mis apis, la verdad saber usar terraform si te salva de mucho cuando trabajas en la nube
Me lo esperaba de Google con la fama que tiene de matar proyectos/servicios
"Este es uno de los grandes peligros que tenemos con la nube".
Richard Stallman: se los dije…
Yo acá lo único que veo son oportunidades de negocio 😊. Saludos!
hahaha
Pero que esto no es una lección de que como empresa no puedes confiar en código(como Jquery en su momento), funcionalidad, soporte, bases de datos de terceros?, a menos que sea por contrato no puedes confiar a menos si es gratis.
me esta gustando este canal👍
La nube no es infinita, creo que puede ser una crisis de espacio, esto va a ser grandes movimientos de datos a otras nubes, al parecer la nube, va a tener que ser una sesión a un almacenamiento, en casa, y permisos de acceso solo con una sesión online, que permita el acceso desde cualquier parte de internet, un celular antiguo, o un raspberry con un ssd, y una especie de sistema operativo de servidor de aws code commit para raspberry pi(bajo consumo).
Lo malo de darle tanto poder a esas empresas, por desgracia somos esclavos de "nuestras decisiones", porque tal cual lo muestras, toman decisiones sin pensarlo o sin importar qué puede pasar, y la solución no está en tener los mismos servicios en otras empresas (Azure, GCP, Heroku, etc.), porque el coste sube dependiendo de tu "redundancia". Como bien dicen allí en X (antes Twitter), el problema es la falta de comunicación, y como bien dices, ¿Por qué no avisar con tiempo? Mal, mal, mal...
Pareciera que AWS quiere cavar su propia tumba.
Me pregunto si el cierre es porque no genera consumo de red
Yo como devops en una teleoperadora española durante 6 años migre entre 4 soluciones git más de 600 repos solo por falta de presupuesto y tacañería de jefazos, lleva meses algo asi
Esto afecta mas que todo la credibilidad de la empresa. Lo mismo que con UNITY.
Por este tipo de cosas es que hay que tratar de ser agnósticos con los servicios Cloud
Lo mismo vi en GCP con el servicio propietario de repositorios de codigo llamado Google cloud repositories... coincidencia, casualidad 🤔
te hace todo más fácil, pero. a costa de tu billetera
Pregunta desde la ignorancia, para que usan la cloud en web?
Yo esto lo se desde el principio, por eso a pesar de que me interese mucho la tecnologia cloud, tampoco hay que dejarle todo a ella
Siento qué incógnito también caerá porque esta cómo abandonado
Cognito, no incógnito XD
No lo hará, mejorará la documentación, pero veo muy poco probable que cambie ya que amplify o la validacion de las APIS siempre pasa a traves de OAuth ante cognito user pools
Por último que te brindan alguna herramienta para poder migrar a servicios sustitutos
Verás las risas el día que un proveedor de cloud, de los muchos que salieron como setas en los últimos años, cierre por completo y deje tirados a sus usuarios.
Por que usas deprecado y no obsoleto o discontinuado?
Por qué son similares pero tiene sus diferencias, deprecado por qué aún se usa pero se está recomendando migrar, descontinuado es que ya no se dará soporte, ni parches, bla bla, aquí no es descontinuado por que aws apenas está avisando y por lo tanto aún hay soporte para los usuarios existentes, pero obviamente pasara a descontinuado en un futuro cercano, obsoleto es que de plano ya existen mejores alternativas y se usan mas que el que esta obsoleto (este ya no se usa, ya es un porcentaje mínimo quien lo usa)
chale, no me hagas esto MIDU, es muy temprano para enterarme de que tengo que migrar mas 400 repos con su cicd :c
menos mal decidí Azure a pesar de la moda xD
Entonces ya no vale la pena estudiar AWS ?
sin dudas el servicio más NEFASTO que aws ha decidido sacar es, fue y será CODE COMMIT, no se pueden cerrar prs, no se pueden agregar reviews a las prs, no se puede poner protección de branch, y no sigo porque me hace acordar lo mal que la pasé trabajando con esa tecnología. ¿Porqué elegimos code commit? Porque al ser la empresa partner de aws nos exigian utilizar cierta cantidad de servicios en los proyectos de nuestros clientes (a cambio de beneficios obvio). Me pone muy contento que lo manden con odin.
Todo lo de CI/CD de amazon la verdad es que no se compara con otros servicios
todo un exito AWS por quitarme el gestor documental workdocs... en plena migración de la ISO27001:2013 a 2022
Casi nadie usaba esos productos y las empresas que pagan soporte seguro les ayudan a migrarse
Alguien sabe si cerraron el servicio de la voz con inteligencia artificial?
Lo malo para uno como estudiante o trabajador es tener que capacitarse a fondo en el nuevo servicio.
Y aparte capacitarse sin saber cuanto tiempo durara vigente dicho servicio. Quizá lo mejor sea no especializarse demasiado
Bajada de ingresos para Amazon? Recortan servicios que parecen buenos
bueno, esto paso con google y los servicios orientados a mqtt e iot, amazon aun lo tiene, pero si google lo saco que le queda al resto?
Si llegan a dejar de dar soporte a S3 se acaban la mitad de las empresas del mundo
En todos los cloud providers discontinúan distintos servicios, es normal, parte del ciclo de vida tecnológico. Pasa en on-premises, y en todos lados. La única solución es migrar y ya.
0:47 creo que esa persona nunca ha tenido ese problema
Ni tampoco una pareja
yo he pensado en estudiar cloud y pensaba empezar con AWS, aun valdra la pena? que piensan de las alternativas como Azure o GCloud?
Por lo que tengo entendido, con que estudies uno, no es complicado agarrarle el truco a los demas, si quieres por demanda laboral, los mas populares son aws, azure y gcp, en ese orden
Cloud9 justo en la infancia.
Claro, yo creo que Cloud Commit no lo usa ni Dios, ni los de AWS jaja. Por cierto, van a cerrar AWS QLDB, una base de datos inmutable tipo blockchain, aunque en este caso, me mandaron varios correos anunciando el fin del soporte para Julio de 2025 y una posible alternativa, migrar a Aurora PostgreSQL.
Por qué hay un 9 en el título?
@@MissiFull cloud9 es un producto de aws
Como para fiarte de estos servicios...
CodeCommit era muy malo, asi que me parece bien que le den de baja. Solo que algunos servicios de aws te obligaban a usarlo porque disque tenia mejor integracion.
Por eso utilizo Azure
busquemosle el lado positivo, mas trabajo para programadores...
El problema de AWS es que no piensa en la experiencia de usuario!
Tu plataforma deberia ser cloud agnostic y si las cosas que tienes en la nube son muy importantes tu DRP tiene que soportar migraciones y estas se tienen que testear con frequencia. Al menos eso opino yo :)
Que es el AWS ?
Bueno eso pasa cuando usas las herramientas de otros, no importa si es nube o tierra o subsuelo.
Uy MIdu como es eso de: si ya lo tienes dentro😮😅
Me dio por realizar un scrip, no lo he testeado, pero lo voy a pasar por si alguien quiere hacer su aporte, ¿cómo podría pasarlo Midu o gente? Gracias!
NO me chin… ni aunque sea bait… *procede a tratar de certificarse en GCP y migrar todo lo que se tiene en la chamba…*
A mí esta arbitrariedad y esta manera de hacer me recuerda a Google con Flutter.
Van a dar de baja codecommit, incluso creo ya no está disponible para nuevas cuentas.
Hace unos meses nos pasamos a bitbucket, igual git commit no era el mejor🤣
En Azure pasa cada rato este mes muere cloudapp
Demasiados servicios, el que mucho abarca poco aprieta.
En la empresa donde trabajo usan cloud9