- Uma conta que compartilha as coisas estranhas vividas diariamente no Microsoft Azure. Já passou de 400 dias
- Dia 403: Houve recentemente o #Microsoft Cloud for Sustainability Technical Summit. Mas, na prática, pareceu mais um summit de #Copilot com um leve foco em sustentabilidade. (Esta captura de tela foi tirada apenas das três primeiras sessões)
- Dia 402: O novo recurso de #AI do Azure CLI tem funcionado muito bem até agora (captura de tela de erro)
- Dia 401: Imagem de erro de link. Este é apenas um dos inúmeros casos de links na documentação do #Azure que levam a seções que nem existem
...
1 comentários
Opiniões no Hacker News
Antigamente, quando eu trabalhava na Mojang, fomos adquiridos pela Microsoft e tentamos migrar da AWS para o Azure
Na superfície, fazia sentido: nossos custos na AWS eram de seis dígitos em dólares por mês, enquanto poderíamos usar o Azure de graça
Mas, depois de cerca de um ano e de incontáveis horas gastas pela nossa equipe e pelos especialistas em soluções que a organização do Azure nos designou, todos concordamos que teríamos de continuar mantendo aquele custo de seis dígitos pago a um dos grandes concorrentes da Microsoft
Desde então, deixei de ver o Azure como um provedor de nuvem viável para uso real; talvez um dia eu precise reavaliar, mas pode ser que essa não seja a primeira vez que eu esteja errado
No geral foi ok, mas os problemas começaram quando passamos a usar o CosmosDB, que na época se chamava DocumentDB
O DocumentDB inicial era realmente péssimo, o preço era muito difícil de prever e todo fim de semana chegavam faturas absurdas; o SDK .NET fornecido também era cheio de bugs e horrível
O pior era que a UI web parecia estar diretamente acoplada a uma instância específica do CosmosDB
Se você dimensionasse poucos recursos para o banco de dados, ele ficava lento, e a própria interface web que você precisava usar para aumentar os recursos também ficava lenta junto
Então houve situações em que precisávamos desligar a aplicação inteira para aumentar os recursos do Cosmos, e a Microsoft pareceu completamente amadora
Entendo que hoje o Cosmos melhorou muito, mas o gosto que ficou daquela época foi péssimo
Se eu ganhasse alguns créditos gratuitos, até poderia tentar o Azure de novo, mas hoje eu jamais recomendaria
Rodar o maior serviço de e-mail do mundo na stack Windows teria sido uma validação enorme, mas levou anos até dar certo
https://www.zdnet.com/article/ms-moving-hotmail-to-win2000-s...
https://jimbojones.livejournal.com/23143.html
Imagino que talvez fossem recursos específicos da AWS, como a forma da AWS lidar com serverless, que não podiam ser levados diretamente para o Azure; mas sempre quero aprender por que uma migração de X para Y fracassou
O fato de as tecnologias voltadas a jogos terem amadurecido nesse meio-tempo provavelmente também ajudou
Correção: AWS -> Azure :)
Como a AWS estava à frente de modo geral, havia uma lacuna tecnológica na época, e parece que essa lacuna foi fechada mais tarde
Tudo bem, a Microsoft vai mudar o nome na semana que vem e refazer completamente a UI de administração e a API
Agora o nome será Dynamics CoPilot OneAI 365 for Business OneCloud
live.com, outrasoutlook.com, e outras coisas comosharepoint.com,msbinbows.comMas a documentação e todas as outras referências continuarão mantendo o nome antigo
Pela minha experiência, vi organizações usando desde racks de servidores on-premises até Linode, AWS e Azure, e as reclamações sobre infraestrutura de nuvem eram proporcionais ao uso de serviços gerenciados
Equipes que dependiam principalmente de máquinas virtuais e, no máximo, de bancos de dados relacionais gerenciados, quase não reclamavam
É preciso manter alguns scripts a mais, mas isso é um incômodo pequeno comparado a brigar com os problemas e comportamentos peculiares dos serviços gerenciados
Claro que uma máquina virtual comum é mais fácil de manter do que um serviço gerenciado, e é por isso que você paga muito mais ao provedor de nuvem por serviços gerenciados, para não ter de fazer isso diretamente
Então isso quer dizer que esse esforço é essencialmente inútil?
Como o principal motivo para muitas empresas migrarem para a nuvem são os serviços gerenciados, não dá para dizer que essa afirmação seja nada controversa
Um cliente precisava de um túnel IPsec para a VPC onde ficam os servidores de produção e, como não queríamos manter essa configuração por conta própria só por causa de um cliente, verificamos o serviço da AWS e havia uma solução IPsec gerenciada
Então o cliente entrou em contato dizendo que o túnel tinha caído, e a solução era que o cliente precisava reiniciar do lado dele para restabelecer a conexão
Você até pode ativar logs no S3 para tentar entender o motivo, mas, segundo a explicação da AWS, tudo deveria estar normal
Mesmo usando só EC2, acontecem coisas estranhas
Recentemente, uma instância EC2 parou de responder e o Auto Scaling Group não a substituiu; qualquer ação dava erro dizendo que a instância não estava em execução, mas o estado mostrava que estava em execução
Felizmente meu chefe concorda, mas ele não tem autoridade total
Por causa do lock-in de fornecedor e da compatibilidade de APIs que é quase, mas não totalmente, compatível com open source, fico mais preocupado quanto mais equipes adotam
Dizem “mas é mais fácil!”, então vamos ver
Antes de por volta de 2014, a AWS reduzia periodicamente os preços dos principais serviços, repassando a queda nos custos de tecnologia
O Azure não gostou disso e começou a igualar os preços da AWS, acompanhando imediatamente os mesmos descontos nos mesmos serviços
Isso é uma forma de precificação predatória, porque o objetivo é eliminar o incentivo para reduzir preços ao impedir que o concorrente ganhe participação de mercado mesmo quando baixa os preços
Eu queria muito gostar do Azure, porque ele se integra bem às ferramentas, mas continuava esbarrando em limitações de disponibilidade de máquinas virtuais e em estranhezas de UX
Na AWS, nunca passei por não conseguir uma máquina nem por duvidar se uma ação minha tinha sido realmente aplicada
Também considerei o FaaS do Azure algumas vezes, mas hoje estou firmemente no campo do “não use, fuja rápido”
A experiência em torno do Azure Functions é tão estranha que não dá para se sentir confortável, e acessar logs ou outros artefatos binários também é absurdamente doloroso
É tão fácil rodar um build .NET autocontido em uma máquina virtual Windows/Linux vazia que não há motivo para se envolver com toda essa complexidade adicional
Também há comportamentos que quebram automação, como o SQL Server enviar callback dizendo que está em execução quando, na verdade, só ficará pronto 20 minutos depois
Estou meio convencido de que
terraform time_sleepfoi criado especificamente para contornar problemas do AzureÉ o mesmo serviço que você acaba usando quando um function app passa a precisar de mais do que funções simples, como tempos de execução mais longos ou ausência de atraso de cold start
O App Services leva um tempo para acostumar, mas é um contêiner Win Server/IIS travado, com FTPS integrado, endpoint de verificação de integridade para autocorreção, deploy com armazenamento especificado, opções de escalonamento automático e SLA de 99,95%
Alguns anos atrás ele não era muito bom em desempenho, mas SKUs Premium com 2 ou mais vCPUs de CPUs modernas não deram problema
É mais caro que máquinas virtuais, mas lidar com segurança e atualizações de VMs de servidor web dá um trabalho enorme
Adquirimos uma empresa que estava hospedada no Azure
Eles usavam Postgres hospedado e serviços .NET sobre Windows, e a infraestrutura era pequena, algo como 200–300 cores e 1 TB de memória
A cada poucos dias, a Microsoft derrubava instâncias aleatórias por manutenção e cortava a rede por mais de 10 minutos
O Postgres hospedado tinha um desempenho trágico, então migramos; um especialista baseado na Índia orientou usar outro tipo de volume e, depois de reiniciar a instância, o banco de dados não subiu por causa de latência de I/O
Esse especialista disse que estava ocupado e evitou reuniões por 3 dias seguidos, e o RCA veio como um documento pela metade, que parecia ter sido escrito por LLM, dizendo que a culpa não era deles, embora os gráficos dissessem outra coisa
A única coisa em que supera GCP e AWS é que o dashboard carrega rápido
Mas é triste que, se você executar 2 operações de rede parecidas em paralelo, elas falhem ou demorem 10 vezes mais do que executá-las em sequência
Fuja, não use
Entre todos os provedores de PaaS, o Azure tem as piores abstrações e serviços
É triste que, em geral, todo mundo aceite consumir esses serviços estranhos, criando empregos para arquitetos de cloud e especialistas
Como precisam manter os parceiros relevantes, acabam alimentando design ruim e acoplamento frouxo
Na verdade, essa também é minha opinião sobre TI corporativa como um todo
Em uma empresa pequena, com cerca de 30 desenvolvedores, herdei uma bagunça no Azure; depois criei nas ferramentas de desenvolvimento abstrações mais próximas do padrão do setor para os serviços necessários e, alguns anos depois, migramos para a Hetzner
Os desenvolvedores daqui praticamente não percebem a diferença
Nossas ferramentas cuidam do workflow e das abstrações de serviço, e essas coisas não deveriam mudar só porque o provedor mudou
A conta mensal caiu para um décimo, e usamos parte desse dinheiro para criar a melhor experiência de desenvolvimento imaginável
Vejo isso como uma troca excelente
Só há dois casos em que faz sentido usar uma grande cloud
Ou você está em um MVP realmente pequeno, ou em um ambiente gigantesco, distribuído globalmente, que precisa de elasticidade
Para a maioria das empresas, ambos são mais exceção do que regra
Acho que qualquer usuário do Azure conseguiria listar 100 motivos para não usar o Azure, e o mesmo valeria para a maior parte dos grandes softwares
Mesmo como alguém com pouca exposição a outras clouds, era fácil perceber que a experiência de usuário do Azure fica para trás por falta de cuidado adequado
Hoje o número de páginas em que é preciso clicar em “ver mais” para a barra de filtros funcionar direito deveria ser obviamente 0
Esse é um padrão objetivamente ruim, existe há anos e “deveria” ser fácil de corrigir, mas provavelmente nunca vai virar prioridade
No fim, a menos que resolver esses problemas seja um valor central da organização ou afete claramente a receita, eles não serão corrigidos
Para a comunidade de usuários, a publicidade e a visibilidade desses problemas sempre são importantes
Uso tanto AWS quanto Azure, e uma coisa de que gosto muito no Azure é o portal
É como a AWS 2.0: a bagunça de cloud fica abstraída, e sobram apenas as configurações que você realmente precisa manipular e as relações entre elas
Também gosto da AWS, mas toda vez que entro em um ambiente desconhecido e preciso fazer engenharia reversa de todas as conexões, termino precisando de uma bebida
Quando usei o Azure por alguns dias, o portal foi realmente doloroso
Cada clique levava 5 a 10 segundos para responder, e às vezes uma mudança básica de configuração exigia olhar para um spinner Ajax por mais de 2 minutos
Como alguém consegue gostar de trabalhar assim?
Parece que alguém está tentando deliberadamente torná-las o mais confusas possível, mas não faço ideia do objetivo
Não estou dizendo que a opinião seja inválida ou que seja mentira, mas nunca vi alguém gostar do portal do Azure, nem mesmo entre pessoas que vivem dentro do ecossistema Azure o tempo todo
Se não for, é engraçado
Eu estou totalmente no lado oposto, então acho que é questão de gosto
Usei bastante os dois, e o dashboard do Azure ainda é irritante, mas, em termos de usabilidade, é muito melhor que o da AWS
Além disso, fica claro que a Microsoft investe tempo e dinheiro em documentação, enquanto a documentação da AWS sempre foi fraca
Se você é uma empresa pequena e não opera contêineres, a Cloudflare é uma nuvem muito subestimada
Sei que ela é criticada por outros motivos, mas, se você está cansado das big 3 ou 4, a experiência para desenvolvedores é realmente ótima
[1]: https://blog.cloudflare.com/container-platform-preview/
Gosto para sites em Svelte, mas ficar preso à linguagem e às limitações baseadas em requisição-resposta é uma restrição enorme
Para eu me interessar, no mínimo precisaria ter contêineres e volumes persistentes
Eu odeio o Azure com muita paixão
Estou em uma equipe que cria uma ferramenta para automatizar a criação de projetos/contas/assinaturas por provedor de nuvem
Nosso provedor principal é o GCP, e a implementação foi bem fácil
Houve algumas armadilhas, mas foram fáceis de contornar
Agora precisamos oferecer suporte ao Azure em um cenário multicloud
Antes estávamos na AWS, mas saímos de 95% dela; ainda há algumas equipes lá, mas quase não criamos ferramentas além de módulos Terraform
Só que a Azure API, a MS Graph API e os SDKs em Go das duas são o maior monte de lixo com que já lidei
Tudo é ponteiro, até literais de string precisam ser transformados em ponteiro, mas às vezes não
A documentação é imprecisa; algumas APIs aceitam só o ID, enquanto outras aceitam o caminho completo
Algumas coisas estão documentadas, mas muitas APIs indicam o formato errado
Nenhuma API retorna IDs dos recursos relacionados, então é preciso buscar tudo, e há buscas demais baseadas em nome
Tivemos até que adicionar uma camada de cache de IDs para não consultar repetidamente os mesmos recursos durante a criação
Usamos uma máquina de estados para a criação e conseguimos retomar do meio, então precisamos de bastante código baseado em verificação e retomada
No geral, é o provedor de nuvem com o pior design e implementação; se eu tivesse escolha, jamais recomendaria ou escolheria
As coisas escritas internamente em Go geralmente são ótimas
Criamos uma internamente, mas também temos interesse em opções de terceiros
Ainda assim, por causa de regras de negócio internas, talvez faça mais sentido criar por conta própria do que comprar