Arsitektur tumpukan startup inti
Banyak pelajaran yang Anda pelajari di perusahaan yang lebih besar tidak secara langsung berlaku untuk tumpukan pertama startup. Dalam tahap penjelajahan awal produk, Anda perlu mengoptimalkan penyebaran untuk kecepatan, biaya, dan opsionalitas. Opsionalitas mengacu pada seberapa cepat Anda dapat mengubah arah dalam arsitektur tertentu.
Bisnis dalam fase perluasan atau ekstrak pengembangan produk mungkin menggunakan arsitektur layanan berorientasi layanan atau mikro. Jenis arsitektur penyebaran ini jarang tepat untuk startup yang belum menemukan produk/pasar cocok atau traksi komersial.
Untuk tumpukan startup inti, desain monolitik sederhana adalah yang terbaik. Desain ini membatasi waktu yang dihabiskan untuk mengelola infrastruktur, sekaligus memberikan kemampuan yang cukup untuk menskalakan karena startup memenangkan lebih banyak pelanggan.
Kemungkinan kasus penggunaan
Artikel ini menyajikan contoh tumpukan startup inti sederhana, dan membahas komponennya.
Arsitektur
Startup, Contoso, telah membangun prototipe aplikasi dengan back end Ruby on Rails dan front end React yang ditulis dalam TypeScript. Tim Contoso telah menjalankan demo di laptop mereka. Sekarang mereka ingin menyebarkan aplikasi mereka untuk pertemuan penjualan pelanggan pertama mereka.
Nota
Pilihan teknologi di sini dari Ruby, React dan TypeScript hanya ilustrasi. Arsitektur startup ini sama-sama berlaku untuk banyak bahasa dan kerangka kerja lainnya.
Meskipun aplikasi ini ambisius, aplikasi ini belum membutuhkan arsitektur yang kompleks dan berbasis layanan mikro. Contoso memilih desain monolitik sederhana yang mencakup komponen tumpukan startup yang direkomendasikan.
Unduh file Visio dari arsitektur ini.
Aliran Data
Dalam arsitektur tumpukan startup inti ini:
Azure App Service menyediakan server aplikasi sederhana untuk menyebarkan aplikasi yang dapat diskalakan tanpa mengonfigurasi server, load balancer, atau infrastruktur lainnya. App Service mendukung penyebaran kontainer seperti dalam contoh di sini, dan juga mendukung penyebaran tanpa kontainer untuk ASP.NET, ASP.NET Core, Java, Ruby, Node.js, PHP, atau Python.
Azure Database for PostgreSQL adalah layanan database Azure untuk sistem manajemen database relasional sumber terbuka (RDBMS) terkemuka. Anda dapat berkonsentrasi pada pengembangan aplikasi Anda daripada mengelola server database.
Azure juga memiliki layanan database terkelola untuk SQL, MySQL, MongoDB, Apache Cassandra, Gremlin, dan Redis.
Selain penawaran terkelola, Azure Marketplace mencakup database yang digunakan dalam arsitektur startup juga, seperti CockroachDB, Neon Serverless Postgres, dan SQLite.
Azure Virtual Network mengegmentasi lalu lintas jaringan dan menjaga layanan internal tetap terlindungi dari ancaman internet. Server aplikasi Anda menggunakan integrasi jaringan virtual untuk berkomunikasi dengan database tanpa paparan internet.
GitHub Actions membangun integrasi berkelanjutan dan penyebaran berkelanjutan (CI/CD) ke dalam manajemen kode sumber Anda. GitHub Actions memiliki dukungan yang luas untuk berbagai bahasa, dan integrasi yang kuat dengan layanan Azure.
Azure Blob Storage menyimpan aset statis dan memindahkan beban jauh dari server aplikasi.
Azure Front Door dengan WAF mempercepat dan mengamankan pengiriman konten kepada pengguna melalui jaringan pengiriman konten global (CDN) dan firewall aplikasi web.
Azure Monitor memantau dan menganalisis apa yang terjadi di seluruh infrastruktur aplikasi Anda.
Komponen tumpukan startup inti
Tumpukan kompleks dapat menghasilkan bug yang membutuhkan perhatian konstan. Arsitektur canggih mungkin mengurangi membangun produk Anda. Bug tidak disebabkan oleh kompleksitas, tetapi tumpukan kompleks membuatnya lebih mudah untuk mengirim bug. Tidak semua arsitektur canggih membuang-buang energi, tetapi membuang-buang sumber daya Anda jika Anda belum menemukan produk/pasar yang cocok. Tumpukan startup pertama Anda harus sederhana dan keluar dari jalan Anda, sehingga Anda dapat berkonsentrasi pada pengembangan produk.
Diagram sederhana berikut menunjukkan tumpukan startup inti yang direkomendasikan. Komponen-komponen ini cukup untuk mendapatkan produk Anda dari tanah dan ke tangan pelanggan Anda. Untuk 80 persen startup, tumpukan ini adalah semua yang Anda butuhkan untuk menguji hipotesis dasar yang dibangun ke dalam produk Anda. Startup yang bekerja dalam pembelajaran mesin, internet of things (IoT), atau lingkungan yang sangat diatur mungkin memerlukan lebih banyak komponen.
CDN
Dengan beberapa pelanggan di awal, CDN mungkin tampak prematur. Namun, menambahkan CDN ke produk yang sudah dalam produksi dapat memiliki efek samping yang tidak terduga. Yang terbaik adalah mengimplementasikan CDN di muka. CDN menyimpan konten statis lebih dekat dengan pelanggan Anda, dan menyediakan fasad di belakang yang dapat Anda iterasi pada API dan arsitektur Anda.
Server aplikasi
Kode Anda perlu berjalan di suatu tempat. Idealnya, platform ini harus mempermudah penyebaran, sekaligus membutuhkan input operasional yang paling tidak mungkin. Server aplikasi harus menskalakan secara horizontal, tetapi beberapa intervensi penskalaan manual baik-baik saja saat Anda masih dalam tahap penjelajahan.
Seperti kebanyakan tumpukan ini, server aplikasi pada dasarnya harus berjalan sendiri. Secara tradisional, server aplikasi adalah komputer virtual, atau instans server web yang berjalan di server bare-metal. Sekarang, Anda dapat melihat opsi platform-as-a-service (PaaS) seperti App Service di atas dan kontainer untuk menghapus overhead operasional.
Konten statis
Menyajikan konten statis dari server aplikasi Anda membuang sumber daya. Setelah Anda mengonfigurasi alur CI/CD, pekerjaan untuk membangun dan menyebarkan aset statis dengan setiap rilis adalah sepele. Sebagian besar kerangka kerja web produksi menyebarkan aset statis dengan CI/CD, jadi ada baiknya untuk memulai dengan menyelaraskan dengan praktik terbaik ini.
Basis data
Setelah aplikasi berjalan, Anda perlu menyimpan data anda dalam database. Untuk sebagian besar kasus, database relasional adalah solusi terbaik. Database relasional memiliki beberapa metode akses dan kecepatan solusi yang diuji waktu. Database relasional mencakup Azure SQL Database dan Azure Database for PostgreSQL. Beberapa kasus penggunaan memerlukan database dokumen atau database NoSQL seperti MongoDB atau Azure Cosmos DB.
Agregasi log
Jika ada yang salah dengan aplikasi Anda, Anda ingin menghabiskan waktu sesedikim mungkin mendiagnosis masalah. Dengan menggabungkan log dan menggunakan pelacakan aplikasi dari awal, Anda membantu tim Anda fokus pada masalah itu sendiri. Anda tidak perlu mengakses file di server aplikasi dan melakukan pore melalui log untuk mendapatkan data pemantauan.
CI/CD
Kurangnya penyebaran yang dapat diulang dan cepat adalah salah satu hambatan terburuk untuk mempercepat ketika Anda melakukan iterasi pada produk. Alur CI/CD yang dikonfigurasi dengan baik menyederhanakan proses penyebaran kode di server aplikasi Anda. Penyebaran cepat dan mudah berarti Anda melihat hasil tenaga kerja Anda dengan cepat. Integrasi yang sering menghindari basis kode berbeda yang menyebabkan konflik penggabungan. Konsep dan tekniknya sama untuk sebagian besar proyek yang Anda buat dengan menggunakan Dockerfile.
Kontributor
Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.
Penulis utama:
- Andrew Harvey | CTO dan Advokat Startup
Kontributor lain:
- Bangsal Nick | Arsitek Solusi Cloud
Langkah selanjutnya
Sumber daya terkait
- Arsitektur untuk startup
- Praktik terbaik dalam aplikasi cloud
- Cara-cara terbaik untuk menggunakan jaringan pengiriman konten (CDN)
- Sepuluh prinsip desain untuk aplikasi Azure