paint-brush
วิธีสร้างรายได้ 1 ล้านเหรียญสหรัฐด้วย AWS ภายใน 1 ปีโดย@gianpicolonna
65,525 การอ่าน
65,525 การอ่าน

วิธีสร้างรายได้ 1 ล้านเหรียญสหรัฐด้วย AWS ภายใน 1 ปี

โดย Gianpi Colonna5m2024/04/28
Read on Terminal Reader
Read this story w/o Javascript

นานเกินไป; อ่าน

ลดต้นทุนคลาวด์ AWS ของคุณลง 90%! เรียนรู้ 4 ขั้นตอนในการเพิ่มประสิทธิภาพการใช้จ่าย: ท้าทายสมมติฐาน ปรับแต่งทรัพยากร ใช้อินสแตนซ์ Graviton และตรวจสอบการใช้งาน

Company Mentioned

Mention Thumbnail
featured image - วิธีสร้างรายได้ 1 ล้านเหรียญสหรัฐด้วย AWS ภายใน 1 ปี
Gianpi Colonna HackerNoon profile picture
0-item
1-item


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



ต้นทุนด้านคลาวด์มักถูกมองข้ามและไม่ได้รับการคำนึงถึงในช่วงเริ่มต้นของโครงการของบริษัทต่างๆ การสำรวจของ HashiCorp ในปี 2021 พบว่าบริษัทเกือบ 40% ใช้จ่ายด้านคลาวด์เกินตัวในปี 2021 [ 1 ] ในปี 2023 บริษัทเกือบทั้งหมด (94%) ยอมรับว่ากำลังสิ้นเปลืองเงินไปกับคลาวด์ [ 1 ] และต้นทุนด้านคลาวด์อย่างน้อย 30% ก็สูญเปล่าไป [ 2 ] การใช้จ่ายด้านคลาวด์มีมูลค่าเกือบ 500 พันล้านดอลลาร์ในปี 2022 ดังนั้นเราจึงพูดถึงการสูญเปล่า 150 พันล้านดอลลาร์ต่อปี!!


นี่ไม่เพียงเป็นความกังวลเรื่องรายได้ที่สูญเสียไปเท่านั้น แต่ยังมีแนวทางปฏิบัติด้านความยั่งยืนที่ไม่ดีอีกด้วย พลังงานที่สูญเปล่ามูลค่า 150,000 ล้านดอลลาร์!


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


ฉันพูดจากมุมมองของวิศวกรข้อมูล แต่การเรียนรู้แบบเดียวกันนี้สามารถนำไปใช้กับแนวทางวิศวกรรมซอฟต์แวร์อื่นๆ ได้

มาดำดิ่งลงไปกันเลย


ต้องใช้เงินเท่าใดจึงจะใช้จ่ายด้านคลาวด์ 1 ล้านเหรียญสหรัฐฯ ในแต่ละปี?

บิลคลาวด์ประเภทนี้โดยปกติจะจำกัดเฉพาะกับองค์กรขนาดใหญ่มากที่ดำเนินงานทั่วโลกและมีลูกค้าหลายล้านราย


เพื่อให้คุณเห็นภาพได้ ค่าใช้จ่ายด้านคลาวด์ 1 ล้านเหรียญสหรัฐอาจเกิดจากการประมวลผลงาน Spark ETL ที่ ~1.5Tb ต่อชั่วโมง ตลอด 24 ชั่วโมง 7 วันต่อสัปดาห์ ตลอดทั้งปี ตัวอย่างอื่นอาจเป็นแอปพลิเคชันที่ได้รับคำขอหลายพันล้านรายการต่อวันจากสถานที่ต่างๆ ทั่วโลก


ในองค์กรขนาดใหญ่ มีแอปพลิเคชันหลายร้อยรายการที่มีขนาดนี้ ส่งผลให้มีการทำสัญญากับผู้ให้บริการระบบคลาวด์เป็นมูลค่าหลายพันล้านดอลลาร์ ตัวอย่างเช่น Airbnb มีข้อผูกพันที่จะใช้จ่ายเงิน 1.2 พันล้านดอลลาร์สำหรับทรัพยากรระบบคลาวด์เป็นเวลา 5 ปี เมื่อสิ้นปี 2019 [3 ]


ที่ Expedia เราลดต้นทุนของ ETL สำหรับการประมวลผลข้อมูลซึ่งอยู่ที่ 1.1 ล้านดอลลาร์ต่อปี เหลือเพียง 100,000 ดอลลาร์ต่อปี โดยการนำแนวทางการเพิ่มประสิทธิภาพมาใช้ ซึ่งนั่นหมายถึงการลดต้นทุนได้ถึง 91%!!


ไม่ใช่ว่าบริษัททั้งหมดจะมีแอปพลิเคชันขนาดใหญ่เช่นนี้ แต่ลองจินตนาการว่าคุณสามารถลดค่าใช้จ่ายด้านคลาวด์ลงได้ถึง 90% เพียงสำหรับแอปพลิเคชันเดียวหรือสำหรับทั้งบริษัทของคุณดูสิ



เราจะเริ่มต้นการออมเงินอย่างไร?

ขั้นตอนที่ 1: ท้าทายสมมติฐานการออกแบบของคุณ

ไปรับรายการแอปพลิเคชันที่มีราคาแพงที่สุดของคุณและ ท้าทายสมมติฐานการออกแบบของคุณ

  • คุณกำลังสร้างแอปพลิเคชันที่มีความพร้อมใช้งาน 99.999% และมีเวลาแฝงต่ำกว่ามิลลิวินาที แต่ในทางปฏิบัติ ผู้ใช้ก็พอใจแล้วหากมีความพร้อมใช้งาน 99% และมีเวลาแฝงหลายร้อยมิลลิวินาทีใช่หรือไม่
  • คุณกำลังสร้างชุดข้อมูลที่มีหลายพันล้านแถวแต่ผู้ใช้จะใช้การรวมข้อมูลบางส่วนของการวัดเท่านั้นใช่หรือไม่
  • คุณกำลังลงจอดข้อมูลแบบเรียลไทม์แต่ข้อมูลได้รับการวิเคราะห์เพียงครั้งเดียวต่อวันเท่านั้นใช่หรือไม่?
  • คุณรีเฟรชแคชทุก ๆ 10 วินาที แต่กลับเปลี่ยนแปลงแค่ข้ามวันเท่านั้นใช่หรือไม่


คำถามเหล่านี้ล้วนเกี่ยวข้องกับคำถามที่สำคัญที่สุด นั่นคือ แอปพลิเคชันจะถูกใช้ได้อย่างไร มูลค่าทางธุรกิจของแอปพลิเคชันจะเป็นอย่างไร แอปพลิเคชันช่วยให้เราบรรลุเป้าหมายที่กำหนดได้อย่างไร


แน่นอนว่าคำตอบเหล่านี้ มักจะไม่ชัดเจนในช่วงเริ่มต้นของโครงการ แต่ด้วยเหตุนี้ การออกแบบจึงควรเป็นกระบวนการแบบวนซ้ำเสมอ เพื่อให้การเปลี่ยนแปลงเกิดขึ้นได้อย่างราบรื่นที่สุด วิศวกรควรยอมรับวิวัฒนาการและการเปลี่ยนแปลง โดยจัดแนวทางการพัฒนาแอปพลิเคชันให้สอดคล้องกับผลกระทบ


ขั้นตอนที่ 2: ปรับแต่งทรัพยากรโครงสร้างพื้นฐานให้เหมาะกับความต้องการของคุณ

ขั้นตอนที่สองประกอบด้วยการจัดเตรียมทรัพยากรที่เหมาะสมให้กับแอปพลิเคชันและปรับให้เข้ากับโครงสร้างพื้นฐานที่เหมาะสม


ในฐานะวิศวกร คุณควรทราบถึงวิธีการคำนวณต้นทุนคลาวด์ ตัวอย่างเช่น AWS จัดเตรียมอินสแตนซ์เฉพาะจุด ซึ่งคุณสามารถเสนอราคาสำหรับคลัสเตอร์ได้ ซึ่งมีประโยชน์อย่างยิ่งหากคุณมีแอปพลิเคชันที่ทนทานต่อความผิดพลาดและมีความยืดหยุ่น ใช้อินสแตนซ์เหล่านี้หากทำได้ AWS อ้างว่าสามารถลดต้นทุนได้มากถึง 90% [ 4 ]


