Adeus ao EC2-Classic, foi um ótimo tempo
(allthingsdistributed.com)- A AWS encerrou a última instância do EC2-Classic em 15 de agosto de 2023, concluindo a operação do modelo inicial de computação em nuvem que começou com o lançamento do EC2 em 2006
- O núcleo do Classic era uma rede plana única 10.0.0.0/8, e a inovação da época foi simplificar a obtenção de capacidade computacional ao ocultar uma implementação interna complexa
- Em 2006, o m1.small oferecia, por $0.10 por hora, vCPU equivalente a um Xeon de 1.7GHz, 1.75GB de RAM, disco local de 160GB e rede de 250Mb/s; depois disso, o EC2 evoluiu para instâncias de grande porte como a P3dn.24xlarge
- Foram adicionados Elastic IP, Auto Scaling, Load Balancing, CloudWatch e novos tipos de instância, e em 2013 a VPC se tornou o novo padrão de área de nuvem isolada e definível por cliente
- O Classic continuou por mais 10 anos mesmo após novas plataformas de virtualização como o Nitro, por causa do uso dos clientes, e documentação, ferramentas e suporte continuaram até que todas as instâncias fossem encerradas ou migradas
Encerramento do EC2-Classic e estrutura inicial
- A AWS sempre adotou uma abordagem cuidadosa ao encerrar serviços dos quais os negócios dos clientes dependem
- O SimpleDB continua sendo oferecido mesmo depois que o DynamoDB se consolidou como opção de banco de dados “NoSQL” para os clientes
- Dois anos após o anúncio de Jeff Barr sobre a aposentadoria do EC2-Classic, em 15 de agosto de 2023 a última instância do Classic foi encerrada
- O EC2 operou por quase 17 anos, e entre os serviços da AWS apenas o SQS e o S3 são mais antigos que o EC2
- O maior fator que diferenciava o “Classic” era a arquitetura de rede
- Em 2006, o EC2 começou como uma única rede gigantesca 10.0.0.0/8
- Todas as instâncias eram executadas em uma rede plana única compartilhada com outros clientes
- Ele oferecia recursos como security groups e Public IP atribuído no momento do início da instância
- Embora a pilha interna fosse extremamente complexa, os usuários conseguiam obter a capacidade computacional de que precisavam de forma simples
Mudanças no desempenho das instâncias
- Em 2006, ao executar uma instância m1.small, era possível usar a seguinte configuração
- CPU virtual equivalente a um processador Xeon de 1.7GHz
- 1.75GB de RAM
- 160GB de disco local
- Largura de banda de rede de 250Mb/s
- $0.10 por hora
- Depois disso, o EC2 evoluiu para instâncias como a P3dn.24xlarge
- Vazão de rede de 100Gbps
- 96 vCPU
- 8 GPUs NVIDIA v100 Tensor Core com 32GiB de memória
- 768GiB de memória do sistema
- 1.8TB de armazenamento SSD local
- EFA para acelerar workloads de ML
- O EC2-Classic transformou hardware em um recurso programável, permitindo que desenvolvedores, fundadores, startups e empresas usassem tanta capacidade computacional quanto quisessem, quando precisassem
- Complexidades como gerenciamento de infraestrutura, compra de novo hardware, upgrades de software e substituição de discos com defeito foram abstraídas
Transição para a VPC e suporte de longo prazo
- Este blog foi migrado para o m1.small logo após o lançamento do EC2, executando Moveable Type e um banco de dados local
- Depois, foi convertido em um serviço de alta disponibilidade com recursos como failover no RDS
- Após o lançamento do recurso Amazon S3 Website em 2011, ele foi migrado para uma base em S3
- Desde então, operou em estado “serverless” por 12 anos
- À medida que as demandas dos clientes aumentavam, foram adicionados Elastic IP, Auto Scaling, Load Balancing, CloudWatch e vários novos tipos de instância
- Em 2013, com a ativação da VPC, cada cliente da AWS passou a poder gerenciar uma área de nuvem segura, isolada e definida de acordo com o seu negócio
- A VPC se tornou o novo padrão e forneceu o nível de controle que permitiu aos clientes construir sistemas mais abrangentes na nuvem
- Mesmo depois de o EC2 evoluir para uma nova plataforma de virtualização chamada Nitro, o Classic continuou com suporte por mais 10 anos por causa do uso dos clientes
- A equipe do EC2 manteve a operação até que todas as instâncias Classic fossem encerradas ou migradas
- Ao longo de todo o processo, foram fornecidos documentação, ferramentas, suporte da equipe de engenharia e suporte da equipe de gestão de contas
- O encerramento do EC2-Classic mostra o quanto a nuvem mudou desde 2006 e reforça a necessidade de construir sistemas capazes de evoluir e reexaminar a arquitetura com uma perspectiva aberta
1 comentários
Opiniões no Hacker News
EC2-Classic parecia mágica
Parecia que finalmente tínhamos chegado a um futuro em que o software assumia a responsabilidade pela rede, e podíamos esquecer a velha complexidade da época em que redes eram montadas com cabos
Em vez das sub-redes IP tradicionais, a nuvem funcionava em torno de security groups, e, com apenas alguns recursos como hierarquia, acho que poderia ter substituído completamente o papel das sub-redes da rede tradicional
Depois de usar EC2-Classic por bastante tempo, engenharia de rede era fácil e divertida, mas o novo modelo de VPC é complicado, desanima, e nem sei bem se ele permite algo que não pudesse ser expresso com security groups
Já escrevi antes sobre isso com mais detalhes — ou, dependendo do humor, com mais veemência —, mas o sentimento mais forte ao migrar do EC2-Classic foi a frustração de ver pessoas piorando algo que funcionava bem
https://news.ycombinator.com/item?id=36829190
https://news.ycombinator.com/item?id=33569889
https://news.ycombinator.com/item?id=27990847
https://news.ycombinator.com/item?id=25988915
Por trás dos panos, a AWS cria uma VPC automaticamente, e você consegue usar quase como o antigo Classic até decidir mexer nas configurações da VPC, como se fosse uma medida de “quebrar o vidro em caso de emergência”
https://aws.amazon.com/vpc/lattice/
Ainda assim, ele vai além de simplesmente colocar security groups sobre uma rede plana: cada endpoint HTTP vira automaticamente um recurso IAM, todos os serviços podem ser tratados como nativos da AWS e podem usar as mesmas políticas IAM, então é bem interessante
Dá para adicionar uma única entrada para a AWS na tabela de roteamento interna da empresa sem passar pela internet pública, e esse tipo de configuração seria problemática em uma rede plana compartilhada
Entendo que VPC seja necessária ao integrar com rede corporativa, VPN etc., mas na prática há muitos casos em que ela complica demais as coisas mesmo quando não é necessária
A notação IPv4 na citação é confusa
Ela diz que “quando lançamos o EC2 em 2006, era uma única rede enorme 10.2.0.0/8”, mas, pelo que entendo, /8 fixa apenas o primeiro octeto, ficando no intervalo 10.0.0.0–10.255.255.255
Então não entendo por que o 2 seria importante aqui; e, se o 2 é importante, não deveria ser /16?
Considerando a fonte e minha confiança na notação, talvez haja algum outro significado que especialistas consigam perceber, então fiquei curioso; se for só um erro de digitação, desculpe por parecer tão implicante
Deveria ser 10.0.0.0/8; já corrigimos no blog e também corrigimos a confusão relacionada à memória do P3dn.24xlarge
A maior sub-rede que pode ser criada começando em 10.2.0.0 é 10.2.0.0/15
Fico pensando se, em vez de ser um erro de digitação, poderia ser uma forma estranha de se referir a 10.0.0.0/8 excluindo 10.1.0.0/16
Interpretei que o autor quis dizer que as máquinas recebiam endereços 10.2/16, mas ainda podiam rotear para serviços ou máquinas da AWS em outras sub-redes 10/8, como 10.1/16
“A complexidade de gerenciar infraestrutura, comprar novo hardware, fazer upgrades de software e substituir discos com defeito foi abstraída”, mas no lugar entrou apenas a complexidade da AWS
Mesmo antes da AWS, você não precisava comprar hardware diretamente nem trocar pessoalmente discos defeituosos; a empresa de hospedagem fazia isso
Claro que você não entrava pessoalmente no datacenter para trocar o disco, mas o processo era muito diferente do que se obtém com a AWS
Ainda hoje há muitas empresas de hospedagem web operando do modo antigo, mas existe um motivo para as pessoas preferirem serviços como a AWS
Isso é bem diferente da capacidade de subir, com alguns cliques, um novo servidor em hardware separado
Se tudo de que você precisa é um VPS, use um VPS; pessoalmente, nesse caso prefiro a Hetzner
Mas, para atender às necessidades de grandes organizações, a AWS inevitavelmente precisa ser complexa
Além disso, a interface do console da AWS para iniciar EC2 melhorou muito e lida com uma quantidade considerável de complexidade por você
A Oracle também continua faturando bilhões de dólares, apesar de toda a sua reputação
Eu estava lendo a frase “encerrar um serviço não é algo que se faça na AWS, e é bem raro”, justamente enquanto fazia uma pausa de um épico trabalho para mover nossas coisas do OpsWorks antes do encerramento em maio
Antes de Kubernetes e Terraform aparecerem, criei alguns clusters com OpsWorks
Mas, pelo que ouvi de pessoas da AWS, internamente ele não era muito bem mantido e a parte de trás estava bem bagunçada; então, considerando como o panorama tecnológico mudou bastante desde que o serviço foi lançado, não é surpreendente que ele esteja sendo encerrado agora
RIP OpsWorks
O título é “nós fazemos X”, mas o texto soa como “nós não fazemos X aqui”, então no começo eu não entendi muito bem o que o texto queria dizer
Esse serviço entrou em “modo de manutenção” e, no início deste ano, o acesso pelo console também foi removido
O trecho “no keynote do re:Invent de 2013, há 10 anos, dissemos que queríamos dar suporte tanto às cargas de trabalho de hoje quanto às de amanhã, e nosso compromisso com o Classic é a melhor prova disso” é exatamente o motivo pelo qual as empresas confiam na AWS
A equipe do EC2 manteve o Classic funcionando bem até que todas as instâncias fossem encerradas ou migradas, e acho que é esse tipo de coisa que cria confiança
Ainda me lembro de quando trabalhava na Serif e precisávamos de hospedagem web para um novo site de mídia social que seria integrado ao software de desktop de scrapbook
Na época, como sempre, havia muitas tecnologias novas e reluzentes, e uma delas era o Microsoft Silverlight; implementamos “Deep Zoom” no site para que os usuários pudessem ampliar facilmente os scrapbooks publicados e ver os detalhes
Outra tecnologia nova era a AWS, e o EC2 tinha acabado de ser lançado, então era bem empolgante poder subir instâncias nos EUA, na Irlanda e em Amsterdã com um botão e, se elas morressem, apertar o botão de novo para subir novas
Assim como hoje, havia uma complexidade considerável escondida por trás de uma UI simples, e tivemos que aprender os vários tipos de armazenamento e quais eram persistentes
Acho que as primeiras instâncias EC2 não eram tão estáveis quanto as de hoje e, de fato, perdemos completamente uma ou duas e tivemos que recriá-las, então fazíamos muitos snapshots
Não havia infraestrutura como código nem DevOps, mas criamos nosso próprio cluster de alta disponibilidade, e um engenheiro com quem eu trabalhava escreveu do zero, em C++, um software para monitorar os bancos de dados em várias instâncias EC2 e manter o cluster vivo
Na época também não existiam arquitetos de nuvem, então não sabíamos muito bem o que estávamos fazendo nem o que era prudente, mas a tecnologia funcionou muito bem e, depois dos tropeços iniciais, criamos uma comunidade de internet bastante ativa
O site foi feito em PHP e MySQL; transformávamos XML gerado a partir dos dados relacionais em SQL em HTML usando XSLT, e não havia muito JavaScript, só algo como jQuery
O deploy provavelmente era feito enviando os arquivos pelo FileZilla, e então o software de cluster em C++ replicava os arquivos enviados para as instâncias EC2 em outras zonas de disponibilidade
Olhando para trás, provavelmente não precisávamos ter servidores em três zonas de disponibilidade, mas o trabalho foi realmente divertido e foi uma boa época que me apresentou à AWS
A AWS não tinha uma camada de banco de dados, então usávamos instâncias com Elastic Block Store anexado para durabilidade
Agora só falta permitirem de verdade um orçamento fixo, em vez da possibilidade de a cobrança do cartão de crédito sair do controle
A Microsoft faz isso e me lembro de que o Google também fazia, mas não sei por que a Amazon não faz
Também estou esperando por isso há quase 20 anos
Pessoalmente, eu gostaria que a AWS simplesmente tivesse tomado uma decisão e colocado IPv6 no Classic para seguir em frente
Ironicamente, o pós-Classic parece uma regressão e ficou muito mais parecido com a infraestrutura com que tínhamos que lidar antes da nuvem
A maior parte das coisas novas que crio fica em cima da Cloudflare, então hoje quase não penso em sub-redes, VPC e coisas do tipo
Todas elas precisam se integrar às redes internas, então VPC se torna necessária
Se eu entendi direito, fico me perguntando se todas as instâncias Classic foram migradas para tipos mais modernos sem intervenção dos proprietários das contas
Também fico curioso se houve reinicialização nesse processo ou se foi feito por migração ao vivo
Porque é difícil extrair migração ao vivo de uma plataforma de virtualização que originalmente não foi pensada para isso
Também fico pensando se a configuração de rede original ainda é emulada, ou se algumas aplicações de clientes podem ter quebrado
Os detalhes estão aqui: https://aws.amazon.com/blogs/aws/ec2-classic-is-retiring-her...
Parece que a AWS gastou tempo, pessoal e dinheiro para tirar os clientes do EC2-Classic, e também fez um esforço considerável para automatizar o processo e torná-lo menos doloroso
Ex.: https://repost.aws/knowledge-center/ssm-migrate-ec2classic-v...
A rede original mudou de um modelo em que todo mundo ficava na mesma sub-rede para um em que cada um recebe sua própria sub-rede, então aplicações de clientes de fato podiam quebrar
As pessoas às vezes fazem coisas pouco inteligentes por motivos bastante compreensíveis, como colocar endereços IP hardcoded em /etc/hosts quando o servidor de nomes caiu e depois esquecer de reverter
Para fazer bem uma migração dessas, é preciso tanto o chicote quanto a cenoura
O chicote é que, no fim, o serviço será descontinuado e deixará de ser oferecido; a cenoura é automação, lembretes repetidos de que é necessária uma janela de manutenção, instruções claras e, acima de tudo, disposição para realmente conversar com os clientes e responder a eles
Mas a AWS deu anos para as pessoas fazerem isso e, quando necessário, procurou todos os usuários e ajudou
Pode ter havido descontos ou ameaças de encerramento
É surpreendente que não tenha havido nem uma única instância cujo proprietário tivesse esquecido ou se recusado a mexer, então é realmente interessante entender como isso foi possível
O vencimento do cartão de crédito pode ter sido a chave, já que é possível que a maioria das contas esquecidas tenha sido desativada automaticamente
Imagino que tenha sido algo parecido
VMs são difíceis de mover automaticamente se não forem configuradas especificamente para serem movíveis; por exemplo, a ordem dos dispositivos no barramento PCIe pode mudar, e vários IDs da máquina, como o endereço MAC, também podem mudar
Se você não garantir que a VM não seja afetada por essas mudanças, é bem provável que surjam problemas após a migração
Este nível de suporte é algo que toda empresa de software deveria buscar
É exatamente isso que clientes corporativos querem ver e pelo que pagam