Adiós a EC2-Classic, fue una gran época
(allthingsdistributed.com)- AWS apagó la última instancia de EC2-Classic el 15 de agosto de 2023, cerrando así la operación del modelo inicial de cómputo en la nube que comenzó con el lanzamiento de EC2 en 2006
- El núcleo de Classic era una red plana única 10.0.0.0/8, y su innovación en ese momento fue simplificar la obtención de capacidad de cómputo mientras ocultaba una implementación interna compleja
- En 2006,
m1.smallofrecía por $0.10 por hora una vCPU equivalente a un Xeon de 1.7GHz, 1.75GB de RAM, 160GB de disco local y red de 250Mb/s; más adelante, EC2 se expandió hasta instancias grandes comoP3dn.24xlarge - Se añadieron Elastic IP, Auto Scaling, Load Balancing, CloudWatch y nuevos tipos de instancia, y en 2013 VPC se convirtió en el nuevo estándar de áreas de nube aisladas y definibles por cliente
- Classic se mantuvo 10 años más incluso después de nuevas plataformas de virtualización como Nitro, debido al uso por parte de clientes, y se siguieron ofreciendo documentación, herramientas y soporte hasta que todas las instancias fueran apagadas o migradas
El fin de EC2-Classic y su estructura inicial
- AWS ha abordado con cautela el retiro de servicios de los que dependen los negocios de sus clientes
- SimpleDB sigue disponible incluso después de que DynamoDB se consolidara como la opción de base de datos “NoSQL” para los clientes
- Dos años después del anuncio de Jeff Barr sobre el retiro de EC2-Classic, la última instancia de Classic fue apagada el 15 de agosto de 2023
- EC2 operó durante casi 17 años, y entre los servicios de AWS solo SQS y S3 son más antiguos que EC2
- El mayor elemento distintivo de “Classic” era su arquitectura de red
- En 2006, EC2 comenzó con una única red gigante 10.0.0.0/8
- Todas las instancias se ejecutaban en una red plana única compartida con otros clientes
- Ofrecía funciones como grupos de seguridad y direcciones IP públicas asignadas al iniciar la instancia
- La pila interna era muy compleja, pero para el usuario era posible obtener el cómputo necesario de forma sencilla
Cambios en el rendimiento de las instancias
- En 2006, al ejecutar una instancia
m1.small, se disponía de la siguiente configuración- CPU virtual equivalente a un procesador Xeon de 1.7GHz
- 1.75GB de RAM
- 160GB de disco local
- 250Mb/s de ancho de banda de red
- $0.10 por hora
- Más adelante, EC2 se expandió hasta instancias como
P3dn.24xlarge- 100Gbps de rendimiento de red
- 96 vCPU
- 8 GPU NVIDIA v100 Tensor Core con 32GiB de memoria cada una
- 768GiB de memoria del sistema
- 1.8TB de almacenamiento SSD local
- EFA para acelerar cargas de trabajo de ML
- EC2-Classic convirtió el hardware en un recurso programable, permitiendo que desarrolladores, fundadores, startups y empresas usaran tanto cómputo como necesitaran, cuando lo necesitaran
- Se abstrajo la complejidad de administrar infraestructura, comprar nuevo hardware, actualizar software y reemplazar discos dañados
La transición a VPC y el soporte a largo plazo
- Este blog fue migrado a
m1.smallpoco después del lanzamiento de EC2, y ejecutaba Moveable Type y una base de datos local- Más adelante se convirtió en un servicio de alta disponibilidad con capacidades como failover de RDS
- Tras el lanzamiento de la función de sitio web de Amazon S3 en 2011, se migró a una base sobre S3
- Después operó durante 12 años en estado “serverless”
- A medida que crecían las necesidades de los clientes, se añadieron Elastic IP, Auto Scaling, Load Balancing, CloudWatch y varios tipos nuevos de instancia
- En 2013, con la habilitación de VPC, cada cliente de AWS pudo administrar áreas de nube seguras, aisladas y definidas según su negocio
- VPC se convirtió en el nuevo estándar y ofreció el nivel de control necesario para que los clientes construyeran sistemas más integrales en la nube
- Incluso después de que EC2 evolucionara a una nueva plataforma de virtualización llamada Nitro, Classic siguió recibiendo soporte durante 10 años más debido a su uso por parte de los clientes
- El equipo de EC2 mantuvo la operación hasta que todas las instancias de Classic fueran apagadas o migradas
- Durante todo el proceso se ofrecieron documentación, herramientas, soporte del equipo de ingeniería y apoyo del equipo de gestión de cuentas
- El retiro de EC2-Classic muestra cuánto ha cambiado la nube desde 2006 y la necesidad de construir sistemas capaces de evolucionar y volver a examinar la arquitectura con una perspectiva abierta
1 comentarios
Opiniones de Hacker News
EC2-Classic era como magia
Por fin se sentía que habíamos llegado a un futuro en el que el software se hacía cargo del networking y podíamos olvidarnos de la vieja complejidad de armar redes con cables
En vez de las subredes IP tradicionales, la nube funcionaba alrededor de los grupos de seguridad, y con algunas funciones más, como una estructura jerárquica, parece que podría haber reemplazado por completo el rol de las subredes del networking tradicional
Tras usar EC2-Classic durante mucho tiempo, la ingeniería de redes me resultaba fácil y divertida, pero el nuevo enfoque con VPC es complejo, quita las ganas, y ni siquiera tengo claro si permite algo que no se pudiera expresar con grupos de seguridad
Ya escribí antes sobre esto con más detalle, o con más intensidad según el ánimo, pero la sensación más fuerte al pasar de EC2-Classic fue la frustración de ver cómo otros empeoraban algo que funcionaba perfectamente bien
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 detrás, AWS crea una VPC automáticamente, y hasta que el usuario no toca la configuración de la VPC como medida de “romper el vidrio”, se puede usar casi igual que el antiguo Classic
https://aws.amazon.com/vpc/lattice/
Eso sí, va más allá de simplemente poner grupos de seguridad sobre una red plana: cada endpoint HTTP se convierte automáticamente en un recurso de IAM, todos los servicios se tratan como nativos de AWS y se pueden usar las mismas políticas de IAM, lo cual está bastante bien
Puedes agregar una única entrada hacia AWS en la tabla de ruteo interna sin pasar por la Internet pública, y ese tipo de configuración causa problemas en una red plana compartida
Entiendo que VPC sea necesaria al integrarse con redes internas, VPN y demás, pero en la práctica muchas veces complica demasiado las cosas aunque en realidad no se necesite VPC en absoluto
La notación IPv4 en la cita confunde
Dice: “Cuando lanzamos EC2 en 2006, era una enorme red 10.2.0.0/8”, pero entiendo que con /8 solo queda fijo el primer octeto, por lo que el rango sería 10.0.0.0~10.255.255.255
Entonces no entiendo por qué el 2 es importante aquí, y si el 2 es importante, ¿no debería escribirse como /16?
Dada mi confianza en la fuente y en la notación, me da curiosidad si hay algún otro significado que un experto pueda interpretar; y si es solo un typo, perdón por ser tan quisquilloso
Debía ser 10.0.0.0/8; ya lo corregimos en el blog, y también arreglamos la confusión relacionada con la memoria de la P3dn.24xlarge
La subred más grande que se puede crear empezando en 10.2.0.0 es 10.2.0.0/15
Más que un typo, se me ocurre que podría ser una forma extraña de escribir 10.0.0.0/8 excluyendo 10.1.0.0/16
Interpreté que el autor quería decir que las máquinas recibían direcciones 10.2/16, pero también podían rutear hacia servicios o máquinas de AWS en otras subredes 10/8, como 10.1/16
“Se abstrajo la complejidad de administrar infraestructura, comprar hardware nuevo, actualizar software y reemplazar discos fallados”, pero en su lugar simplemente llegó la complejidad de AWS
Incluso antes de AWS no hacía falta comprar hardware directamente ni cambiar discos fallados uno mismo; las empresas de web hosting lo hacían
Claro que uno no entraba personalmente al datacenter a cambiar un disco, pero era un proceso muy distinto de lo que se obtiene con AWS
Incluso hoy hay muchas empresas de web hosting que operan a la antigua, pero hay razones por las que la gente prefiere servicios como AWS
Hay una gran diferencia con la capacidad de levantar un servidor nuevo en hardware separado con unos cuantos clics
Si lo único que necesitas es un VPS, usa un VPS; personalmente, para ese caso prefiero Hetzner
Pero para manejar las necesidades de organizaciones grandes, AWS inevitablemente tiene que ser complejo
Además, la interfaz de lanzamiento de EC2 en la consola de AWS ha mejorado muchísimo y se encarga de bastante complejidad por ti
Oracle también sigue ganando miles de millones de dólares a pesar de toda su reputación
Estaba leyendo la frase “cerrar un servicio no es algo que AWS haga, y es bastante raro”, justo mientras me tomaba un descanso de una épica tarea de migrar nuestras cosas desde OpsWorks antes de su cierre en mayo.
Antes de que aparecieran Kubernetes y Terraform, armé varios clústeres con OpsWorks.
Dicho eso, por lo que escuché de gente de AWS, internamente no tenía buen mantenimiento y por detrás era bastante desordenado, así que no sorprende que lo retiren ahora que el panorama tecnológico cambió mucho desde que se lanzó el servicio.
RIP OpsWorks
El título dice “nosotros hacemos X”, pero el texto se lee como “nosotros aquí no hacemos X”, así que al principio no entendía bien qué quería decir el artículo.
Ese servicio entró en “modo mantenimiento” y a principios de este año también le quitaron el acceso desde la consola.
El pasaje que dice “en la keynote de re:Invent de 2013, hace 10 años, dijimos que queríamos dar soporte tanto a las cargas de trabajo de hoy como a las de mañana, y nuestro compromiso con Classic es la mejor prueba de eso” es justamente la razón por la que las empresas confían en AWS.
El equipo de EC2 mantuvo Classic funcionando bien hasta que todas las instancias fueron terminadas o migradas, y creo que ese tipo de cosas genera confianza.
Todavía recuerdo cuando trabajaba en Serif y necesitábamos hosting web para un nuevo sitio de redes sociales que se integraría con nuestro software de escritorio de álbumes de recortes.
En ese momento, como siempre, había muchas tecnologías nuevas y brillantes; una de ellas era Microsoft Silverlight, y usamos su “Deep Zoom” en el sitio para que los usuarios pudieran acercarse fácilmente a los álbumes publicados y ver los detalles.
Otra tecnología nueva era AWS, y EC2 acababa de lanzarse, así que era bastante emocionante poder levantar instancias en Estados Unidos, Irlanda y Ámsterdam con un botón, y si morían, apretar el botón de nuevo para crear otra.
Igual que ahora, detrás de una UI sencilla había bastante complejidad, y tuvimos que aprender sobre varios tipos de almacenamiento y cuáles eran persistentes.
Creo que las primeras instancias de EC2 no eran tan confiables como las actuales y, de hecho, perdimos por completo una o dos y tuvimos que recrearlas, así que sacábamos muchos snapshots.
No había infraestructura como código ni DevOps, pero armamos nuestro propio clúster de alta disponibilidad, y un ingeniero con el que trabajaba escribió desde cero en C++ un software que monitoreaba las bases de datos en varias instancias EC2 y mantenía vivo el clúster.
En ese entonces tampoco había arquitectos cloud, así que no sabíamos muy bien qué estábamos haciendo ni qué era lo más sensato, pero la tecnología funcionó muy bien y, después de las primeras pruebas y errores, construimos una comunidad de Internet bastante activa.
El sitio estaba hecho en PHP y MySQL; convertíamos XML generado a partir de datos relacionales en SQL a HTML usando XSLT, y no usábamos mucho JavaScript, apenas algo de jQuery.
El despliegue probablemente consistía en subir archivos con FileZilla y luego el software de clúster en C++ replicaba esos archivos a las instancias EC2 en otras zonas de disponibilidad.
Mirando hacia atrás, probablemente no necesitábamos tener servidores en tres zonas de disponibilidad, pero fue un trabajo muy divertido y una gran época en la que conocí AWS por primera vez.
AWS no tenía una capa de base de datos, así que usábamos instancias con Elastic Block Store adjunto para tener durabilidad.
Lo único que falta ahora es que permitan de verdad un presupuesto fijo, en lugar de la posibilidad de que el cargo de la tarjeta de crédito se dispare.
Microsoft lo hace y recuerdo que Google también lo hacía, pero no sé por qué Amazon no.
Llevo esperando esto casi 20 años.
Personalmente, me habría gustado que AWS simplemente tomara la decisión de agregarle IPv6 a Classic y siguiera adelante.
Irónicamente, post-Classic parece un retroceso y se volvió mucho más parecido a la infraestructura con la que teníamos que lidiar antes de la nube.
La mayoría de las cosas nuevas las estoy montando sobre Cloudflare, así que ya casi no pienso en subredes, VPC y demás.
Todas ellas necesitan integrarse con sus redes internas, así que terminan necesitando VPC.
Si entendí bien, me pregunto si todas las instancias Classic se migraron a tipos más modernos sin intervención de los propietarios de las cuentas.
También me pregunto si hubo reinicios durante ese proceso, o si se manejó con migración en vivo.
Porque es difícil sacar migración en vivo de una plataforma de virtualización que originalmente no fue pensada para eso.
También me pregunto si la configuración de red original todavía se emula, o si algunas aplicaciones de clientes pudieron haberse roto.
Los detalles están aquí: https://aws.amazon.com/blogs/aws/ec2-classic-is-retiring-her...
Parece que AWS dedicó tiempo, personal y dinero para sacar a los clientes de EC2-Classic, y también hizo bastante esfuerzo para automatizar el proceso y hacerlo menos doloroso.
Ejemplo: https://repost.aws/knowledge-center/ssm-migrate-ec2classic-v...
La red original cambió de un modelo en el que todos estaban en la misma subred a uno en el que cada quien recibe su propia subred, así que las aplicaciones de clientes efectivamente podían romperse.
La gente a veces hace cosas poco inteligentes por razones suficientes, como hardcodear direcciones IP en /etc/hosts cuando se cae el nameserver y luego olvidarse de revertirlo.
Para hacer bien una migración así hacen falta tanto el garrote como la zanahoria.
El garrote es que al final vas a suspender el servicio y negarte a proporcionarlo; la zanahoria es automatización, recordatorios repetidos de que se necesita una ventana de mantenimiento, instrucciones claras y, sobre todo, la disposición de hablar de verdad con los clientes y responderles.
Eso sí, AWS les dio años a las personas para hacerlo y, si hacía falta, fue a buscar y ayudar a todos los usuarios.
Puede que haya habido descuentos o amenazas de cierre.
Me sorprende que no hubiera ni una sola instancia cuyo propietario la hubiera olvidado o se hubiera negado a hacer el trabajo, así que realmente me intriga cómo fue posible.
La caducidad de las tarjetas de crédito pudo haber sido clave, porque probablemente desactivó automáticamente la mayoría de las cuentas olvidadas.
Supongo que fue algo parecido.
Las VM son difíciles de mover automáticamente si no están configuradas específicamente para poder trasladarse; por ejemplo, puede cambiar el orden de los dispositivos en el bus PCIe, y también pueden cambiar varios ID de la máquina, como la dirección MAC.
Si no garantizas que la VM no se vea afectada por esos cambios, es muy probable que haya problemas después de moverla.
Este nivel de soporte es al que toda empresa de software debería aspirar.
Esto es exactamente lo que los clientes empresariales quieren ver y por lo que pagan.