Seri arsitektur evolusioner, bagian 3

“Capai peningkatan maksimal 🚀”

“Arsitektur Evolusioner” adalah seri blog empat bagian yang menunjukkan bagaimana desain dan keputusan solusi berkembang ketika perusahaan melalui tahapan siklus hidup perusahaan rintisan yang berbeda. Dalam seri ini, kami mengikuti Contoh Perusahaan Rintisan dengan ide untuk menciptakan aplikasi “pasar saham fantasi”, mirip dengan liga olahraga fantasi. Mereka membayangkan menggelar empat “turnamen” selama satu tahun.

Blog kedua menjelaskan bagaimana perusahaan rintisan mulai mengembangkan solusi teknis mereka sementara para pendiri bersiap-siap untuk penggalangan dana. Pada bagian 3, kita akan melihat bagaimana Contoh Perusahaan Rintisan berkembang lebih lanjut dalam mematangkan tumpukan teknologi mereka dan memosisikan diri dengan baik untuk skala yang lebih besar.

Penskalaan secara efisien dengan beralih ke arsitektur layanan mikro

Tim perdagangan saham fantasi terus berkembang dan komponen serta solusi baru sedang dibangun. Seiring dengan berkembangnya portofolio teknis, mulai muncul beberapa celah yang membutuhkan perhatian tim.

“Kebiasaan lama sulit dihilangkan,” dan tim mulai melihat bagaimana hal ini dapat menyebabkan masalah bagi pertumbuhan perusahaan rintisannya: Jadwal yang ketat dan antusiasme untuk menyelesaikan lebih banyak hal dengan waktu yang lebih singkat menyebabkan meningkatnya hutang teknis. Salah satu aspek dari hutang teknis ini adalah proliferasi monolit secara bertahap, yang berlawanan dengan arsitektur layanan mikro yang awalnya diputuskan oleh tim. Kekhawatiran monolit, seperti skalabilitas dan hambatan performa, mulai muncul saat pengujian dan pengenalan fitur-fitur baru. Untungnya, tim dengan cepat menyadari tantangan yang ditimbulkan oleh pendekatan monolitik ini terhadap penskalaan beban kerja yang optimal. Mereka memutuskan untuk kembali dan mengevaluasi ulang praktik pengembangan mereka. Salah satu developer ingat bahwa arsitek solusi AWS (SA) telah mengantisipasi beberapa masalah ini dalam percakapan sebelumnya. Tim Contoh Perusahaan Rintisan menjadwalkan panggilan dengan AWS untuk mendapatkan bantuan.

Memecah monolit dan bertransisi ke paradigma berbasis layanan mikro adalah topik yang luas sehingga AWS SA merekomendasikan Hari Imersi Modernisasi Aplikasi untuk tim di Contoh Perusahaan Rintisan. Hari imersi ini menggunakan lokakarya terkait sebagai latar belakang, dengan fokus pada beban kerja yang relevan dengan perusahaan rintisan. Acara ini dihadiri oleh hampir semua developer di perusahaan dan berakhir dengan perubahan besar. Selama satu hari, tim dapat mempelajari cara menentukan, mendesain, dan mengimplementasikan layanan mikro dengan benar. Mereka juga belajar tentang pemetaan jalur migrasi bertahap dari aplikasi monolit ke serangkaian layanan mikro tanpa harus mengulang semuanya sekaligus. Tim senang dapat mengetahui kesalahan mereka sejak dini dan mempelajari beberapa praktik terbaik yang akan membantu mereka pada masa mendatang. Arsitek solusi juga membagikan Laporan Resmi AWS yang berfokus pada strategi modernisasi yang dapat mengisi kesenjangan pengetahuan pada tim Contoh Perusahaan Rintisan.

Pengalaman dengan modernisasi aplikasi memberikan banyak sekali nilai bagi Contoh Perusahaan Rintisan sehingga tim memutuskan untuk menerapkan pendekatan yang sama dalam memanfaatkan praktik terbaik yang ada untuk area fungsional yang berbeda pada masa mendatang. Para rekayasawan dan manajer produk menjadwalkan panggilan untuk membagikan rencana kerja mereka selama sisa tahun ini dengan AWS, sebagai upaya untuk menghindari pekerjaan yang berulang-ulang. Contoh Perusahaan Rintisan telah menandatangani perjanjian kerahasiaan bersama (MNDA) dengan AWS dan terdapat pertukaran ide yang produktif di kedua belah pihak selama percakapan ini, serta beberapa kabar baik: Ternyata fitur yang sedang dipertimbangkan untuk dikembangkan oleh Contoh Perusahaan Rintisan sudah ada dalam rencana kerja AWS untuk kuartal berikutnya, dan hal ini akan meluangkan sebagian besar waktu rekayasa untuk tim.

Topik berikutnya pada daftar area Contoh Perusahaan Rintisan yang akan ditingkatkan berkaitan dengan Infrastruktur sebagai Kode (IaC), integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD), dan pengujian otomatis. Dua orang yang baru saja direkrut sebagai operasi developer (DevOps) tidak puas dengan banyak mekanisme operasional saat ini di perusahaan rintisan, terutama hal-hal, seperti pembangunan dan pengujian lingkungan, serta manajemen artefak kode. Adanya tim yang berkembang di Contoh Perusahaan Rintisan berarti terdapat lebih banyak orang yang memiliki akses ke proses sensitif ini sehingga menimbulkan risiko yang tidak perlu. Dua anggota tim baru sudah memiliki pengalaman dengan Terraform sebagai pendekatan mereka terhadap IaC. Mereka senang mengetahui bahwa AWS didukung dengan baik oleh Terraform, dan menemukan alat lain, seperti AWS CloudFormation dan AWS CDK jika diperlukan alternatif. Namun, mereka masih membutuhkan bantuan dengan pengaturan CI/CD mereka. Upaya mereka sejauh ini masih kurang kohesif dan terbukti sulit untuk membuat alat build bekerja dengan baik dengan alat deployment mereka. Selain itu, mereka masih mencari pendekatan yang cocok untuk mengelola citra kontainer mereka. Tim AWS merekomendasikan untuk melihat AWS CodePipeline karena memenuhi kebutuhan untuk mengintegrasikan build dan alat deployment tanpa hambatan dan juga mencakup pengujian otomatis, semuanya dipasangkan dengan dukungan untuk berbagai lingkungan. Menggunakan CodePipeline memungkinkan integrasi dengan solusi yang belum tentu dibangun secara native di AWS, serta dukungan kuat untuk alat lain, seperti AWS CodeBuild, AWS CodeDeploy, dan alat pihak ketiga. Menerapkan CodePipeline memungkinkan Contoh Perusahaan Rintisan untuk memeriksa item besar lain dari daftarnya.

Dengan tim yang sudah berada di jalur yang tepat untuk implementasi layanan mikro yang tepat, mereka merasa diberdayakan untuk mengatasi beberapa tantangan kompleks lainnya yang masih belum terselesaikan. Salah satunya, kehadiran beberapa layanan yang beroperasi secara independen secara alami memunculkan persoalan komunikasi di antara layanan-layanan ini. Terdapat tanda tanya besar seputar apakah setiap panggilan lintas layanan harus sinkron atau asinkron dalam komunikasi, disamping bagaimana tim dapat mulai mengadopsi pola praktik terbaik, seperti pesan publish/subscribe (PubSub). Tim ini sangat memahami bahwa mengadopsi arsitektur berbasis peristiwa akan bermanfaat, terutama dengan beralih dari arsitektur monolitik, tetapi mereka sedikit kewalahan dengan banyaknya rangkaian layanan AWS yang terkait dengan arsitektur tersebut, termasuk tetapi tidak terbatas pada Amazon EventBridge, Amazon Simple Queue Service (Amazon SQS), Amazon Simple Notification Service (Amazon SNS), dan Amazon Managed Streaming for Apache Kafka (Amazon MSK). Kali ini, tim dapat menemukan beberapa sumber daya sendiri sebagai titik awal yang baik, seperti beberapa lokakarya dan blog yang sangat berguna tentang topik tersebut. Paradigma " berbasis acara " perlahan-lahan menjadi alat tambahan di dalam kotak peralatan tim.

Mengembangkan strategi keamanan yang lebih kuat

Keamanan terus menjadi prioritas utama bagi perusahaan rintisan dan alat bantu, seperti AWS Startup Security Baseline (AWS SSB) membantu mereka untuk memulai. Sayangnya, Anda tidak mungkin bisa memiliki keamanan yang maksimal. Implementasi awal AWS WAF merupakan langkah awal yang baik, tetapi tim perlu mulai berpikir lebih proaktif tentang pencegahan, deteksi, dan perbaikan. Mereka mulai meningkatkan keterampilan mereka pada banyak layanan AWS yang berfokus pada keamanan yang dapat membantu mereka menerapkan strategi keamanan yang kuat.

Tim yang terus berkembang dan keterlibatan partner membuat kontrol akses, perizinan, dan tata kelola menjadi topik lain yang membutuhkan lebih banyak perhatian. Tim ini mencoba menerapkan praktik terbaik, seperti prinsip hak akses yang paling rendah ketika menerapkan izin. Setidaknya, mereka ingin memindahkan beban kerja produksi ke dalam akun mereka sendiri yang terpisah. Ketika tim mengadopsi praktik-praktik terbaik ini, mereka melihat peningkatan kompleksitas operasional karena adanya tambahan lapisan manajemen dan izin yang harus mereka tangani. Menjadi sangat jelas bahwa mereka membutuhkan pendekatan mekanis untuk struktur akun. Seseorang menyinggung tentang AWS Organizations, yang tampaknya merupakan langkah ke arah yang benar sehingga mereka menghubungi AWS SA tepercaya untuk berdiskusi. SA membagikan beberapa saran yang relevan, seperti mempertimbangkan AWS Control Tower sebagai pendekatan yang lebih mudah untuk mengelola banyak akun dan AWS Organizations. Karena ini adalah langkah pertama dari banyak langkah untuk mencapai strategi multi-akun yang kuat, AWS SA juga membagikan panduan preskriptif “Bertransisi ke beberapa akun AWS” kepada tim. Panduan ini mencakup praktik terbaik seputar migrasi akun, manajemen pengguna, jaringan, keamanan, dan arsitektur saat beralih ke pengaturan beberapa akun.

Mengoptimalkan beban kerja untuk performa

Tim ini sedang menangani beberapa bagian fundamental sehingga perusahaan rintisan ini akan siap untuk tumbuh dengan kecepatan yang tepat. Beberapa hal utama telah dicoret dari daftar dan yang lainnya telah memiliki rencana aksi. Para developer berusaha semaksimal mungkin untuk mengoptimalkan beban kerja mereka demi performa, tetapi mereka juga telah mengidentifikasi beberapa peluang untuk peningkatan lebih lanjut yang melampaui kode, seperti edge caching dengan Amazon CloudFront, caching di tingkat aplikasi dengan caching Amazon ElastiCache dan Database. Tim ini semakin bergantung pada Layanan Terkelola AWS untuk memberikan fungsionalitas yang mereka butuhkan sekaligus meminimalkan kompleksitas operasional yang terkait. Layanan terkelola lain yang ditemukan oleh beberapa developer dan ternyata sangat mudah digunakan adalah AWS Batch. Pendekatan pemrosesan feed awal dengan AWS Lambda mulai mencapai batasnya karena peningkatan eksponensial dalam volume data yang perlu diproses. Setelah beberapa kali bereksperimen, para developer dapat memetakan jalur untuk menggunakan AWS Batch yang memungkinkan mereka untuk terus berkembang dengan peningkatan beban operasional yang relatif kecil dan dengan biaya yang tetap rendah.

Membuktikan proposisi nilai perusahaan rintisannya

Semua kerja keras di Contoh Perusahaan Rintisan ini tidak luput dari perhatian. Membangun dengan cara yang tangkas, tetapi berkelanjutan tanpa bergantung pada solusi jangka pendek menunjukkan bahwa perusahaan sedang memikirkan jangka panjang, menunjukkan kematangan, dan memiliki kemampuan untuk memberikan. Ciri-ciri ini bersama–dengan solusi inovatif dan kesesuaian pasar produk yang baik—adalah inti dari proposisi nilai perusahaan. Para pendiri berhasil menyampaikan nilai perusahaan mereka kepada beberapa perusahaan modal ventura yang berbeda dan menutup putaran pendanaan Seri A pertama mereka. Contoh Perusahaan Rintisan sedang dalam usaha mencapai peningkatan maksimal.

Lihat blog pertama dan blog kedua dalam seri Arsitektur Evolusioner.