Dari ribuan sesi yang ada di re:Invent lalu, tidak semuanya berisi melulu tentang teknis yang mendalam. Beberapa sesi membahas tentang startup, termasuk yang ingin saya bahas kali tentang bagaimana Arsitektur di Startup Teknologi Terkini yang dibawakan oleh Mackenzie Kosut. Mackenzie Kosut adalah Global Startup Advocate di AWS. Mackenzie mengunjungi startup di seluruh dunia untuk mendengarkan apa yang mereka bangun dan memberikan bimbingan.

Mackenzie membagikan 4 praktik terbaik yang dia temukan terdapat di semua startup yang sukses tentang bagaimana mereka membentuk tim pengembang mereka. Dia memberikan contoh implementasi praktik ini dalam 6 perusahaan startup antara lain Zocdoc, Segment, Reddit, Intercom, Nextdoor, dan Oscar.

Empat praktik tersebut adalah 1) Cari dan hilangkan penghambat atau kondisi menunggu, 2) Dukungan terhadap tim pengembang, 3) Membuat semua proses menjadi terus-menerus dan berkelanjutan, dan 4) Menjaga sistem agar tetap sederhana.

Cari dan hilangkan penghambat atau kondisi menunggu

Pada setiap lingkungan startup yang dia pelajari, Mackenzie menginvestasikan waktunya dalam mencari penghambat proses atau kondisi menunggu. Umumnya masalah ini terdapat dalam interaksi antar manusia , misalnya ketika sebuah tim menunggu tim lain untuk menghidupkan server atau menunggu persetujuan. Sesudah menemukan kondisi-kondisi seperti ini Mackenzie dan timnya berusaha untuk mengubah prosesnya menjadi otomatis.

Sebagai contoh, di startupnya yang lama yakni Oscar, Mackenzie mengimplementasikan ChatOps, yakni mengembangkan sebuah chatbot yang dapat berinteraksi dengan pengembang untuk melakukan hal-hal yang biasanya dilakukan dan menghambat pengembang jika dilakukan manual. Dengan adanya chatbot, tim pengembang Oscar dapat meminta bot untuk membuat server atau database yang dapat langsung digunakan.

Mendukung tim pengembang

Dengan adanya lebih dari 100 pengembang, ZocDoc menghadapi tantangan untuk melakukan migrasi ke AWS cloud dan proyek open source karena para pengembangnya masih belum familiar. Untuk menyelesaikan masalah ini, ZocDoc memberikan budget sebesar 100 USD setiap bulannya bagi pengembang untuk mencoba layanan-layanan yang ada di AWS. Selanjutnya agar pengembang dapat lebih termotivasi untuk mencoba layanan tersebut, ZocDoc membangun budaya hackathon di mana pengembang dapat mengajukan ide dan mempresentasikan solusi layanan AWS yang digunakan. Budaya ini menyebabkan banyak inovasi yang terjadi di dalam ZocDoc dan mereka berhasil memigrasikan seluruh aplikasinya ke infrastuktur AWS.

Dari pengalaman ZocDoc, ada tiga pelajaran yang kita sebagai startup bisa tiru bagaimana ZocDoc sukses berinovasi dengan memberikan dukungan terhadap pengembangnya. Pertama, startup harus memberikan akses kepada pengembang agar dapat terus bereksperimen. Selanjutnya, tim ini harus didukung untuk bisa menghasilkan ide dan bereksperimen. Dan terakhir, kita harus terbuka terhadap ide dan saran yang dilayangkan dari setiap sudut pada organisasi kita.

Membuat semua proses menjadi terus-menerus dan berkelanjutan

Beberapa tahun lalu Nextdoor ingin mengurangi lama waktu dalam mendeploy layanan mereka ke production. Seperti banyak startup lainnya, porsi besar dari aplikasi Nextdoor adalah monolith ketimbang microservices. Langkah pertama yang mereka lakukan adalah dengan membuat proses deployment dari monolith tersebut menjadi proses terus-menerus dan berkelanjutan menggunakan proses release train. Proses ini membantu mereka mempunyai visibilitas terhadap lama deployment.

Saat itu mereka menggunakan deployment dengan membuat image debian ke EC2. Proses ini masih memakan waktu sekitar satu jam. Bayangkan jika ketika mereka mendeploy sebuah fitur kemudian seseorang menemukan sebuah bug. Mereka akan membutuhkan waktu satu jam lagi untuk mendeploy perbaikan ditambah waktu untuk memperbaiki bug tersebut.

Berangkat dari tantangan tersebut, Nextdoor terus mempertanyakan bagaimana cara menurunkan lama proses deployment dengan menginvestigasi tiap subproses dari deployment. Mereka akhirnya bisa menurunkan proses deployment menjadi 5-7 menit sebanyak 20-30 deployment setiap harinya dengan menggunakan Amazon ECS.

Menjaga sistem agar tetap sederhana

Mackenzie menyarankan agar tim pengembang membuat arsitektur aplikasinya menjadi sesederhana mungkin. Saat dia masih di Tumblr, timnya membuat apa yang disebut Pengujian Jam 3 Pagi. Jika terjadi kerusakan pada jam 3 pagi, ketika kita bangun saat itu dan diminta untuk menangani masalah tersebut, apakah kita bisa langsung memahami sistem tersebut dan menemukan akar masalah? Jika tidak, maka sistem yang kita buat terlalu kompleks.

Reddit dengan tim yang hanya berisi 2 orang dapat membangun sistem yang mampu melayani 1 milyar pemutaran video di situsnya. Apa yang dilakukan oleh tim ini adalah membangun sebuah sistem yang sederhana dalam waktu yang cukup singkat. Arsitekturnya berisi pemrosesan lambda untuk melakukan transcoding dari video yang diunggah ke S3 dan Amazon SQS dan SNS untuk mempublikasikan video kembali ke S3. Arsitekturnya sangat sederhana sehingga jika terjadi sesuatu kesalahan, sangat mudah untuk melihat arsitektur diagram (bisa dilihat di video di bawah) dan mencari letak kesalahan.

Untuk menjaga agar sistem selalu sederhana ada tiga hal yang bisa dilakukan. Hal pertama adalah gunakan produk-produk off-the-shelf sebisa mungkin. Kedua, jangan menciptakan hal yang sebenarnya sudah diciptakan. Kedua hal ini juga akan membantu kita agar bisa tetap fokus kepada produk yang membedakan kita dengan yang lain. Lalu ketiga, jangan berpikir bahwa sistem yang kompleks adalah elegan; justru sebaliknya, teruslah memikirkan bagaimana cara membuat sistem menjadi lebih sederhana.


Ini adalah salah satu tulisan dari seri re:Invent 2019 yang saya liput. Dalam tulisan ini saya meliput sesi berjudul “Startup Modern: Melihat Arsitektur dari Startup Sukses Hari Ini” yang dibawakan oleh Mackenzie Kosut, Global Startup Evangelist di AWS. Tulisan-tulisan lain yang terkait bisa dilihat di link ini. Youtube video dari sesi ini bisa diakses di link ini (atau putar di bawah).

Jika ada ide topik atau permintaan topik lain seputar AWS, silakan tulis di bagian komentar!

Leave a comment

Leave a Reply

%d bloggers like this: