Azure Platform Foundations untuk startup

Artikel ini memberikan orientasi cepat dengan lensa startup di lima pilar platform dasar: komputasi, jaringan, penyimpanan, kontainer, dan data. Untuk setiap pilar, Anda akan mendapatkan tabel keputusan singkat yang memetakan situasi Anda ke layanan default, beserta catatan tentang kapan harus meninjau kembali pilihan tersebut seiring pertumbuhan startup Anda.

Dalam artikel ini, Anda mempelajari cara

Pilih layanan komputasi, jaringan, dan penyimpanan dasar Azure yang tepat untuk tahap Anda.
Tentukan apakah Azure Kubernetes Service adalah platform kontainer yang tepat untuk tahap Anda, dan apa yang harus digunakan sebagai gantinya jika tidak.
Pilih platform data pertama di seluruh beban kerja relasional, dokumen, vektor, dan analitik.
Terapkan seperangkat kecil pengaturan bawaan untuk biaya, keandalan, dan keamanan yang tetap efektif seiring pertumbuhan Anda.
Kenali sinyal yang memberi tahu Anda pilihan default telah melampaui kegunaannya.

Prasyarat

Langganan Azure aktif.
Azure CLI terinstal dan masuk. Untuk masuk, jalankan az login.
Akses Pemilik atau Kontributor pada setidaknya satu grup sumber daya.
Pemahaman tentang halaman arahan portal Azure sangat membantu tetapi tidak diperlukan.
Pemahaman dasar tentang dasar-dasar Azure (wilayah, langganan, dan grup sumber daya).

Mengapa ini penting untuk startup

Pada startup tahap awal, biaya pilihan infrastruktur yang salah bukanlah tagihan. Itulah seminggu yang terbuang saat Anda harus bermigrasi dari layanan yang salah setelah membangun sistem di sekitarnya. Kelima pilar dalam artikel ini adalah area-area ketika pilihan default yang keliru cenderung menimbulkan efek berantai: platform komputasi yang salah menentukan alur deployment Anda; basis data yang salah membatasi model data Anda; topologi jaringan yang salah menghalangi pelanggan korporat pertama Anda. Anda tidak memerlukan tim platform, teknisi keandalan situs, atau spesialis operasi keuangan untuk membuat pilihan ini dengan baik. Anda memerlukan konfigurasi bawaan yang cukup baik untuk dirilis, serta sinyal yang jelas yang memberi tahu kapan konfigurasi tersebut perlu ditinjau kembali. Jika startup Anda berada dalam program Microsoft untuk Startups, default yang sama akan merentangkan kredit Anda lebih jauh dan membuat Anda memenuhi syarat untuk mendapatkan manfaat lanjutan nanti.

Komputasi: tempat kode Anda berjalan

Azure memiliki lebih dari selusin layanan komputasi. Kabar baiknya: untuk sebagian besar beban kerja tahap awal, tiga di antaranya mencakup apa yang Anda butuhkan.

Situasi Anda	Layanan Azure default	Mengapa	Kunjungi kembali kapan
Aplikasi web atau API HTTP, satu atau dua layanan, Anda menginginkan runtime terkelola	Azure App Service (Linux)	Tidak perlu pembuatan kontainer. TLS bawaan, domain kustom, slot penyebaran, dan skala otomatis. Paket gratis dan dasar cukup terjangkau untuk menjalankan lingkungan staging, meskipun slot dan penskalaan otomatis memerlukan paket Standard atau yang lebih tinggi.	Anda ingin menjalankan lebih dari beberapa layanan, memerlukan penskalaan per layanan, atau memerlukan sidecar.
Fungsi berbasis peristiwa, pekerjaan terjadwal, atau handler webhook	Azure Functions (Paket konsumsi)	Pembayaran per eksekusi. Dapat diskalakan hingga nol. Pengikatan menghapus sebagian besar kode lem untuk antrean, blob, dan pemicu HTTP.	Cold start memperburuk latensi yang dirasakan pengguna atau menyebabkan Anda melampaui batas paket Konsumsi.
Layanan mikro kontainer, Anda menginginkan runtime opini tanpa mengelola Kubernetes	Azure Container Apps	Dibangun di atas Kubernetes dengan penskalaan otomatis berbasis KEDA, namun Anda tidak mengelola kluster. Dapr tersedia sebagai integrasi opsional. Skala-ke-nol, revisi, dan ingress HTTPS disertakan.	Anda memerlukan kontrol tingkat kluster, penjadwal kustom, atau jaringan tingkat lanjut.
Pemrosesan batch jangka panjang, pelatihan GPU, atau migrasi lift-and-shift dari beban kerja mesin virtual yang ada	Azure Virtual Machines	Kontrol sistem operasi penuh. Gunakan kumpulan skala komputer virtual saat Anda memerlukan penskalaan horizontal.	Beban operasional penerapan patch dan pengelolaan image mulai memperlambat proses rilis.
Anda yakin memerlukan Kubernetes (lihat bagian 4 sebelum berasumsi ini)	Azure Kubernetes Service	Sarana kontrol terkelola. Cocok dengan tim yang sudah memiliki pengalaman Kubernetes atau persyaratan platform tertentu.	Lihat bagian Kontainer untuk kriteria keputusan AKS.

Tip

Mulailah dengan App Service untuk aplikasi web pertama Anda yang digunakan pengguna, dan Azure Functions untuk semua kebutuhan berbasis peristiwa. Anda dapat pindah ke Azure Container Apps atau Azure Kubernetes Service nanti tanpa mengubah kode aplikasi Anda, jika Anda menjaga aplikasi tetap stateless dan menulis konfigurasi ke variabel lingkungan.

Memilih antara Aplikasi Kontainer dan App Service

Aplikasi Kontainer dan App Service saling tumpang tindih. Penentu yang paling jujur: jika aplikasi Anda sudah berjalan sebagai image kontainer dan Anda menginginkan skala per layanan (replika yang berbeda untuk lapisan web dibandingkan dengan worker), Container Apps unggul. Jika aplikasi Anda adalah satu proses web dan Anda tidak ingin mempertahankan Dockerfile, App Service akan menang.

Caution

Pertimbangkan Azure Kubernetes Service ketika Anda memiliki persyaratan jelas yang tidak terpenuhi oleh opsi yang lebih sederhana. Meskipun menawarkan fleksibilitas dan kontrol yang kuat, ia juga memperkenalkan pertimbangan operasional tambahan (seperti peningkatan, ukuran kumpulan simpul, konfigurasi ingress, dan manajemen sertifikat). Jika diadopsi terlalu dini, tim sering menemukan lebih banyak waktu masuk ke manajemen platform daripada membangun fitur produk.

Jaringan: apa yang harus disiapkan pada hari pertama

Sebagian besar beban kerja Azure tahap awal tidak memerlukan jaringan virtual pada hari pertama. App Service, Functions, Container Apps, dan sebagian besar database terkelola memberi Anda titik akhir publik dengan TLS yang aman untuk diekspos, selama Anda mengatur autentikasi dengan benar. Menambahkan kompleksitas jaringan sebelum Anda memiliki alasan adalah pengoptimalan dini yang paling umum pada Azure.

Situasi Anda	Pendekatan default	Mengapa	Kunjungi kembali kapan
Aplikasi baru, lalu lintas web publik, belum ada persyaratan kepatuhan	Gunakan titik akhir publik dengan TLS. Tidak ada jaringan virtual.	Beban operasional paling rendah. App Service, Container Apps, dan database terkelola menangani TLS untuk Anda. Gunakan Microsoft Entra ID untuk autentikasi.	Pelanggan perusahaan pertama Anda meminta konektivitas privat.
Anda memerlukan koneksi privat antara aplikasi dan database terkelola	Integrasi jaringan virtual di sisi komputasi, titik akhir privat di sisi database	Lalu lintas data tetap berada di jaringan backbone Microsoft. Basis data tidak terekspos secara publik. Layanan terkelola yang sama, tidak ada perubahan aplikasi.	Hari pertama jika Anda menangani data yang dilindungi; jika tidak, ketika audit atau pelanggan bertanya.
Anda memerlukan satu titik akses publik yang melayani beberapa backend dengan perutean, terminasi TLS, dan firewall aplikasi web	Azure Front Door (global) atau Azure Application Gateway (regional)	Front Door menambahkan jaringan pengiriman konten global dan edge caching. Application Gateway adalah pilihan regional yang native untuk jaringan virtual.	Anda telah melampaui TLS dan perutean bawaan App Service.
Anda memerlukan alamat IP statis untuk lalu lintas keluar (misalnya, daftar IP yang diizinkan oleh pemroses pembayaran)	Gateway NAT yang dilampirkan ke jaringan virtual Anda	IP keluar yang dapat diprediksi. Diperlukan oleh banyak API pihak ketiga.	Vendor membutuhkannya. Jangan tambahkan secara spekulatif.
Topologi multiwilayah atau multiakun	Peering jaringan virtual atau Azure Virtual WAN	Arsitektur jaringan nyata dimulai di sini. Di luar cakupan untuk sebagian besar tim pada tahap Eksplorasi.	Multi-wilayah adalah persyaratan nyata, bukan aspirasi.

Important

Amankan Microsoft Entra ID dan penetapan peran pada langganan Anda sebelum mengkhawatirkan isolasi jaringan. Sebagian besar insiden keamanan Azure di perusahaan kecil berasal dari identitas dengan izin berlebihan, bukan dari eksposur jaringan. Gunakan grup Microsoft Entra ID untuk akses teknik, dan jangan bagikan Pemilik di cakupan langganan.

Penyimpanan: blob, file, dan disk

Azure Storage adalah jenis sumber daya tunggal (akun penyimpanan) yang mengekspos empat layanan data: blob, file, antrean, dan tabel. Untuk keputusan penyimpanan aplikasi, Anda hampir selalu memilih antara blob (penyimpanan objek), file (berbagi file terkelola), dan disk terkelola (memblokir penyimpanan yang melekat pada komputer virtual).

Apa yang Anda simpan	Layanan Azure default	Mengapa	Kunjungi kembali kapan
File yang diunggah pengguna, laporan yang dihasilkan, log, artefak model, cadangan	Azure Blob Storage (tingkat panas)	Penyimpanan objek. Murah, tahan lama, menskalakan ke petabyte. Gunakan tier cool atau archive di lain waktu untuk data yang jarang Anda baca.	Anda memerlukan semantik file POSIX atau baca-tulis acak ke dalam satu file dari beberapa komputer.
Sistem file bersama yang dipasang oleh beberapa komputer virtual atau kontainer	Azure Files (Standard) atau Azure NetApp Files (throughput tinggi)	Volume bersama Blok Pesan Server (SMB) atau Sistem File Jaringan (NFS). Hindari menggunakan ini untuk konten yang sesuai dengan model blob.	Anda mulai menggunakan berbagi file sebagai antrean atau database. Pindahkan ke primitif kanan.
Disk untuk mesin virtual	Disk yang dikelola Premium SSD v2	Kinerja yang dapat disesuaikan, rasio harga-kinerja yang baik untuk disk aplikasi. SSD premium v2 tidak dapat digunakan sebagai disk OS; pasangkan dengan SSD Premium (v1) atau SSD Standar untuk OS. SSD standar dapat diterima untuk beban kerja throughput rendah.	Anda memerlukan penyimpanan blok bersama di seluruh komputer virtual (gunakan Azure Elastic SAN atau Azure NetApp Files).
Aset situs web statis (bundel aplikasi satu halaman, situs pemasaran, dokumentasi)	Azure Storage hosting situs web statis + Azure Front Door	Static Web Apps adalah default modern: domain kustom bawaan, TLS terkelola gratis, distribusi global, GitHub Actions CI/CD, dan autentikasi bawaan. Situs web statis di Storage + Front Door masih berfungsi untuk konfigurasi berbiaya sangat rendah, tetapi secara bawaan tidak mendukung header kustom atau autentikasi.	Anda menambahkan halaman yang dirender di server. Pindah ke App Service atau Aplikasi Kontainer.

Note

Akun penyimpanan memiliki batas sementara 250 per wilayah per langganan (dapat dinaikkan menjadi 500 berdasarkan permintaan). Itu sudah lebih dari cukup untuk tim yang masih dalam tahap awal. Kesalahan yang harus dihindari adalah membuat satu akun penyimpanan per layanan mikro; kelompokkan menurut lingkungan (produksi, penahapan, pengembangan) dan dengan pola akses (panas, dingin, arsip) sebagai gantinya.

