Hampir Semua Keputusan Infrastruktur yang Saya Dukung/Sesali Setelah 4 Tahun Mengelola Infrastruktur di Startup

 (cep.dev)
87 poin oleh xguru 2024-02-28 | 4 komentar | Bagikan ke WhatsApp
  • Untuk setiap pilihan, ditandai sebagai Endorse (dukung) dan Regret (sesal)

Memilih AWS

  • Memilih AWS dibanding Google Cloud: Saya mendukung keputusan memilih AWS. AWS berfokus pada pelanggan. Google Cloud terasa bergantung pada robot dan otomatisasi.
  • EKS: Saya mendukung penggunaan EKS. EKS menawarkan integrasi yang dalam dengan layanan AWS, dan Kubernetes juga sudah banyak mengejar ketertinggalan dalam berbagai hal (misalnya integrasi dengan Route53 menggunakan externaldns)
  • Add-on terkelola EKS: Saya menyesali penggunaan add-on terkelola EKS. Kami perlu menyesuaikan instalasi, dan setelah beralih ke chart helm, pengalaman operasional menjadi lebih baik

Database dan caching

  • RDS: Saya mendukung penggunaan RDS. Data adalah bagian terpenting dari infrastruktur, dan biaya menggunakan RDS sepadan
  • Redis ElastiCache: Saya mendukung penggunaan Redis. Redis sangat efektif untuk cache dan penggunaan umum
  • ECR: Saya mendukung migrasi dari quay.io ke ECR. ECR lebih stabil dan integrasi perizinannya lebih dalam

Jaringan dan dukungan

  • AWS VPN: Saya mendukung penggunaan AWS VPN. VPN sangat sederhana untuk dikonfigurasi dan dipahami. Kami menggunakan Okta untuk mengelola akses VPN, dan pengalamannya sangat baik
  • AWS Premium Support: Saya menyesalinya. Biaya AWS Premium Support sangat mahal, dan tidak sepadan jika pengetahuan internal tentang AWS Anda tidak kurang
  • Control Tower Account Factory for Terraform: Saya mendukung integrasi AFT. Ini membantu mengotomatisasi pembuatan akun dan menstandarkan tag

Otomatisasi proses

  • Otomatisasi postmortem dengan bot Slack: Saya mendukung otomatisasi proses postmortem. Ini membantu mendorong orang untuk menulis postmortem
  • Menggunakan template insiden di PagerDuty: Saya mendukung penggunaan template saat insiden terjadi. Ini memungkinkan sedikit penyesuaian dengan memanfaatkan fleksibilitas Notion
  • Tinjauan rutin tiket PagerDuty: Saya mendukung peninjauan rutin konfigurasi alert. Ini membantu memastikan alert yang tidak penting pun tidak diabaikan
  • Mengelola postmortem di Datadog atau PagerDuty: Saya menyesali penggunaan alat manajemen terintegrasi untuk postmortem. Keduanya sulit disesuaikan untuk proses postmortem. Menurut saya, lebih baik menggunakan alat yang kuat seperti Notion

Lain-lain

  • Rapat pelacakan biaya bulanan: Saya mendukung rapat bulanan untuk meninjau biaya SaaS. Ini memastikan apakah biaya sudah tepat dan tindakan yang diperlukan diambil. Di AWS, item dikelompokkan berdasarkan tag dan dipisahkan per akun. Saya merekomendasikan untuk tidak berhenti di AWS saja, tetapi meninjau semua sumber pengeluaran besar yang dimiliki perusahaan
  • Tidak lebih banyak menggunakan FaaS: Saya menyesali bahwa kami tidak bisa sepenuhnya menggunakan FaaS karena tidak ada opsi FaaS untuk pekerjaan GPU. Banyak pekerjaan CPU sebenarnya bisa ditangani dengan FaaS. Keuntungan tersembunyi lain dari Lambda adalah sangat mudah melacak biaya dengan akurasi tinggi
  • GitOps: Saya mendukung penggunaan GitOps. Kami menggunakan GitOps untuk banyak bagian infrastruktur dan berinvestasi dalam pengembangan alat untuk membantu memahami status deployment
  • Mengutamakan efisiensi tim: Saya mendukung memprioritaskan peningkatan efisiensi tim. Saya tidak pernah menyesal menginvestasikan waktu dalam otomatisasi atau dokumentasi
  • Beberapa aplikasi berbagi satu database: Saya menyesali beberapa aplikasi berbagi satu database. Ini menimbulkan berbagai masalah

Adopsi SaaS

  • Terlambat mengadopsi platform identitas: Kami dulu menggunakan Google Workspace untuk memberikan izin, tetapi saya menyesali tidak mengadopsi solusi identitas seperti Okta lebih awal. Okta terintegrasi dengan baik dan membantu menyelesaikan masalah keamanan serta kepatuhan
  • Notion: Saya mendukung penggunaan Notion untuk menulis dokumentasi. Notion adalah pilihan yang sangat baik dan jauh lebih mudah digunakan dibanding yang pernah saya pakai sebelumnya (wiki, Google Docs, Confluence, dll.). Konsep database untuk mengatur halaman sangat berguna
  • Slack: Saya mendukung penggunaan Slack. Ini efektif sebagai alat utama untuk komunikasi

Alat dan layanan pengembangan

  • Pindah dari JIRA ke Linear: Saya mendukung penggunaan Linear alih-alih JIRA. Menurut saya JIRA terlalu rumit dan berat
  • Tidak menggunakan Terraform Cloud: Saya tidak menyesali tidak menggunakan Terraform Cloud karena biayanya tidak bisa dibenarkan. Kami beralih ke Atlantis dan menambahkan otomatisasi yang diperlukan ke pipeline CI/CD
  • GitHub Actions untuk CI/CD: Saya cukup mendukung (Endorse-ish) penggunaan GitHub Actions. Action di marketplace dan sintaksnya mudah digunakan. Kekurangannya adalah dukungan yang terbatas untuk workflow self-hosted

Pilihan teknologi

  • Datadog: Saya menyesali penggunaan Datadog. Biayanya sangat mahal, dan model biayanya tidak cocok untuk klaster Kubernetes dan perusahaan AI
  • PagerDuty: Saya mendukung penggunaan PagerDuty. Produknya bagus dan harganya masuk akal
  • Migrasi skema by Diff: Saya cukup mendukung penggunaan alat untuk migrasi skema. Data itu penting dan migrasi skema bisa berisiko
  • Ubuntu untuk server dev: Saya mendukung penggunaan Ubuntu sebagai server pengembangan. Dukungannya baik dan memiliki sebagian besar paket yang dibutuhkan
  • AppSmith: Saya mendukung penggunaan AppSmith untuk otomatisasi proses bagi engineer internal. Kami melakukan self-hosting dan hasilnya cukup memuaskan. Awalnya kami mempertimbangkan integrasi yang lebih dalam dengan menggunakan retool, tetapi saat itu kami tidak bisa membenarkan harganya hanya untuk beberapa integrasi
  • helm: Saya mendukung penggunaan Helm v3. Ada masalah dengan deployment CRD dan pelatihan developer, tetapi ini cukup baik untuk mengemas dan men-deploy objek Kubernetes
  • chart helm di ECR (oci): Saya mendukung penyimpanan chart helm di registry OCI. Ini lebih minim masalah dibanding cara lama yang menggunakan S3 dan plugin
  • bazel: Saya tidak yakin tentang bazel. Untuk deployment layanan Go, ini terasa berlebihan, dan GitHub Actions lebih mudah digunakan oleh lebih banyak engineer
  • Tidak menggunakan OpenTelemetry: Saya menyesali mengirim metrik langsung menggunakan API DataDog. Saya merekomendasikan menggunakan OpenTelemetry sejak awal
  • Memilih renovatebot alih-alih dependencyabot: Saya menyesali tidak memikirkan lebih awal tentang menjaga dependensi tetap terbaru. Renovatebot bisa dikustomisasi, tetapi pengaturan dan debugging-nya rumit
  • Kubernetes: Saya mendukung penggunaan Kubernetes. Kami membutuhkan sarana untuk meng-host layanan yang berjalan jangka panjang, dan Kubernetes populer serta bekerja dengan baik
  • Membeli IP sendiri: Saya mendukung membeli blok IP sendiri saat bekerja dengan mitra eksternal. Ini membantu menyediakan blok CIDR yang lebih besar untuk di-whitelist oleh mitra eksternal
  • Memilih Flux untuk GitOps k8s: Saya tidak menyesali memilih Flux sebagai alat GitOps untuk Kubernetes. Tetap perlu mengembangkan alat yang membantu memahami status deployment
  • Karpenter untuk manajemen node: Saya mendukung penggunaan Karpenter saat memakai EKS. Ini lebih andal dan lebih efisien biaya dibanding autoscaler lain
  • Menggunakan SealedSecrets: Saya menyesali penggunaan SealedSecrets. Ini rumit bagi developer dan menghilangkan otomatisasi rotasi password bawaan AWS
  • Menggunakan ExternalSecrets: Saya mendukung penggunaan ExternalSecrets untuk sinkronisasi password AWS -> Kubernetes. Ini mudah dipahami developer dan memudahkan pembuatan/pembaruan password di AWS menggunakan terraform
  • Menggunakan ExternalDNS: Saya mendukung penggunaan ExternalDNS. Ini menyinkronkan entri DNS Kubernetes -> Route53 dan hampir tidak menimbulkan masalah selama 4 tahun terakhir
  • Menggunakan cert-manager: Saya mendukung penggunaan cert-manager untuk pengelolaan sertifikat SSL. Sangat intuitif untuk membuat sertifikat Let's Encrypt dan tidak menimbulkan masalah
  • Bottlerocket untuk EKS: Saya menyesali menjalankan klaster EKS dengan Bottlerocket. Masalah CSI jaringan sering terjadi dan sulit di-debug
  • Memilih Terraform dibanding CloudFormation: Saya mendukung penggunaan Terraform. Ini memudahkan ekspansi ke penyedia SaaS lain dan memiliki sintaks yang lebih mudah dibaca daripada CloudFormation
  • Tidak menggunakan solusi IaC berbasis kode: Saya tidak menyesalinya. Sementara Terraform dan CloudFormation menggunakan file data, Pulumi atau CDK mendeskripsikan infrastruktur sebagai kode. Sifat HCL Terraform yang terbatas membantu mengurangi kompleksitas
  • Tidak menggunakan service mesh jaringan: Saya tidak menyesalinya. Service mesh memang keren, tetapi perusahaan cenderung meremehkan kompleksitasnya. Saran umum untuk infrastruktur adalah "lebih sedikit itu lebih baik"
  • Load balancer Nginx untuk ingress EKS: Saya tidak menyesalinya dan mendukung penggunaan Nginx. Teknologi ini memang tua, tetapi stabil dan sudah teruji
  • homebrew untuk skrip perusahaan: Saya mendukung penggunaan homebrew untuk distribusi skrip perusahaan. Ini cukup baik untuk mendistribusikan skrip dan biner ke pengguna Linux maupun Mac
  • Go untuk layanan: Saya mendukung penggunaan bahasa Go untuk layanan. Mudah dipelajari oleh engineer baru dan secara keseluruhan merupakan pilihan yang baik

