Infrastruktur Global dan Keandalan

 

Tujuan Pembelajaran

Dengan mempelajari modul ini, diharapkan Anda dapat:

• Merangkum manfaat dari infrastruktur global AWS.
• Menjelaskan konsep dasar Availability Zone.
• Menjelaskan manfaat Amazon CloudFront dan Edge locations.
• Membandingkan berbagai metode yang dapat menyajikan layanan AWS.

Sudah siap? Mari mulai perjalanan kita di modul ini dengan melangkah ke materi berikutnya!

Pengenalan ke Infrastruktur Global dan Keandalan

Selamat datang! Untuk memulai modul ini, mari kita sedikit berbincang tentang high availability (ketersediaan tinggi).

Ceritanya begini. Katakanlah pelanggan Anda ingin menikmati secangkir latte hangat di kedai kopi kita. Namun sayangnya, hari ini tak berjalan seperti biasa. Ada parade perayaan keberhasilan migrasi cloud yang menghalangi jalan menuju ke sana dan akan berbaris tepat di depan kedai kopi tersebut.

Sebenarnya ini bagus karena siapa yang tak suka melihat banyak balon dan permen? Akan tetapi, hal ini juga dapat berdampak buruk terhadap bisnis kita karena saat parade berlangsung, pelanggan yang tadinya ingin datang ke kedai kopi akan dialihkan jalannya sehingga tidak bisa mampir. Akibatnya, pelanggan akan kecewa dan penjualan pun menurun.

Untungnya, kita telah berpikir jauh ke depan untuk menyiasati gangguan semacam ini. Tahukah Anda? Sebenarnya kedai kopi kita tidak hanya berada di satu tempat saja loh, melainkan terdapat juga di beberapa lokasi lain di seluruh kota.

Dengan demikian, Anda tak perlu khawatir lagi jika ada parade di sejumlah ruas jalan. Bahkan tak hanya untuk parade, halangan lain seperti banjir, bencana, atau apa pun yang bisa mencegah pelanggan ke kedai kopi, telah kita atasi.

Sekarang kedai kopi kita dapat selalu tersedia bagi pelanggan. Mereka tetap bisa mendapatkan secangkir latte dengan mengunjungi kedai kopi kita lainnya yang berada tidak terlalu jauh. Semuanya akan baik-baik saja, bukan? Kita tetap bisa menjalankan bisnis dan pelanggan tetap bisa mendapatkan kopi.

Nah, AWS pun telah melakukan hal yang serupa dengan itu, yaitu dengan menyiapkan infrastruktur global AWS.

Tahukah Anda hikmah cerita di atas? Janganlah kita menempatkan semua sumber daya hanya di satu data center saja. Karena jika terjadi hal yang tidak diinginkan pada data center tersebut--seperti pemadaman listrik atau bencana alam--semua aplikasi akan down (mati) sekaligus. Bahkan, memiliki dua data center pun tetap tidak cukup baik loh.

Solusinya adalah Anda membutuhkan high availability (ketersediaan tinggi) dan fault tolerance (toleransi terhadap kesalahan). High availability adalah kemampuan untuk memastikan bahwa sistem selalu bekerja dan dapat diakses dengan waktu henti yang minimal tanpa memerlukan intervensi manusia. Sedangkan fault tolerance berarti sistem masih mampu beroperasi meskipun beberapa komponen mengalami kegagalan.

Faktanya, AWS beroperasi di lokasi yang berbeda-beda di seluruh dunia yang disebut Region. Tapi sabar ya. Kita baru akan membicarakan hal ini secara mendalam di modul mendatang. Jadi, mari kita lanjutkan!\

Infrastruktur Global AWS

Untuk memahami infrastruktur global AWS, yuk kita mulai dengan menguraikan kebutuhan dasar untuk memulai bisnis di masa sekarang ini. Apa saja? Tentu kita membutuhkan:

• Aplikasi yang harus berjalan.
• Konten yang perlu disimpan.
• Data yang perlu dianalisis.