Catatan tentang pencadangan

Azure Backup dan opsi redundansi akun penyimpanan (Penyimpanan Redundan Lokal, Penyimpanan Redundan Zona, Penyimpanan Geo Redundan) dapat disetel per akun dan per disk. Penyimpanan Redundan Lokal (LRS) sudah memadai untuk pengembangan dan staging. Gunakan Zone Redundant Storage (ZRS) untuk data produksi. Geo Redundant Storage menambahkan biaya dan bukan pengganti pemulihan bencana tingkat aplikasi.

Kontainer dan Azure Kubernetes Service

Azure memiliki tiga cara untuk menjalankan kontainer dalam produksi: Azure Container Apps, Azure Container Instances, dan Azure Kubernetes Service. Hal tersebut sesuai dengan ukuran tim yang berbeda dan kapasitas operasional yang berbeda.

Situasi Anda	Layanan Azure default	Mengapa	Ketika mulai sakit
Anda memiliki image kontainer dan menginginkan runtime terkelola dengan ingress HTTPS, penskalaan hingga nol, dan revisi	Azure Container Apps	Platform tanpa server di Kubernetes dengan autoscaling KEDA, tetapi Anda tidak melihat atau mengelola kluster. Bayar sesuai yang digunakan. Cocok sampai Anda mencapai persyaratan tingkat kluster. Dapr tersedia sebagai integrasi opsional.	Anda memerlukan penjadwal kustom, jaringan tingkat lanjut (beberapa kartu antarmuka jaringan, plugin Antarmuka Jaringan Kontainer kustom), atau operator Kubernetes tertentu.
Anda ingin menjalankan satu kontainer sebagai tugas sekali jalan atau batch singkat	Azure Container Instances	Jalur tercepat dari gambar ke kontainer yang sedang berjalan. Tidak ada orkestrasi. Ditagihkan per detik waktu berjalan.	Anda membutuhkan sesuatu yang menyerupai service mesh atau autoscaling untuk lebih dari satu kontainer.
Anda sudah mengoperasikan Kubernetes di tempat lain, atau arsitektur aplikasi Anda benar-benar memerlukannya	Azure Kubernetes Service	Sarana kontrol terkelola. Gunakan pool node, plugin jaringan, pengontrol ingress, dan stack observabilitas Anda sendiri.	Hari pertama. Rencanakan peningkatan yang sedang berlangsung (versi minor dirilis setiap 4 bulan), penyetelan kumpulan simpul, dan manajemen sertifikat.
Anda tidak yakin apakah Anda membutuhkan Kubernetes	Aplikasi Kontainer untuk saat ini	Anda dapat membangun kembali Azure Kubernetes Service nanti jika diperlukan. Memindahkan aplikasi stateless yang dikontainerkan hanya membutuhkan beberapa hari, bukan berminggu-minggu.	Anda memiliki kebutuhan konkret (ekosistem operator, kebijakan tingkat kluster) yang dapat Anda beri nama. "Membuat sesuatu tahan terhadap perubahan di masa depan" bukanlah kebutuhan yang konkret.

Kapan lulus ke AKS

Pindah ke Azure Kubernetes Service (AKS) ketika setidaknya dua hal ini benar:

Anda menjalankan lebih dari sepuluh layanan dengan pertimbangan terkait siklus hidup dan jaringan yang sama.
Anda memerlukan pengontrol kustom, sidecar, atau Definisi Sumber Daya Kustom (CRD) yang tidak disediakan oleh Container Apps.
Anda memerlukan integrasi jaringan virtual yang mendalam dengan penegakan kebijakan yang ketat.
Anda menstandarkan ekosistem sumber terbuka berbasis Kubernetes (Argo, Istio, KEDA, dan sebagainya).

Jika Anda mengadopsi AKS, ikuti arsitektur Garis Besar AKS. Kerangka Kerja Microsoft Azure Well-Architected dan referensi Garis Besar AKS bersama-sama mencakup default keamanan, penskalan, dan peningkatan yang Anda inginkan.

