Di bagian 2 seri ini , kami menerapkan konsep yang pertama kali diperkenalkan di bagian 1 dan merancang startup perangkat lunak kencan online fiktif bernama eTumble. Kami menghasilkan "dokumen hidup" untuk strategi, desain, dan arsitektur kami. Tujuan dari posting ini untuk menyatukan semuanya dan merencanakan infrastruktur yang diperlukan untuk mewujudkan ide kami, dan mengakomodasi kebutuhan penskalaan kami di masa depan.

Prasyarat untuk bergerak maju

• Anda telah membaca bagian 1 dari seri ini
• Anda sudah familiar dengan framework/metodologi yang kami jelajahi di bawah ini dengan setidaknya menonton tautan video yang dibagikan di bagian 1
• Anda telah membaca bagian 2 dari seri ini

Tanpa menulis satu baris kode pun atau mengeluarkan uang , latihan "dokumen hidup" kami yang dibuat di bagian 2 mengungkapkan persyaratan sistem yang menginformasikan kebutuhan infrastruktur hosting kami di masa mendatang:

Kami tidak perlu segera memenuhi semua kebutuhan "di luar", tetapi menyadarinya saat merancang dan membangun MVP kami dapat membantu meminimalkan pengerjaan ulang. Mari jelajahi caranya!

Lingkup MVP awal berdasarkan peta cerita dan OGSM

eTumble bersiap untuk menjadi hal besar berikutnya dalam kencan online. Tim kami telah dengan bijak meluangkan waktu untuk melakukan analisis SWOT, mendokumentasikan rencana strategis 3–5 tahun kami menggunakan OGSM Framework, memvisualisasikan dan memprioritaskan MVP kami menggunakan Story Mapping, dan merancang serta mendokumentasikan arsitektur kami menggunakan bagian dari metodologi Model C4.

Rencana OGSM kami mengidentifikasi tujuan awal 25.000 pengguna di tahun pertama, dan taktik untuk mencapai tujuan kami seperti program rujukan, dan demo kampus. Setelah beberapa iterasi pemetaan cerita, kami menetapkan cakupan MVP kami — dan menuliskannya .

Jika kami melewatkan perencanaan strategis untuk mengidentifikasi pentingnya promosi, kami mungkin tidak cukup mengulangi peta cerita untuk menyelesaikan MVP, yang membantu memprioritaskan apa yang kami buat terlebih dahulu. Lebih menakutkan lagi, kami mungkin menyebutnya "Mike's Match Maker" (di atas) alih-alih nama kami yang lebih keren, eTumble. ;-)

Mendapatkan MVP kami ke tangan pengguna yang dituju dengan cepat akan memberi kami pemahaman yang lebih baik tentang domain masalah, dan akibatnya memengaruhi keputusan di tingkat strategis dan ide. Inilah mengapa rencana kami disebut sebagai "dokumen hidup" dan harus diulang dari waktu ke waktu saat kami mempelajarinya.

Memilih platform cloud hosting kami

Memilih vendor cloud hosting dapat menjadi latihan politik, atau agama, dalam organisasi atau tim mana pun. Saya lebih suka menggunakan pendekatan berbasis data untuk keputusan ini dan menjelaskan bagaimana kami melakukannya di perusahaan sebelumnya dalam wawancara BrightTALK tahun 2020 ini.

Di bagian awal seri ini, saya menghindari fakta bahwa kami akan menggunakan Google Cloud Platform (GCP), jadi saya akan menjelaskan secara singkat pendekatan tipikal saya.

Saya telah mengatur proses ini di organisasi sebelumnya, dan salah satunya memiliki lini produk dengan strategi yang mengutamakan seluler, jadi alasan saya memilih GCP berasal dari pengalaman sebelumnya, dan mendukung ribuan perusahaan di DoiT. AWS Amplify adalah solusi yang bersaing, namun kalah dibandingkan dengan Firebase GCP yang menggunakan banyak kriteria di atas, terutama kemudahan penggunaan.

Artikel ini merinci lebih lanjut membandingkan dua kerangka kerja seluler populer, Firebase GCP vs. AWS Amplify , tetapi berada di balik paywall Medium. Konsensusnya adalah Firebase lebih komprehensif, lebih mudah digunakan, dan mungkin lebih hemat biaya.

Apa pun platform yang Anda pilih, kami telah mengidentifikasi persyaratan jangka pendek dan jangka panjang dari sistem kami. Anggaplah kita telah melalui proses evaluasi di atas, memilih GCP karena berbagai alasan, dan sekarang harus merancang infrastruktur cloud hosting kita.

Mengotomatiskan penerapan kode sumber kami

Selain orang-orangnya, inti dari setiap startup perangkat lunak adalah kode sumber mereka — teks terstruktur yang diubah menjadi instruksi yang dapat dipahami dan diproses oleh komputer. Agar program kami dapat menjangkau audiens yang kami tuju (dengan asumsi tidak ada "MVP Layar Asap" pada tahap ini), program tersebut perlu diterapkan ke lingkungan hosting pilihan kami.

Salah satu strategi kami untuk eTumble adalah berinovasi lebih cepat daripada yang lain. Meskipun ini dapat menjelaskan banyak aspek dari permulaan perangkat lunak, kami akan fokus pada kecepatan pengembang dan kecepatan di mana fungsionalitas baru (cerita pengguna) dapat direalisasikan oleh pengguna akhir. Ada penelitian yang membuktikan ini sebagai keunggulan kompetitif, namun kami tidak akan membahas semua detail pipa DevOps dan DevSecOps serta CI/CD dalam artikel ini.

Bagaimana hal ini terjadi dapat menjadi preferensi pribadi dari tim pengembangan. Banyak vendor hosting kode sumber (misalnya, — Github.com, Gitlab.com, atau Bitbucket.com) sekarang memiliki perkakas sendiri. Banyak juga yang menawarkan webhook saat terjadi peristiwa yang memicu solusi pihak ketiga. Setiap penyedia cloud hosting juga memiliki layanannya sendiri, seperti Azure Dev Ops dari Microsoft, atau Cloud Build dan Cloud Deploy dari GCP.

Biasanya, rekomendasi saya untuk sebagian besar organisasi adalah mempertimbangkan solusi penyedia cloud, minimal untuk fase "penyebaran" jaringan pipa pembangunan Anda, karena ini menghilangkan kebutuhan untuk berbagi kunci akun layanan jangka panjang (yang dapat dikompromikan) dengan pihak ke-3 sistem. GCP menawarkan Workload Identity Federation yang memungkinkan Anda menetapkan peran IAM ke solusi pihak ketiga tanpa berbagi kunci, yang juga merupakan opsi.

Pertimbangan untuk penskalaan di cloud

Untuk monolit atau tidak

Mari kita hadapi itu, sebagian besar startup perangkat lunak yang sukses secara global saat ini dimulai sebagai aplikasi monolit 3 tingkat. Tidak ada yang salah dengan monolit pada tahap awal. Coupling meminimalkan banyak kerumitan teknis dan sebagai "Topologi Tim" menyiratkan keputusan ini sering tentang beban kognitif pada tim Anda . Dengan tujuan 25.000 pengguna di tahun pertama kami, dan fokus kampus, ini adalah desain yang sepenuhnya dapat diterima untuk apa yang tercakup dalam MVP kami.

Masalahnya sering terjadi saat Anda mulai menskalakan. Namun, jangan takut, karena kami dapat merancang solusi "cepat-dan-kotor" kami untuk dengan mudah memperhitungkan arsitektur layanan mikro kami di masa depan.

Dalam diagram arsitektur Model C4 kami, kami mengidentifikasi "Pengontrol" dalam tampilan komponen, untuk aplikasi "Backend API". Baris yang menunjukkan penerbitan pesan ke Pub/Sub, misalnya, pada awalnya dapat menyertakan logika layanan mikro dalam aplikasi API pada lapisan "Model" dari arsitektur Model-View-Controller (MVC). Rute API tetap sama.

Saat memperhitungkan layanan mikro, kami dapat memindahkan fungsionalitas "Model" dari aplikasi API ke layanan terpisah dan berkomunikasi melalui HTTP/RPC atau perpesanan asinkron. Jika Anda berencana ke depan, Anda dapat mendesain lapisan pembungkus untuk pemanggilan fungsi atau metode yang awalnya berinteraksi dengan lapisan data, dan beralih ke panggilan jarak jauh di masa mendatang dengan sedikit perubahan kode.

Namun, jika Anda telah merancang sistem terdistribusi yang cukup, Anda dapat memilih arsitektur berbasis peristiwa seperti yang diilustrasikan dalam Diagram Kontainer kami.

Menjadi "tanpa server" atau menggunakan wadah

Di awal seri 3 bagian ini saya menyatakan bahwa startup perangkat lunak saat ini memiliki keunggulan dibandingkan lima hingga sepuluh tahun yang lalu, sebagian karena penyedia cloud hyperscale. Produk tanpa server seperti AWS Lambda, Google Cloud Functions, atau bahkan Azure Functions adalah contoh yang bagus. Pengembang dapat mendorong kode mereka ke "runtime" ini dan mendapat manfaat dari tanpa pemeliharaan infrastruktur dan penskalaan otomatis.

Meskipun ini tampak seperti pendekatan yang jelas untuk meluncurkan MVP Anda, perhatikan ladang ranjau utang teknis yang Anda tanam di sepanjang jalan. Beberapa layanan ini menawarkan emulator sehingga Anda dapat membuat dan menguji secara lokal, membantu mengurangi ketergantungan dan biaya lingkungan lain.

Saya lebih suka memanfaatkan solusi tanpa server untuk pekerjaan asinkron tujuan tunggal kecil yang dipicu oleh peristiwa di sistem Anda seperti "file diunggah atau diubah" atau "pesan diterbitkan".

Untuk membuat API yang akan merutekan permintaan ke berbagai bagian backend, aplikasi dalam container mungkin merupakan pilihan yang lebih bijaksana. Karena semua dependensi dikemas dalam image, container menyederhanakan pengembangan dan pengujian lokal. Sebagian besar penyedia cloud hosting menawarkan solusi container “tanpa server” seperti ECS di AWS, dan Cloud Run atau App Engine Flexible di GCP.

Saya lebih suka portabilitas kontainer untuk aplikasi yang lebih kompleks dan jika Anda mengikuti prinsip metodologi aplikasi 12 faktor , mereka juga mengurangi risiko pergeseran konfigurasi ke lingkungan yang berbeda dalam pipa CI/CD Anda.

Priyanka Vergadia di Google menyediakan koleksi "catatan sketsa" dan ilustrasi di bawah ini " Di mana saya harus menjalankan barang-barang saya " adalah panduan yang berguna.

Memanfaatkan grup email untuk menskalakan dari satu tim ke banyak tim

Asumsikan kami memulai dengan beberapa orang tetapi rencana kami pada akhirnya membutuhkan dukungan puluhan juta pengguna di banyak negara. Kami pasti akan menskalakan organisasi kami untuk menyertakan banyak tim dan spesialis (sumbu y, dan sumbu z dari Skala Cube AKF juga berlaku untuk organisasi kami).

Praktik terbaik saat menyiapkan Identity and Access Management (IAM) dengan platform cloud adalah menetapkan peran ke grup, bukan ke pengguna individual. Dalam sebuah artikel yang saya tulis beberapa tahun lalu tentang penataan perusahaan di cloud , saya menjelaskan grup awal yang direkomendasikan dan banyak lagi.

grup yang kami dirikan pada tahap awal dapat disesuaikan dengan organisasi (hanya anggota yang berubah seiring waktu)

Bahkan jika startup kami dimulai dengan tiga orang, tidak ada yang menghentikan kami untuk menentukan grup dan menambahkan orang ke beberapa grup untuk memulai . Saat kami mempekerjakan lebih banyak orang, kami dapat secara bertahap menyerahkan grup kepada spesialis.

Pada skala perusahaan, Anda pada akhirnya dapat memecah tim lebih jauh sesuai kebutuhan dan tuntutan beban kognitif. Dari mana pun Anda memulai, praktik terbaiknya adalah memberikan peran cloud IAM kepada grup, bukan pengguna individu, agar lebih mudah mempertahankan dan meminimalkan pengerjaan ulang — perhatikan polanya di sini.

Merancang hierarki sumber daya cloud Anda untuk multi-tenancy

Daftar periksa Referensi GCP Aman yang saya tulis beberapa tahun lalu menyertakan contoh ilustrasi desain praktik terbaik yang direkomendasikan. Saat kami merancang arsitektur cloud kami untuk MVP kami, mungkin ada beberapa pekerjaan "buang" selama tahap awal, tetapi saya masih merekomendasikan struktur serupa saat menyiapkan hierarki sumber daya cloud apa pun.

Saat organisasi berkembang, menuju versi produk yang lebih baru yang diilustrasikan dalam peta cerita pengguna kami, kami dapat beralih ke administrasi jaringan terpusat, manajemen klaster Kubernetes, dan struktur tim multi-penyewa. Hal ini sering membuat startup perangkat lunak tersandung saat mereka mencapai titik belok yang dijelaskan di bagian 1 seri ini.

mungkin ada beberapa pekerjaan "buang" selama tahap awal

GCP memiliki referensi bagus yang menjelaskan cara membangun multi-tenancy perusahaan dengan lebih detail. Di bawah ini adalah ilustrasi seperti apa infrastruktur cloud eTumble di masa mendatang ketika kami mencapai tujuan Y2 dan Y3 kami (mengabaikan tampilan sumber daya untuk mempersingkat artikel).

Poin utama di sini adalah untuk memperhatikan bahwa proyek folder layanan bersama awal tidak pernah berubah, dan grup yang kami buat pada tahap awal dapat disesuaikan dengan organisasi (hanya anggota yang berubah seiring waktu). Setiap penyewa (tim) mempertahankan sumber daya khusus mereka seperti database dan rahasia dalam proyek masing-masing, dan direferensikan dari aplikasi kemas yang diterapkan ke kluster di ruang nama masing-masing.

Sistem eksternal (otentikasi, pembayaran, email, dll.)

Rencana dan desain kami mengilustrasikan kebutuhan akan sistem eksternal seperti email transaksional, pembayaran online, dan kemungkinan identitas dan autentikasi. Saat memilih penyedia solusi eksternal, pertimbangkan hal berikut:

• beberapa lingkungan untuk pengujian dan produksi dengan autentikasi terpisah
• mempertahankan dan merotasi kredensial di penyimpanan rahasia terenkripsi
• insentif komersial tersedia untuk dibeli melalui pasar

Selamat karena berhasil sejauh ini! Seri 3 bagian ini membawa Anda dalam perjalanan dari metodologi dan kerangka kerja yang berguna, hingga merancang startup perangkat lunak dari awal, dan terakhir menggunakan "dokumen hidup" untuk merencanakan infrastruktur cloud untuk tahap awal dan selanjutnya.

• Bagian 1: pengantar latar belakang dan metodologi
• Bagian 2: menerapkan metodologi dengan startup fiktif
• Bagian 3: merancang dan menskalakan infrastruktur cloud

Saya menantikan Anda mengambil prinsip-prinsip ini dan menyelesaikan di mana kita tinggalkan untuk membantu mengatasi kesepian dalam skala planet . ;-)

Jika Anda merasa seri ini akan bermanfaat bagi orang lain, tolong jangan merahasiakannya. Berikan setiap bagian beberapa "cinta" dan tepuk tangan, dan bagikan dengan yang lain. Terima kasih sudah membaca!