หากคุณบังเอิญเจอหน้านี้แล้วคิดว่าจะรวยได้อย่างรวดเร็วด้วยแผนการรวยอย่างรวดเร็ว ฉันขอโทษที่ทำให้คุณผิดหวัง บทความนี้จะพูดถึงวิธีลดค่าใช้จ่ายด้านคลาวด์ลง 1 ล้านดอลลาร์ ซึ่งคุณจะสร้างรายได้เพิ่มขึ้นเป็นล้านดอลลาร์ ซึ่งคุณสามารถนำเงินนั้นไปซื้อหลักสูตรออนไลน์เกี่ยวกับวิธีรวยได้อย่างรวดเร็วด้วย AWS ของฉันได้ ( ) ลิงก์ไปยังหลักสูตรที่นี่ ต้นทุนด้านคลาวด์มักถูกมองข้ามและไม่ได้รับการคำนึงถึงในช่วงเริ่มต้นของโครงการของบริษัทต่างๆ การสำรวจของ HashiCorp ในปี 2021 พบว่าบริษัทเกือบ 40% ใช้จ่ายด้านคลาวด์เกินตัวในปี 2021 [ ] ในปี 2023 บริษัทเกือบทั้งหมด (94%) ยอมรับว่ากำลังสิ้นเปลืองเงินไปกับคลาวด์ [ ] และต้นทุนด้านคลาวด์อย่างน้อย 30% ก็สูญเปล่าไป [ ] การใช้จ่ายด้านคลาวด์มีมูลค่าเกือบ 500 พันล้านดอลลาร์ในปี 2022 ดังนั้นเราจึงพูดถึงการสูญเปล่า 150 พันล้านดอลลาร์ต่อปี!! 1 1 2 นี่ไม่เพียงเป็นความกังวลเรื่องรายได้ที่สูญเสียไปเท่านั้น แต่ยังมีแนวทางปฏิบัติด้านความยั่งยืนที่ไม่ดีอีกด้วย พลังงานที่สูญเปล่ามูลค่า 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 หรือเป็นเพียงค่าใช้จ่ายที่เพิ่มขึ้นครั้งเดียว ! ตั้งค่าการแจ้งเตือนและคู่มือการใช้งานที่จำเป็น สิ่งสำคัญคือ ให้นำแท็กการจัดสรรต้นทุนไปใช้งานเพื่อติดตามการใช้จ่ายตามแผนก โปรเจ็กต์ หรือสภาพแวดล้อม หลีกเลี่ยงความเสี่ยงในการสร้างข้อมูลล้นหลามที่ไม่สามารถติดตามต้นทุนได้หรือต้องเดินทางไกลในระบบบันทึกข้อมูลที่แตกต่างกัน ควรจะต้องรวดเร็วและง่ายดายในการย้อนกลับไปยังต้นทุนแอปพลิเคชันที่กำหนด ความคิดสุดท้าย ไม่ว่าคุณจะทำงานที่ไหน การทำให้การส่งมอบฟีเจอร์ใหม่ ๆ เข้ากับการปรับปรุงฟีเจอร์ที่มีอยู่ให้เหมาะสมนั้นเป็นเรื่องยาก ใครบ้างที่ไม่เคยถูกกดดันให้ส่งมอบฟีเจอร์แปลกใหม่ ๆ อย่างรวดเร็ว อย่างไรก็ตาม สิ่งสำคัญคือทั้งวิศวกรและผู้จัดการจะต้องตัดสินใจอย่างรอบคอบและเชิงรุกเกี่ยวกับโครงการปัจจุบันของตนเอง รวมถึงการจัดการความเสี่ยงและโอกาสอย่างมีประสิทธิภาพ
