บอกลา EC2-Classic มันเป็นช่วงเวลาที่ยอดเยี่ยม

 (allthingsdistributed.com)
1 คะแนน โดย GN⁺ 2023-09-03 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • AWS ปิด อินสแตนซ์สุดท้ายของ EC2-Classic เมื่อวันที่ 15 สิงหาคม 2023 เป็นการยุติการดำเนินงานของโมเดลคอมพิวต์บนคลาวด์ยุคแรกที่เริ่มต้นพร้อมการเปิดตัว EC2 ในปี 2006
  • แก่นหลักของ Classic คือ เครือข่ายระนาบเดียว 10.0.0.0/8 และนวัตกรรมในเวลานั้นคือการทำให้การจัดหาคอมพิวต์เป็นเรื่องง่าย โดยซ่อนการทำงานภายในที่ซับซ้อนไว้
  • ในปี 2006 m1.small ให้บริการ vCPU เทียบเท่า Xeon 1.7GHz, RAM 1.75GB, ดิสก์โลคัล 160GB และเครือข่าย 250Mb/s ในราคา $0.10 ต่อชั่วโมง และต่อมา EC2 ก็ขยายไปสู่อินสแตนซ์ขนาดใหญ่อย่าง P3dn.24xlarge
  • มีการเพิ่ม Elastic IP, Auto Scaling, Load Balancing, CloudWatch และประเภทอินสแตนซ์ใหม่ ๆ และในปี 2013 VPC ก็กลายเป็นมาตรฐานใหม่ของพื้นที่คลาวด์ที่แยกกั้นและกำหนดได้สำหรับลูกค้าแต่ละราย
  • Classic ยังคงถูกรักษาไว้อีก 10 ปีหลังจากมีแพลตฟอร์มเวอร์ชวลไลเซชันใหม่อย่าง Nitro เนื่องจากลูกค้ายังใช้งานอยู่ และมีเอกสาร เครื่องมือ และการสนับสนุนต่อเนื่องจนกว่าอินสแตนซ์ทั้งหมดจะถูกปิดหรือย้ายระบบ

การสิ้นสุด EC2-Classic และโครงสร้างยุคแรก

  • AWS ใช้แนวทางอย่างระมัดระวังเมื่อจะยุติบริการที่ธุรกิจของลูกค้าพึ่งพา
    • SimpleDB ยังคงให้บริการต่อไป แม้ DynamoDB จะกลายเป็นตัวเลือกฐานข้อมูล “NoSQL” ของลูกค้าแล้วก็ตาม
  • สองปีหลังจาก Jeff Barr ประกาศล่วงหน้าเรื่องการยุติ EC2-Classic เมื่อวันที่ 15 สิงหาคม 2023 อินสแตนซ์สุดท้ายของ Classic ก็ถูกปิดลง
  • EC2 ดำเนินงานมาเกือบ 17 ปีแล้ว และในบรรดาบริการของ AWS มีเพียง SQS และ S3 เท่านั้นที่เก่ากว่า EC2
  • ปัจจัยที่แยก “Classic” ออกมาอย่างเด่นชัดที่สุดคือ สถาปัตยกรรมเครือข่าย
    • ในปี 2006 EC2 เริ่มต้นด้วยเครือข่ายขนาดมหึมาเพียงเครือข่ายเดียวคือ 10.0.0.0/8
    • อินสแตนซ์ทั้งหมดทำงานอยู่บนเครือข่ายระนาบเดียวที่ใช้ร่วมกับลูกค้ารายอื่น
    • มีฟีเจอร์อย่าง security group และ Public IP ที่กำหนดให้เมื่อเริ่มอินสแตนซ์
  • สแต็กภายในซับซ้อนมาก แต่ผู้ใช้สามารถจัดหาคอมพิวต์ที่ต้องการได้อย่างเรียบง่าย

การเปลี่ยนแปลงของประสิทธิภาพอินสแตนซ์

  • หากรันอินสแตนซ์ m1.small ในปี 2006 จะได้ใช้คอนฟิกต่อไปนี้
    • CPU เสมือนเทียบเท่าโปรเซสเซอร์ Xeon 1.7GHz
    • RAM 1.75GB
    • ดิสก์โลคัล 160GB
    • แบนด์วิดท์เครือข่าย 250Mb/s
    • $0.10 ต่อชั่วโมง
  • ต่อมา EC2 ขยายไปสู่อินสแตนซ์อย่าง P3dn.24xlarge
    • ทรูพุตเครือข่าย 100Gbps
    • 96 vCPU
    • NVIDIA v100 Tensor Core GPU 8 ตัว พร้อมหน่วยความจำ 32GiB
    • หน่วยความจำระบบ 768GiB
    • สตอเรจ SSD โลคัล 1.8TB
    • EFA สำหรับเร่งความเร็วเวิร์กโหลด ML
  • EC2-Classic เปลี่ยนฮาร์ดแวร์ให้เป็น ทรัพยากรที่โปรแกรมได้ ทำให้นักพัฒนา ผู้ก่อตั้ง สตาร์ทอัพ และองค์กรขนาดใหญ่สามารถใช้คอมพิวต์ได้มากเท่าที่ต้องการ เมื่อต้องการ
    • ความซับซ้อนอย่างการจัดการโครงสร้างพื้นฐาน การซื้อฮาร์ดแวร์ใหม่ การอัปเกรดซอฟต์แวร์ และการเปลี่ยนดิสก์ที่เสีย ถูกทำให้เป็นนามธรรม

การย้ายไป VPC และการสนับสนุนระยะยาว

  • บล็อกนี้ถูกย้ายไปยัง m1.small ไม่นานหลัง EC2 เปิดตัว และรัน Moveable Type กับฐานข้อมูลโลคัล
    • ต่อมาถูกเปลี่ยนเป็นบริการความพร้อมใช้งานสูงที่มีการทำ failover ของ RDS เป็นต้น
    • หลังจาก ฟีเจอร์ Amazon S3 Website เปิดตัวในปี 2011 ก็ย้ายไปใช้ S3 เป็นฐาน
    • หลังจากนั้นดำเนินงานในสถานะ “serverless” เป็นเวลา 12 ปี
  • เมื่อความต้องการของลูกค้าเพิ่มขึ้น ก็มีการเพิ่ม Elastic IP, Auto Scaling, Load Balancing, CloudWatch และประเภทอินสแตนซ์ใหม่หลากหลายประเภท
  • ในปี 2013 VPC ถูกเปิดใช้งาน ทำให้ลูกค้า AWS แต่ละรายสามารถจัดการพื้นที่คลาวด์ที่ปลอดภัย แยกกั้น และกำหนดให้เหมาะกับธุรกิจของตนได้
    • VPC กลายเป็นมาตรฐานใหม่ และมอบระดับการควบคุมที่ช่วยให้ลูกค้าสร้างระบบบนคลาวด์ได้อย่างครอบคลุมยิ่งขึ้น
  • แม้ EC2 จะพัฒนาไปสู่แพลตฟอร์มเวอร์ชวลไลเซชันใหม่ที่ชื่อ Nitro แล้ว Classic ก็ยังได้รับการสนับสนุนต่อไปอีก 10 ปี เนื่องจากลูกค้ายังใช้งานอยู่
  • ทีม EC2 คงการดำเนินงานไว้จนกว่าอินสแตนซ์ Classic ทั้งหมดจะถูกปิดหรือย้ายระบบ
    • ตลอดกระบวนการ มีการให้เอกสาร เครื่องมือ การสนับสนุนจากทีมวิศวกรรม และการสนับสนุนจากทีมจัดการบัญชี
  • การสิ้นสุดของ EC2-Classic แสดงให้เห็นว่าคลาวด์เปลี่ยนแปลงไปอย่างมากนับตั้งแต่ปี 2006 และเราควรสร้าง ระบบที่วิวัฒน์ได้ พร้อมกลับมาพิจารณาสถาปัตยกรรมด้วยมุมมองที่เปิดกว้าง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-09-03
ความคิดเห็นบน Hacker News

  • EC2-Classic เคยให้ความรู้สึกเหมือนเวทมนตร์
    ในที่สุดก็รู้สึกว่าเรามาถึงอนาคตที่ซอฟต์แวร์รับผิดชอบเรื่องเน็ตเวิร์ก และไม่ต้องจำความซับซ้อนเก่า ๆ สมัยสร้างเครือข่ายด้วยสายเคเบิลอีกต่อไป
    แทนที่จะยึด subnet ของ IP แบบเดิม คลาวด์ทำงานโดยมี security group เป็นศูนย์กลาง และถ้ามีฟีเจอร์เพิ่มอีกสักสองสามอย่างอย่างโครงสร้างแบบลำดับชั้น ก็น่าจะทดแทนบทบาทของ subnet ในเน็ตเวิร์กแบบดั้งเดิมได้ทั้งหมด
    พอใช้ EC2-Classic มานาน งาน network engineering รู้สึกง่ายและสนุก แต่แนวทาง VPC ใหม่ซับซ้อนจนหมดไฟ และก็ไม่แน่ใจด้วยว่ามันทำให้ทำอะไรที่ security group เคยอธิบายไม่ได้ได้จริงหรือเปล่า
    เคยเขียนเรื่องนี้ละเอียดกว่านี้ หรือบางทีก็เดือดกว่านี้ ตามอารมณ์ แต่ความรู้สึกหลักที่สุดตอนย้ายออกจาก EC2-Classic คือความหงุดหงิดแบบเวลาคนอื่นทำให้สิ่งที่ดีอยู่แล้วแย่ลง
    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

    • ถ้าสร้างบัญชีใหม่ โดยพื้นฐานแล้วมันจะทำงานเหมือน EC2-Classic แบบเดิม
      เบื้องหลัง AWS จะสร้าง VPC ให้เอง และจนกว่าผู้ใช้จะเข้าไปแตะการตั้งค่า VPC แบบ “ทุบกระจกยามฉุกเฉิน” ก็ใช้งานได้แทบเหมือน Classic เดิม
    • VPC Lattice ที่เพิ่งออกมา โดยพื้นฐานแล้วใกล้เคียงกับ “EC2 Classic networking” แต่เป็นรูปแบบที่ต้องจ่ายเงิน
      https://aws.amazon.com/vpc/lattice/
      อย่างไรก็ตาม มันไปไกลกว่าแค่เอา security group มาวางบนเครือข่ายแบบแบน ๆ เพราะแต่ละ HTTP endpoint จะกลายเป็น IAM resource โดยอัตโนมัติ ทำให้จัดการทุก service ได้เหมือนเป็น AWS native และใช้นโยบาย IAM เดียวกันได้ ซึ่งก็ค่อนข้างดี
    • VPC ทำให้ทำสิ่งที่ Classic ทำไม่ได้อย่างชัดเจน
      สามารถเพิ่มรายการเดียวใน routing table ภายในบริษัทเพื่อไปยัง AWS ได้โดยไม่ต้องผ่านอินเทอร์เน็ตสาธารณะ ซึ่งการตั้งค่าแบบนี้จะมีปัญหาในเครือข่ายระนาบเดียวที่ใช้ร่วมกัน
    • หนึ่งในสตาร์ทอัพแรก ๆ ที่เคยทำงานด้วยรันทั้งหมดบน EC2-Classic และความเรียบง่ายของมันก็ดีมาก
      เข้าใจว่าต้องใช้ VPC เมื่อต้องผสานกับเครือข่ายภายในบริษัท, VPN และอื่น ๆ แต่ในความเป็นจริงมีหลายครั้งที่ไม่จำเป็นต้องใช้ VPC เลย แต่กลับทำให้งานซับซ้อนเกินไป

  • สัญกรณ์ IPv4 ในข้อความที่ยกมาทำให้งง
    มันเขียนว่า “ตอนเปิดตัว EC2 ในปี 2006 มันเป็นเครือข่ายขนาดยักษ์เครือข่ายเดียวคือ 10.2.0.0/8” แต่ตามที่เข้าใจ ถ้าเป็น /8 ก็จะล็อกแค่ octet แรก และช่วงจะเป็น 10.0.0.0~10.255.255.255
    ถ้าอย่างนั้นก็ไม่รู้ว่าเลข 2 ตรงนี้สำคัญยังไง และถ้าเลข 2 สำคัญ ก็ควรเขียนเป็น /16 ไม่ใช่หรือ
    เมื่อดูจากแหล่งที่มาและความมั่นใจของตัวเองเรื่องสัญกรณ์นี้ ก็สงสัยว่าผู้เชี่ยวชาญอาจอ่านความหมายอื่นออกหรือเปล่า และถ้าเป็นแค่พิมพ์ผิด ก็ขอโทษที่ดูจู้จี้เกินไป

    • เป็นข้อสังเกตที่ถูกต้อง และเป็น การพิมพ์ผิด
      ควรเป็น 10.0.0.0/8 และได้แก้ในบล็อกแล้ว พร้อมแก้ความสับสนเรื่องหน่วยความจำของ P3dn.24xlarge ด้วย
    • น่าจะพิมพ์ผิด แต่ก็เป็นไปได้ว่าใน subnet 10.0.0.0~10.255.255.255 นั้น เครื่อง EC2-Classic ถูกจัดสรรเฉพาะช่วง 10.2.0.0~10.2.255.255 และกัน 10.x.0.0~10.x.255.255 ไว้สำหรับบริการอื่น
    • 10.2.0.0/8 ไม่ใช่ subnet mask ที่ถูกต้อง จึงมีโอกาสสูงว่าจะเป็นการพิมพ์ผิด
      subnet ที่ใหญ่ที่สุดที่สร้างได้โดยเริ่มจาก 10.2.0.0 คือ 10.2.0.0/15
    • ใช่ และ /8 คือ 10.0.0.0/8
      คิดว่ามันอาจไม่ใช่พิมพ์ผิด แต่เป็นวิธีเขียนแปลก ๆ เพื่อหมายถึง 10.0.0.0/8 ที่ยกเว้น 10.1.0.0/16 ก็ได้
    • มองว่า 10.2.0.0/16 โดยพื้นฐานแล้วเป็นส่วนหนึ่งของช่วงที่อยู่เครือข่ายส่วนตัว 10.0.0.0/8
      ตีความว่าผู้เขียนหมายถึงเครื่องได้รับที่อยู่ 10.2/16 แต่ก็ยังสามารถ route ไปยังบริการหรือเครื่อง AWS ใน subnet 10/8 อื่น ๆ เช่น 10.1/16 ได้

  • แม้จะบอกว่า “ความซับซ้อนของการจัดการโครงสร้างพื้นฐาน การซื้อฮาร์ดแวร์ใหม่ การอัปเกรดซอฟต์แวร์ และการเปลี่ยนดิสก์ที่เสียถูก abstract ออกไป” แต่สิ่งที่เข้ามาแทนก็เป็นแค่ ความซับซ้อนของ AWS
    ก่อนมี AWS ก็ไม่จำเป็นต้องซื้อฮาร์ดแวร์เองหรือเปลี่ยนดิสก์ที่เสียเองอยู่แล้ว บริษัทเว็บโฮสติ้งทำให้

    • การบอกว่า “บริษัทเว็บโฮสติ้งทำให้” เป็นการย่อเรื่องให้เรียบง่ายเกินไป
      แน่นอนว่าไม่ได้เดินเข้า data center ไปเปลี่ยนดิสก์เอง แต่กระบวนการนั้นต่างจากวิธีที่ได้จาก AWS มาก
      ทุกวันนี้ก็ยังมีบริษัทเว็บโฮสติ้งจำนวนมากที่ดำเนินงานแบบเดิม แต่การที่ผู้คนชอบบริการอย่าง AWS ก็มีเหตุผลของมัน
    • ใช่ แต่โดยทั่วไปแล้ว a) ต้องตรวจพบและวินิจฉัยเอง และ b) ต้องรอให้ผู้ให้บริการโฮสติ้งยอมรับและเปลี่ยนให้ ซึ่งอาจใช้เวลาตั้งแต่หลายชั่วโมงถึงหลายสัปดาห์
      มันต่างมากจากความสามารถในการเปิดเซิร์ฟเวอร์ใหม่บนฮาร์ดแวร์อีกชุดได้ด้วยการกดปุ่มไม่กี่ครั้ง
    • ถ้าความต้องการไม่ได้ใหญ่โต AWS ก็ไม่จำเป็นต้องซับซ้อน และใช้ของอย่าง Lightsail ก็ได้
      ถ้าต้องการแค่ VPS ก็ใช้ VPS ไป โดยส่วนตัวแล้วกรณีนั้นชอบ Hetzner มากกว่า
      แต่ถ้าต้องรองรับความต้องการขององค์กรขนาดใหญ่ AWS ก็ย่อมต้องซับซ้อน
      อีกอย่าง อินเทอร์เฟซเปิด EC2 ในคอนโซล AWS ดีขึ้นมากจริง ๆ และช่วยจัดการความซับซ้อนไปได้ไม่น้อย
    • เมื่อดูว่าไม่มีบริษัทเว็บโฮสติ้งรายเดียวที่เติบโตได้เท่า AWS หรือ Azure ก็ค่อนข้างชัดเจนว่าอุตสาหกรรมเต็มใจรับความซับซ้อนแบบไหน
      Oracle เอง แม้จะมีชื่อเสียงสารพัดอย่าง ก็ยังทำเงินได้หลายหมื่นล้านดอลลาร์อยู่

  • ระหว่างที่กำลังอ่านประโยคว่า “การยุติบริการไม่ใช่สิ่งที่ AWS ทำกัน และค่อนข้างเกิดขึ้นได้ยาก” พอดีกำลังพักจากงาน epic ในการย้ายของของเราออกจาก OpsWorks ก่อนปิดบริการในเดือนพฤษภาคม

    • จากประสบการณ์ของผม OpsWorks เป็นบริการที่ยอดเยี่ยม และน่าเสียดายจริง ๆ ที่ต้องปิดตัว
      ก่อนที่ Kubernetes และ Terraform จะออกมา ผมเคยสร้างคลัสเตอร์หลายชุดด้วย OpsWorks
      แต่จากที่ได้ยินจากคนของ AWS ว่าภายในดูแลรักษาได้ไม่ค่อยดี และเบื้องหลังค่อนข้างเละเทะ ก็เลยไม่น่าแปลกใจที่บริการนี้จะถูกยุติในตอนนี้ ซึ่งภูมิทัศน์ด้านเทคโนโลยีเปลี่ยนไปมากจากตอนที่บริการเพิ่งเปิดตัว
      RIP OpsWorks
    • ตรงนี้อ่านแล้วค่อนข้างแปลก
      หัวข้อคือ “เราจะทำ X” แต่เนื้อหาอ่านเหมือน “เราไม่ได้ทำ X ตรงนี้” ตอนแรกเลยไม่ค่อยเข้าใจว่าบทความต้องการจะสื่ออะไร
    • ผมก็รู้สึกแบบเดียวกัน เพราะกำลังจัดการผลพวงจากการย้ายอะไรบางอย่างออกจาก AWS Data Pipeline อยู่เหมือนกัน
      บริการนั้นเข้าสู่ “โหมดบำรุงรักษา” แล้ว และต้นปีนี้ก็เอาการเข้าถึงผ่านคอนโซลออกไปด้วย

  • ข้อความช่วงที่ว่า “เมื่อ 10 ปีก่อน ในคีย์โน้ต re:Invent ปี 2013 เราบอกว่าอยากรองรับทั้ง workload ของวันนี้และ workload ของวันพรุ่งนี้ และความทุ่มเทต่อ Classic คือหลักฐานที่ดีที่สุดของเรื่องนั้น” นี่แหละคือ เหตุผลที่องค์กรต่าง ๆ ไว้วางใจ AWS
    ทีม EC2 ดูแลให้ Classic ทำงานได้ดีต่อไปจนกว่าอินสแตนซ์ทั้งหมดจะถูกปิดหรือย้ายออก และผมคิดว่าสิ่งแบบนี้แหละที่สร้างความไว้วางใจ

  • ยังจำได้ว่าตอนทำงานที่ Serif เราต้องการเว็บโฮสติ้งสำหรับเว็บไซต์โซเชียลมีเดียใหม่ที่จะผสานกับซอฟต์แวร์เดสก์ท็อปทำ scrapbook
    ตอนนั้นก็เหมือนทุกที มีเทคโนโลยีใหม่แวววาวเต็มไปหมด หนึ่งในนั้นคือ Microsoft Silverlight และเราใช้ “Deep Zoom” บนเว็บไซต์ เพื่อให้ผู้ใช้ซูมเข้าไปดูรายละเอียดของ scrapbook ที่เผยแพร่แล้วได้ง่าย
    อีกเทคโนโลยีใหม่คือ AWS และ EC2 เพิ่งเปิดตัวได้ไม่นาน การที่กดปุ่มเดียวก็เปิดอินสแตนซ์ในสหรัฐฯ ไอร์แลนด์ และอัมสเตอร์ดัมได้ และถ้าดับไปก็กดปุ่มอีกครั้งเพื่อเปิดใหม่ได้นั้นน่าตื่นเต้นทีเดียว
    เช่นเดียวกับตอนนี้ ตอนนั้นก็มีความซับซ้อนจำนวนมากซ่อนอยู่หลัง UI ที่ดูเรียบง่าย และเราต้องเรียนรู้ storage หลายประเภท รวมถึงว่าแบบไหนเป็นแบบถาวร
    อินสแตนซ์ EC2 ยุคแรก ๆ ดูเหมือนจะไม่ได้เสถียรเท่าตอนนี้ และเราเคยสูญเสียไปจริง ๆ หนึ่งหรือสองตัวจนต้องสร้างใหม่ เลยทำ snapshot ไว้เยอะมาก
    ตอนนั้นยังไม่มี infrastructure as code หรือ DevOps แต่เราสร้างคลัสเตอร์ high availability ของเราเอง โดยมีวิศวกรที่ทำงานด้วยกันเขียนซอฟต์แวร์ด้วย C++ ตั้งแต่ต้น เพื่อคอยเฝ้าดูฐานข้อมูลบนอินสแตนซ์ EC2 หลายตัวและทำให้คลัสเตอร์ยังทำงานอยู่
    ตอนนั้นยังไม่มี cloud architect ด้วยซ้ำ เราเลยไม่ค่อยรู้ว่ากำลังทำอะไร หรืออะไรคือแนวทางที่ฉลาด แต่เทคโนโลยีทำงานได้ดีมาก และหลังผ่านช่วงลองผิดลองถูกตอนต้นไปแล้ว เราก็สร้างชุมชนอินเทอร์เน็ตที่ค่อนข้างคึกคักขึ้นมาได้
    เว็บไซต์ทำด้วย PHP และ MySQL แปลง XML ที่สร้างจากข้อมูลเชิงสัมพันธ์ใน SQL เป็น HTML ด้วย XSLT ใช้ JavaScript ไม่มาก มีประมาณ jQuery
    การ deploy น่าจะเป็นการอัปโหลดด้วย FileZilla แล้วซอฟต์แวร์คลัสเตอร์ C++ ก็ทำสำเนาไฟล์ที่อัปโหลดไปยังอินสแตนซ์ EC2 ใน availability zone อื่น ๆ
    มองย้อนกลับไป เราคงไม่จำเป็นต้องมีเซิร์ฟเวอร์ใน availability zone สามแห่งก็ได้ แต่งานนั้นสนุกมาก และเป็นช่วงเวลาดี ๆ ที่ทำให้ได้รู้จัก AWS เป็นครั้งแรก

    • จำยุคนั้นได้เลย
      ตอนนั้น AWS ยังไม่มีชั้นฐานข้อมูล เราเลยใช้อินสแตนซ์ที่ผูกกับ Elastic Block Store เพื่อความคงทนของข้อมูล

  • ตอนนี้สิ่งที่ต้องการก็แค่ให้รองรับ งบประมาณแบบคงที่ จริง ๆ แทนความเป็นไปได้ที่ค่าบัตรเครดิตจะพุ่งกระฉูด
    Microsoft ทำอยู่ และเท่าที่จำได้ Google ก็เคยทำด้วย แต่ไม่รู้ว่าทำไม Amazon ถึงไม่ทำ
    ผมรอเรื่องนี้มาเกือบ 20 ปีแล้วเหมือนกัน

    • ถ้าทำแบบนั้น ระบบนิเวศของ ที่ปรึกษาเพิ่มประสิทธิภาพค่าใช้จ่ายคลาวด์ ค่าตัวแพง ๆ ที่แทบไม่ทำอะไรมากไปกว่าการเปิดสวิตช์ไม่กี่ตัวในคอนโซล AWS ก็คงพังลง
    • ทำแบบนั้นแล้วจะได้เงินน้อยลง และลูกค้า AWS ก็ไม่ได้อ่อนไหวต่อราคาขนาดนั้น
    • ไม่เหมือนกันเสียทีเดียว แต่สามารถตั้งค่า การแจ้งเตือนการเรียกเก็บเงิน และการแจ้งเตือนงบประมาณได้

  • ส่วนตัวแล้ว ผมอยากให้ AWS ตัดสินใจไปเลยว่าใส่ IPv6 ให้ Classic แล้วเดินหน้าต่อ
    น่าขันที่ post-Classic ดูเหมือนเป็นการถอยหลัง และคล้ายกับโครงสร้างพื้นฐานที่เราต้องจัดการก่อนยุคคลาวด์มากขึ้นมาก
    ของใหม่ ๆ ที่สร้างส่วนใหญ่ผมวางไว้บน Cloudflare เลยแทบไม่ต้องคิดถึง subnet หรือ VPC แล้ว

    • วิธีขยายธุรกิจ EC2 ไม่ใช่แค่การดึงสตาร์ทอัพเกิดใหม่เท่านั้น แต่คือการดึงองค์กรเดิม ๆ เข้าสู่คลาวด์
      องค์กรเหล่านี้ล้วนต้องผสานกับเครือข่ายภายในองค์กร จึงจำเป็นต้องใช้ VPC

  • ถ้าผมเข้าใจถูก ก็สงสัยว่าอินสแตนซ์ Classic ทั้งหมดถูกย้ายไปยังประเภทที่ทันสมัยกว่าโดยไม่ต้องให้เจ้าของบัญชีเข้ามาเกี่ยวข้องหรือเปล่า
    และสงสัยด้วยว่าระหว่างนั้นมีการรีบูตหรือไม่ หรือจัดการด้วย live migration
    เพราะการดึง live migration ออกมาจากแพลตฟอร์ม virtualization ที่เดิมไม่ได้ออกแบบมาเผื่อเรื่องแบบนั้นเป็นเรื่องยาก
    ยังสงสัยด้วยว่าการตั้งค่าเครือข่ายแบบเดิมยังถูกจำลองอยู่หรือไม่ หรือแอปพลิเคชันของลูกค้าบางส่วนอาจพังไปแล้วหรือเปล่า

    • ไม่ใช่ การย้ายต้องอาศัยการดำเนินการจากเจ้าของบัญชี
      รายละเอียดอยู่ที่นี่: https://aws.amazon.com/blogs/aws/ec2-classic-is-retiring-her...
      ดูเหมือนว่า AWS ใช้ทั้งเวลา กำลังคน และเงินเพื่อย้ายลูกค้าออกจาก EC2-Classic และยังพยายามไม่น้อยในการทำให้กระบวนการเป็นอัตโนมัติและเจ็บปวดน้อยลง
      ตัวอย่าง: https://repost.aws/knowledge-center/ssm-migrate-ec2classic-v...
      เครือข่ายแบบเดิมเปลี่ยนจากโมเดลที่ทุกคนอยู่ในซับเน็ตเดียวกัน ไปเป็นโมเดลที่แต่ละคนได้ซับเน็ตของตัวเอง ดังนั้นแอปพลิเคชันของลูกค้าอาจพังได้จริง
      คนเราบางทีก็ทำสิ่งที่ไม่ค่อยฉลาดนักด้วยเหตุผลที่พอฟังขึ้น เช่น hardcode IP address ไว้ใน /etc/hosts ตอน nameserver ล่ม แล้วลืมย้อนกลับทีหลัง
      การทำ migration แบบนี้ให้ดีต้องมีทั้งไม้แข็งและไม้นวม
      ไม้แข็งคือสุดท้ายจะหยุดบริการและปฏิเสธการให้บริการ ส่วนไม้นวมคือ automation, การแจ้งเตือนซ้ำ ๆ ว่าต้องมี maintenance window, คำแนะนำที่ชัดเจน และเหนือสิ่งอื่นใดคือความตั้งใจที่จะคุยกับลูกค้าจริง ๆ และตอบสนองต่อพวกเขา
    • ไม่ใช่แค่ต้อง restart เท่านั้น แต่ยังต้อง ปรับโครงสร้างเครือข่ายใหม่ ด้วย
      อย่างไรก็ตาม AWS ให้เวลาผู้คนทำเรื่องนั้นหลายปี และถ้าจำเป็นก็เข้าไปช่วยผู้ใช้ทุกคน
    • ไม่ชัดเจน แต่ตามการตีความของผม ดูเหมือนว่า AWS ติดต่อเจ้าของบัญชีทุกคนและโน้มน้าวให้ migrate ด้วยวิธีใดวิธีหนึ่ง แล้วเมื่อทุกคนย้ายหมดจึงปิดบริการ
      อาจมีส่วนลดหรือการขู่ว่าจะปิดบริการด้วยก็ได้
      น่าทึ่งที่ไม่มีอินสแตนซ์แม้แต่ตัวเดียวที่เจ้าของลืมหรือปฏิเสธที่จะดำเนินการ เลยน่าสนใจจริง ๆ ว่าทำได้อย่างไร
      บัตรเครดิตหมดอายุอาจเป็นกุญแจสำคัญก็ได้ เพราะอาจทำให้บัญชีที่ถูกลืมส่วนใหญ่ถูกปิดใช้งานโดยอัตโนมัติ
    • ผมไม่รู้รายละเอียดของ migration ครั้งนี้โดยเฉพาะ แต่เมื่อก่อนเคยรัน VM tier ราคาถูกไว้หลายปี และสุดท้าย AWS ส่งอีเมลมาว่าจะปิดด้วยเหตุผลด้าน maintenance
      เดาว่าน่าจะเป็นวิธีคล้าย ๆ กัน
      VM ย้ายแบบอัตโนมัติได้ยากถ้าไม่ได้ตั้งค่าไว้เป็นพิเศษให้ย้ายได้ เช่น ลำดับอุปกรณ์บนบัส PCIe อาจเปลี่ยน และ machine ID หลายอย่างอย่าง MAC address ก็อาจเปลี่ยนด้วย
      ถ้าไม่รับประกันว่า VM จะไม่ได้รับผลกระทบจากการเปลี่ยนแปลงเหล่านี้ ก็มีโอกาสสูงที่จะเกิดปัญหาหลังย้าย

  • ระดับการสนับสนุน ขนาดนี้คือสิ่งที่บริษัทซอฟต์แวร์ทุกแห่งควรมุ่งไปให้ถึง
    นี่แหละคือสิ่งที่ลูกค้าองค์กรอยากเห็น และเป็นสิ่งที่พวกเขายอมจ่ายเงินให้

    • เหตุผลที่บริษัทที่ผมทำงานด้วยยังเลือก AWS ต่อไป ไม่ใช่เพราะฟีเจอร์ที่ให้มาดีกว่า แต่เพราะ การสนับสนุนดีกว่ามาก