Bacaan terkait

4 komentar

 
nicewook 2024-02-28

Baik isi artikel maupun komentarnya sama-sama sangat berharga.
 
mhj5730 2024-02-28

Wah.... ini informasi praktis yang sulit didapat di mana pun
 
xguru 2024-02-28

Komentar Hacker News

  • Biaya tambahan menggunakan RDS memang sepadan

    • Biaya tambahan menggunakan RDS terasa sangat tidak masuk akal mahalnya setiap kali mempertimbangkan penggantinya dengan klaster SQL Server yang dikolokasikan, sampai rasanya cuma bisa tertawa. Biayanya jauh melebihi jumlah yang bersedia dibayar, sampai bisa menutup rak kolokasi, AWS Direct Connect, server, SAN, lisensi SQL Server, kontrak pemeliharaan, dan gaji DBA internal penuh waktu.
    • Total biaya 12 bulan: 547,441.85 USD
    • Jika markup-nya sudah cukup besar untuk membayar gaji satu atau lebih karyawan penuh waktu, sebaiknya pertimbangkan merekrut orang sebagai gantinya alih-alih terus menskalakan RDS secara membabi buta. Saat memakai RDS, Anda benar-benar membayar sangat mahal, dan keputusan yang dibuat di awal pendirian perusahaan perlu dievaluasi kembali.

  • Mungkin ini pendapat yang tidak populer, tetapi Google Cloud lebih unggul daripada AWS, dan dengan Google Cloud Run Anda bisa menjalankan kontainer Docker di cloud seperti mimpi. Nama layanannya sederhana, jumlah layanan pentingnya lebih sedikit dibanding layanan AWS yang rumit, dan UI-nya lebih intuitif. Kekurangannya adalah tutorial yang lebih sedikit karena komunitasnya kurang besar, lebih sulit mencari tenaga berpengalaman, dan lebih sedikit alat pihak ketiga. Layak dicoba.

  • Menggunakan EC2 + ASG itu sangat menyenangkan. Secara konsep sederhana: luncurkan image ke ASG, lalu atur kebijakan auto scaling. Hampir tidak ada yang perlu dikhawatirkan. Sebaliknya, menggunakan k8s selalu menjadi urusan besar. Dibentuk tim khusus untuk mengelola k8s. Puluhan konsep k8s diperkenalkan, atau diinvestasikan person-year ke "platform engineering" untuk menyembunyikan konsep k8s. Pedoman, SDK, dan berbagai validator dirilis agar k8s bisa digunakan "dengan benar". Meski begitu, tetap saja harus menulis puluhan ribu baris YAML dan kode untuk mengimplementasikan operator. Kadang muncul pertanyaan apakah k8s terlalu intrusif.

  • Pendapat tentang produk SaaS

    • Tidak paham soal pindah dari JIRA ke Linear. Linear memang oke, tetapi sering menemukan hal-hal yang tidak bisa dilakukan atau tidak jelas caranya.
    • Secara umum merekomendasikan penggunaan Terraform Cloud. Menumbuhkan sistem buatan sendiri di rumah mungkin baik-baik saja untuk beberapa tahun pertama, tetapi dalam jangka panjang bisa mahal.
    • Agak mendukung penggunaan GitHub Actions untuk CI/CD. Sebagai gantinya, disarankan memakai GitLab.
    • Sangat tidak setuju soal Datadog. Itu adalah alat monitoring/observability terbaik di pasar. Keluhan paling umum memang biaya, tetapi kebanyakan kasus biaya meledak karena konfigurasi Datadog yang buruk.
    • Mendukung pendapat soal Pagerduty. Pagerduty kira-kira 10 kali lebih mahal daripada Opsgenie dan tidak menawarkan fungsi yang lebih baik. Saat pembaruan kontrak dengan Pagerduty, ketika ditanya fitur apa yang tidak ada di Opsgenie, tim sales menjawab bahwa mereka ingin memposisikan diri sebagai merek premium di pasar. Jadi, saya puas menggunakan merek biasa untuk pelaporan insiden.

  • Bisa dibayangkan developer era 90-an/00-an membaca daftar ini lalu bingung dengan kompleksitas dan istilah-istilahnya.

  • Menarik untuk dibaca, tetapi tidak yakin apakah ini benar-benar ditulis oleh orang yang cukup menyesal sampai merasa perlu menulis blog.

  • Ada dorongan untuk bereksperimen kembali ke satu server raksasa seharga $100k dan menjalankan semuanya dalam satu kotak.

  • Berhasil mempelajari dasar-dasar Kubernetes / EKS, tetapi sedang mempertimbangkan pindah ke ECS. Kubernetes terlalu kompleks dibanding kebutuhan kami. Sulit dikendalikan dengan sesuatu seperti CloudFormation. Load balancer yang diprovisikan lewat add-on sulit dirujuk dari luar Kubernetes. Logging dari EKS Fargate ke Cloudwatch tampaknya tidak berfungsi bahkan setelah mengikuti dokumentasi. Metrik CPU/memori juga tidak bekerja seperti di EKS EC2, dan sepertinya membutuhkan ADOT. Di ECS, lingkungan bisa dikonfigurasi ulang dalam 1/10 waktu dan semuanya berjalan baik.

  • Suka dengan cara tulisan ini ditulis dan isinya. Saya tidak setuju dengan beberapa keputusan dan rekomendasinya, tetapi bahkan dalam kasus seperti itu pun, membaca alasannya tetap sangat bagus. Akan menyenangkan jika lebih banyak tulisan serupa diterbitkan sehingga bisa dibandingkan. Saya jadi terinspirasi untuk menulis sesuatu yang mirip.

  • Basis data "kitchen sink" yang dipakai semua orang adalah masalah umum, tetapi terus berulang. Saat bertumbuh, itu menjadi utang teknis yang signifikan dan bottleneck kinerja. Dengan memakai DB terkelola seperti RDS, kita bisa dengan mudah menjalankan klaster DB terpisah untuk tiap aplikasi utama.