Pengaturan default AKS untuk tim kecil

Setting	Default	Mengapa
Ukuran simpul	pool sistem Standard_D4s_v5, pool pengguna Standard_D8s_v5	Harga ke performa yang dapat diprediksi untuk beban kerja umum
Pengatur skala otomatis kluster	Enabled	Hindari membayar untuk node yang tidak terpakai
Identitas Beban Kerja	Enabled	Menggantikan identitas pod dan terintegrasi dengan Microsoft Entra ID
add-on untuk Azure Policy	Enabled	Pagar pembatas gratis (tanpa kontainer istimewa, label yang diperlukan)
Wawasan Kontainer	Enabled	Metrik dan log kelas satu di Azure Monitor
Kluster pribadi	Aktif untuk produksi	Sarana kontrol hanya dapat dijangkau dari VNet

Azure Container Registry

Terlepas dari platform komputasi mana yang Anda pilih, simpan gambar Anda di Azure Container Registry. Tingkat Dasar sudah cukup untuk tim tahap awal. Gunakan registri terpisah per lingkungan (produksi, penahapan) jika Anda menginginkan isolasi keras, atau satu registri dengan repositori terpisah dan kontrol akses berbasis peran jika Anda menginginkan kesederhanaan.

Platform data: relasional, dokumen, vektor, analitik

Keputusan platform data adalah keputusan yang paling mungkin permanen. Skema yang Anda kirimkan dalam sebulan satu membentuk setiap fitur selama dua tahun ke depan. Pilih default yang cukup fleksibel untuk tumbuh dengan produk, dan tahan godaan untuk memilih database khusus sebelumnya untuk fitur yang belum Anda buat.

Beban kerja Anda	Layanan Azure default	Mengapa	Kunjungi kembali kapan
Data aplikasi transaksional (pengguna, pesanan, konten) dengan skema relasional yang diketahui	Azure Database for PostgreSQL (Server Fleksibel)	Ekosistem ekstensi yang matang, dipahami secara luas, kuat (termasuk pgvector untuk penyematan). Tier burstable cukup murah untuk digunakan pada pengembangan dan staging.	Pola tulis multiwilayah atau pola baca hiperskala. Pertimbangkan Azure Cosmos DB untuk PostgreSQL.
Data operasional dengan skema yang fleksibel, distribusi global, pembacaan dalam hitungan milidetik satu digit yang dapat diprediksi	Azure Cosmos DB (NOSQL API)	Beberapa wilayah secara bawaan. Paket serverless cukup murah sebagai awal. Desain partisi penting; baca panduan kunci partisi sebelum Anda mengirim.	Anda memaksa gabungan relasional melalui lapisan aplikasi. PostgreSQL mungkin jawaban yang tepat.
Telusuri seluruh konten terstruktur dan tidak terstruktur, termasuk generasi berbantuan pengambilan	Pencarian Azure AI	Kata kunci hibrid dan pencarian vektor. Terintegrasi dengan Azure OpenAI Service dan Cosmos DB. Tingkat gratis tersedia untuk pembuatan prototipe.	Anda melebihi batas indeks per tingkat (Standar 1 adalah titik peningkatan umum).
Penyematan vektor untuk fitur pembuatan retrieval-augmented	Mulai dengan pgvector di PostgreSQL atau Pencarian Azure AI	Hindari basis data vektor terpisah untuk versi pertama fitur temu balik. Anda akan mempelajari apa yang sebenarnya Anda butuhkan (pemfilteran, pencarian hibrid, skala) dari penggunaan nyata.	Anda telah mengidentifikasi pola pembacaan Anda, dan kendala yang ada membenarkan penggunaan mesin khusus.
Analisis, pelaporan, dan kueri ad hoc terhadap data produksi	Azure Database for PostgreSQL replika baca (Jelajahi), Microsoft Fabric (Perluas dan Ekstrak)	Replika baca sudah memadai untuk sebagian besar analitik pada tahap Explore. Microsoft Fabric adalah platform analitik modern ketika solusi tersebut tidak lagi memadai bagi kebutuhan Anda.	Replika baca Anda tidak dapat mengikuti, atau pemangku kepentingan bisnis memerlukan permukaan analitik mandiri.
Lapisan cache di depan basis data	Azure Cache for Redis (Tingkat dasar)	Primitif cache standar. Murah untuk ditambahkan nanti; jangan tambahkan secara spekulatif.	Anda melihat pola pembacaan intensif yang jelas yang membebani database hingga jenuh. Ukur sebelum menambahkan.

