Catatan Petra: Sebelum bergabung dengan AWS, saya banyak sekali membaca kisah-kisah langsung tentang bagaimana Amazon mentransformasikan proses pengembangannya untuk meningkatkan kualitas pengalaman pengguna termasuk membangun peralatan untuk mengefisiensikan proses pengembangan.

Di bagian kedua ini, Adrian akan membahas bagaimana Budaya dan Peralatan bisa sejalan dan bagaimana perusahaan bisa mendapatkan keuntungan dari mengadopsi peralatan. Selamat membaca!



Sekali lagi, saya ingin mengucapkan terima kasih kepada Peter Vosshall, Distinguished Engineer di AWS, untuk inspirasi di balik rangkaian posting ini. Saya juga ingin mengucapkan terima kasih kepada kolega dan teman saya Chris Munns, Matt Fitzgerald dan Aileen Gemma Smith atas umpan balik mereka yang berharga.

Kita menjadi apa yang kita perhatikan. Kita membentuk peralatan kita dan kemudian peralatan kita membentuk kita.

Marshall McLuhan

Setelah sebuah sistem dirancang, diimplementasikan, dan diuji, kita sampai pada apa yang bisa dibilang salah satu tantangan terbesar dalam siklus hidup suatu sistem: membuatnya hidup dan mempertahankannya dalam operasi. Rangkaian tulisan ini berfokus pada Keunggulan Operasional (Operational Excellence / OE) – khususnya, tiga elemen yang saling terhubung yang memungkinkan kita untuk berhasil mengoperasikan teknologi yang kita bangun: Budaya, Peralatan, dan Proses.


Sebagaimana dibahas dalam Bagian 1 tentang Budaya, diperlukan tiga elemen yang saling terhubung untuk mengoperasikan teknologi yang kita bangun dengan sukses. Pertama, Anda harus memiliki budaya yang tepat. Kedua, Anda membutuhkan peralatan yang hebat. Dan ketiga, Anda membutuhkan proses yang lengkap.

Bagian 1 dari seri ini membahas sisi budaya OE dan memeriksa budaya Amazon dalam konteks Prinsip Kepemimpinan (Leadership Principle / LP). LP ini adalah DNA perusahaan dan prinsip panduan yang digunakan setiap Amazonian dalam beroperasi. Di Bagian 2, saya membahas peralatan tetapi akan terus menggunakan Prinsip Kepemimpinan sebagai kerangka kerja pendukung untuk memahami motif dan keputusan yang dibuat. Bagian 3 akan membahas proses.

Mari Kita mulai!


Sedikit sejarah

Tentu saja ada beragam perangkat peralatan yang diperlukan untuk mengoperasikan cloud. Kategori penting tercantum di sini:

Otomasi Pengujian (Test Automation)
Manajemen Konfigurasi (Configuration Management)
Penerapan Perangkat Lunak (Software Deployment)
Pemantauan dan Visualisasi (Monitoring and Visualization)
Pelaporan (Reporting)
Manajemen Perubahan (Change Management)
Manajemen Insiden (Incident Management)
Pentiketan Permasalahan (Trouble Ticketing)
Audit Keamanan (Security Auditing)
Peramalan dan Perencanaan (Forecasting and Planning)

Untuk memahami pentingnya peralatan, mari selami Penerapan Perangkat Lunak dan bagaimana hal tersebut memberikan dampak dan membentuk Amazon.

Pada hari-hari awal, sistem yang menjalankan toko buku amazon.com relatif sederhana, menggabungkan arsitektur tiga tingkat (three-tier) dengan halaman depan, server web, database, dan beberapa peralatan internal.

Saat kita bekerja dengan aplikasi monolitik, pengembang mendorong perubahan melalui pipa perilisan (release pipeline) yang berbagi dengan pengembang yang lain sehingga dapat menyebabkan gesekan.

Pertama, semua tim yang berbeda perlu mengoordinasikan perubahan untuk menghindari pelanggaran kode milik orang lain. Memutakhirkan pustaka (library) untuk tujuan keamanan atau kinerja memerlukan restu dan dukungan semua orang karena semua orang harus memutakhirkan pada saat yang sama. Perbaikan dan tambalan cepat membutuhkan persetujuan yang serupa. Itu menyebabkan adanya freeze-merge Jumat, atau lebih buruk, freeze-merge selama berminggu-minggu. (Catatan Petra: freeze-merge adalah keadaan di mana pengembang tidak boleh melakukan penggabungan kode terutama ke produksi untuk hingga yakin kode tersebut tidak akan menyebabkan kerusakan)