Intinya, kita memiliki sesuatu yang harus berjalan dan beroperasi di suatu tempat. Sebelum adanya teknologi Cloud, perusahaan harus menjalankan aplikasi mereka di on-premise karena mereka tak punya pilihan lain. Namun setelah AWS hadir, mereka dapat menjalankannya di data center lain tanpa harus memilikinya.

Tetapi pembahasan kita di modul ini akan jauh lebih dari itu. Kita harus memahami masalah yang fundamental terkait data center.

Kejadian tak terduga seperti terputusnya koneksi ke data center dapat terjadi kapan pun. Ada banyak faktor yang dapat memengaruhi problem seperti ini, salah satunya adalah bencana.

Jika Anda menjalankan on-premise, apa yang akan Anda lakukan saat bencana melanda data center tersebut? Mungkin solusinya adalah membangun data center kedua. Tapi ini bukan solusi yang terbaik.

Harga gedung atau bangunan untuk membangun data center akan terlalu mahal bahkan bisa jadi menghentikan bisnis Anda. Belum lagi biaya untuk perangkat keras, karyawan, listrik, pemanas dan pendingin, serta keamanan.

Oleh sebab itu, sebagian besar perusahaan pada akhirnya hanya menyimpan data cadangan mereka di suatu tempat dan berharap bencana tidak akan pernah datang. Kita semua tahu, harapan bukanlah rencana bisnis yang baik.

Tapi, tenang! AWS dapat membantu Anda mengatasi persoalan tersebut. Solusinya adalah dengan membangun data center dalam kelompok besar yang disebut dengan AWS Regions (Wilayah/Region AWS).

Mari kita bahas bagaimana AWS Regions didesain.

AWS Regions

Diambil dari Jaringan Infrastruktur Global AWS.

AWS telah membangun Region di seluruh dunia agar permintaan traffic bisnis dapat dilayani oleh Region terdekat. Beberapa contoh lokasi Region adalah kota Paris, Tokyo, Sao Paulo, Dublin, Ohio, dll.

Di dalam Region, AWS memiliki beberapa data center yang berisi semua sumber daya yang dibutuhkan seperti komputasi, penyimpanan, jaringan, dll.

Setiap Region tersebut dapat terkoneksi ke Region lain melalui high speed fiber network (jaringan fiber berkecepatan tinggi) yang dikontrol oleh AWS--kita membutuhkannya untuk operasi yang benar-benar global dari satu lokasi ke lokasi lainnya di seluruh dunia.

Ketahuilah! AWS memungkinkan Anda untuk dapat memilih Region mana yang ingin dijalankan. Selain itu, setiap Region juga terisolasi dari Region lainnya. Ini berarti tidak akan ada data yang masuk atau keluar dari Region tersebut kecuali Anda secara eksplisit mengizinkan data itu untuk berpindah.

Misalnya begini. Anda memiliki suatu persyaratan compliance (kepatuhan) dari pemerintah yang menyatakan bahwa informasi keuangan Anda yang berada di kota Frankfurt tidak dapat meninggalkan negara Jerman.

Di sinilah bagaimana AWS benar-benar beroperasi secara out of the box alias unik. Di AWS:

• Setiap data yang disimpan di Region Frankfurt tidak pernah meninggalkan Region Frankfurt.
• Setiap data di Region London tidak pernah meninggalkan Region London.
• Setiap data yang berada di Sydney tidak pernah meninggalkan Region Sydney.

Intinya, semua data yang disimpan di dalam Region, tak akan pernah meninggalkan Region tersebut, kecuali Anda secara eksplisit--dengan kredensial dan izin yang tepat--meminta data tersebut untuk diekspor.

Regional data sovereignty atau kedaulatan data regional adalah bagian dari desain penting AWS Regions, di mana data mengikuti hukum dan undang-undang lokal negara tempat Region berada.

Nah, setelah kita tahu bahwa data dan aplikasi akan tinggal dan berjalan di suatu Region, Anda harus memilih Region mana yang tepat dan sesuai dengan kebutuhan. Ada 4 faktor bisnis yang menentukan pemilihan suatu Region.

1. Compliance (Kepatuhan)
   Sebelum faktor lainnya, Anda harus terlebih dahulu melihat compliance requirement (persyaratan kepatuhan) Anda. Titik. Opsi lainnya menjadi tidak penting saat Anda memiliki persyaratan kepatuhan.
   
   Misalnya, jika Anda memiliki persyaratan bahwa data Anda harus tinggal di perbatasan negara Inggris, maka pilihlah Region London. Atau jika Anda harus masuk ke dalam perbatasan negara Cina, maka Anda bisa memilih salah satu Region Cina.
   
   Namun, sebagian besar perusahaan tidak diatur oleh regulasi yang ketat semacam itu. Jadi, jika Anda tidak memiliki kontrol kepatuhan atau regulasi yang mewajibkan penentuan Region, maka Anda dapat mempertimbangkan faktor lain.

2. Proximity (Kedekatan)
   Memilih region yang paling dekat dengan basis pelanggan akan membantu Anda untuk mengirimkan konten lebih cepat kepada mereka.
   
   Katakanlah suatu perusahaan berlokasi di Washington, DC, namun kebanyakan pelanggannya tinggal di negara Singapura. Nah, untuk kasus ini, solusi yang tepat adalah dengan menjalankan infrastruktur di Region Northern Virginia agar dekat dengan lokasi perusahaan dan menerapkan aplikasi dari Region Singapura.
   
   Dengan begitu, latensi (waktu yang diperlukan untuk mengirim dan menerima data) bisa semakin kecil dan pengiriman konten ke pelanggan menjadi lebih cepat.

3. Feature Availability (Ketersediaan Fitur)
   Adakalanya, Region terdekat mungkin tidak memiliki semua fitur AWS yang Anda inginkan. Namun, AWS terus berinovasi untuk pelanggan. Setiap tahun, AWS merilis ribuan fitur dan produk baru secara spesifik untuk menjawab permintaan dan kebutuhan pelanggan.
   
   Tapi, terkadang layanan baru tersebut membutuhkan banyak perangkat keras fisik baru yang harus AWS bangun agar dapat beroperasi. Dan terkadang, itu berarti AWS harus membangun layanan di satu Region pada satu waktu.
   
   Misal Anda ingin membangun sebuah aplikasi yang menggunakan Amazon Braket--platform komputasi kuantum baru AWS. Faktanya, layanan ini belum tersedia di seluruh AWS Regions sehingga Anda harus menjalankannya di Region yang menyediakannya.
   
   Kalau begitu, dapatkah kita mengharapkan fitur tersebut tersedia di semua Region? Ya, itu ekspektasi yang bagus. Tapi, jika Anda ingin menggunakannya hari ini juga, maka Anda harus mempertimbangkan untuk memilih Region lain yang memiliki fitur tersebut.

4. Pricing (Harga)
   Meskipun spesifikasi perangkat keras pada suatu Region setara dengan Region lain, namun beberapa lokasi bisa lebih mahal pengoperasiannya.
   
   Misal negara Brasil, struktur pajak di sana memiliki tatanan sedemikian rupa sehingga biaya AWS bisa jauh lebih mahal untuk mengoperasikan layanan yang sama persis dibandingkan dengan negara lain. Pengoperasian beban kerja yang sama persis di kota Sao Paulo mungkin bisa 50% lebih mahal daripada di kota Oregon di negara Amerika Serikat.
   
   Harga dapat ditentukan oleh banyak faktor dan AWS akan transparan mengenai hal tersebut.
   
   Ingat! Setiap Region memiliki harga yang berbeda-beda. Jadi, jika bujet adalah perhatian utama Anda, mungkin akan lebih baik untuk mengoperasikan lingkungan AWS Anda di negara lain meskipun basis pelanggan Anda tinggal di Brasil. Sekali lagi, ini berlaku jika anggaran adalah motivasi utama Anda.

Jadi, itulah 4 faktor utama untuk memilih suatu Region: Compliance, Proximity, Feature availability, dan Pricing. Selanjutnya, kita akan menelaah bagian yang lebih kompleks di dalam Region.

Availability Zone

Seperti yang telah kita singgung di materi sebelumnya, menjalankan aplikasi di satu bangunan data center saja bukanlah solusi yang baik karena gedung tersebut bisa mengalami kegagalan untuk sejumlah alasan yang tak dapat dihindari.

Itulah mengapa AWS Regions tidak hanya terdiri dari satu lokasi saja. AWS memiliki banyak data center di seluruh dunia dan setiap Region terdiri dari beberapa data center.

AWS memberi nama satu atau sekelompok data center tersebut dengan sebutan Availability Zone (AZ). Setiap Availability Zone adalah satu atau beberapa data center terpisah dengan daya, jaringan, dan konektivitasnya sendiri-sendiri.

Saat meluncurkan Amazon EC2 instance, sebenarnya Anda menjalankan mesin virtual pada perangkat keras fisik yang diinstal di Availability Zone.

Ketahuilah! Setiap AWS Regions terdiri dari beberapa Availability Zone yang terisolasi dan secara fisik terpisah di dalam Region geografis. AWS tidak membangun Availability Zone bersebelahan satu sama lain. Kenapa?

Karena, jika insiden dengan skala besar terjadi--misal bencana alam--Anda dapat kehilangan konektivitas ke semua sumber daya yang ada di dalam Availability Zone tersebut.

Sekarang begini, saat Anda meluncurkan 1 EC2 instance, itu berarti instance tersebut hanya berjalan di 1 gedung atau 1 Availability Zone saja. Nah, persoalannya, jika terjadi bencana berskala besar, maka aplikasi tersebut tentunya tak lagi dapat melayani bisnis Anda.

Solusi terbaik untuk masalah ini adalah dengan menjalankan beberapa EC2 instance--seperti yang kita pelajari dari contoh scaling sebelumnya. Tetapi, jangan menjalankannya di gedung yang sama.

AWS memberikan jarak Availability Zone sejauh puluhan mil untuk satu sama lainnya namun tetap mempertahankan single-digit millisecond latency (latensi milidetik satu digit).

Sebagai praktik terbaik, AWS selalu menyarankan untuk menjalankan setidaknya 2 Availability Zone dalam satu Region. Itu artinya, Anda perlu menerapkan infrastruktur Anda di 2 AZ yang berbeda.

Dengan demikian, sekarang jika bencana melanda, aplikasi Anda akan tetap beroperasi dengan baik karena momen tersebut hanya melumpuhkan sebagian dari kapasitas Anda, tidak semua. Dan Anda dapat dengan cepat menambah kapasitas di Availability Zone yang tersisa sehingga memungkinkan bisnis Anda terus beroperasi tanpa interupsi.

Tapi Region bukan sekadar tempat untuk mengelola EC2, banyak layanan AWS yang berjalan di level Region. Itu artinya, layanan tersebut sudah beroperasi secara sinkron di beberapa AZ tanpa upaya tambahan.

Ambil contoh layanan Elastic Load Balancing yang telah kita bicarakan sebelumnya. Ia adalah regional construct (konstruksi regional) yang berjalan di semua Availability Zone. Ia dapat pula berkomunikasi dengan EC2 instance yang beroperasi di AZ tertentu.

Layanan regional menurut definisi sudah highly available (sangat tersedia) tanpa biaya tambahan. Jadi, saat merencanakan infrastruktur dengan high availability (ketersediaan tinggi), Anda bisa menggunakan layanan apa pun yang terdaftar sebagai regional scoped service (layanan dengan cakupan regional).

Oke, itulah tadi seputar infrastruktur global AWS. Sekarang, mari kita masuk ke pembahasan materi berikutnya.

Edge Locations

Diambil dari AWS News Blog: 98, 99, 100 CloudFront Points of Presence!

Salah satu hal hebat tentang infrastruktur global AWS adalah caranya didesain untuk membantu Anda melayani pelanggan dengan lebih baik. Ingat kembali materi kita sebelumnya yang berkenaan dengan memilih Region. Salah satu kriteria utamanya adalah proximity alias kedekatan dengan pelanggan.

Tapi, masih ada permasalahan lainnya. Coba pikirkan kembali tentang skenario kedai kopi kita. Anggaplah Anda ingin membangun kedai kopi di suatu kota yang memiliki basis pelanggan besar. Namun sayangnya, kota tersebut tidak berada dekat dengan salah satu AWS Regions. Apa yang harus Anda lakukan?

AWS menyediakan solusinya. Daripada harus membangun kedai kopi baru, Anda dapat membangun kedai satelit (kedai kopi kecil di bawah pelayanan pusat distribusi yang sama) untuk melayani pelanggan Anda di kota tersebut.

Mari kita lihat dari perspektif IT. Misalnya Anda memiliki pelanggan di kota Jakarta yang membutuhkan akses ke data aplikasi. Akan tetapi, data tersebut disimpan di Region Tokyo, tentu dengan jarak yang jauh ini akan menyebabkan latensi yang besar.

Lalu bagaimana solusinya? Begini, daripada semua pelanggan yang berada di kota Jakarta itu mengakses data ke Tokyo, akan lebih baik jika Anda cukup menempatkan salinan data secara lokal atau simpan salinannya ke dalam cache (penyimpanan data sementara agar dapat diakses lebih cepat) di Singapura.

Nah dengan begitu, saat pelanggan dari kota Jakarta mengakses salah satu data Anda, Amazon CloudFront--nanti kita bahas--akan mengambil data dari cache di Edge locations lalu mengirimkannya ke pelanggan tersebut. Data tadi terkirim lebih cepat karena berasal dari Edge locations Singapura--yang jaraknya lebih dekat dengan kota Jakarta--bukan dari Tokyo.

Teknik menyimpan salinan data di cache dengan lokasi yang lebih dekat dengan pelanggan di seluruh dunia adalah konsep yang digunakan oleh jaringan pengiriman konten alias content delivery network (CDN). Di AWS, CDN disebut dengan Amazon CloudFront.

Amazon CloudFront adalah layanan yang dapat membantu Anda untuk mengirimkan data, video, aplikasi, dan API ke pelanggan di seluruh dunia dengan latensi rendah dan kecepatan transfer yang tinggi. Amazon CloudFront menggunakan Edge locations di seluruh dunia untuk membantu mempercepat komunikasi dengan pengguna--di mana pun mereka berada.

Jadi, Edge locations adalah lokasi yang digunakan Amazon CloudFront untuk menyimpan salinan cache dengan jarak yang dekat dengan pelanggan sehingga konten dapat terkirim lebih cepat.

Ketahuilah! Edge locations itu terpisah dari AWS Regions. Sehingga, Anda dapat mengirim konten dari dalam Region ke kumpulan Edge locations di seluruh dunia.

AWS Edge locations tak hanya berguna untuk menjalankan CloudFront, melainkan juga layanan domain name system (DNS) atau sistem nama domain yang dikenal sebagai Amazon Route 53. Layanan ini dapat membantu mengarahkan pelanggan ke lokasi web yang tepat dengan latensi rendah yang andal.

Lalu, mungkin Anda akan bergumam, “Bisa nggak ya kalau kita ingin menggunakan layanan AWS langsung di dalam gedung milik sendiri?” Coba tebak.

Tentu bisa. AWS dapat melakukannya untuk Anda.

Perkenalkan, AWS Outposts. Dengan layanan ini, pada dasarnya, AWS akan menginstal Region mini yang beroperasi penuh, tepat di dalam data center Anda sendiri. Semua infrastruktur dan layanan tersebut dimiliki serta dioperasikan oleh AWS menggunakan 100% kegunaan AWS namun tetap terisolasi di dalam data center Anda.

AWS Outposts bukanlah solusi yang dibutuhkan bagi sebagian besar pelanggan AWS. Tetapi, jika Anda memiliki masalah tertentu yang hanya dapat diselesaikan dengan tetap berada di dalam data center Anda sendiri, AWS Outposts dapat menjadi jalan keluarnya.

Oke, sebenarnya masih banyak yang dapat kita paparkan tentang infrastruktur global AWS. Meskipun demikian, mari kita buat bahasan ini tetap sederhana dan berakhir di sini saja. Jadi, berikut adalah poin kuncinya:

1. Region adalah wilayah yang terisolasi secara geografis di mana Anda dapat mengakses layanan yang diperlukan untuk menjalankan segala macam kebutuhan.
2. Region terdiri dari Availability Zone yang memungkinkan Anda untuk menjalankan seluruh bangunan data center yang terpisah secara fisik dengan jarak puluhan mil sambil menjaga aplikasi Anda tetap bersatu secara logis. Availability Zone membantu Anda untuk dapat mencapai high availability (ketersediaan tinggi) dan disaster recovery (pemulihan bencana) tanpa upaya apa pun dari Anda.
3. AWS Edge locations digunakan untuk menjalankan Amazon CloudFront sehingga dapat memperdekat konten kepada pelanggan Anda di mana pun mereka berada.

Cara Menyediakan Sumber Daya AWS

Sampai di sini, kita telah membicarakan tentang beberapa sumber daya serta infrastruktur global AWS. Melihat materi-materi sebelumnya, muncullah sebuah pertanyaan, bagaimana sebenarnya kita dapat berinteraksi dengan layanan-layanan tersebut?

Jawabannya adalah API--sudah kita singgung sedikit di modul sebelumnya. Di AWS semua aktivitas adalah panggilan API. API adalah application programming interface atau antarmuka pemrograman aplikasi. Dengan kata lain, ada cara yang telah ditentukan sebelumnya untuk Anda sehingga dapat berinteraksi dengan layanan AWS.

Anda dapat memanggil API ini untuk menyediakan, mengonfigurasi, dan mengelola sumber daya AWS. Misal untuk meluncurkan EC2 instance atau membuat AWS Lambda function. Masing-masing akan menjadi permintaan dan panggilan API yang berbeda ke AWS.

Jadi, untuk berinteraksi dengan layanan AWS, Anda dapat menggunakan AWS Management Console, AWS Command Line Interface (CLI), dan AWS Software Development Kit (SDK). Atau berbagai alat lain seperti AWS Elastic Beanstalk dan AWS CloudFormation (layanan yang dapat membuat permintaan untuk dikirim ke AWS API guna membuat dan mengelola sumber daya AWS).

AWS Management Console

AWS Management Console adalah antarmuka berbasis browser yang dapat digunakan untuk mengakses dan mengelola layanan AWS. Melalui console (konsol), Anda dapat mengelola sumber daya AWS secara visual dan dengan cara yang mudah dipahami. Tentu ini adalah cara yang ideal untuk memulai dan membangun pengetahuan Anda tentang layanan AWS.

Dengan AWS Management Console, Anda dapat

• mencari layanan AWS dari nama, kata kunci, atau akronim;
• membangun lingkungan pengujian;
• melihat tagihan AWS;
• melakukan pemantauan; atau
• bekerja dengan sumber daya nonteknis lainnya.

AWS Console versi aplikasi seluler juga tersedia dan dapat Anda gunakan untuk melakukan tugas seperti memantau sumber daya, melihat alarm, dan mengakses informasi penagihan.

AWS Management Console adalah tempat pertama terbaik yang perlu Anda tuju ketika ingin mempelajari tentang AWS.

AWS Command Line Interface

Jika Anda akan menjalankan sumber daya di lingkungan produksi, tentu Anda tak ingin bergantung dengan cara point and click (tunjuk dan klik) yang diberikan console untuk membuat dan mengelola sumber daya AWS.