Important

Pilih satu database default dan tetap di atasnya selama yang Anda bisa. Tim yang menjalankan PostgreSQL, Cosmos DB, Redis, AI Search, sistem antrean, dan basis data graf dengan hanya lima belas engineer tanpa sadar telah menciptakan beban kerja sebesar yang biasanya ditangani oleh satu tim platform.

Di mana Azure OpenAI Service cocok digunakan

Azure OpenAI Service bukan platform data, tetapi memiliki irama keputusan yang sama. Sebagian besar startup yang membangun fitur AI generatif memulai dengan satu penerapan model (model penyelesaian chat terbaru) di satu wilayah, ditambah AI Search atau pgvector untuk pengambilan data. Anda tidak memerlukan alur penyempurnaan khusus, gateway model, atau beberapa penyebaran hingga penggunaan memberi tahu Anda untuk menambahkannya.

Apa yang dibahas artikel ini (dan apa tidak)

Topic	Di artikel ini	Kapan harus menambahkannya
Manajemen identitas dan akses di luar dasar-dasar	No	Hari pertama untuk penyiapan Microsoft Entra ID. Akses Bersyarat dan Privileged Identity Management saat Anda menjalani peninjauan keamanan informasi.
Infrastruktur sebagai Kode (Bicep, Terraform)	No	Saat perubahan portal manual mulai melayang di antara lingkungan. Biasanya saat Anda menambahkan staging.
Integrasi berkelanjutan dan alur penyebaran berkelanjutan	No	Hari pertama. GitHub Actions atau Azure DevOps Pipelines, keduanya sama-sama bisa digunakan.
Pengamatan (log, metrik, jejak)	No	Application Insights sejak hari pertama. Azure Monitor buku kerja saat Anda mengalami kelelahan pemberitahuan.
Manajemen biaya	No	Tetapkan anggaran tingkat langganan pada hari pertama. Tambahkan tag pada sumber daya untuk lingkungan dan pemilik sejak awal.
Kepatuhan (SOC 2, ISO 27001, HIPAA)	No	Ketika pelanggan bertanya. Microsoft Defender untuk Cloud memiliki dasbor kepatuhan yang memetakan kontrol ke sumber daya Azure.
Pemulihan bencana dan multi-wilayah	No	Ketika biaya satu jam waktu henti melebihi biaya rekayasa wilayah kedua.

Ketika pengaturan bawaan platform tidak lagi memadai

Sinyal pertumbuhan ini memberi tahu Anda bahwa default tertentu membutuhkan penggantian yang lebih disyaratkan:

Anda telah menerapkan lebih dari lima layanan yang berbeda di App Service atau Container Apps, dan penskalaan tiap layanan mulai menjadi perhatian sehari-hari. Lihatlah Azure Kubernetes Service.
Tagihan Azure bulanan Anda tumbuh lebih cepat daripada pendapatan bulanan Anda selama dua bulan berturut-turut. Waktu untuk tinjauan Cost Management dan analisis Instans Cadangan atau Paket Penghematan.
Jaringan virtual Anda sekarang mencakup beberapa langganan atau wilayah. Lihat Azure Virtual WAN dan topologi hub-and-spoke.
Satu instance PostgreSQL tidak dapat memuat seluruh working set Anda di memori, dan replika baca pun tidak mampu mengatasi masalah ini. Lihat Cosmos DB untuk PostgreSQL atau arsitektur sharding.
Kueri analitik pada database produksi sangat memengaruhi latensi aplikasi. Pindahkan analitik ke Microsoft Fabric.
Anda menjalankan lebih dari dua akun penyimpanan per lingkungan untuk pola akses yang sama. Konsolidasikan.
Anda telah menambahkan negara ketiga dengan pelanggan yang membayar. Waktunya mengevaluasi wilayah kedua, penyimpanan dengan redundansi geografis, dan strategi perutean Front Door.