Bir startup’ta 4 yıl boyunca altyapı işletirken iyi bulduğum/pişman olduğum (neredeyse) tüm altyapı kararları

 (cep.dev)
87 puan yazan xguru 2024-02-28 | 4 yorum | WhatsApp'ta paylaş
  • Tüm seçimler için Endorse (destek) ve Regret (pişmanlık) olarak işaretlenmiş

AWS seçimi

  • AWS yerine Google Cloud seçimi: AWS’yi seçmeyi destekliyorum. AWS müşteriye odaklanıyor. Google Cloud ise robotlara ve otomasyona dayanan bir yapı hissi veriyor.
  • EKS: EKS kullanmayı destekliyorum. EKS, AWS servisleriyle derin entegrasyon sağlıyor ve Kubernetes de birçok açıdan yetişti (ör. externaldns kullanarak Route53 ile entegre olmak gibi).
  • EKS yönetilen eklentileri: EKS yönetilen eklentilerini kullanmış olmaktan pişmanım. Kurulumu özelleştirme ihtiyacı oldu ve helm chart’larına geçtikten sonra daha iyi bir operasyon deneyimi yaşadım.

Veritabanı ve önbellekleme

  • RDS: RDS kullanmayı destekliyorum. Veri, altyapının en önemli parçası ve RDS kullanım maliyeti buna değer.
  • Redis ElastiCache: Redis kullanmayı destekliyorum. Redis, hem cache hem de genel kullanım için çok etkili.
  • ECR: quay.io’dan ECR’ye taşınmış olmayı destekliyorum. ECR daha kararlı ve yetki entegrasyonu daha derin.

Ağ ve destek

  • AWS VPN: AWS VPN kullanmayı destekliyorum. VPN’i kurmak ve anlamak çok basit. VPN erişimini yönetmek için Okta kullanıyoruz ve deneyimimiz çok iyi oldu.
  • AWS premium desteği: Pişmanım. AWS premium destek çok pahalı ve kurum içinde AWS bilgisi eksik değilse buna değmiyor.
  • Control Tower Account Factory for Terraform: AFT entegrasyonunu destekliyorum. Hesap oluşturmayı otomatikleştiriyor ve etiketlerin standartlaşmasına yardımcı oluyor.

Süreç otomasyonu

  • Slack bot ile postmortem otomasyonu: Postmortem sürecini otomatikleştirmeyi destekliyorum. İnsanları postmortem yazmaya yönlendirmeye yardımcı oluyor.
  • PagerDuty olay şablonları kullanımı: Olay anında şablon kullanmayı destekliyorum. Notion’ın esnekliği sayesinde bir miktar özelleştirme yapılabiliyor.
  • PagerDuty ticket’larını düzenli gözden geçirme: Alarm yapılandırmalarını düzenli olarak gözden geçirmeyi destekliyorum. Önemsiz görünen alarmların da göz ardı edilmemesini sağlıyor.
  • Datadog veya PagerDuty’de postmortem yönetimi: Postmortem için birleşik bir yönetim aracı kullanmış olmaktan pişmanım. Her ikisinde de postmortem sürecini özelleştirmek zor. Bence Notion gibi güçlü bir araç kullanmak daha iyi.

Diğer

  • Aylık maliyet takip toplantısı: SaaS maliyetlerini gözden geçirmek için aylık toplantı yapmayı destekliyorum. Maliyetlerin makul olup olmadığını kontrol etmeyi ve gerekli aksiyonları almayı sağlıyor. AWS tarafında kalemleri etiketlere göre gruplayıp hesap bazında ayırıyoruz. Sadece AWS ile sınırlı kalmayıp şirketin tüm büyük harcama kalemlerine bakmayı öneririm.
  • Daha fazla FaaS kullanmamak: GPU işleri için FaaS seçeneği olmadığı için FaaS’i tamamen kullanamamış olmaktan pişmanım. Birçok CPU işi FaaS ile çözülebilirdi. Lambda’nın bir diğer gizli avantajı da maliyeti çok yüksek doğrulukla takip etmeyi son derece kolaylaştırması.
  • GitOps: GitOps kullanmayı destekliyorum. Altyapının büyük bir kısmında GitOps kullanıyoruz ve dağıtım durumunu anlamaya yardımcı olacak araçlar geliştirmeye yatırım yapıyoruz.
  • Takım verimliliğini önceliklendirmek: Ekibin verimliliğini artırmayı önceliklendirmeyi destekliyorum. Otomasyona veya dokümantasyona zaman ayırdığım için hiç pişman olmadım.
  • Birden fazla uygulamanın tek bir veritabanını paylaşması: Birden fazla uygulamanın tek bir veritabanını paylaşmış olmasından pişmanım. Bu birçok soruna yol açtı.

SaaS benimseme

  • Kimlik platformunu geç devreye almak: Eskiden yetki atamak için Google Workspace kullanıyorduk ama Okta gibi bir kimlik çözümünü daha erken benimsememiş olmaktan pişmanım. Okta iyi entegre oluyor ve güvenlik ile uyumluluk sorunlarını çözüyor.
  • Notion: Dokümantasyon için Notion kullanmayı destekliyorum. Harika bir seçim oldu ve geçmişte kullandıklarımdan (wikiler, Google Docs, Confluence vb.) çok daha kolay çalışıyor. Sayfaları düzenlemek için veritabanı kavramı faydalı.
  • Slack: Slack kullanmayı destekliyorum. İletişim için temel araç olarak etkili.

Geliştirici araçları ve servisler

  • JIRA’dan Linear’a geçiş: JIRA yerine Linear kullanmayı destekliyorum. JIRA’nın fazla karmaşık ve ağır olduğunu düşünüyorum.
  • Terraform Cloud kullanmamak: Terraform Cloud maliyetini gerekçelendiremediğim için kullanmamış olmaktan pişman değilim. Atlantis’e geçtik ve ihtiyaç duyduğumuz otomasyonu CI/CD pipeline’ına ekledik.
  • CI/CD için GitHub Actions: GitHub Actions kullanımını bir ölçüde destekliyorum (Endorse-ish). Marketplace aksiyonları ve söz dizimi kullanımı kolay. Kendi barındırılan workflow’lar için desteğin sınırlı olmasını dezavantaj olarak görüyorum.

Teknoloji seçimleri

  • Datadog: Datadog kullanmış olmaktan pişmanım. Çok pahalı ve maliyet modeli Kubernetes cluster’ları ile yapay zeka şirketleri için uygun değil.
  • PagerDuty: PagerDuty kullanmayı destekliyorum. Ürün iyi ve fiyatı makul.
  • Diff tabanlı şema migrasyonu: Şema migrasyonu için araç kullanımını bir ölçüde destekliyorum. Veri önemli ve şema migrasyonları riskli olabilir.
  • Geliştirme sunucuları için Ubuntu: Geliştirme sunucularında Ubuntu kullanmayı destekliyorum. İyi destekleniyor ve ihtiyaç duyulan çoğu paketi barındırıyor.
  • AppSmith: İç mühendislik ekipleri için süreç otomasyonunda AppSmith kullanmayı destekliyorum. Self-hosted kullanıyoruz ve yeterince memnunuz. Başta daha derin entegrasyon için retool denemiştik ama o dönemde bunun yalnızca birkaç entegrasyon için olan fiyatını haklı çıkaramadık.
  • helm: Helm v3 kullanmayı destekliyorum. CRD dağıtımı ve geliştirici eğitimi tarafında sorunlar var ama Kubernetes nesnelerini paketlemek ve dağıtmak için yeterince iyi.
  • ECR içinde helm chart’ları (oci): Helm chart’larını OCI deposunda tutmayı destekliyorum. S3 ve eklenti kullanılan önceki yaklaşıma kıyasla sorunsuz.
  • bazel: bazel konusunda emin değilim. Go servislerini dağıtmak için fazla ağır kaçıyor gibi görünüyor ve GitHub Actions daha fazla mühendisin kolayca kullanabileceği bir seçenek.
  • OpenTelemetry kullanmamak: Metrikleri doğrudan DataDog API’siyle göndermiş olmaktan pişmanım. OpenTelemetry kullanımını en baştan öneririm.
  • dependencyabot yerine renovatebot seçimi: Bağımlılıkları güncel tutma konusunu daha erken düşünmemiş olmaktan pişmanım. Renovatebot özelleştirilebilir ama kurulumu ve hata ayıklaması karmaşık.
  • Kubernetes: Kubernetes kullanmayı destekliyorum. Uzun süre çalışan servisleri barındıracak bir araca ihtiyaç var ve Kubernetes popüler, ayrıca iyi çalışıyor.
  • Kendi IP’lerini satın almak: Dış partnerlerle çalışırken kendi IP bloklarını satın almayı destekliyorum. Bu, dış partnerlere whitelist için daha büyük CIDR blokları vermeyi kolaylaştırıyor.
  • k8s GitOps için Flux seçimi: Kubernetes için GitOps aracı olarak Flux seçmiş olmaktan pişman değilim. Dağıtım durumunu anlamaya yardımcı araçlar geliştirmek gerekiyor.
  • Node yönetimi için Karpenter: EKS kullanırken Karpenter kullanmayı destekliyorum. Diğer autoscaler’lara göre daha güvenilir ve daha maliyet etkin.
  • SealedSecrets kullanımı: SealedSecrets kullanmış olmaktan pişmanım. Geliştiriciler için karmaşık ve AWS’nin mevcut parola rotasyonu otomasyonunu kaybettiriyor.
  • ExternalSecrets kullanımı: AWS -> Kubernetes parola senkronizasyonu için ExternalSecrets kullanmayı destekliyorum. Geliştiricilerin anlaması kolay ve terraform kullanarak AWS içinde parolaları kolayca oluşturup güncelleyebiliyorsunuz.
  • ExternalDNS kullanımı: ExternalDNS kullanmayı destekliyorum. Kubernetes -> Route53 DNS kayıtlarını senkronize ediyor ve son 4 yılda neredeyse hiç sorun çıkarmadı.
  • cert-manager kullanımı: SSL sertifikası yönetimi için cert-manager kullanmayı destekliyorum. Let's Encrypt sertifikaları üretmek için oldukça sezgisel ve sorunsuz.
  • EKS için Bottlerocket: Bottlerocket ile EKS cluster işletmiş olmaktan pişmanım. Ağ CSI sorunları sık yaşanıyor ve hata ayıklaması zor.
  • Terraform ve CloudFormation seçimi: Terraform kullanmayı destekliyorum. Başka SaaS sağlayıcılarına genişlemek daha kolay ve CloudFormation’a göre daha okunabilir bir söz dizimine sahip.
  • Kod tabanlı IaC çözümü kullanmamak: Pişman değilim. Terraform ve CloudFormation veri dosyaları kullanırken Pulumi veya CDK altyapıyı kodla tanımlıyor. Terraform’un HCL dilinin kısıtlayıcı doğası karmaşıklığı azaltmaya yardımcı oluyor.
  • Ağ mesh’i kullanmamak: Pişman değilim. Ağ mesh’i havalı ama şirketler genelde karmaşıklığını olduğundan az değerlendiriyor. Altyapı için genel tavsiyem şu: “daha az, daha iyidir”.
  • EKS ingress için Nginx load balancer: Pişman değilim, Nginx kullanmayı destekliyorum. Eski ama kararlı ve kendini kanıtlamış bir teknoloji.
  • Şirket script’leri için homebrew: Şirket script’lerini dağıtmak için homebrew kullanmayı destekliyorum. Hem Linux hem Mac kullanıcılarına script ve binary dağıtmak için yeterince iyi.
  • Servisler için Go: Servislerde Go dilini kullanmayı destekliyorum. Yeni mühendislerin öğrenmesi kolay ve genel olarak iyi bir seçim.

İlgili okumalar

4 yorum

 
nicewook 2024-02-28

Hem ana metin hem de yorumların tamamı oldukça değerli içerikler.
 
mhj5730 2024-02-28

Vay be.... Gerçekten de başka yerde bulunması zor, son derece pratik bilgiler.
 
xguru 2024-02-28

Hacker News görüşleri

  • RDS kullanmanın ek maliyeti buna değer

    • RDS kullanmanın ek maliyeti, her colocated SQL server cluster alternatifi düşündüğümde gülünç derecede pahalı geliyor. Ödemeye razı olunandan çok daha fazlasına; bir colocation rack, AWS Direct Connects, sunucular, SAN, SQL Server lisansları, bakım sözleşmeleri ve tam zamanlı şirket içi DBA maaşı bile karşılanabilir.
    • 12 aylık toplam maliyet: 547,441.85 USD
    • Kâr marjı bir veya daha fazla tam zamanlı çalışanın maaşını karşılayabilecek kadar büyüdüğünde, RDS’yi körlemesine büyütmek yerine insan işe almayı düşünmek gerekir. RDS kullanırken gerçekten çok para ödüyorsunuz ve şirketin ilk dönemlerinde verilmiş kararları yeniden değerlendirmelisiniz.

  • Google Cloud’un AWS’den daha iyi olduğunu söylemek popüler olmayan bir görüş olabilir, ama Google Cloud Run ile Docker container’larını bulutta çalıştırmak adeta rüya gibi. Servis adlandırmaları basit, AWS’nin karmaşık servislerine kıyasla önemli servis sayısı daha az ve arayüz daha sezgisel. Eksileri ise küçük topluluk nedeniyle daha az eğitim içeriği, deneyimli insan bulmanın zorluğu ve daha az üçüncü taraf araç. Denemenizi öneririm.

  • EC2 + ASG kullanmak çok keyifli. Kavramsal olarak basit: image’ı ASG’ye deploy edersiniz ve autoscaling policy ayarlarsınız. Neredeyse dert edilecek bir şey yoktur. Buna karşılık k8s kullanmak her zaman büyük bir iştir. k8s’i yönetmek için başlı başına bir ekip kurarsınız. k8s’in onlarca kavramını ekibe tanıtırsınız ya da "platform engineering" için insan-yılı harcayıp bu kavramları gizlersiniz. k8s’i "doğru" kullanabilmek için kılavuzlar, SDK’ler ve türlü türlü validator yayınlarsınız. Buna rağmen operator implement etmek için on binlerce satır YAML ve kod yazarsınız. Bazen k8s’in fazla istilacı olup olmadığını merak ediyorum.

  • SaaS ürünleri hakkında görüşler

    • JIRA’dan Linear’a geçişi anlamıyorum. Linear fena değil ama sık sık yapamadığım veya nasıl yapıldığını bilmediğim şeylerle karşılaşıyorum.
    • Terraform Cloud kullanımını genel olarak öneriyorum. Kendi sisteminizi şirket içinde büyütmek ilk birkaç yıl sorun olmayabilir ama uzun vadede pahalıya patlayabilir.
    • CI/CD için GitHub Actions kullanımına bir ölçüde katılıyorum. Bunun yerine GitLab kullanmanızı öneririm.
    • Datadog hakkındaki görüşe kesinlikle katılmıyorum. Piyasadaki en iyi monitoring/observability aracı. En yaygın şikâyet maliyet ama çoğu durumda insanlar Datadog’u yanlış yapılandırdığı için masraf kontrolden çıkıyor.
    • Pagerduty konusundaki desteğe katılıyorum. Pagerduty, Opsgenie’den yaklaşık 10 kat daha pahalı ve daha iyi özellikler sunmuyor. Pagerduty ile sözleşme yenilerken, satış temsilcisine Opsgenie’de olmayan hangi özelliklere sahip olduklarını sorduğumda, pazarda premium marka olarak konumlanmak istediklerini söylediler. Bu yüzden incident reporting için daha sıradan bir markayı kullanmak bana yeterli geliyor.

  • 90’lar/00’ler geliştiricilerinin bu listeyi okuyup karmaşıklık ve terimler karşısında afallayacağını hayal ediyorum.

  • İlginç bir yazı ama gerçekten blog yazacak kadar pişmanlık duyan biri tarafından yazıldığından emin değilim.

  • Tek bir devasa 100 bin dolarlık sunucuya geri dönüp her şeyi tek kutuda çalıştırmayı deneme dürtüsü hissediyorum.

  • Kubernetes / EKS temellerini öğrenmeyi başardım ama ECS’ye geçmeyi düşünüyorum. Kubernetes ihtiyaçlarımıza kıyasla fazla karmaşık. CloudFormation benzeri araçlarla kontrol etmek zor. Eklentilerle oluşturulan load balancer’lara Kubernetes dışından referans vermek zor. EKS Fargate’de Cloudwatch logging, belgeleri takip etmeme rağmen çalışmıyor gibi görünüyor. EKS EC2’de olduğu gibi CPU/memory metrikleri çalışmıyor ve ADOT gerekiyor gibi duruyor. ECS’de ortamı 1/10 sürede yeniden kurdum ve her şey sorunsuz çalıştı.

  • Bu yazının üslubunu ve içeriğini beğendim. Bazı karar ve önerilere katılmıyorum ama o durumlarda bile gerekçelerini okumak çok değerli. Keşke bu tür yazılardan daha fazla yayımlansa ve karşılaştırabileceğimiz bir yol olsa. Ben de benzer bir yazı yazmak için ilham aldım.

  • Herkesin kullandığı mutfak lavabosu veritabanı yaygın bir sorun ve tekrar tekrar yaşanıyor. Büyüdükçe ciddi teknik borca ve performans darboğazlarına dönüşüyor. RDS gibi yönetilen bir DB kullanırsanız, ana uygulama bazında ayrı DB cluster’larını kolayca işletebilirsiniz.