Ambil contoh pembuatan Amazon EC2 instance. Dengan AWS Management Console, Anda perlu klik berkali-kali, mengatur semua konfigurasi, barulah instance Anda dapat diluncurkan. Jika nantinya ingin meluncurkan EC2 instance lain, Anda harus kembali ke console dan melakukan proses klik yang sama terhadap layar-layar itu lagi. Ini akan membuang banyak waktu.

Jika seorang manusia terus-menerus melakukan penyediaan manual semacam ini, artinya Anda membuka peluang terhadap potensi kesalahan karena manusia sangat mudah untuk lupa mengeklik kotak centang atau salah mengeja sesuatu.

Jawaban untuk masalah ini adalah dengan menggunakan sarana yang memungkinkan Anda membuat skrip atau memprogram panggilan API, yaitu dengan AWS Command Line Interface atau CLI.

CLI memungkinkan Anda untuk mengendalikan layanan AWS dengan baris perintah melalui satu alat. Jelas ini berbeda dengan gaya navigasi visual dari AWS Management Console. AWS CLI tersedia untuk pengguna Windows, macOS, dan Linux.

Dengan menulis perintah menggunakan CLI, Anda dapat membuat tindakan yang dapat ditulis berkali-kali. Misal Anda menulis dan menjalankan perintah untuk meluncurkan EC2 instance. Nah, jika Anda ingin meluncurkan instance lain, cukup jalankan kembali perintah tersebut. Dengan demikian, Anda akan terhindar dari human error alias kesalahan manusia.

Selain itu, Anda juga dapat menjalankan skrip tersebut secara otomatis, contohnya dengan berdasarkan jadwal atau dipicu oleh proses lain.

AWS Software Development Kit

Cara lain untuk berkomunikasi dengan AWS adalah melalui AWS Software Development Kit atau SDK. SDK memudahkan Anda untuk berinteraksi dengan sumber daya AWS melalui berbagai bahasa pemrograman.

Hal ini memudahkan developer (pengembang) untuk membuat program di AWS tanpa menggunakan low-level API serta menghindari pembuatan sumber daya secara manual yang dari tadi kita bincangkan.

Sederhananya, low-level API memungkinkan Anda untuk memanipulasi fungsi di dalam API secara terperinci sesuai dengan kebutuhan. Lawannya adalah high-level API, yang memberikan lebih banyak fungsi dalam satu perintah dan lebih mudah digunakan sehingga Anda tak perlu mendalami detail teknis dan struktur API-nya.

Untuk membantu Anda memulai menggunakan SDK, AWS menyediakan dokumentasi dan sampel kode untuk setiap bahasa pemrograman yang didukung, yaitu mencakup C++, Go, Java, JavaScript, .NET, Node.js, PHP, Python, dan Ruby.

AWS Elastic Beanstalk

Opsi-opsi sebelumnya, yaitu AWS Management Console, CLI, dan SDK adalah cara penyediaan dan pengelolaan lingkungan AWS yang harus Anda lakukan sendiri.

Kita telah belajar, bahwa jika ingin menyediakan sumber daya, kita dapat melakukan salah satu cara di bawah ini:

• Masuk ke konsol, arahkan dan klik.
• Menulis beberapa perintah.
• Menulis beberapa program untuk melakukannya.

Nah, selain yang disebutkan di atas, ada juga cara lain untuk mengelola lingkungan AWS Anda menggunakan managed service (layanan terkelola) seperti AWS Elastic Beanstalk.

AWS Elastic Beanstalk adalah layanan yang dapat membantu Anda menyediakan lingkungan berbasis Amazon EC2. Tak perlu lagi harus klik sana sini di console atau menulis beberapa baris perintah untuk membangun jaringan, EC2 instance, scaling (penyesuaian kapasitas), dan Elastic Load Balancer.