ข้อควรพิจารณาอื่นๆ ที่คุณอาจต้องการพูดถึงคือ:

  • คุณกำลังให้บริการลูกค้าทั่วโลกหรือเฉพาะในพื้นที่ทางภูมิศาสตร์เดียวเท่านั้นหรือไม่ คุณต้องการให้โครงสร้างพื้นฐานของคุณครอบคลุมทั่วโลกจริงหรือคุณสามารถตั้งค่าให้ใกล้กับฐานลูกค้าของคุณมากขึ้นได้หรือไม่
  • คุณกำลังจัดเตรียมอินสแตนซ์คลัสเตอร์ของคุณมากเกินไปหรือไม่ พยายามตรวจสอบให้แน่ใจว่ามีกำลังการผลิตเพียงพอที่จะรองรับโหลดสูงสุดโดยไม่มีค่าใช้จ่ายที่ไม่จำเป็น ใช้การปรับขนาดอัตโนมัติเพื่อปรับทรัพยากรแบบไดนามิกตามความต้องการจริง เพื่อป้องกันการจ่ายเงินเกินสำหรับทรัพยากรที่ไม่ได้ใช้งาน
  • หากคุณกำลังทำงานกับข้อมูลและ Spark โปรดแน่ใจว่าคุณเข้าใจแนวคิดและการปรับแต่ง Spark แล้ว! หากคุณไม่เข้าใจ โปรดดูทรัพยากรต่อไปนี้ [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ]

ขั้นตอนที่ 3: ใช้อินสแตนซ์ AWS Graviton

การใช้อินสแตนซ์ AWS Graviton นั้นมีข้อเสียเพียงเล็กน้อยหรือแทบไม่มีเลย AWS ได้ลงทุนอย่างหนักในการสร้างโปรเซสเซอร์ที่คุ้มต้นทุนที่สุด คุณสามารถลดค่าใช้จ่ายด้านคลาวด์ได้มากถึง 40% เพียงเปลี่ยนจากโปรเซสเซอร์ที่ใช้ Intel มาเป็นโปรเซสเซอร์ที่ใช้ ARM [ 10 ]


ข้อควรระวังประการเดียวคือแอปพลิเคชันของคุณจะต้องเข้ากันได้กับโปรเซสเซอร์ ARM ที่ Graviton ใช้ หากคุณกำลังจัดการกับบริการที่มีการจัดการ เช่น RDS หรือ OpenSearch การเปลี่ยนแปลงจะไม่มีความซับซ้อนเลย AWS จะจัดการกับระบบปฏิบัติการพื้นฐานและความเข้ากันได้ของแอปพลิเคชัน หากคุณกำลังสร้างแอปพลิเคชันของคุณเอง คุณอาจต้องคอมไพล์แพ็คเกจใหม่ขึ้นอยู่กับภาษาที่คุณใช้ Java และภาษาอื่นๆ ไม่จำเป็นต้องเปลี่ยนแปลง ในขณะที่ Python ต้องใช้ความเอาใจใส่บ้าง


ขั้นตอนที่ 4: ติดตามการใช้จ่ายต้นทุนและให้ความรู้เกี่ยวกับการตระหนักรู้ต้นทุน

สุดท้าย อย่าลืมติดตามค่าใช้จ่ายของคุณอยู่เสมอ เพื่อไม่ให้เกิดค่าใช้จ่ายที่เพิ่มขึ้นหรือลดลงอย่างไม่คาดคิด ค่าใช้จ่ายในวันที่ 0 ของการสมัครของคุณจะแตกต่างจากค่าใช้จ่ายในวันที่ 170 ตรวจสอบให้แน่ใจว่าคุณติดตามการเปลี่ยนแปลง และเข้าใจถึงสาเหตุที่เกิดการเปลี่ยนแปลงนี้: เป็นการซ้อนค่าใช้จ่ายของที่เก็บข้อมูล S3 หรือเป็นเพียงค่าใช้จ่ายที่เพิ่มขึ้นครั้งเดียว


ตั้งค่าการแจ้งเตือนและคู่มือการใช้งานที่จำเป็น !


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


ความคิดสุดท้าย

ไม่ว่าคุณจะทำงานที่ไหน การทำให้การส่งมอบฟีเจอร์ใหม่ ๆ เข้ากับการปรับปรุงฟีเจอร์ที่มีอยู่ให้เหมาะสมนั้นเป็นเรื่องยาก ใครบ้างที่ไม่เคยถูกกดดันให้ส่งมอบฟีเจอร์แปลกใหม่ ๆ อย่างรวดเร็ว


อย่างไรก็ตาม สิ่งสำคัญคือทั้งวิศวกรและผู้จัดการจะต้องตัดสินใจอย่างรอบคอบและเชิงรุกเกี่ยวกับโครงการปัจจุบันของตนเอง รวมถึงการจัดการความเสี่ยงและโอกาสอย่างมีประสิทธิภาพ