Cara Mendapat $1 Juta Dengan AWS dalam Satu Tahun

Jika anda terjumpa halaman ini memikirkan anda akan menjadi kaya dengan skim cepat kaya, saya minta maaf untuk mengecewakan anda. Artikel ini lebih suka bercakap tentang cara mengurangkan bil kos awan anda sebanyak $1 juta. Dengan melakukan itu, anda pada dasarnya akan menjana pendapatan tambahan juta dolar — yang boleh anda belanjakan untuk membeli kursus dalam talian saya tentang cara menjadi kaya dengan AWS ( pautan ke kursus di sini ).

Kos awan sering diabaikan dan tidak diambil kira pada permulaan projek Syarikat. Tinjauan HashiCorp 2021 mendapati hampir 40% syarikat membelanjakan kos awan secara berlebihan pada 2021 [ 1 ]. Pada tahun 2023, hampir semua syarikat (94%) mengakui bahawa mereka membazir wang di awan [ 1 ] dan sekurang-kurangnya 30% daripada kos awan telah dibazirkan [ 2 ]. Perbelanjaan awan hampir $500 bilion pada 2022 — oleh itu kita bercakap tentang $150 bilion dibazirkan setahun!!

Ini bukan sahaja kebimbangan terhadap pendapatan yang terlepas tetapi juga amalan kemampanan yang lemah. $150 bilion tenaga terbuang!

Penemuan ini melibatkan perusahaan besar dan juga yang lebih kecil, daripada kematangan awan tinggi kepada kematangan awan rendah. Ia merujuk kepada AWS, tetapi prinsip yang sama boleh digunakan untuk mana-mana pembekal awan lain. Jadi, jika mana-mana bahagian tugas anda berada di awan, maka artikel ini adalah untuk anda.

Saya bercakap dari perspektif jurutera data, tetapi pembelajaran yang sama boleh digunakan untuk amalan kejuruteraan perisian lain.

Jom selami.

Apakah yang diperlukan untuk membelanjakan $1 juta dalam kos awan dalam setahun?

Bil awan jenis ini biasanya terhad kepada perusahaan yang sangat besar yang beroperasi secara global dengan berjuta-juta pelanggan.

Untuk memberi anda idea, bil awan $1 juta boleh dihasilkan daripada pemprosesan kerja Spark ETL ~1.5Tb sejam 24x7 selama 365 hari setahun. Contoh lain mungkin aplikasi yang menerima berbilion-bilion permintaan sehari dari berbilang lokasi di dunia.

Dalam perusahaan besar, terdapat ratusan aplikasi pada saiz ini — menghasilkan kontrak berbilion dolar dengan penyedia awan. Sebagai contoh, Airbnb mempunyai komitmen untuk membelanjakan $1.2 bilion pada sumber awan selama lima tahun pada akhir 2019 [3 ].

Di Expedia kami mengurangkan kos untuk pemprosesan data ETL berharga $1.1 juta dolar setahun kepada hanya $100,000 setahun dengan melaksanakan amalan pengoptimuman. Itu 91% pengurangan kos!!

Tidak semua syarikat mempunyai aplikasi bersaiz besar tetapi bayangkan mengurangkan kos awan anda sebanyak 90% hanya untuk satu aplikasi atau untuk keseluruhan syarikat anda.

Bagaimana kita mula menabung?

LANGKAH 1: Cabar andaian reka bentuk anda

Pergi dan dapatkan senarai aplikasi anda yang paling mahal dan cabar andaian reka bentuk anda .

• Adakah anda membina aplikasi yang mempunyai ketersediaan 99.999% dan kependaman sub-milisaat tetapi secara realistik pengguna akan cukup baik dengan ketersediaan 99% dan beratus-ratus kependaman milisaat?
• Adakah anda membuat set data dengan berbilion baris tetapi pengguna hanya akan menggunakan pengagregatan beberapa langkah?
• Adakah anda mendaratkan data dalam masa nyata tetapi data hanya dianalisis sekali sehari?
• Adakah anda memuatkan semula cache setiap 10 saat tetapi ia hanya benar-benar berubah sepanjang hari?

Semua soalan ini kembali kepada soalan yang paling penting: bagaimanakah aplikasi itu akan digunakan? Apakah nilai perniagaan untuk ia wujud? Bagaimanakah aplikasi membantu kami mencapai matlamat tertentu?

Sudah tentu, semua jawapan ini selalunya tidak jelas pada permulaan projek; tetapi itulah sebabnya reka bentuk harus sentiasa menjadi proses berulang — membenarkan perubahan berlaku dengan lancar yang mungkin. Jurutera harus menerima evolusi dan perubahan, menyelaraskan pembangunan aplikasi dengan impak.

LANGKAH 2: Perhalusi sumber infrastruktur anda mengikut keperluan anda

Langkah kedua terdiri daripada menyediakan aplikasi dengan sumber yang betul dan menyesuaikannya dengan infrastruktur yang betul.

Sebagai seorang jurutera, ketahui cara kos awan dikira. Sebagai contoh, AWS menyediakan contoh spot, di mana anda boleh membida untuk harga kluster — ini amat berguna jika anda mempunyai aplikasi yang tahan terhadap kesalahan dan fleksibel. Gunakannya jika anda boleh — AWS menuntut pengurangan kos sehingga 90% [ 4 ].

Beberapa pertimbangan lain yang mungkin anda ingin atasi ialah:

• Adakah anda melayani pelanggan secara global atau hanya dalam satu kawasan geografi? Adakah anda benar-benar memerlukan infrastruktur anda untuk hidup di seluruh dunia atau bolehkah anda menyediakannya lebih dekat dengan pangkalan pelanggan anda?
• Adakah anda terlalu memperuntukkan kejadian kelompok anda? Cuba pastikan ada kapasiti yang mencukupi untuk mengendalikan beban puncak tanpa kos yang tidak perlu. Gunakan penskalaan automatik untuk melaraskan sumber secara dinamik berdasarkan permintaan sebenar, mengelakkan lebihan bayaran untuk sumber terbiar.
• Jika anda bekerja dengan data dan Spark, pastikan anda memahami konsep dan penalaan Spark! Jika anda tidak, lihat sumber berikut [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ].

LANGKAH 3: Gunakan tika AWS Graviton

Terdapat sedikit atau tiada kelemahan dalam menggunakan tika AWS Graviton. AWS telah melabur banyak dalam mencipta pemproses yang paling kos efektif. Anda boleh mendapat sehingga 40% pengurangan dalam perbelanjaan awan hanya dengan menukar daripada pemproses berasaskan intel kepada pemproses berasaskan ARM [ 10 ].

Satu-satunya kaveat untuk ini ialah aplikasi anda perlu serasi dengan pemproses berasaskan ARM yang dijalankan oleh Graviton. Jika anda berurusan dengan perkhidmatan terurus seperti RDS atau OpenSearch maka tiada kerumitan sama sekali dalam penukaran — AWS menangani keserasian OS dan aplikasi yang mendasari. Jika anda membina aplikasi anda sendiri, maka anda mungkin perlu menyusun semula pakej bergantung pada bahasa yang anda gunakan — Java dan bahasa lain tidak memerlukan perubahan manakala Python memerlukan sedikit perhatian.

LANGKAH 4: Pantau perbelanjaan kos anda dan didik tentang kesedaran kos

Akhir sekali, jangan lupa untuk terus memantau kos anda untuk kemuncak dan kejutan yang tidak dijangka. Kos pada hari 0 permohonan anda akan berbeza daripada kos pada hari 170. Pastikan anda menjejaki perubahan dan anda memahami sebab perubahan itu berlaku: adakah ia menyusun kos storan s3 atau ia hanya sekali sahaja spike?

Sediakan makluman dan buku panduan operasi yang diperlukan !

Yang penting, laksanakan teg peruntukan kos untuk menjejaki perbelanjaan mengikut jabatan, projek atau persekitaran. Elakkan risiko mencipta paya data di mana kos tidak dapat dikesan atau memerlukan perjalanan panjang merentasi sistem log yang berbeza. Ia sepatutnya cepat dan mudah untuk kembali kepada mana-mana kos permohonan yang diberikan.

Fikiran akhir

Di mana sahaja anda bekerja, mengimbangi penyampaian ciri baharu dengan pengoptimuman ciri semasa adalah sukar. Siapa yang tidak didesak untuk menyampaikan ciri unik baharu pada kelajuan cahaya.

Walau bagaimanapun, adalah penting bagi kedua-dua jurutera dan pengurus untuk membuat keputusan yang disengajakan dan proaktif tentang projek semasa mereka, mengurus risiko dan peluang dengan berkesan.