Ucapkan selamat tinggal kepada semua itu. AWS Elastic Beanstalk dapat menyediakan dan mengelola semua infrastruktur tersebut sembari tetap memberi visibilitas dan kendali atas sumber daya yang mendasarinya. Dengan begitu, Anda bisa fokus pada aplikasi bisnis bukan infrastrukturnya.

Cukup unggah kode dan tentukan konfigurasi yang Anda inginkan, maka AWS Elastic Beanstalk pun akan mengolah informasi tersebut dan membangun lingkungan AWS-nya untuk Anda.

Lingkungan yang dimaksud adalah:

• Penyesuaian Kapasitas
• Load balancing (Penyeimbang beban)
• Auto-scaling (Penskalaan otomatis)
• Pemantauan kesehatan aplikasi

Simpan konfigurasi lingkungan tersebut sehingga nantinya akan memudahkan Anda saat menerapkannya kembali.

AWS CloudFormation

Layanan lain yang dapat Anda gunakan untuk membantu membuat penerapan (deployment) otomatis dan berulang adalah AWS CloudFormation.

AWS CloudFormation adalah layanan infrastructure as code (infrastruktur sebagai kode) yang memungkinkan Anda untuk menentukan berbagai sumber daya AWS dengan cara deklaratif menggunakan dokumen berbasis teks JSON atau YAML yang disebut sebagai CloudFormation template.

Format deklaratif memudahkan Anda untuk memberikan spesifikasi apa yang ingin dibangun tanpa harus mendeskripsikan detail bagaimana caranya karena mesin CloudFormation yang akan mengurusnya. Anda hanya perlu menulis baris kode untuk membangun lingkungan ketimbang menggunakan AWS Management Console.

AWS CloudFormation tak hanya terbatas pada solusi berbasis EC2, melainkan mendukung banyak sumber daya AWS, seperti penyimpanan, database, analitik, machine learning, dan banyak lagi.

Oke, setelah Anda menentukan sumber daya dalam CloudFormation template, AWS CloudFormation akan menguraikannya dan mulai menyediakan semua sumber daya tersebut secara paralel.

AWS CloudFormation mengelola semua panggilan API. Anda dapat menjalankan CloudFormation template yang sama di beberapa akun atau Region. Dengan begitu, layanan ini akan membuat lingkungan yang identik di dalamnya. Tak akan ada lagi human error karena semua proses berjalan secara otomatis dengan sepenuhnya.

Ikhtisar

Luar biasa! Kita sudah berbincang banyak hal di modul ini. Kita telah:

• Membahas bagaimana klaster logis dari data center membentuk Availability Zone. Lalu, Availability Zone membentuk Region dan tersebar secara global.
• Menelaah cara memilih Region dan Availability Zone yang ingin dioperasikan. Sebagai praktik terbaik, Anda harus selalu menerapkan infrastruktur minimal di 2 Availability Zone.
• Menilik beberapa layanan AWS seperti Elastic Load Balancing, Amazon SQS, dan Amazon SNS.
• Membicarakan tentang Edge locations dan bagaimana Anda dapat menyebarkan konten untuk mempercepat pengiriman ke pelanggan.
• Membahas perangkat edge seperti AWS Outposts yang memungkinkan Anda menjalankan infrastruktur AWS langsung di data center Anda sendiri.
• Mendiskusikan bagaimana cara menyediakan sumber daya AWS melalui berbagai opsi: AWS Management Console, SDK, CLI, AWS Elastic Beanstalk, dan AWS CloudFormation--di mana Anda mempelajari cara menyiapkan infrastructure as code (infrastruktur sebagai kode).

Dengan mempelajari modul ini, semoga Anda Anda dapat memahami bahwa AWS tersedia secara global dan betapa mudahnya memulai dengan penyediaan sumber daya.

Materi Pendukung

Tinjau tautan berikut untuk mempelajari lebih lanjut tentang konsep yang telah kita jelajahi di modul ini:

• Infrastruktur Global
• Wilayah & AZ Infrastruktur Global
• AWS Networking and Content Delivery Blog
• SDK dan Toolkit Pemrograman untuk AWS
• Studi Kasus