- Una cuenta que comparte las cosas extrañas que experimenta a diario en Microsoft Azure. Ya superó los 400 días
- Día 403: Recientemente hubo un #Microsoft Cloud for Sustainability Technical Summit. Pero en realidad se sintió más como un summit de #Copilot con un ligero enfoque en sostenibilidad. (Esta captura de pantalla fue tomada solo de las primeras tres sesiones)
- Día 402: La nueva función de #AI de Azure CLI ha estado funcionando de maravilla hasta ahora (captura de pantalla del error)
- Día 401: Imagen de error de enlace. Es solo uno de los innumerables casos de enlaces en la documentación de #Azure que llevan a una sección que ni siquiera existe
...
1 comentarios
Opiniones de Hacker News
Hace tiempo, cuando trabajaba en Mojang, tras la adquisición por parte de Microsoft intentamos migrar de AWS a Azure.
En la superficie tenía sentido: mientras que el costo de AWS era de seis cifras en dólares al mes, Azure lo podíamos usar gratis.
Pero, después de más o menos un año y de incontables horas invertidas por nuestro equipo y por los expertos en soluciones que nos asignó la organización de Azure, todos coincidimos en que debíamos seguir pagando ese costo de seis cifras a uno de los grandes competidores de Microsoft.
Desde entonces dejé de ver a Azure como un proveedor de nube viable para uso real, y aunque quizá algún día tenga que reevaluarlo, tal vez no sería la primera vez que me equivoque.
En general estaba bien, pero los problemas empezaron cuando comenzamos a usar CosmosDB, que en ese entonces se llamaba DocumentDB.
El DocumentDB inicial era realmente pésimo; era muy difícil predecir el costo, cada fin de semana llegaban facturas absurdas, y el SDK de .NET que ofrecían estaba lleno de bugs y era horrible.
Lo peor era que la interfaz web parecía estar vinculada directamente a una instancia específica de CosmosDB.
Si asignabas pocos recursos a la base de datos, se volvía lenta, y también se retrasaba la propia interfaz web que tenías que usar para aumentar esos recursos.
Así que hubo situaciones en las que tuvimos que apagar toda la aplicación para poder subir los recursos de Cosmos, y Microsoft se sentía completamente amateur.
Entiendo que Cosmos ahora ha mejorado mucho, pero esa experiencia dejó un sabor demasiado amargo.
Si me dieran algún tipo de créditos gratis, podría volver a probar Azure, pero hoy no lo recomendaría bajo ninguna circunstancia.
Poder operar el servicio de correo electrónico más grande del mundo sobre el stack de Windows habría sido una garantía enorme, pero les tomó años lograrlo.
https://www.zdnet.com/article/ms-moving-hotmail-to-win2000-s...
https://jimbojones.livejournal.com/23143.html
Supongo que tal vez era alguna función propia de AWS, como su forma de manejar serverless, que no se podía trasladar directamente a Azure, pero siempre me interesa aprender por qué una migración de X a Y fracasó.
Seguramente también ayudó que, mientras tanto, las tecnologías del lado de juegos se volvieran más completas.
Edición: AWS -> Azure :)
Como AWS estaba adelantado en general, en ese momento había una brecha tecnológica, y parece que después esa brecha se cerró.
Está bien, Microsoft le cambiará el nombre la próxima semana y reemplazará por completo la UI de administración y la API.
Ahora se llamará Dynamics CoPilot OneAI 365 for Business OneCloud.
live.com, otrasoutlook.com, y otrassharepoint.com,msbinbows.comy cosas por el estilo.Pero la documentación y todas las demás referencias seguirán conservando el nombre anterior.
En mi experiencia, he visto organizaciones que usan desde racks de servidores on-premises hasta Linode, AWS y Azure, y las quejas sobre infraestructura en la nube eran proporcionales al uso de servicios administrados.
Los equipos que dependían principalmente de máquinas virtuales y, como mucho, de una base de datos relacional administrada casi no se quejaban.
Hay que mantener algunos scripts adicionales, sí, pero es una molestia menor comparada con pelearse con los problemas y comportamientos extraños de los servicios administrados.
Obviamente, una máquina virtual común es más fácil de mantener que un servicio administrado, y por eso le pagas mucho más al proveedor de nube por un servicio administrado, para no tener que hacerlo tú mismo.
Entonces, ¿la idea es que ese esfuerzo es básicamente inútil?
Para muchas empresas, la razón principal para migrar a la nube son los servicios administrados, así que no diría que esta afirmación no sea polémica en absoluto.
Un cliente necesitaba un túnel IPsec hacia la VPC donde estaban los servidores de producción, y como no queríamos mantener esa configuración nosotros mismos por un solo cliente, revisamos los servicios de AWS y había una solución administrada de IPsec.
Pero el cliente avisó que el túnel se había caído, y la solución fue que el cliente tenía que reiniciarlo de su lado para restablecer la conexión.
Podías activar el logging en S3 para ver por qué, pero según la explicación de AWS, todo debería estar normal.
Incluso usando solo EC2 pasan cosas raras.
Recientemente, una instancia EC2 dejó de responder y el Auto Scaling Group no la reemplazó; cualquier operación que intentábamos daba un error de que la instancia no estaba en ejecución, pero su estado figuraba como en ejecución.
Por suerte mi jefe está de acuerdo, pero no tiene autoridad total.
Por el vendor lock-in y la compatibilidad de API que casi coincide con el open source, pero no del todo, me preocupa más a medida que más equipos lo adoptan.
Dicen “¡pero es más fácil!”, y habrá que ver.
Antes de más o menos 2014, AWS reducía periódicamente los precios de sus servicios principales y trasladaba la caída de los costos tecnológicos.
A Azure no le gustó eso, así que empezó a igualar los precios de AWS y replicaba de inmediato los mismos descuentos en los mismos servicios.
Eso es una forma de precios predatorios, porque busca eliminar el incentivo a bajar precios al impedir que un competidor gane cuota de mercado aunque reduzca sus precios.
Quería que Azure me gustara de verdad porque se integra bien con las herramientas, pero seguía topándome con limitaciones de disponibilidad de máquinas virtuales y rarezas de UX
En AWS nunca me pasó no poder conseguir una máquina ni dudar de si lo que hice se había aplicado realmente
También consideré varias veces el FaaS de Azure, pero ahora estoy firmemente del lado de “no lo uses y sal corriendo”
La experiencia alrededor de Azure Functions es tan extraña que no hay forma de sentirse cómodo, y acceder a los logs u otros artefactos binarios también es increíblemente doloroso
Es tan fácil ejecutar una build autocontenida de .NET en una máquina virtual Windows/Linux vacía que no hay motivo para meterse con toda esta complejidad adicional
También hay comportamientos que rompen la automatización, como que SQL Server envíe un callback diciendo que ya está en ejecución cuando en realidad faltan otros 20 minutos para que esté listo
Estoy medio convencido de que
terraform time_sleepse creó específicamente para evitar problemas de AzureEs el mismo servicio que terminas usando cuando una app de funciones necesita ir más allá de funciones simples y requiere tiempos de ejecución más largos o no tener latencia de cold start
App Services toma tiempo para acostumbrarse, pero es un contenedor Win Server/IIS bloqueado con FTPS integrado, endpoint de verificación de estado para autocuración, despliegues apuntando a un almacenamiento, opciones de autoescalado y SLA de 99.95%
Hace unos años no era gran cosa en rendimiento, pero los SKU Premium de 2 o más vCPU con CPUs modernas no me dieron problemas
Es más caro que una máquina virtual, pero lidiar con la seguridad y las actualizaciones de una VM de servidor web es muchísimo trabajo
Adquirimos una empresa que estaba hosteada en Azure
Usaban Postgres hosteado y servicios .NET sobre Windows, y la infraestructura era pequeña, de unos 200 a 300 cores y 1 TB de memoria
Cada pocos días Microsoft bajaba instancias al azar por mantenimiento y cortaba la red por más de 10 minutos
El Postgres hosteado tenía un rendimiento trágico, así que lo migramos; un especialista basado en India nos indicó usar otro tipo de volumen, y después de reiniciar la instancia la base de datos no levantó por latencia de I/O
Ese especialista dijo que estaba ocupado y evitó reuniones durante 3 días seguidos, y el RCA fue un documento a medias, probablemente escrito por un LLM, diciendo que no era culpa de ellos, aunque las gráficas contaban otra historia
Lo único en lo que le gana a GCP y AWS es que el dashboard carga rápido
Eso sí, si ejecutas en paralelo 2 operaciones de red similares, fallan o tardan 10 veces más que ejecutándolas en secuencia, lo cual da tristeza
Huyan, no lo usen
De todos los proveedores PaaS, Azure tiene las peores abstracciones y servicios
Da tristeza que en general todos acepten consumir estos servicios raros y que eso cree puestos para arquitectos y especialistas cloud
Como tienen que mantener relevantes a los partners, alimentan malos diseños y acoplamientos flojos
En realidad, eso también resume lo que pienso de toda la TI empresarial
En una empresa pequeña de unos 30 desarrolladores heredamos un desastre en Azure; luego creamos en las herramientas de desarrollo abstracciones más cercanas a los estándares de la industria para los servicios que necesitábamos, y unos años después nos mudamos a Hetzner
Los desarrolladores aquí prácticamente no notan la diferencia
Nuestras herramientas se encargan del workflow y las abstracciones de servicios, y esas cosas no deberían cambiar porque cambie el proveedor
La factura mensual quedó en una décima parte, y usamos parte de ese dinero para construir la mejor experiencia de desarrollo imaginable
Me parece que fue un intercambio excelente
Solo hay dos casos en los que vale la pena usar una gran nube
Cuando estás en una escala realmente pequeña de MVP, o cuando tienes un entorno global enorme y distribuido que necesita elasticidad
Para la mayoría de las empresas, ambos son más bien excepciones
Creo que cualquier usuario de Azure podría armar 100 razones para no usar Azure, y con la mayoría del software grande pasaría lo mismo
Incluso como alguien con poca exposición a otras nubes, era fácil ver que la experiencia de usuario de Azure no está bien gestionada y se queda atrás
La cantidad de páginas en las que hay que presionar “ver más” para que la barra de filtros funcione correctamente ya debería ser claramente 0
Es un patrón objetivamente malo, existe desde hace años y “debería” ser fácil de arreglar, pero probablemente nunca será prioridad
Al final, problemas así no se corrigen a menos que resolverlos sea un valor central de la organización o afecte claramente los ingresos
Para la comunidad de usuarios, la apertura y visibilidad de estos problemas siempre son importantes
Uso tanto AWS como Azure, y una cosa que realmente me gusta de Azure es el portal
Como AWS 2.0: se abstrae el desorden cloud y solo quedan las configuraciones que realmente necesitas tocar y sus relaciones entre sí
También me gusta AWS, pero cada vez que entro a un entorno desconocido y tengo que hacer ingeniería inversa de todas las conexiones, al terminar necesito un trago
Cuando probé Azure durante unos días, el portal fue realmente doloroso
Cada clic tardaba entre 5 y 10 segundos en responder, y a veces cambiar una configuración básica implicaba mirar un spinner de Ajax durante más de 2 minutos
¿Cómo se puede disfrutar trabajar así?
Parece que alguien las estuviera haciendo deliberadamente lo más confusas posible, pero no alcanzo a imaginar con qué propósito
No digo que tu opinión sea inválida ni que estés mintiendo, pero nunca he visto a alguien a quien le guste el portal de Azure, ni siquiera entre quienes viven cada hora dentro del ecosistema de Azure
Si no lo es, me da risa
Yo estoy en el extremo totalmente opuesto, así que supongo que será cuestión de gustos
He usado bastante ambos, y aunque el dashboard de Azure sigue siendo irritante, en términos de usabilidad es mucho mejor que AWS
Además, Microsoft claramente dedica tiempo y dinero a la documentación, mientras que la documentación de AWS siempre me pareció floja
Si eres una empresa chica y no operas contenedores, Cloudflare es una nube muy subestimada
Sé que la critican por otros motivos, pero si ya te cansaste de los 3 o 4 grandes, la experiencia para desarrolladores es realmente excelente
[1]: https://blog.cloudflare.com/container-platform-preview/
Me gusta para sitios en Svelte, pero estar atado a un lenguaje y a restricciones basadas en request-response es una limitación enorme
Como mínimo necesitaría contenedores y volúmenes persistentes para que me interese
De verdad odio Azure con pasión
Estoy en un equipo que crea herramientas para automatizar la creación de proyectos/cuentas/suscripciones por proveedor de nube
Nuestro proveedor principal es GCP, y la implementación fue bastante fácil
Hubo algunas trampas, pero se pudieron sortear sin problema
Ahora tenemos que dar soporte a Azure para multicloud
Antes estábamos en AWS, pero salimos en un 95%; aunque todavía quedan algunos equipos, casi no creamos herramientas más allá de módulos de Terraform
Pero la Azure API, la MS Graph API y los SDK de Go de ambas son el mayor montón de basura con el que me ha tocado trabajar
Todo es un puntero, e incluso los literales de string hay que convertirlos en punteros, aunque a veces no
La documentación es inexacta: algunas API aceptan solo el ID, pero otras aceptan la ruta completa
Algunas cosas están documentadas, pero muchas API indican formatos incorrectos
Ninguna API devuelve los ID de recursos relacionados, así que hay que buscarlos todos, y hay demasiadas búsquedas basadas en nombres
Incluso tuvimos que agregar una capa de caché de ID para no consultar repetidamente los mismos recursos durante la creación
Usamos una máquina de estados para la creación y podemos reanudar desde la mitad, así que necesitamos mucho código basado en verificación y reanudación
En general, es el proveedor de nube con el peor diseño e implementación; si tuviera opción, jamás lo recomendaría ni lo elegiría
Las cosas escritas internamente en Go suelen ser excelentes
Nosotros creamos una internamente, pero también nos interesan opciones de terceros
Aunque por nuestras reglas internas de negocio, quizá tenga más sentido hacerla nosotros que comprarla