- Startup tahap awal mungkin lebih baik menghabiskan waktu untuk membangun produk dan mencari product-market fit, alih-alih menyiapkan Kubernetes atau auto-scaling sejak hari pertama
- 20–30 fungsi Lambda serta log yang tersebar di SQS dan CloudWatch membuat debugging, perubahan, dan deployment menjadi sulit; sebenarnya masih ada ruang untuk menyederhanakannya menjadi satu container NodeJS atau aplikasi Flask/FastAPI dengan Redis
- Dalam contoh yang memisahkan CRUD dan logika bisnis ke 7 microservice di atas EKS, waktu yang dihabiskan untuk operasi infrastruktur lebih banyak daripada pengembangan fitur
- Bahkan satu VM saja dapat menyediakan komputasi yang cukup untuk layanan tahap awal jika memanfaatkan opsi seperti EC2, GCP VM, Hetzner, latitude.sh, serta server kelas RAM 40GB dan multicore
- Meski konfigurasinya sederhana, agar layak dipakai di praktik nyata tetap perlu HTTPS, SSH/SSM terbatas, CI/CD, DNS, backup DB, VM standby, disaster recovery, aturan keamanan, dan kebijakan retensi backup
Bagaimana infrastruktur yang berlebihan muncul di startup tahap awal
- Pieter Levels diperkenalkan sebagai contoh yang menjalankan beberapa micro-SaaS di satu server, menghindari kompleksitas infrastruktur cloud, dan berfokus pada product-market fit
- Pendekatan ini bukan jawaban yang cocok untuk semua tim, tetapi menunjukkan dengan baik situasi ketika deployment dan pengelolaan infrastruktur menjadi kompleks demi kompleksitas itu sendiri
- Tim pengembang kecil setelah MVP bisa mengalami kesulitan dalam deployment dan pengelolaan database, tetapi tidak semua proyek membutuhkan Kubernetes, sistem terdistribusi yang rumit, dan auto-scaling sejak hari pertama
- Infrastruktur sederhana memungkinkan tim menghabiskan lebih banyak waktu untuk membuat produk yang baik dan menemukan kecocokan pasar
- Perusahaan skala enterprise memiliki persoalan tersendiri seperti compliance dan tenaga kerja dalam jumlah besar, tetapi startup tahap awal tidak perlu meniru kompleksitas itu begitu saja
Contoh nyata: beban operasional yang ditimbulkan kompleksitas
-
Kelebihan beban Lambda
- Ada 20–30 fungsi Lambda untuk berbagai layanan berbeda
- SQS dan berbagai pekerjaan background juga dikonfigurasi berbasis Lambda
- Log tersebar di seluruh CloudWatch sehingga pelacakan penyebab menjadi sulit
- Debugging terasa menyakitkan, perubahan menjadi rumit, dan deployment tetap kompleks bahkan dalam monorepo
- Semuanya sebenarnya bisa dibuat lebih sederhana dengan satu container NodeJS atau aplikasi Python Flask/FastAPI, serta pekerjaan background berbasis Redis
-
Kelebihan microservice
- Ada 7 microservice kecil yang berjalan di atas Kubernetes EKS
- CRUD dan logika bisnis dipisahkan ke layanan terpisah
- Kubernetes memang kuat, tetapi tim tersebut menghabiskan lebih banyak waktu untuk infrastruktur daripada pengembangan fitur
- Tetap menjadi pertanyaan apakah pemisahan layanan sejauh itu benar-benar diperlukan pada skala tersebut
Mengapa pendekatan satu server realistis
- Konfigurasi satu server adalah cara yang memanfaatkan performa VM modern secara maksimal
- VM yang kuat dan ramah anggaran bisa diperoleh dari Hetzner dan latitude.sh
- Instance GCP VMs dan EC2 juga berada di kisaran harga yang masuk akal
- Server dengan RAM 40GB dan beberapa core bisa menjadi pilihan yang lebih baik daripada banyak layanan terdistribusi, banyak Lambda, atau banyak ECS task
- Karena semuanya terkumpul di satu tempat, operasi dan pengelolaan menjadi lebih mudah
- Skalabilitas hingga jutaan QPS bisa ditangani ketika waktunya benar-benar tiba, dan pada saat itu kemungkinan besar sudah ada tim infrastruktur
- Operasi satu VM yang stabil memerlukan perangkat operasional dasar
- Mesin yang kokoh seperti EC2, GCP VM, atau Hetzner
- Akses aman seperti HTTPS untuk web dan SSH dengan pembatasan IP atau SSM untuk deployment
- CI/CD untuk deployment tanpa downtime
- Konfigurasi DNS
- Backup database secara berkala
- VM standby untuk redundansi
- Strategi disaster recovery yang solid dan mean time to recovery yang sudah diuji diperlukan, dan ini bisa dicapai dengan VM backup
Docker Compose dan Docker Compose Anywhere
- Docker Compose bagus untuk mengelola beberapa layanan dengan satu perintah dalam pengembangan lokal, tetapi kurang banyak dimanfaatkan di produksi
- Docker Swarm disebut sudah deprecated
- Docker Compose bisa menimbulkan downtime saat update
- Ada panduan deployment produksi, dan perlu keseimbangan antara kesederhanaan dan kesiapan produksi
- Docker Compose Anywhere adalah proyek akhir pekan untuk membuat konfigurasi satu VM menjadi lebih sederhana
- Menyiapkan server Linux dengan satu klik melalui GitHub Actions
- Mendukung continuous deployment tanpa downtime menggunakan GitHub Container Registry dan Docker Rollout
- Menyediakan pengelolaan environment variable dan secret, serta sedang mempertimbangkan age atau sops untuk meningkatkan keamanan
- Menyediakan backup Postgres otomatis berbasis GitHub Actions
- Mendukung beberapa aplikasi dalam satu VM
- Mengotomatiskan SSL dengan Traefik dan Let’s Encrypt
- Dapat men-deploy aplikasi Next.js, Go, Python, Node.js, dan lainnya
Prinsip keamanan dan operasi yang tetap tidak boleh hilang meski sederhana
- Keamanan dan perlindungan data tidak boleh diabaikan bahkan dalam konfigurasi sederhana
- Diperlukan aturan firewall yang ketat dan hanya membuka port yang dibutuhkan
- Kelola SSH key dengan aman; di AWS lebih disarankan SSM, sedangkan di GCP lebih disarankan CLI
- Bastion host dapat digunakan untuk memperkuat keamanan
- Lindungi secret dan pertimbangkan penggunaan WAF atau Cloudflare
- Kirim backup database terenkripsi ke S3 atau cloud storage aman yang setara
- Buat snapshot disk secara berkala untuk redundansi tambahan
- Terapkan kebijakan retensi untuk backup dan snapshot
- Prioritas engineer adalah menjaga kesederhanaan setup dan berfokus pada produk inti
- Konfigurasi kompleks yang meniru engineering Google atau cara perusahaan besar, serta tool baru, dapat dengan mudah mengalihkan perhatian
- Hal terpenting, baik untuk startup maupun bukan, adalah berbicara dengan pengguna dan menemukan product-market fit
1 komentar
Pendapat di Hacker News
Saya sering bersusah payah di berbagai proyek karena teknologi yang sedang tren
Ukuran tim kecil, tetapi dengan alasan membutuhkan “skalabilitas tak terbatas”, mereka kerap menghasilkan keluaran dengan kualitas yang sulit dipercaya rendahnya, dan ada juga tim yang belum matang yang bahkan tidak benar-benar memahami apa itu LTS tetapi memutuskan bahwa mereka membutuhkan Kubernetes
Sekarang saya punya kode Puppet yang ringkas untuk membuat VM yang sudah di-hardening dengan ukuran apa pun di penyedia mana pun yang saya inginkan, lalu menjalankan layanan Docker, backend Python, atau penyajian file statis di atasnya
Entah VM Hetzner itu 2 core atau 48 core, saya bisa membuat layanan dalam 5 menit, mengendalikan konfigurasi dengan manifes yang dikelola di source control, dan memantau kepatuhan konfigurasi dengan plugin Naemon kustom
Ini proses yang sepenuhnya dapat direproduksi, tetapi tim-tim startup membuat konfigurasi sekali pakai seperti kepingan salju di cloud, menghabiskan ribuan euro setiap bulan, namun menghasilkan sesuatu yang lebih buruk daripada yang dilakukan para pionir DevOps pada 2017
Saya juga menulis artikel berjudul The Emperor's New clouds tentang topik ini: https://logical.li/blog/emperors-new-clouds/
Saya tidak pernah memahami pertanyaan “bagaimana cara mereproduksi konfigurasi tanpa Docker atau teknologi lain”
Script-nya deterministik, versi dependensi dikunci, konfigurasi, argumen input, dan urutan eksekusinya sama, serta berjalan di perangkat komputasi yang deterministik
Tidak ada alasan mengapa itu tidak bisa direproduksi
Alih-alih mengatakan ada Docker di VM yang di-hardening, cukup katakan ada kubelet, dan alih-alih beberapa “docker services” yang tambal sulam, Anda bisa mengendalikan semua VM itu dengan control plane k8s yang biayanya sangat kecil
Saya tidak tahu mengapa cara itu lebih baik, dan justru terlihat lebih buruk
Infrastruktur cloud yang buruk adalah ketika Anda mencoba memakai semua yang dijual AWS sampai seluruh infrastruktur terikat pada lapisan abstraksi yang terlalu tinggi dan tidak bisa dipindahkan ke platform lain
k8s sama sekali bukan hal seperti itu
Jika jawaban untuk salah satu di antaranya adalah “buatan sendiri” atau “tinggal pakai satu script”, justru itulah alasan k8s bernilai
Untuk backend Python, cukup reproduksi build script di VPS:
pip install requirements.txt>python main.py>nano /etc/systemd/system/myservice.service>systemd start myservice> selesaiUntuk memperluas instance, masukkan perintah-perintah ini ke bash script
build_my_app.sh, yang akan berperan seperti Dockerfile baru dan bisa diinstal di server mana pun dalam puluhan detikJika dipakai sebagai IaaS, prototipe bisa dibuat jauh lebih cepat dibanding cara lain, termasuk VPS dari penyedia lain
Khususnya Google Cloud memiliki efek lock-in yang lebih kecil dan lebih sesuai dengan prinsip minimnya kejutan
Namun setelah membuat prototipe, Anda perlu bertanya apakah sebaiknya membangunnya ulang di tempat yang lebih murah
Fakta bahwa disk bisa diperluas nyaris tanpa batas dan mendukung snapshot itu bagus, dan cloud bisa memungkinkan prototipe diskalakan hingga beban produksi untuk mengukur skala yang benar-benar dibutuhkan
Tetapi jika mengandalkan “sihir cloud” seperti Cloud Run atau Lambda, waktu yang dihabiskan untuk belajar dan debugging pada akhirnya sama saja dengan melakukannya dengan cara lama
Di startup kecil, kami hampir melakukan seperti ini
Memang ada bagian rumit seperti autoscaling antrean kerja yang bercampur GPU, tetapi intinya adalah nginx, aplikasi web, Postgres, Redis di satu VM
Karena B2B, trafiknya juga hampir tidak ada
Para developer bisa menjalankan konfigurasi yang sama persis di laptop Linux atau VM Linux di platform lain, dan jika mau, masing-masing juga bisa punya VM cloud untuk demo atau pengujian
Bootstrap sistem baru kira-kira hanya memasukkan SSH key ke repositori dan menjalankan skrip shell
Mudah di-debug, tidak rumit atau mahal, dan sebelum perlu scaling horizontal, masih bisa scaling vertikal cukup jauh
Tidak cocok untuk semua orang, tetapi menurut saya sepenuhnya memadai sebelum tahap seed
Ini satu tingkat indireksi dari cara “menyimpan public key di repositori”, dan pengguna bisa mengganti key mereka sendiri tanpa perubahan Git
Selain itu, meski sudah cukup menyimpang dari penjelasan awal, penyewaan SSH key sangat bagus karena menangani situasi offboarding dengan jauh lebih baik: https://github.com/hashicorp/vault/blob/v1.12.11/website/con...
Saat mencari tautannya, saya juga menemukan dokumentasi yang mengklaim Vault juga menyediakan kata sandi sekali pakai <https://github.com/hashicorp/vault/blob/v1.12.11/website/con...>
Namun saya berada tegas di kubu “PasswordLogin no”, jadi untuk yang itu silakan gunakan dengan hati-hati masing-masing
Postgres bisa melakukan apa saja
Dalam konfigurasi seperti itu, bagaimana cara melacak konfigurasi dan update VM?
Jawabannya adalah “tidak, tidak perlu”
SaaS saya awalnya berjalan di satu server, lalu setelah mendapatkan product-market fit, saya memindahkannya ke beberapa server
Server-server ini adalah server bare-metal Hetzner, tidak ada microservice dan tidak berurusan dengan Kubernetes, tetapi kami menjalankan database terdistribusi
Server bare-metal ini jauh lebih kuat dibanding mesin virtual milik penyedia cloud
Beberapa tahun lalu saya juga mengukurnya sendiri: https://jan.rychter.com/enblog/cloud-server-cpu-performance-...
Secara keseluruhan, pendekatan ini sangat efektif sampai terasa absurd
Tidak perlu menghadapi kompleksitas seperti Kubernetes, menghindari kegagalan berantai yang tak terhindarkan dalam sistem kompleks, serta menghemat waktu pengembangan, pemeliharaan, dan biaya server bulanan
Pertanyaan umum adalah “tapi bagaimana dengan scaling?”, padahal belum tentu scaling itu akan dibutuhkan, dan dengan komputer sekuat ini serta desain yang masuk akal, 3–5 server saja bisa membawa Anda sangat jauh
Tentu saja ini bukan berarti menjalankan bisnis dari lemari di rumah
Untuk manajemen server, otomatisasi tetap diperlukan, dan saya memakai ansible serta terraform
Itu memancing optimisme bahwa software akan sukses besar dalam waktu sangat singkat, dan orang-orang ingin mempercayainya
Saya tidak tahu apakah Anda membaca artikelnya atau hanya melihat judulnya
Kalau Anda turun sampai bagian A few considerations di bawah, mungkin akan sulit untuk tertawa
“Beberapa pertimbangan” itu adalah paket pekerjaan keamanan yang cukup besar, terutama jika Anda menyimpan atau mengirim informasi yang sangat sensitif
Dalam situasi seperti ini, bagaimana menangani persyaratan kepatuhan seperti HIPAA?
Ada dua jenis programmer
Mereka yang merasa sudah melihat semuanya, dan mereka yang tahu bahwa mereka hampir belum melihat apa-apa
Karena itu, pernyataan absolut seperti ini melelahkan
Inti 20% dari Kubernetes adalah deployment, pod, service, cara menangani deployment blue-green, definisi deklaratif, dan pemisahan namespace, dan itu benar-benar bagus
Kalau hanya mematuhi dasar sederhana ini, memakai layanan Kubernetes cloud terkelola, dan menaruh database yang memiliki state di luar cluster, pengalamannya jadi baik
Masalah muncul ketika orang tersedot ke lubang kelinci “cloud native” dan mulai memakai segala macam sistem open-source niche, operator, ambassador, pola sidecar, dan sebagainya
Hal-hal seperti itu dibuat untuk lingkungan tempat beberapa tim teknologi yang saling independen tetapi terhubung, serta berbagai bahasa pemrograman, hidup berdampingan
Dalam diskusi seperti ini, saya merasa orang sering membicarakan dua hal yang berbeda
Bagi saya, itu hanyalah cara deployment yang seragam, lebih baik daripada Docker Compose
Untuk control plane biayanya sangat kecil, dan worker hanyalah VM biasa dengan kubelet
Namun bagi banyak orang, “Kubernetes” tampaknya berarti paragraf kedua di atas
Sama sekali tidak harus dipakai seperti itu
Cukup coba menyiapkan cluster k3s dan pelajari hanya workload, service, ingress
Itu sudah cukup untuk menggantikan VM tambal-sulam dan konfigurasi Docker
99% hanya perlu atau menginginkan sesuatu setingkat docker-compose++
Kalau zero-downtime deployment tersedia secara default, dan ada sistem konfigurasi sederhana untuk replica set atau mekanisme replikasi/distribusi lain, hampir selesai sudah
Akan bagus kalau ada sesuatu yang hanya melakukan itu
Kubernetes membawa banyak beban, sementara Docker Compose sedikit terlalu mendasar untuk kebutuhan produksi yang penting
Kubernetes punya kira-kira sejuta knob dan dial yang bisa disetel agar cocok untuk penggunaan apa pun, tetapi sama halnya, kita juga bisa mengabaikannya dan menjaga semuanya tetap sederhana dengan hanya memakai fitur inti
Kita bisa cepat membuat setup dengan deployment yang layak, log dan metrik yang sangat mudah, serta developer experience yang bagus
Reputasinya sangat buruk dan saya belum pernah memakainya sebelumnya, jadi ketika bertanya apakah boleh menyiapkan server untuk tool internal, saya sudah bersiap menghadapi yang terburuk
Kenyataannya, orang yang menyiapkannya memberi tutorial 30 menit, menjelaskan seluruh konsepnya, lalu memberi cukup informasi untuk men-deploy server, dan saya berhasil men-deploy tanpa masalah
Membuat auto deployment lewat
git pushjuga selesai sangat cepatBagi saya, itu tampak seperti pilihan yang terlalu jelas
Jauh lebih mudah dipakai jika service-nya tidak benar-benar hanya satu
Namun saya memang tidak menginstalnya sendiri, jadi mungkin reputasi buruknya berasal dari bagian itu
Kalau di CV tidak ada k8s, siapa yang bisa dapat pekerjaan baru? :)
Seriusnya, saya rasa banyak orang sengaja mengambil jalan sulit untuk mempelajari infrastruktur berskala besar
Alasan umum lainnya adalah “kalau pelanggan jadi sangat banyak, ini akan jauh lebih mudah” atau “bisa diskalakan secara dinamis sesuai permintaan”
Semua itu masuk akal bagi orang yang membangunnya, tetapi tidak seberapa masuk akal bagi founder atau CTO profesional
Sebagian orang tidak peduli pada kebutuhan dan jadwal calon pelanggan, lalu membakar uang untuk membuat omong kosong yang tampak keren
Mirip seperti pergi ke bengkel untuk mengganti ban, tetapi mekaniknya butuh 3 minggu karena, demi hasrat pengembangan dirinya, ia ingin memasang hidrolik lowrider dan dop roda berputar
Yang terburuk adalah bagi orang berikutnya, semuanya menjadi secara inheren ambigu
Kita tidak tahu apakah sesuatu ada di sana karena memang benar-benar diperlukan, atau hanya hiasan berkilau
Saya tidak tahu apakah orang melakukannya karena minat, karena menyukai teknologi, atau seperti yang disebutkan tadi, untuk meningkatkan kemampuan secara teknokratis agar bisa memasukkan k8s ke CV
Saya hanya berpikir, “kelihatannya menyakitkan untuk dikelola”
Karena itu, menurut saya infrastruktur k8s sebaiknya dirancang dan dikerjakan oleh kelompok yang lebih sempit berisi orang-orang yang benar-benar ahli, atau setidaknya ahli yang bisa membimbing para mentee
Dan jika tidak perlu, yaitu pada kebanyakan startup, usaha kecil, dan perusahaan berukuran biasa, sebaiknya tetap memakai paradigma yang sudah ada yang lebih mudah digunakan
Mereka sangat puas dengan pilihan itu, dan telah menuliskannya secara rinci di blog
Ini adalah kasus ketika “kalau pelanggan jadi sangat banyak, ini akan jauh lebih mudah” benar-benar tepat sasaran
Ini debat lama dan sering melelahkan, tapi tetap saja saya tambahkan dua sen saya
Apakah harus memilih framework yang kompleks sejak hari pertama? Mungkin tidak, kecuali tim punya pengalaman yang cukup
Namun yang saya tentang adalah gagasan bahwa mengelola infrastruktur dengan proses dan alat kustom selalu membutuhkan upaya pemeliharaan lebih sedikit daripada alat yang sudah teruji
Sikap keras kepala menolak orang-orangan sawah bernama “kompleksitas”, padahal proses buatan sendiri sama sekali tidak sederhana dan banyak menyita waktu dari produk inti
Semua orang suka kesederhanaan menyalin binary ke VPS dan me-restart layanan
Namun tak lama kemudian Anda butuh pengelolaan konfigurasi dan secret, lalu ketika server menjadi lebih dari satu demi ketersediaan dan redundansi, Anda butuh gradual deployment, load balancing, rollback, dan sebagainya
Anda juga akan menginginkan lingkungan staging, dan workflow ini harus mudah direplikasi
Ketika tim membesar, akan terlihat juga bahwa lingkungan yang mirip production tidak bisa dijalankan secara lokal
Begitulah requirement terus bertambah
Pada akhirnya, untuk setiap requirement baru, alih-alih mengandalkan solusi standar yang sudah diselesaikan orang lain, Anda harus menyelesaikannya dengan cara khusus Anda sendiri
Belakangan ini menjadi masalah sunk cost
Apakah akan membuang alat kustom yang Anda kenal dan pahami, lalu pindah ke “kompleksitas” yang tidak Anda kenal?
Semakin banyak Anda berinvestasi, semakin sulit pindah di kemudian hari
Saran saya adalah mengikuti praktik sejak awal yang membuat perpindahan ke alat standar nanti menjadi mudah
Artinya, deploy dengan container sejak hari pertama dan mengadopsi metodologi 12-factor
Lalu ketika Anda mulai kesulitan karena fitur yang dibutuhkan, lebih baik beralih ke alat teruji lebih awal daripada terlambat
Besar kemungkinan Anda akan menyadari bahwa ketakutan terhadap hal yang tidak dikenal itu tidak berdasar, dan dalam jangka panjang waktu yang dihabiskan untuk infrastruktur akan berkurang
Pendekatan yang pernah saya pertimbangkan adalah mulai dari hari pertama dengan alat standar, yaitu k8s + gitops, tetapi tetap menjalankannya di satu VM
Bagaimana menurut Anda?
Sebaliknya, ada banyak “cloud engineer” yang memahami sistem cloud “kompleks” seperti ini dan bisa men-deploy serta memeliharanya dengan terraform
Itu adalah skill set yang bisa langsung dipakai
VM, block/blob storage, DNS, IdP, registrar domain
Hanya sejauh itu yang pernah saya pakai dengan nyaman di cloud
Begitu masuk ke FaaS dan teman-temannya, bagi saya rasanya benar-benar aneh
Sulit bagi saya menerima bahwa saya tidak bisa mengintip mesin tempat lingkungan production berjalan
Pengalaman debugging lewat dashboard cloud itu buruk sekali
Saya melihat pendekatan Microsoft sebagai yang paling dekat dengan sesuatu yang benar-benar “berfungsi”, tetapi tetap saja sangat mengerikan dan saya tidak ingin menyentuhnya lagi
Setelah 10 tahun pun arsitektur ideal saya masih berupa codebase monolitik di satu VM yang berkomunikasi dengan instance SQLite lokal
Munculnya storage NVMe cukup banyak memperkuat pendekatan ini
Backup ditangani dengan snapshot perangkat block storage, dan durabilitas transaksi ditangani dengan replikasi WAL bila diperlukan
Sederhana sampai terasa bodoh
Ini membuat kita bisa fokus pada bisnis dan pelanggan
Pelanggan sama sekali tidak peduli soal hal seperti ini, dan tidak akan membayar untuk itu
Semua kode dan infrastruktur adalah faktor negatif murni, jadi sebaiknya dimiliki sesedikit mungkin
Ketika orang mengatakan cloud lebih mahal daripada on-premises, sering kali inilah alasannya
Jika Anda akan menjalankan VM 24 jam sehari, ada pilihan yang lebih baik
Bahkan buku microservices pun mengatakan buat monolit terlebih dahulu
Sebelum mendapatkan respons pengguna nyata, Anda tidak tahu bagaimana sistem seharusnya dipecah, dan memecah monolit lebih mudah daripada merombak layanan
Mungkin saja Anda tidak pernah perlu memecah monolit selamanya
Stripe pada akhirnya memang memisahkan sebagian dari monolit Rails, tetapi monolit itu bisa melaju sangat jauh
Sulit membuat debugging lebih mudah daripada monolit seperti Django/Rails
Namun sedikit melihat ke depan ke mana infrastruktur akan bergerak memang membantu
Versi awal perusahaan kami dibuat sebagai container Django Docker di satu VM, dan deployment dilakukan manual dengan
docker pull; docker stop; docker startKonfigurasi ini bertahan lebih lama dari yang diperkirakan
Docker bagus sebagai cara menghindari masalah packaging dependency
Di tahap awal, masalah seperti apakah server punya file header C yang diperlukan saat menginstal driver DB baru, atau apakah konfigurasinya berbeda dari Mac, bisa merepotkan
Setelah seed extension round, kami pindah ke k8s karena kebutuhan bisnis akan reliabilitas dan skalabilitas, dan k8s bertahan dengan baik sampai Series B
Karena semuanya sudah di-Docker-kan, transisinya juga mudah, tetapi pada tahap awal kami secara agresif mengurangi kompleksitas
Dan jangan membuat ulang versi jelek dari fitur yang sudah disediakan framework; pakailah framework dengan benar
Dalam hal ini, satu orang berpengalaman memberi hasil lebih baik daripada 10 orang yang belum berpengalaman
Seiring waktu, perbedaannya terakumulasi
Menurut saya separuh alasan sebenarnya orang muak dengan monolit adalah karena monolit yang buruk dan tidak dioperasikan dengan benar
Katanya data harus disimpan di layanannya sendiri, dan jika diperlukan pendekatan multi-paradigma seperti relasional dan full-text search, itu bisa menjadi beberapa layanan
Pengalaman pengguna juga harus memakai layanannya sendiri
Setidaknya harus ada layanan lain di antaranya, dan biasanya Django dan Rails masuk di sini
Secara opsional, katanya layanan tambahan seperti autentikasi dan transaksi finansial juga mungkin diperlukan
Saya mengoperasikan satu proyek selama sekitar 6 tahun di satu VPS 10 dolar per bulan
Berkat diskon permanen yang didapat dari lowendtalk, sebenarnya saya membayar lebih sedikit, dan penyedianya adalah provider VPS yang berfokus pada server game
Selain satu kali down seharian karena saya mengacaukan konfigurasi sehingga harus reinstall OS bersih, dan satu kali provider mengganti alamat IP setelah pemberitahuan sebelumnya, stabilitasnya nyaris di level 99,999
Teknologi VPS sudah berkembang sangat jauh dan sangat stabil
Disk node dikonfigurasi dengan RAID 1, dan saat maintenance node, VM itu sendiri juga bisa dengan mudah di-live migration ke mesin lain
Snapshot juga bisa dibuat
Bagi saya, alasan memilih infrastruktur cloud bukan karena stabilitas yang lebih tinggi, melainkan karena fitur kolaborasi dan manajemen operasi seperti IAM, secret management, infrastructure as code, atau alasan kepatuhan data center seperti HIPAA
Tergantung situasinya
Secara pribadi, saya suka solusi berbasis cloud karena sangat menghemat waktu
Namun harus sangat selektif memilih apa yang akan dipakai, dan ada juga solusi yang terlalu rumit sehingga jelas-jelas kontraproduktif
Saya menjalankan startup bootstrap kecil
Kami bahkan kekurangan uang untuk menggaji diri sendiri, dan saya menyambung hidup lewat konsultasi sampingan
Dengan anggaran dan waktu yang terbatas seperti ini, kami harus sangat berhati-hati memilih apa yang akan dipakai
Karena itu saya suka layanan seperti Google Cloud
Tagihan GCP kami cukup rendah, hanya beberapa ratus euro per bulan
Kami bisa saja pindah ke penyedia yang lebih murah, tetapi sulit membenarkan investasi waktunya, dan dibanding AWS yang pernah saya pakai dulu, saya juga menyukai UI dan alat-alat dari Google
Kami tidak punya kebutuhan memakai Kubernetes
Biaya menjalankan klaster kosong saja mungkin lebih mahal daripada tagihan GCP bulanan kami saat ini
Kami juga tidak membutuhkannya karena tidak terjebak dalam perangkap microservices
Tetapi saya suka Docker
Docker membuat deployment software menjadi sangat mudah
Situs web kami adalah bucket Google Storage yang disajikan melalui load balancer dan Google CDN
Load balancer yang sama merutekan panggilan REST ke dua VM yang menjalankan monolith
VM-VM ini berkomunikasi dengan DB terkelola, Elasticsearch terkelola, dan Redis terkelola
DB dan Elasticsearch memang mahal, tetapi memakainya sebagai layanan terkelola menghemat banyak waktu dan tenaga
Hampir hanya itu yang kami punya, dan setup ini sederhana serta tidak terlalu mahal
Jika semuanya dipindahkan ke tempat seperti Hetzner, biaya mungkin bisa turun sekitar 50%
Itu mungkin layak dicoba, tetapi bagi saya bukan urusan yang sangat mendesak
Kehilangan layanan terkelola itu akan membuat hidup saya lebih sulit
Beberapa pelanggan tampaknya lebih menyukai AWS, jadi suatu hari kami mungkin harus kembali ke AWS, dan itu juga menjadi pertimbangan