Arsitektur Microservices saat ini sedang ngetren. Kami di ArtiVisi juga sudah mengadopsi arsitektur ini dalam beberapa projec terakhir. Dan bahkan sudah mengadakan trainingnya. Dilihat dari sisi development dan deployment, microservice memang memungkinkan organisasi untuk bisa membuat aplikasi sesuai kebutuhan dengan cepat. Proses yang dulunya memakan waktu berbulan-bulan dari konsep sampai go-live, sekarang bisa dipercepat menjadi beberapa minggu saja.
Salah satu ciri khas dari arsitektur microservices adalah ada banyak aplikasi kecil-kecil yang saling berkomunikasi satu dengan lainnya. Dengan demikian, kita dituntut untuk banyak mendeploy aplikasi. Masing-masing aplikasi juga bisa dibuat dengan teknologi yang berbeda-beda sesuai dengan kebutuhan dan trend masa kini.
Kalau mau diikuti idealnya, satu VPS berisi satu aplikasi. Atau satu docker container berisi satu aplikasi, dan satu VPS bisa berisi banyak docker container. Akan tetapi tentu saja kita tidak berada di dunia yang serba ideal. Ada kalanya kita harus berkompromi dengan budget, sehingga satu VPS harus rela menghosting banyak aplikasi sekaligus.
Pada artikel kali ini, kita akan mendeploy beberapa aplikasi microservices dalam satu host karena keterbatasan budget. Walaupun kantong kere, hanya mampu sewa satu VPS, tapi bisa tetap hore dengan arsitektur jaman now :D
Satu VPS biasanya hanya punya satu IP public. Dengan keterbatasan ini, maka kita perlu sedikit berakrobat supaya semua aplikasi kita bisa berbagai pakai port-port penting seperti misalnya port HTTPS (443). Sebagai studi kasus, pada artikel ini kita akan mendeploy beberapa aplikasi yang dibuat dengan bahasa pemrograman dan framework berbeda, yaitu Java dengan Spring Boot, NodeJS dengan Express, Ruby dengan Rails, dan tidak ketinggalan aplikasi sejuta umat Wordpress yang dibuat dengan PHP. Kita ingin mengakses keempatnya dengan alamat sebagai berikut:
https://app1.artivisi.id : Aplikasi Java dengan Spring Boot
https://app2.artivisi.id : Aplikasi NodeJS dengan ExpressJS
https://app3.artivisi.id : Aplikasi Ruby dengan RubyOnRails
https://wp.artivisi.id : Aplikasi PHP dengan Wordpress
Keempat aplikasi akan dihosting/dijalankan di satu mesin yang sama. Saya akan gunakan VPS termurah yang disediakan Digital Ocean, seharga $5 sebulan.
Pada bagian pertama ini, kita akan membahas cara setup VPS dan Nginx sebagai Front Proxy. Artikel selanjutnya akan membahas implementasi masing-masing backend.
Salah satu keuntungan menggunakan version control adalah kita bisa dengan mudah mengembalikan kondisi file ke masa lalu. Hal ini dibutuhkan bila ternyata ada anggota tim membuat perubahan yang ternyata tidak bisa digunakan. Contohnya, di Java kita menggunakan library FlywayDB untuk mengurus migrasi database. File migrasi ini sekali sudah dijalankan maka tidak boleh diedit lagi. Bila diedit, maka akan keluar error seperti ini
Selama ini, bila kita membuat aplikasi yang ada fitur kirim emailnya (reset password, pengumuman, newsletter, dan sebagainya), biasanya kita menggunakan protokol SMTP. Akan tetapi, beberapa tahun belakangan ini, layanan SaaS (software as a service) bermunculan seperti cendawan di musim hujan. Sebagian besar di antaranya tidak lagi menggunakan protokol SMTP, tapi menyediakan API di atas protokol HTTP.
Ada banyak penyedia jasa layanan email, diantaranya:
SendGrid
MailerLite
Amazon
GMail
Pada artikel ini kita akan membahas yang paling populer saja, yaitu GMail. GMail menyediakan dua pilihan bila kita ingin mengirim email dari aplikasi kita : SMTP atau HTTP API. Kita akan gunakan HTTP API.
Pada artikel sebelumnya, kita sudah membahas tentang workflow development baik sebagai kontributor maupun sebagai maintainer. Dengan dua artikel tersebut, kita sudah bisa membuat perubahan dalam source code, dan juga bisa menerima dan mengintegrasikan hasil pekerjaan orang lain ke repo utama.
Walaupun demikian, kita belum membahas bagaimana cara mengelola siklus pengembangan aplikasi. Kita terutama ingin mengatasi beberapa permasalahan berikut:
bagaimana semua kontributor bisa bekerja sama dengan baik
bagaimana memastikan kode program yang dihasilkan oleh kontributor bisa direview dengan seksama
bagaimana melakukan rilis ke testing server dan production
bagaimana menangani bug yang terjadi di production sambil tetap mengerjakan development untuk versi selanjutnya
bagaimana meng-copy bugfix yang sudah kita kerjakan di atas production release (hotfix) ke development
bagaimana mengotomasi proses rilis menggunakan continuous integration/delivery
TLDR; Workflow yang kita gunakan di ArtiVisi adalah sebagai berikut:
single permanent branch : master
develop di topic branch
push branch ke remote
raise pull request dari branch
merge pull request
hapus branch setelah merge
deploy ketika ada tag dibuat
A.B.C-M.xxx : deploy ke dev (otomatis)
A.B.C-RC.xxx : deploy ke test (otomatis)
A.B.C-RELEASE : deploy ke production (manual)
bugfix di release branch, kemudian merge ke master
Pada artikel sebelumnya, kita sudah membahas tentang apa yang harus dilakukan oleh kontributor agar hasil pekerjaannya siap untuk digabungkan dengan repository utama/induk/upstream, yaitu membuat Pull Request.
Sebagai maintainer project, tugas kita adalah memilah semua kontribusi yang masuk. Bila kontribusinya bagus, maka kita masukkan ke dalam project. Bila kurang bagus, kita pandu untuk memperbaikinya.
Kita bisa menerima kontribusi dalam berbagai bentuk, misalnya:
Pull Request di aplikasi version control (Github, Gitlab, Bitbucket, dsb)
Link repository kontributor dan branchnya
File patch
Begitu kita mendapatkan kontribusi, ada beberapa hal yang harus kita lakukan, yaitu:
