Sebelumnya saya telah menjelaskan 5 point dalam 12 faktor app di artikel sebelumnya, dan dalam artikel ini saya akan melanjutkan point-point yang belum sempat saya tuliskan.

6. Proses-proses

12 Faktor App mengharuskan setiap aplikasi/proses yang jalan adalah stateless, yang dimaksud stateless adalah proses tidak menyimpan sesi, state, atau data apapun yang dibutuhkan oleh pengguna di lokal sistem dimana aplikasi tersebut berjalan, tidak saling berbagi-pakai (share) dengan proses lain, adapun setiap data yang ada harus disimpan di backend database.

Kebalikan dari stateless adalah stateful yakni proses yang menyimpan sesi di lokal proses.

Mengapa 12 faktor mengharuskan demikian? Karena salah satunya adalah untuk mempermudah scaling, sehingga ketika kita memasang load-balancer misalnya setiap pengguna bisa di-routing ke proses manapun tanpa khawatir ada sesi yang hilang.

Sehingga sebenarnya aplikasi yang membutuhkan sticky-session itu telah melanggar 12 faktor app.

7. Port Binding

Kita sudah mulai memasuki poin-poin 12 faktor app yang mungkin relevansinya mulai banyak mengarah ke SaaS.

12 faktor app mengharuskan aplikasi self-contained artinya bisa berdiri sendiri dan tidak tergantung dengan pihak ketiga misalnya web container untuk mengexpose port, sebagai contoh java servlet aplikasi yang membutuhkan web container untuk mengekspos port itu tidak memenuhi sarat ini.

8. Konkurensi

Men-scale menggunakan model proses, setali dengan poin 6, 2 faktor app menginginkan proses sebagai pintu utama untuk konkurensi, ini memudahkan kita dalam menjaga agar aplikasi tetap berjalan dengan lancar dalam kondisi high load atau beban tinggi, contoh dengan memisahkan beberapa tipe request ke dalam proses-proses khusus, ya mungkin teman-teman pernah membaca tentang micro service?

9. Disposabilitas

Proses menurut 12 faktor app harus mudah untuk dijalankan dan mudah untuk dihentikan kapanpun, ini memastikan agar aplikasi kita kokoh dan mudah untuk di-scale.

Pada sistem operasi Linux dan Unix-like mungkin kita pernah mengalami ada proses yang ketika kita coba hentikan dengan mengirimkan sinyal SIGTERM menggunakan kill [PID] tapi prosesnya tidak berhenti-henti, atau sangat lama proses berhentinya, hal ini biasanya terjadi ketika proses sedang sibuk-sibuknya, menggunakan banyak resource karena peningkatan jumlah pengguna konkuren misalnya. Dan mungkin ada pula yang malah tidak bisa dihentikan sama sekali tidak mati-mati sehingga kita mulai memutuskan untuk mengirimkan sinyal SIGKILL menggunakan perintah kill -9 [PID], nah proses yang seperti ini tidak memenuhi sarat "disposability".

Layaknya sebuah aplikasi yang kita buat harus bisa berjalan sebagai servis atau daemonized menggunakan aplikasi sistem seperti service manager Systemd yang harus bisa menangani operasi seperti start, restart dan stop.

10. Kemiripan Lingkungan Dev/Prod

Ketika kita mengembangkan sebuah produk, kita biasanya akan membuat setidaknya dua server yang satu untuk keperluan dev (pengembangan) dan yang satunya lagi untuk keperluan prod (produksi), server dev biasanya kita gunakan untuk mengembangkan aplikasi dimana iterasi prosesnya terjadi terus menerus di sini sebelum nanti akan dirilis dan di-update ke server produksi (prod) yang digunakan secara real oleh pengguna.

Di server dev biasanya test dan UAT (User Acceptance Test) juga terjadi untuk memastikan bahwa aplikasi yang kita buat dengan perubahan terbaru layak untuk masuk ke server prod. Nah di sini bisanya terjadi hal-hal yang tidak diharapkan, misalnya setelah di-test dan di-UAT di server dev sukses tanpa masalah apapun namun ketika dirilis ke server prod muncul kesalahan (bug) yang tidak terjadi ketika dites di server dev. Mengapa demikian? Hal ini biasanya karena ada perbedaan lingkungan antara dev dan prod, contoh di dev kita menggunakan http web server Apache dan di prod kita menggunakan Nginx, perbedaan lingkungan ini meningkatkan potensi munculnya masalah yang tidak singkron antara dev dan prod. Untuk itu 12 faktor app mensyaratkan lingkungan untuk aplikasi antara dev dan prod harus semirip mungkin, kalau di dev menggunakan Apache ya di prod menggunakan Apache.

Munculnya perbedaan antara server dev dan prod biasanya dipicu oleh:

  1. Waktu deployment dengan development cycle yang panjang, mungkin proses development hingga mencapai prod bisa memakan waktu mingguan bahkan bulanan. Seharusnya development cycle harus lebih cepat, misal aplikasi harus terdeploy dalam hitungan jam, sehingga kita akan segera tahu ketika ada masalah dan cepat dalam penanganannya.
  2. Gap antar personel, program ditulis oleh programmer dan di-deploy oleh devops yang berakibat apabila ada beberapa perubahan konfigurasi di luar kode misal konfigurasi http server atau perubahan skema database yang mana devops tidak mengetahui hal itu, biasanya akan muncul kegagalan di prod. Solusinya? Programmer dan devops atau orang yang terlibat dalam proses deployment harus bekerja dekat antara satu dengan yang lainnya, dan harus selalu proaktif memantau tingkah laku aplikasi di server prod.
  3. Gap antar tool, developer menggunakan Apache, SQLite, dan OSX untuk development sementara di server menggunakan Nginx, MySQL, dan Linux. Sebaiknya samakan tool dan lingkungannya, setdaknya kalau kita tidak bisa menyamakan sistem operasinya maka samakan tool-toolnya.

11. Loging

Jadikan log sebagai aliran kejadian (event stream). Log menjadi sarana untuk kita mengetahui apa yang sedang dilakukan oleh aplikasi kita yang sedang berjalan. Pada aplikasi server biasanya log ditulis pada suatu berkas (file), tetapi itu hanyalah format keluaran (output format).

12 faktor app tidak mengatur tentang apakah aplikasi harus mengarahkan log ke log server atau ke berkas, namun berharap agar aplikasi memperlakukan log sebagai aliran kejadian (event stream) dan menuliskannya ke output standar (stdout) sehingga memudahkan pekerjaan programmer di level dev dengan cukup hanya melihat layar terminal.

Namun di level staging dan prod, log harus bisa ditangkap oleh lingkungan pengeksekusi --bahasa indonya kok gak enak banget ya?-- maksudnya log harus bisa di-capture oleh execution environment dan diagregasi lalu diarahkan ke log server terpusat untuk bisa dipantau secara mudah dari satu tempat, proses ini tidak perlu dilakukan oleh aplikasi itu sendiri, tetapi kita bisa menggunakan program-program seperti Logplex dan Fluentd untuk keperluan ini.

12. Proses Admin

Yang dimaksud proses admin adalah proses yang dikhususkan untuk keperluan seperti pemeliharaan (maintenance), update skema database, dan operasi-operasi lain yang biasanya merupakan akibat dari perubahan versi. Sebagai contoh ada perubahan skema di database karena kebutuhan bisnisnya mengharuskan itu, maka kita perlu membuatkan script untuk melakukan itu yang harus dipastikan telah bekerja di dev dengan baik.

Saya sendiri biasanya membuat CLI (command line tool) dalam setiap aplikasi server yang saya kembangkan dan saya bentuk seperti terminal shell, dan setiap prosedur yang telah dijalankan akan saya simpan revisinya ke database untuk memastikan idempotensi-nya (one-off).

Terimakasih telah membaca artikel ini, happy coding!

[] Robin