Setelah pengembangan fitur, Anda dihadapkan dengan pertanyaan sulit: Bagaimana Anda mendorong perubahan ini melalui pipa pengiriman?

Karena semua pengembang berbagi segala hal, Anda perlu membangun kembali seluruh aplikasi, menjalankan seluruh test-suite, dan melakukan deployment ulang semua komponen.

Bahkan perubahan satu-baris atau kecil dalam kode perlu melalui proses ini. “Proses perubahan satu baris” yang mahal ini adalah alasan mengapa tim deployment memiliki proses “fast deploy”, yang mencakup melangkahi bagian kontrol kualitas di pipeline dan menambahkan lebih banyak risiko dan potensi kegagalan

Amazon dulu memiliki tim yang tersentralisasi dan berdedikasi yang dikenal sebagai “Houston”. Tugas utamanya adalah melakukan deployment aplikasi situs web monolitik ini ke dalam produksi menggunakan skrip Perl yang menjalankan “website-push“.

Memanggil Houston

Nama Houston berkaitan dengan fakta bahwa penyebaran itu berisiko saat itu.

“Aplikasi ini telah dideploy!”

akan sering diikuti oleh:

“Houston, kita punya masalah.”

Membangun Goliat

Fase kedua dari deployment adalah untuk menyalin build terbaru dari alat command-line ke server NFS yang terpusat. Hal ini cukup memungkinkan hingga server NFS gagal dan merusak seluruh operasi.

Alat command-line ini bervariasi mulai dari administrasi server hingga layanan pelanggan. Di bawah ini adalah perintah yang digunakan oleh operator layanan pelanggan yang ingin mengeluarkan pengembalian uang untuk pelanggan.

> /opt/amazon/customer-service/bin/request-refund

Karena database yang sama digunakan oleh toko buku, alat layanan pelanggan, dan alat pusat pemenuhan, operator layanan pelanggan harus masuk ke server dan menjalankan perintah Unix.

Mempertimbangkan bahwa dalam kehidupan saya sebelumnya saya menghapus basis data produksi menggunakan skrip yang serupa, saya menemukan skrip seperti ini cukup keren, namun agak berisiko. Tapi saya agak menyimpang 🙂

Seperti yang dapat Anda bayangkan, menggunakan “monolith” itu tidak semulus sutra. Untuk perusahaan yang berkembang pesat seperti Amazon — mencoba berinovasi dan bersaing untuk pelanggan yang bahagia — hal ini tidak dapat diterima.

Amazon membuat beberapa perubahan penting: satu adalah arsitektur dan yang lainnya adalah organisasi.

Mematahkan monolit

Pertama, monolith dipecah menjadi arsitektur berorientasi layanan (Service Oriented Architectur / SOA) – apa yang sekarang kita sebut arsitektur micro-service.

Dari monolit ke SOA, dan micro-services

Beberapa persyaratan ketat harus diperhitungkan selama proses refactoring ini: Layanan yang dibuat harus (1) kecil, (2) fokus, (3) tujuan tunggal, dan (4) terhubung melalui API HTTP.

Untuk memberi Anda gambaran tentang dekomposisi tersebut, tombol “Beli Sekarang” pada halaman ritel amazon.com adalah layanan semacam itu.

Layanan “Beli Sekarang” dan buku yang harus Anda baca.

Pemecahan ini menciptakan arsitektur yang sangat terpisah, dengan layanan yang ditentukan oleh HTTP API standar. Selama API itu tetap stabil, tim yang mengoperasikan layanan itu dapat melakukan iterasi lebih cepat, tanpa khawatir akan merusak layanan milik tim lain.


Hukum Conway

Hukum Conway dinamai Melvin Conway, yang memperkenalkannya pada tahun 1967.

“Organisasi yang merancang sistem … dibatasi untuk menghasilkan rancangan yang merupakan salinan dari struktur komunikasi organisasi-organisasi ini.”

M. Conway

Hukum Conway memberi tahu kita bahwa agar perangkat lunak dikembangkan dan berfungsi dengan baik, pengembang harus sering berkomunikasi satu sama lain. Dengan demikian, struktur antarmuka perangkat lunak sistem sering kali merupakan cermin dari organisasi yang merilisnya.

Setelah menghancurkan monolit, Amazon memecah organisasi. Organisasi hierarki top-down dipecah menjadi tim-tim kecil — cukup kecil untuk diberi makan oleh dua pizza. Ketika “tim dua-pizza” ini tumbuh melampaui 8-12 orang, mereka dipecah dan kembali fokus.

Tim dua pizza diberi otonomi penuh: bekerja dengan pelanggan internal dan eksternal, menetapkan peta jalan mereka, menyetujui spesifikasi layanan, menulis kode, menjalankan tes, menyebarkan ke produksi, dan bahkan mengoperasikan layanan.

Tanggung jawab tim dua-pizza.

Dua perubahan ini membuat segalanya berjalan lebih lancar. Tim mengembangkan fitur lebih cepat dari sebelumnya. Namun, hal-hal itu belum terlalu bagus.

Apa yang Anda lakukan ketika segalanya tidak bagus?

Anda mengukur. Anda mengumpulkan data. Anda mendengarkan anekdot.

“Aku tidak pernah menebak. Adalah kesalahan besar untuk membuat teori sebelum seseorang memiliki data. Tanpa disadari orang mulai memelintir fakta agar sesuai dengan teori, alih-alih teori yang sesuai dengan fakta.

Sir Arthur Conan Doyle.

Dua Prinsip Kepemimpinan, menurut saya, penting untuk mengembangkan pola pikir pengumpulan data dan memahaminya sebelum memulai pekerjaan apa pun:

Menyelam Dalam (Dive Deep)

Pemimpin beroperasi di semua tingkatan, tetap terhubung dengan detail, sering mengaudit, dan skeptis ketika metrik dan anekdot berbeda. Tidak ada tugas di bawah mereka.

Bersikeras pada Standar Tertinggi

Para pemimpin memiliki standar tinggi tanpa henti – banyak orang mungkin berpikir standar ini terlalu tinggi. Para pemimpin terus meningkatkan standar dan mendorong tim mereka untuk memberikan produk, layanan, dan proses berkualitas tinggi. Para pemimpin memastikan bahwa cacat tidak diturunkan dan bahwa masalah telah diperbaiki, sehingga mereka tetap diperbaiki.

Ciri-ciri budaya ini membuat Amazon mengukur proses pengembangan perangkat lunaknya. Amazon mendapati bahwa butuh waktu rata-rata 16 hari dari code check-in untuk digunakan untuk produksi. Juga ditemukan bahwa personel operasi melakukan pekerjaan manual yang signifikan, termasuk email dan tiket. Dengan kata lain, orang menghabiskan sebagian besar waktu mereka menunggu.

Itulah masalah yang harus dipecahkan: mengotomatisasi jalur produksi untuk menghindari pengembang menunggu.

Di sinilah Anda mulai menyadari bahwa Budaya dan Peralatan berjalan seiring. Tanpa menyelam jauh ke dalam masalah, tanpa ingin menaikkan standar, transformasi berikutnya pasti tidak akan terjadi, dan Amazon tidak akan berada di tempatnya saat ini.

Tempat Peralatan

Brazil, Apollo, dan Pipeline

Untuk menghindari pengembang membuang-buang waktu menjalankan perintah build, Amazon menciptakan sistem build terpusat yang di-host bernama Brazil. Fungsi utama Brasil adalah menyusun, membuat versi, dan manajemen dependensi, dengan fokus pada reproducibility dari setiap build. Brasil mengeksekusi serangkaian perintah untuk menghasilkan artefak yang dapat disimpan dan kemudian digunakan. Untuk menyebarkan artefak ini, Apollo dibuat.

Apollo dikembangkan untuk secara andal melakukan deployment seperangkat artefak perangkat lunak yang ditentukan ke seluruh armada mesin virtual. Pengembang menentukan proses untuk satu host dan kemudian Apollo berkoordinasi untuk melakukan pembaruan ke seluruh armada host.

Itu adalah hal yang besar! Pengembang hanya dapat melakukan push-deploy aplikasi mereka ke lingkungan pengembangan, pementasan (staging), dan produksi. Tidak ada login ke host, tidak ada perintah untuk dijalankan. Penyebaran otomatis ini menghilangkan hambatan dan memungkinkan tim untuk berinovasi dan menghadirkan fitur baru bagi pelanggan dengan cepat.

Penggunaan ekstensif tim Apollo oleh Amazon telah mendorong pengembangan fitur baru, dan hari ini Apollo dapat melakukan lebih banyak lagi – misalnya, dapat melakukan pembaruan bergulir dengan pemeriksaan kesehatan yang memungkinkan aplikasi tetap tersedia selama pembaruan. Apollo juga dapat melakukan deployment secara simultan ke banyak host di lokasi yang berbeda jika armada didistribusikan di pusat data yang terpisah. Fitur itu memastikan aplikasi tetap seimbang selama penyebaran dan redundan jika terjadi kegagalan di satu lokasi. Apollo melakukan semua ini sambil melacak status penyebaran masing-masing host, dan menggunakan informasi itu untuk menahan masalah potensial selama melakukan deployment.

Perlu dicatat bahwa Apollo menggunakan Amazon Linux Instance (AMI) kustom yang telah dibuat sebelumnya sebagai dasar untuk melakukan deployment. AMI khusus itu mewakili lingkungan OS standar dengan prasyarat yang sudah dibuat, membuatnya lebih mudah untuk menstandarkan pen-deploy-an.

Jika Anda ingin mempelajari lebih lanjut tentang Apollo, silakan baca tulisan di blog Werner Vogels.

Namun, deployment otomatis tidak dapat menyelesaikan semuanya. Sebetulnya, deployment adalah bagian dari gambaran yang lebih besar. Mereka adalah bagian dari alur kerja yang dimulai secara instant ketika pengembang mengirim kode ke repositori dan berakhir ketika perubahan itu berhasil dijalankan dalam produksi.

Pipelines memodelkan alur kerja tersebut, dan jalur yang kode ambil dari check-in ke produksi. Pipelines adalah sistem deployment berkelanjutan yang memungkinkan pengembang untuk membuat deployment otomatis sepenuhnya – mulai dari kode saat check-in dan lolos pengujian – hingga produksi, tanpa intervensi manual.

Tentu saja, tidak semuanya bisa sepenuhnya otomatis. Meski begitu, Pipeline akan mengotomatiskan langkah-langkah yang nyaman bagi tim, dan yang paling penting, mengodifikasi langkah-langkah yang diperlukan antara check-in kode untuk menjalankannya dalam produksi.

Pipeline juga merupakan tempat langkah verifikasi terjadi, baik itu pengujian, verifikasi kepatuhan, ulasan keamanan, audit, atau persetujuan eksplisit.

Contoh Pipeline

Sebuah pipa terdiri dari sejumlah tahap. Contoh di atas dimulai dengan membangun paket ke dalam sejumlah set versi aplikasi, kemudian mengalir ke tahap Gamma, kemudian tahap produksi sebagian, dan akhirnya, tahap produksi penuh. Setiap panah adalah langkah promosi yang berfungsi sebagai gerbang validasi sebelum rilis berlanjut ke tahap berikutnya.

Pipeline dimulai sebagai program percontohan untuk sejumlah kecil tim. Pada akhir uji coba, salah satu dari tim tersebut telah mencapai pengurangan sebanyak 90 persen dalam waktu yang diperlukan untuk beralih dari check-in ke produksi. Ya, pengurangan 90 persen!

Ketika tim Amazon lainnya melihat keberhasilan tim yang mempelopori Pipeline, mereka secara alami mulai memigrasi proses perilisan mereka ke dalam pipelines. Tim yang sudah terlanjur memiliki proses rilis yang dibuat khusus mulai mengikuti ke metode standar yang digunakan oleh semua orang.

Lebih jauh, migrasi ke Pipeline memungkinkan tim menemukan cara baru untuk menyederhanakan seluruh proses pengiriman.

Akhirnya, perlu disebutkan bahwa rantai peralatan di atas terintegrasi erat dengan sistem logging dan pemantauan yang lazim dipakai.


Menggerakkan konsistensi, standardisasi, dan penyederhanaan

Brasil, Apollo, dan Pipeline membawa banyak kebaikan bagi Amazon dan pelanggan kami. Itu juga membawa banyak perubahan perangkat lunak, dan pada tahun 2019 Amazon melakukan ratusan juta deployment dalam setahun.

Lebih penting lagi, ketika mempercepat pengiriman perangkat lunak, adopsi luas alat-alat ini mengurangi risiko kegagalan penyebaran karena alat-alat ini mendorong konsistensi, standarisasi, dan penyederhanaan proses rilis. Tentu saja pengembangan alat-alat ini menghasilkan lebih sedikit cacat diluncurkan ke dalam produksi — dan pelanggan yang lebih bahagia. Inilah esensi dari OE.

“[…] adopsi luas alat-alat ini […]”

Pernyataan di atas sangat penting karena, tanpa adopsi luas dari Brasil, Apollo, dan Pipa, semua ini tidak akan terjadi.

Bagaimana Anda memungkinkan adopsi alat secara luas dalam organisasi Anda untuk mendorong konsistensi, standardisasi, dan penyederhanaan proses?

Tanpa memberitahukan banyak dari Bagian 3 dari seri ini, ini semua tentang proses lengkap – atau apa yang suka Amazon sebut mekanisme fungsional.

Proses Lengkap -> Mekanisme Baik

Sebuah mekanisme terdiri dari tiga langkah: peralatan, adopsi, dan audit. Memang, alat tidak berguna jika Anda tidak memiliki program pelatihan dan cara untuk mendorong adopsi itu.

Di Amazon, kami memiliki beberapa cara untuk mempromosikan transfer pengetahuan dan melatih orang untuk mendorong adopsi alat dan praktik lainnya. Beberapa hal yang penting:

Pertama, kami memiliki banyak pelatihan dan kamp pelatihan yang dapat diikuti siapa pun. Tergantung pada perannya, beberapa wajib, sebagian sukarela. Sesi wajib muncul secara otomatis dalam apa yang disebut jalur pembelajaran, yang merupakan cara standar untuk meningkatkan peran.

Kedua, kami memiliki repositori internal video, whitepaper, kursus, dan artikel wiki yang mencakup berbagai topik – mulai dari pola arsitektur dan panduan budaya hingga pengkodean praktik terbaik.

“Pengetahuan, seperti udara, sangat penting bagi kehidupan. Seperti udara, tidak ada yang harus ditolak.”

Alan Moore

Kesimpulan

Pertama, Anda harus secara konsisten meningkatkan standar dan mendorong tim untuk memberikan produk, layanan, dan proses berkualitas tinggi.

Untuk melakukannya, Anda harus menyelam jauh ke dalam data Anda dan memahami masalah yang Anda hadapi. Mulailah dengan mengukur keseluruhan proses pengiriman Anda.

Apakah Anda tahu berapa lama antara kode pertama berkomitmen untuk penyebaran dalam produksi? Apakah Anda tahu jumlah cacat yang melewati pipa pengiriman Anda? Apakah Anda tahu jumlah ancaman keamanan yang tidak terdeteksi?

(1) Salah satu hal paling penting yang dapat dilakukan organisasi adalah memelihara budaya mengukur segalanya. Tanpa pengukuran, Anda beroperasi dalam kegelapan, melalui asumsi.

Mengukur memungkinkan Anda mendapatkan wawasan tentang apa yang hilang di organisasi Anda — dan untuk mendorong pengembangan alat yang diperlukan untuk perbaikan.

(2) Untuk memastikan alat yang dibangun adalah yang tepat, uji coba mereka dengan beberapa tim terlebih dahulu, dan lakukan iterasi dengan mereka sampai kisah suksesnya begitu baik sehingga mereka secara alami menginfeksi kelompok lain. Tekanan sosial adalah hal yang indah 🙂

Dan, teruslah mengukur. Jangan puas dengan “cukup baik.” Anda, pada saat ini, sedang mengatur flywheel baru untuk kepentingan pelanggan Anda.

(3) Memiliki rantai peralatan standar yang sama di seluruh organisasi adalah kuncinya. Meskipun terkadang tidak disukai oleh pengembang, standardisasi alat seringkali mendorong konsistensi dan penyederhanaan. Dan peningkatan yang dilakukan untuk alat apa pun segera bermanfaat bagi semua orang.

(4) Untuk memberi manfaat bagi seluruh organisasi, pastikan Anda terus melatih orang-orang Anda dan mempromosikan transfer pengetahuan.

Terakhir, jika pipa pengiriman Anda perlu ditingkatkan, Brasil, Apollo, dan Pipa telah mengilhami pengembangan paket perangkat peralatan pengembangan AWS Code *. Anda dapat menggunakan alat-alat seperti AWS CodeCommit, AWS CodeBuild, AWS CodeDeploy, AWS CodePipeline, dan AWS CodeStar hari ini di organisasi Anda.

Alat-alat ini dirancang untuk membantu Anda membangun aplikasi seperti Amazon. Mereka memfasilitasi praktik seperti pengiriman berkelanjutan dan infrastruktur sebagai kode dan akan membantu Anda mempercepat pengembangan perangkat lunak dan siklus rilis Anda.


Akhir Kata

Itu saja untuk Bagian 2, rekan-rekan. Harap jangan ragu untuk membagikan umpan balik dan pendapat Anda. Di pos berikutnya, saya akan membahas bagian penting dari Keunggulan Operasional: proses yang lengkap.

-Adrian


Leave a comment

Leave a Reply

%d bloggers like this: