edgy blueprint

The time is closer.

edgy blueprint

Hai, sudah lama tidak berbicara. Ada beberapa hal yang ingin gue bagikan. Namun sebelum membahas tentang apa yang menjadi judul dari tulisan ini, mari kita berbicara seputar "latar belakang" dari tulisan ini terlebih dahulu.

Latar Belakang

Nyari kerja susah, meskipun perusahaan bilang nyari pekerja susah juga. Entah yang "kurang sreg" dari pihak perusahaan atau pekerja, ini adalah lingkaran setan klasik yang udah berbusa-busa pernah gue bahas.

Karena itulah, gue memberanikan diri untuk memulai hal baru. Gue dan my boss sedang memulai ahensi, kalau perusahaan/organisasi/lo butuh Frontend Engineer, kita menyebut ahensi kita sebagai Frontend Engineer as a Service.

Hahaha.

Oke, mungkin ada ribuan ahensi yang sudah ada di Indonesia, mungkin sampai jutaan bila di dunia. Lalu di tahun ini, kita (baru) mulai ahensi. Apa yang bisa membuat kita bersaing dengan mereka?

Terlebih, kita baru mulai. Dan berdua, tanpa nama. Tanpa portfolio.

Seperti yang kita tau, persaingan melahirkan inovasi. Harus ada "nilai unik" untuk bisa menjawab "Why you should choose us than others?". Gue enggak tertarik bersaing di harga, dan kalau dikualitas, gue juga gak bisa 100% menjamin. Jadi, ini nilai unik yang ingin kita tawarkan.

Tentang edgy

Pada 10 Juni 2019, gue mendaftarkan domain dengan nama edgy.network. Entah gue lupa nama tersebut datang dari mana, intinya gue bikin itu karena gue ingin membuat DIY CDN gitu.

Pada waktu tersebut (sampai hari ini), gue habiskan waktu gue untuk riset. Dari cara kerja CDN under the hood, security nya, caching, geo-routing, dsb. Perjalanan masih panjang, kita pijak dari batu loncatan awal terlebih dahulu: Deployment Platform.

Dulu banget, gue pakai Surge untuk "meng-expose" localhost gue ke client. Surge udah oke banget, sederhana, dan gratis. Cukup ketik surge lalu website kita bisa diakses di internet.

Lalu tidak lama kemudian ada Zeit Now, dibuat oleh seseorang yang punya nama di internet dan industri IT. Sejauh yang gue inget (dulu), Zeit Now ini seperti Surge. Tapi daripada cuma situs statis, mereka menawarkan dinamis juga (seperti Heroku). Dulu deploy ke Now bisa via Dockerfile, yang artinya bisa deploy berbagai backend di platform mereka.

Oh iya, ada juga Heroku. Heroku pemain lama, di backing oleh perusahaan terpercaya (Salesforce), menawarkan hal-hal essential untuk menjalankan aplikasi di Cloud™.

Lalu, ada juga Netlify. Netlify hampir mirip dengan Zeit & Surge, bedanya, mereka menawarkan CDN (ADN) sebagai fitur andalannya. Juga, Netlify Build (dulu deploy ke Now cuma via now) yang mana mentenagai untuk menggunakan workflow CI/CD dengan mudah.

Oke, 4 layanan diatas udah berjalan lama. Dan di backing oleh VC terpercaya, memiliki engineers yang oke-oke, punya plan gratis, dan relatif bermarkas di SF (I have a reason why I add this!), lalu, apa yang bisa kita jual disini?

Ini rada tricky, tapi gue benci politik. Yang akan gue jual disini adalah, pertama, menjadikan masyarakat Indonesia sebagai kelas utama, yang kedua, yeah, ini akan Open Source. THE WHOLE PLATFORM.

Untuk poin yang petama, ini ada alasan tersendiri (yang mana alasan utama kenapa gue beli domain edgy.network), dan yang kedua, alasannya akan lebih panjang.

Jadi gini, gimana kalau kita (developer Indonesia) bikin platform serupa juga? Sejauh yang gue tau, belum ada/banyak yang bergerak di industri PaaS ini. Untuk SaaS mungkin sudah banyak ya, tapi untuk platform?

Terlebih yang Open Source, alias, yang menjadikan "pembelajaran" sebagai alasan utama daripada "bisnis".

Oke gue salah, CloudKilat punya Kilat Iron yang entah belum pernah gue coba. Yang mana, mungkin, mirip seperti Heroku. Mungkin.

Nah jadi mau gak mau gue harus riset dong, dan inilah hasil riset yang akan gue bagikan. Kenapa di bagikan? Toh kode nya juga akan di Open Source, kan? Including the whole .yml files.

Platform

Now & Netlify pada dasarnya hanya melakukan git clone lalu mem-build project kamu di server mereka cloud. Karena menggunakan workflow CI/CD, sumber utama dari project nya adalah remote repository.

Lalu mereka akan men-detect project kamu menggunakan apa. React/Vue/Angular kah yang based on JavaScript? Hugo kah yang dari Go? Atau, Zola yang based on Rust? Apapun. Mereka memiliki field build command untuk kasus mereka tidak bisa mendeteksi project kamu menggunakan apa.

Setelah itu, project kamu dibuat menggunakan perintah build yang sudah didefinisikan tersebut. Lalu artifact akan diunggah ke somewhere else yang biasanya Object Storage.

Rahasianya ada disini. Gue enggak tau apakah Netlify & Zeit menyimpan artifact tersebut per-project (di mount ke project) atau tidak. Kalau gue, enggak.

Alasannya akan gue bahas dibagian "CDN".

Lanjut, lalu mereka di Load Balancer/Reverse Proxy utama mereka akan "me-label" project mu tersebut per-host. Yang gue pelajari, Netlify & Zeit beda dalam melakukan routing ini.

Contoh diatas, meskipun gue akses ke zeit.co namun dengan host zeit.now.sh, server mereka memberi response dari zeit.now.sh yang mana masih satu infra dengan mereka. Kalau nyoba request ke yang diluar infra mereka, akan mendapatkan error BAD GATEWAY/502. Kalau Netlify, dia cuma beda response code aja, daripada 502 jadinya 404.

Sebagai kesimpulan, berikut diagram sederhana terkait platform mereka:

Diagram diatas hanya "gambaran" berdasarkan hasil riset, pengalaman & pengetahuan gue. Jika ada salah, feel free to let me know.

Oke kita sudah selesai di bagian platform, sekarang mari kita ke bagian CDN.

CDN/ADN

CDN/ADN bukanlah konsep yang asing. Jika CDN adalah tentang "men-deliver" content yang terdekat dengan pengunjung, ADN adalah tentang men-deliver aplikasi terdekat ke pengunjung.

CDN melakukan caching dari origin server ke edge server. Sedangkan untuk ADN, bisa pikirkan ini adalah tentang Multi CDN/CDN yang lebih "pintar". Begini gambarannya, misal kita pakai Cloudflare, CF memiliki edge server/PoP yang banyak tersebar diberbagai wilayah.

Jika servermu berada di Bandung dan pengunjungmu berada di Jakarta, maka gambarannya kira-kira seperti ini:

Client/pengunjung hanya mengakses edge server, lalu memberikan response nya entah dari cache (HIT) atau langsung (MISS). Menariknya, pengunjung hanya perlu mengakses server yang berada di Bekasi daripada harus jauh-jauh ke Bandung, yang mana mengurangi latensi.

Dan juga, ini menghemat dalam bandwidth. Server kita memakan resources lebih sedikit dari biasaya, thanks to CDN.

Dan untuk ADN, singkatnya, situsmu di deploy ke server yang terdekat dengan pengunjung juga. Tidak terlalu bergantung dengan caching yang dilakukan di edge server, karena aplikasi biasanya lebih dinamis daripada hanya sebuah situs/konten.

edgy as a platform (and CDN?)

Mari kita mulai berbicara tentang edgy, sengaja gue bawa 2 diagram diatas agar lebih mudah dipahami dan juga siapa tau ingin berkontribusi baik dari sisi security atau apapun itu hahaha.

Disisi platform, hampir sama dengan kebanyakan. Nah ini disisi CDN sedikit tricky, kita bahas dulu dari "static server".

Jika melihat Now & Netlify, mereka sama-sama menyediakan "static hosting", benar? Misal kita memiliki direktori build yang mana adalah hasil dari npm run build dari project create-react-app, lalu kita deploy ke Now/Netlify, dan boom, project kita bisa diakses oleh orang lain! Tanpa perlu setting server, hanya direktori build dengan index.html sebagai entrypoint.

Sebenarnya, pasti ada server. Entah Reverse Proxy seperti Nginx, atau apapun itu yang mendukung serving static assets. Untuk design si edgy, kita juga begitu. Tapi, kita mengandalkan S3-compatible server untuk meng-serve aplikasi kita.

Entah itu dari AWS S3, Google Cloud Storage, atau Azure Blob Storage, mereka menyediakan "server" untuk meng-serve static assets kita.

Dan juga, ter-distribusi across region, bukan? Proses membuat CDN sederhana disini menjadi sedikit lebih mudah dan murah. Begini gambarannya:

Kita menjadikan origin server nya adalah S3 (AWS/GCP/Azure, which is more secure, right?) dan yang menjadi edge nya adalah aplikasi kita sendiri yang berada di infra platform kita. Edge akan me-request ke origin jika request yang ada belum ada di local cache.

Edge kita tersebut hanya static server yang bertindak sebagai reverse proxy. Mengapa reverse proxy didalam reverse proxy? Untuk melakukan "pre-process" yang ada di level user seperti inject script, redirect, dsb.

Logic untuk purge cache local ada caranya sendiri in case user mengubah data untuk inject script (e.g: update GA snippet), redirect, dsb. Sumbernya untuk sekarang (06 Apr 2020) masih dari local (edgy.json) yang bersumber dari server (platform). Jika ada teknik lain yang lebih efektif, efisien, dan nyaman, drop us a line!

Untuk security, masih dalam tahap riset khususnya untuk bagian cache poisoning. Gue desain platform ini dengan pendekatan immutable deployment, dan juga untuk caching bergantung dengan Etag dan immutable caching, jika ada teknik lain, let us know!

Under the hood

Project di-build di server CI, upload artifact ke S3 berdasarkan project id & deployment id, lalu mem-build static server (menggunakan Kaniko), lalu dideploy dengan (environment) variable yang sudah ditetapkan di build time (untuk hal-hal terkait S3, kecuali S3 endpoint & tls certificate).

Deployment menggunakan Knative, proxy via Envoy dan berada di cluster Kubernetes (because I can why not). Berbicara seputar bisnis, setiap project memiliki fitur autoscaling (thx to k8s) dan di charge on-demand berdasarkan bandwidth, you got the point.

Baru berani berbicara segitu karena baru sampai disitu.

Sejauh ini berdasarkan kalkulator fariz platform ini memakan flat $20/mo, sebuah angka yang relatif kecil untuk PaaS dan dengan free credit $300 dan free-tier plan hahaha.

Penutup

Platform ini akan gue rilis sebagai closed BETA setelah pembuatan landing page untuk ahensi kelar, dan EA setelah mendapatkan >= 100 invite request, dan GA setelah mendapatkan 100 calon paid subscriber.

Kode akan di Open Source setelah GA (alibi buat refactoring dulu haha) dan pastinya setelah hal-hal terkait ahensi kelar.

Tujuan gue membuat ini selain sebagai bahan R&D adalah sebagai bentuk perwujudan "bisa gak sih kita bikin kayak gitu?". Dan juga, untuk mempermudah workflow sebagaimana ribetnya workflow ahensi, termasuk ahensi lain yang tertarik menggunakan platform kita.

Dan, ya, nilai unik. Daripada cuma bacot jualan di landing page kalo blablabla, juga bisa talk is cheap show me the code since we are a die-hard open source enthusiast.

Sebagai bocoran, platform ini udah punya plan gratis dari lahir untuk project open source:

Karena gue yakin platform tanpa komunitas tidak menjadi apa-apa, dan komunitas yang paling yoi adalah komunitas open source.

Banyak pelajaran yang gue dapet setelah riset berbulan-berbulan, dan satu hal penting yang gue pelajari: Going cloud is about abstraction.

Sebagai penutup, platform ini akan dirilis diatas lisensi MIT, namun dengan Common Clause. Yang singkatnya, lo dapet semua benefit dari MIT, kecuali, lo gak boleh membuat layanan komersial diatas platform kita.

Kenapa kita pakai Common Clause? Karena, kita bukan siapa-siapa. Dan kita akan kalah oleh kapitalis yang duitnya lebih banyak dari jumlah seluruh module yang ada di npm registry.

Terakhir, terima kasih sudah membaca ini. Platform sudah 70%, that's why I write about this. Kalau tertarik untuk mencoba, drop me or @adriantirusli a line! Untuk saat ini, infra platform berada di non indo, dan belum menemukan Kubernetes as a Service (atau yang oke) di Indo.

Dan, ya, sewa bare metal pasti mahal. Kecuali ada yang mau sponsorin~

Anyway. Thank you. Harapan gue, dengan membuat PaaS ini, gue (and other developers builders) bisa lebih produktif dalam membuat sesuatu, tanpa harus memusingkan hal-hal terkait server (I'm not talking about FaaS).

Dan juga, memenuhi sesuai kebutuhan & kondisi di Indonesia. This is our effort to bridging the gap between Development & Operation, so, let's build something awesome & useful together!