Sanallaştırılmış teklifler önemli ölçüde daha kötü performans gösteriyor (2019 denemelerime bakın: httpsjan.rychter.com/enblog/cloud-server-cpu-performance ve daha pahalı. Aradaki fark, gerekli olmadığını düşündüğüm "talebe göre ölçeklendirme"yapabilmenizdir. en azından benim durumumda. Ve ölçeklendirmeye ihtiyacım olursa, bunu yine de yapabilirim, sadece yeni sunucular almak saniyeler yerine saatler alıyor. Pekala, saniyeler içinde ölçeklendirmeye ihtiyacım yok
Benim durumumda, tam üretim ortamı ve yinelenen hazırlama/yedekleme ortamı için aylık faturamın tamamı sabit, basit, öngörülebilir, AWS'ye ödemem gereken tutarla karşılaştırıldığında çok düşük ve hala çok fazla performans boşluğum var.
Kayda değer bir şey, fiziksel sunucuları sanal sunucular gibi ele aldığımdır: her şey ansible aracılığıyla yönetilir ve her şeyi sıfırdan yeniden oluşturabilirim. Aslında, Digital Ocean'da başka bir "devcloud"ortamı kullanıyorum ve bu ortam, kurulumun geri kalanını yapan ansible'a geçmeden önce terraform kullanılarak döndürülüyor.
VendorOps ve kubernet'ler gibi karmaşık araçların son on yılda ortaya çıkan karmaşıklık tüccarları tarafından tercih edildiğinden şüpheleniyorum. Özgeçmişte harika görünüyor ve teknoloji liderlerine yanlış bir başarı hissi veriyor.
Bu arada, muhtemelen çoğu startup'tan daha önemli olan Stackoverflow, özel makinelerde ilerliyor.
1: httpsstackoverflow.blog/2016/02/17/stack-overflow-the-arc..
Görünüşe göre bu alandaki eğilim, doğrudan en yüksek soyutlama katmanına atlamak. Temel bilgileri atlayıp $buzzword araçlarına, kitaplıklarına ve ürünlerine işaret edin
Bunun farklı biçimlerde anlık görüntülerini görürsünüz. Biri, Y'yi öğrenmek için X'in ne kadarını bilmem gerekiyor gibi şeyler soran sosyal medya ileti dizileridir. Burada X temel, muhtemelen çok istikrarlı bir teknoloji veya alan ve Y bir günlük araç veya doğrudan bir ürün veya hizmettir.
CORBA oraya ait. Ve belki de semantik web şeyleri bile. Kesinlikle xml!
XML harikadır - buna inanmıyorsanız, JSON'u ayrıştırmanın zahmeti ilginizi çekebilir: httpseriot.ch/projects/parsing_json.html
Ve beni YAML'a başlatmayın..
Yönetilen veritabanlarına, otomatik anlık görüntülere, barındırılan yük dengeleyicilere, tak ve çalıştır blok depolamaya vb.
Gece yarısı donanım arızaları, yeni bir sunucunun çalıştırılması ve düzgün çalışmaması hakkında değil, ürünümüzün iyi olup olmadığı konusunda endişelenmek istiyorum çünkü yapılandırma yönetimini tek bir kutuyla kullanma, tek bir kontrolden çıkmış göreve sahip olma teşviki yoktu. OOM'a veya tam diske neden olmak ve yalnızca bu görevler yerine her şeyi bozmak VM, 1000 gün boyunca çalışan bir makineyi yeniden başlatma korkusu vb.
Bana göre bulutun çekiciliği, gerekmediğinde geçici bir FAANG ölçeklenebilirlik hevesi değil, otomatik işletim sistemi yama uygulaması, otomatik yük dengeleme, NAT hizmetleri, merkezi, analiz edilebilir günlükler, yönetmek zorunda olmadığım veritabanı hizmetleridir. hizmetlerde yapılan yükseltmeler, kripto anahtarların ve sırların yönetilmesi ve tabii ki nesne depolama. (Bunların hepsi startupımızda kullandığımız şeyler)
Bir uzvun üzerine çıkıp, belirli bir ölçeğe ulaştığımızda özel sunucuların tam tersi yerine çok uygun/maliyet etkin olabileceğini söyleyebilirim. Şimdilik, girişimim için bulut masrafları buna değer
Ortam yapılandırmanızı kod olarak yapıyorsanız, hedefinizin özel bir sunucu, bir sanal makine veya bir API aracılığıyla yapılandırılmış buluta özgü bir kurulum olması sonuçta önemli olmamalıdır.
Hangisi olduğu önemli değil, mesele şu ki, sadece bir komut çalıştırarak size yeni bir kutu inşa edebilecek veya yaramazlık yapan bir kutuyu iyi bilinen durumuna geri getirebilecek bir taneye sahipsiniz.
Elbette, Go(o)'nun onu harekete geçiren asıl yığını geliştirilebilir (ve gerçekten de gelişiyor)
Bununla birlikte, gerçek şu ki, yaklaşımınız doğru; hemen hemen tüm işletmeler (yeni kurulan şirketler!) değer sağlamaya, gerçek niş alanı belirlemeye vb. odaklanmak yerine aşırı gelişiyorlar. (Evet, bunun bir de talep tarafı var, çünkü Risk sermayesi parasıyla şişirilmiş girişimler, yükü üstlenebilecek, onlarla birlikte ölçeklenebilecek, SLA'lar ve reklamı yapılması gereken diğer şeyler için 3. taraflara bağımlı olmak istiyorlar.)
Kubernetes muhteşem! Ne zaman rakip olabilecek bir işletmenin Kubernetes kullanmaya başladığını görsem, hemen rahatlıyorum çünkü artık onlar için endişelenmeme gerek olmadığını biliyorum. İnanılmaz karmaşıklıktaki bir teknoloji yığınında izi sürülemeyen sorunları çözmeye çalışarak ve iki ila üç kat daha büyük trafiğe sahip işletmeler için tasarlanmış bir sistemin dayattığı sınırlamaları aşmaya çalışarak, çözülemeyen bir teknik sorun yığını içinde kaybolmak üzereler. Ayrıca, COGS'leri benimkinden çok daha yüksek olacak, bu da sadece VC parasını yakmadıkları sürece (bu durumda çok kısa sürede ortaya çıkarlar) ürünlerini daha yüksek fiyatlandırmaları gerektiği anlamına geliyor.
Her tarafta iyi şeyler
Ansible zorunludur, statik bir duruma doğru çalışabilir ve hepsi bu. Bir sorunla karşılaşırsa SSH bağlantısını keser, tonlarca python hatası ağlar ve sonsuza kadar pes eder. Envanteriyle bile bildirimsel olmaktan uzak
k8s, bildirilen durumlarına doğru ilerleme kaydetmeye çalışan kontrol döngülerinden biridir. Başarısızlık sorun değil, yeniden denenecek. Sürekli olarak kendi durumunu kontrol eder, raporlamak için güzel bir API'ye sahiptir ve pek çok birleştirilmiş konsept sayesinde konuşlandırılmış bileşenler arasında garip çakışmalar olması daha zordur. (Ancak birden fazla oyun kitabını Ansible ile entegre etmek önemsiz değildir.)
httpsgithub.com/spantaleev/matrix-docker-ansible-deploy
Ve k8'ler çok fazla eskimişlik sergilese bile, temel fikirlerin yaklaşan daha ince tezahürleri var. (Örn. httpsgithub.com/aurae-runtime/aurae )
Ve şimdi de insanların standart olmayan daha basit bir uygulama kullanmasını mı öneriyorsunuz?
Bu nedenle, elbette, minimum düzeyde karmaşık bir çözüm uygulayabilir veya "raftan"bir şey kullanabilirsiniz.
k8s karmaşıktır ve bir kısmı sizin durumunuz için kesinlikle gereksizdir, ancak aynı zamanda oldukça geneldir, esnektir, iyi desteklenmiştir, vs.
>insanların standart olmayan daha basit bir uygulama kullanmasını mı öneriyorsunuz?
Önerdiğim şey, eğer k8s projesi/yazılımı başarısız olamayacak kadar büyürse, o zaman insanlar bir alternatife geçebilir. Neyse ki k8s kavramları ve API açık kaynaktır, bu nedenle diğer projelerde uygulanabilirler ve k8s seçmenin Oracle benzeri bir satıcıya kilitlenme olmadığını göstermek için böyle bir örnek verdim.
Bulut sağlayıcılarından pratik olarak ücretsiz olarak aldığınız tüm harika şeyleri her zaman duyuyorum. Bu şeylerin kurulumu ve kullanımı gerçekten bu kadar kolay mı? Ne zaman bir bulut hizmetinde LAMP yığınımı kurmaya çalışsam, o kadar kafa karıştırıcı ve korkutucu bir süreçti ki sonunda pes ettim. Biraz daha zorlamam gerekip gerekmediğini merak ediyorum ve Bulut Cennetine ulaşacağım
"Burada bu tür özelliklere sahip kümelenmiş bir MySQL istiyorum"diyebilmek, bunu kendi başınıza yapmaktan çok daha iyidir (zaman açısından). Güncellemeler ayrıca sisteme güzel bir şekilde sarılmıştır, bu yüzden yük devretmelerin/yeniden başlatmaların doğru sırada olmasını manuel olarak sağlamak yerine sadece "en son güncellemeyi uygula"diyorum.
Yani işleri basitleştirmek için para ödüyorsunuz, ancak bu basitleştirmeden elde edilen kazanç yalnızca daha büyük projelerde devreye giriyor. Tek bir sunucuda, kullanıcılarınız bir hata sayfası alırken yeniden başlatabileceğiniz bir şeye sahipseniz, buna değmeyebilir.
Bulut kolay değildir, ancak küçük bir sunucu odasının soğutma ve güç verimliliğini verimlilik seviyelerine yakın herhangi bir yerde elde etmeye çalışmak, çoğu büyük veri merkezinin yayınlaması, birden fazla sağlayıcıya sahip internet bağlantısı olduğu için neredeyse imkansızdır.
Bulutun üzerinde çalıştığı herhangi bir veri merkezi operatörü tarafından yönetildiği için bulutla birlikte tüm bu tür şeyler ortadan kalkar, ancak insanların unuttuğu şey, bunun genellikle buluttan daha iyi bir maliyet/değer sunan eski moda ortak yerleşim hizmetleri için de geçerli olduğudur.
Ve AWS veya Azure gibi şeyleri yönetmek kesinlikle daha zor olsa da, küçük ölçekli vpc sağlayıcılarının sizden sakladığı veya gerçekten tek bir ev sunucusuyla elde edemediğiniz çok sayıda soyutlamayı sızdırdığı için, bir çift çalıştırmak zorunda kalma ölçeğinde zor değil SAN tabanlı depolamaya sahip raflar değerinde vmware sunucuları Bulut işleriyle, sanal sunucuları vb. yapılandırmakla ilgili olduğu için yapacak daha çok yapılandırmanız olur. PC'yi odanıza bir kutu içinde taşımak yerine, kullanılabilir hale getirmek için "yapılandırmalısınız" DO veritabanlarının, beğeninize göre yapılandırabileceğiniz, DO Alanlarında (S3 gibi) depolayabileceğiniz yedekleri vardır. DB kullanıcı yönetimi kolaydır. Redis için önbellek sunucuları da var Bir yük dengeleyici ekleyebilir ve çeşitli web sunucularınıza bağlayabilirsiniz. 2x web sunucularını, bir DB sunucusunu, önbellek sunucusunu, yük dengeleyiciyi, bir depolama sunucusunu kurmam ve hepsini birkaç basit form kullanarak gerektiği gibi bağlamam yaklaşık 30 dakikamı aldı. Bunu gerçekten yenemezsin Daha fazla bilgi veya görüşünüz varsa lütfen paylaşın İnternette bir Linux sunucusunu güçlendirmekle ilgili pek çok makale var, benim denediklerimin adımları takip etmesi 30 dakikadan biraz fazla sürüyor, eğer her bir şeyin ne yaptığını, neden yaptığını gerçekten öğrenmeye ve anlamaya çalışıyorsam çok daha uzun sürüyor önemli olan, altta yatan güvenlik açığının ne olduğu ve bazı ayarları kendi özel kullanım durumum için nasıl özelleştirmem gerekebileceğidir. Çevrimiçi olarak örnek kurulum betikleri bulabileceğinizden eminim (otomatik güncellemeleri, güvenlik duvarını, uygulamaları vb. yapılandırmak, 'curl $URL've ardından 'chmod +x $FILE've 'bash $FILE'çalıştırma meselesi olmalıdır. Yapılandırma yönetimine ihtiyacım yoktu (Sanırım önemli olan sağlayıcımın yedekleme hizmetini kullanıyorum) Bunun gibi bir şey: httpsraw.githubusercontent.com/potts99/Linux-Post-Install.. (httpswww.reddit.com/r/selfhosted/comments/f18xi2/ubuntu_d adresinde görüldü) Açıkçası, aynı şey uzun süre çalışan VM'ler için de söylenebilir ve bu, disiplinli bir ekibe sahip olarak çözülebilir, ancak bence bu genellikle uzun süre çalışan tek bir özel makinenin olduğu bir ortamda daha olasıdır. Hetzner, yönetilen veritabanları dışında tüm bunlara sahiptir httpswww.hetzner.com/managed-server Web barındırma paketleri ayrıca 1..unlimited DB'leri (MySQL ve PostgreSQL) içerir. httpswww.hetzner.com/webhosting/ otomatik yedekleme ve yük devretme özelliği var mı? >Rezerve edilen günlük yedekleme veya sunucu türüne dahil olan yedekleme ile tüm veriler günlük olarak yedeklenir ve maksimum 14 gün süreyle saklanır. KonsoleH yönetim arayüzü aracılığıyla yedeklerin kurtarılması (Geri Yükleme) mümkündür Ancak, yönetilen sunuculardaki veritabanlarının o sunucuda çalışan uygulamalar tarafından kullanılması amaçlandığı izlenimine kapılıyorum, bu nedenle gerçekten bir yük devretme kavramı yok httpswww.hetzner.com/legal/managed-server/ Tek bir sunucudaki tek bir sürücünün arızalanması asla bir üretim kesintisine neden olmamalıdır Birçok yapılandırma sorunu, kendi kendine yeten dağıtımlara kadar izlenebilir. Bu yazı tipi dosyasının veya JRE'nin gerçekten tüm sunucuya yüklenmesi gerekiyor mu yoksa onu dağıtımınıza paketleyebilir misiniz? Dağıtımlarımız şirket içi ve EC2 hedeflerini kullanır. Dağıtım betiği farklı değildir, yalnızca ana bilgisayarın IP'si farklıdır Şimdi, S3'ü %100 kullanacağım bir şey için kullanıp kullanamayacağımı söyleyeceğim. Aynı özellik setine sahip bir şirket içi alternatifi yoktur. DevOps'un amacı "Evcil hayvan değil, sığır"dır. Başarısızlık noktalarınızı bulmak için sunucunuza haftada bir madde işareti koyun En azından Dokku kullanan diğer kişiler için deneyimi daha iyi hale getirebilmemiz için Discord/Slack'imize girip gördüğünüz sorunlardan bazılarını gündeme getirirseniz çok sevinirim. Bana ulaşmaktan çekinmeyin (nickim `savant`) Önsözüme izin verin ve Docker hakkında yalnızca çalışma bilgisine sahip bir uygulama geliştiricisi olduğumu söyleyeyim.Altyapı konusunda çok yetenekli değilim ve mücadele ettiğim uygulamanın kendine özgü dağıtım parametreleri var: Bu, oluşturulduktan sonra statik olan bir Postgres veritabanını doldurmak için birkaç gig statik HTML taramasını derleme sırasında ayrıştıran bir Python uygulaması. Bir Flask web uygulaması daha sonra bu veritabanına hizmet eder. HTML ayrıştırma hızlı bir şekilde gelişir ve bu nedenle doldurulmuş DB verileri, uygulama görüntülerinin bir parçası olarak paketlenmelidir. IIRC, DB kalıcı olmadığında, bunun yerine uygulamanın başka bir geçici parçası olduğunda Dockerfiles'ı yapılandırmakla mücadele ettim, ancak aşılabilir görünüyordu. Daha büyük sorun, ideal olarak önbelleğe alındığında, özellikle DigitalOcean ve yerel ortamımda aklı başında davranacak şekilde, her yapı için S3'ten nadiren değiştirilen verilerin konserlerini çekmekten nasıl kaçınılacağı gibi görünüyordu. Doğru Docker görüntü katmanı önbelleğe almanın sorunu çözeceğini tahmin ediyorum, ancak bilgimin ve sabrımın sonuna oldukça hızlı bir şekilde ulaştım. Dokku'nun DX'i normal şeyler yapan insanlar için harika görünüyor. :) 0. httpscoolify.io/ Ayrıca kim en yeni, en havalı oyuncakla başkasının kuruşuna oynamak istemez ki? Esneklik (veya akış/dönme ile uğraşmak) birincil itici güç olmaktan çıkıp ölçek/maliyet hakim olmaya başladığında, yolculuğun ilerleyen aşamalarında (bazılarını) şeyleri buluttan çıkarmak için kesinlikle bir argüman vardır. Elbette, Hetzner üzerinde çalışan bir şey elde edebilirsiniz, ancak çok daha fazla soruyu yanıtlamaya hazırlıklı olun. Bunu isteme konusunda son kuruluş noktanız konusunda hemfikir olun, bu da yine üzücü olan, başka bir yol çok daha iyi olabilecekken, bu iş "gereksinimlerinin"yazılımınızı nasıl tasarlayacağınızı ve barındıracağınızı dikte etmesidir. Felaket kurtarma çok gerçek bir sorundur. Bu yüzden düzenli olarak test ediyorum. Bir kavurucu dünya senaryosunda, bir saatten daha kısa bir süre içinde ikincil (aşamalı) bir sistemde veya terraformed bir bulut sisteminde çalışmaya başlayabilirim. İşim için bu yeterli
Bir büyüme patlaması yaşadık ve daha önce hepsinde olduğu gibi, bu, çok sayıda deneyimsiz insana çok fazla para ve acil beklentiler verildiği anlamına geliyordu. Bu, kargo kültürü ve sömürücü pazarlama için bir reçete
Ancak büyüme yavaşlıyor ve para daha pahalı hale geliyor, bu yüzden yavaşlayın ve heyecan verici yeni varyasyonlarla eski dersleri yeniden öğrenmeye başlayın. (Buradaki gibi: çıplak metal ölçeklendirmeyi ve kapsayıcılar ve orkestrasyonla yönetme)
Ve tüm döngü bir sonraki patlamada tekrar edecek. şimdilik sektörümüz bu kadar
Sağlam bir özel sunucu, paylaşımlı donanımda arızalı bir VPS'den %99 oranında daha kullanışlıdır, ancak sağladıkları tüm kaynaklara ihtiyacınız yoksa bunun maliyetinin arttığı açıktır.
Evet - ama "tüm havalı çocukların şu anda yaptığını yapma"özlemi, en azından normalde "yöneticiler"olarak anılacak kişilerde, "çalışanlar"ile karşılaştırıldığında güçlüdür.
sonuç A) devasa mikro hizmetler/bulut harcaması ters gidiyor, en azından en iyi uygulamaları takip ediyordunuz, böyle şeyler oluyor, ne yapabilirsiniz?
sonuç B) bir Hetzner sunucusuyla gittiniz ve bir şeyler ters gitti, mikro hizmetlere geçtiniz ve gitmeliydiniz, yeni bir iş aramanın tadını çıkarın
Böylece yöneticileri mikro hizmetler/bulut seçmeye teşvik eder. Şirket için doğru karar olmayabilir ama yönetici için doğru karardır ve kararı yönetici verir.
(Zor yoldan öğrendiğim gibi, bir uzantı isteyen ve çalışan bir yazılım yazan bir danışman olmak gibi.)
Kurucular ve diğer herkes arasında bir kopukluk var
Kurucular, her yıl >10x olacaklarına inanıyorlar
Gerçek şu ki, başarısız olma ihtimalleri %90
Zamanın %90'ında - herhangi bir konuda başarısız olmakta sorun yok
Başarıya ulaştığınız zamanın %10'unun bir kısmında bulut olmadan da iyi durumdasınız - en azından birkaç yıllık başarı için, gerekirse geçiş yapmak için bolca zaman
Yalnızca bir sorumlu kurulumum var ve bu hem sanallaştırılmış sunucular hem de fiziksel sunucular için çalışabilir. Fark yok. Tek fark, sanallaştırılmış sunucuların önce terraform ile kurulması ve fiziksel olanların önce sipariş edilmesi ve IP'lerinin bir yapılandırma dosyasına (envantere) girilmesi gerekmesidir.
Tabii ki, diğer birçok bulut hizmetine bağımlı kalmamaya da dikkat ediyorum. Örneğin sunucular arası iletişim için VpnCloud (httpsgithub.com/dswd/vpncloud) kullanıyorum. Bir yan fayda olarak, bu aynı zamanda bana herhangi bir zamanda herhangi bir altyapı sağlayıcısına geçme esnekliği sağlıyor.
Benim asıl amacım, sanallaştırılmış tekliflerin kullanımları olsa da, ayda 10$'lık bir hobi VPS'si ile hızla büyüyen B2C işine sahip bir şirket arasında (devasa) bir boşluk olduğuydu. Yeni işletmelerin çoğu aslında bu boşluğa düşüyor: Kârlı bir B2B Hizmet Olarak Sunulan Yazılımda hokey sopası katlanarak büyüme beklemiyorsunuz. Her zamanki varsayılan "AWS kullan"seçimini sorgulamanız gereken yer burasıdır. SMM'lerimi ve marjlarımı önemsiyorum, bu yüzden bu seçimi çok dikkatli görüyorum
Siz bir yazılım şirketi değilsiniz, temelde Sprockets üretip satıyorsunuz
Buradaki görüşler, "sunucuları satın almak ve bakımını yapmak"(PaaS kötüdür) için büyük bir mühendislik/BT personeli işe almak ve ardından muhtemelen "kendiniz bir kod yazmak"(SaaS kötüdür) veya şu anda burada popüler olan herhangi bir şey (buradaki son ileti dizisi) olacaktır. "Git olmadan PHP'yi SFTP üzerinden zorlamak ve daha fazlasına ihtiyacınız varsa"lol)
Ancak işletmelerin One Thing Well yapması ve temel yetkinlikleri dışındaki şeyler için rekabet etmeye çalışmaktan (bunu manuel olarak yapmaktan) kaçınması gerektiğine inanıyorum. Bu durumda, Sprocket Masters'ın kendi donanımlarını yönetmeye çalışmaması ve ölçekleme, güvenlik, çalışma süresi, uyumluluk ve tüm küçük ayrıntıları halletmek için bir sağlayıcıya güvenmesi gerektiğini kesinlikle düşünüyorum. Ayrıca, yazılımlarının mümkün olduğu kadar az şirket içi yazılımla bataklık standardı olması gerektiğini düşünüyorum. Bir yazılım mağazası değiller ve mümkün olduğunca az kod yazmaları gerekiyor.
Gerçekçi olarak, Widget Master'lar, hepsini manuel olarak yapmaya karar vermedikçe bu siteleri oldukça küçük bir kadroyla çalıştırabilir, bu durumda muhtemelen çok daha büyük bir kadroya ihtiyaç duyarlar.
Bununla birlikte, benim de gördüğüm ve önceki posterin bahsettiğini düşündüğüm şey, işin özünde teknolojinin yer aldığı ve orada genellikle daha az mantıklı olduğu ve zamandan tasarruf etmek yerine zamana mal olduğu görülüyor. AWS uzmanlarının olmasının bir nedeni var: önemsiz değil. "Gerçek"sunucular da önemsiz değildir, ancak bulut hizmetlerinden daha zor da değildir.
Ancak bu ajanslar, fiziksel donanımın bakımı için de personele sahip olmak istemiyorlar.
Ancak Sprocket Masters'ın yalnızca acil durumlara yanıt verebilmesi için hâlâ pahalı bir Bulut Danışmanına sahip olması gerekiyor.
Bulut sorunlarıyla ilgilenecek bir personeliniz olacaksa, bunun yerine bir sunucu da kiralayabilirsiniz.
İlk günlerde kişisel olarak işletmemiz için Tahsis Edilmiş Sunucular çalıştırdım, ancak genişleyip ölçeklendikçe, maliyetler artmasına rağmen çeşitli hizmetleri hızlı bir şekilde sağlamak için Bulut sağlayıcılarıyla birlikte gitmek çok daha kolay hale geldi. Potansiyel bir müşteriye "AWS gibi bulut"kullandığınızı söylemenin, "Bu makineleri bazı şirketler tarafından yönetilen bir veri merkezinde kiralıyoruz"ifadesinden çok daha kolay olduğunu belirtmeye bile gerek yok (aslında daha iyi olabilir, ancak müşteriler çoğunlukla bunu anlamayacak) . Denetim, Uyumluluk ve diğerleri
Birçoğu için bundan çok daha az. Birkaç kez viral olan (24 saatte 30.000 görüntüleme) küçük bir yan proje yürütüyorum[1] ve tek çekirdekli bir CPU web sunucusunda ve benzer şekilde tek bir CPU çekirdeğinde yönetilen bir Postgres üzerinde çalışıyor. Tam kullanıma yaklaşmadı bile
1: httpsaihelperbot.com/Bazılarını lambda fonksiyonlarına çevirebilir miyim?Veya ECS'ye geçmek mi?Veya başka bir bulut hizmeti du jour'a mı geçiyorsunuz?Belki.Ancak bu yorumu yazmak için harcadığım süre, şimdiden böyle bir geçiş için yaklaşık altı aylık birikime bedel."Düğmeye bas, %100 güvenilir şekilde çevrilmiş hizmet al"dan daha zorsa, bunu haklı çıkarmak zordurBunun bir nedeni de şu: bulut artık bu tür şeyleri mümkün kılan başka hizmetler sağlıyor.Temel mesajlaşma için bir Kafka kümesi çalıştırmama gerek yok, hepsi bir mesaj veri yolu ile geliyor.Bunu kullanıyorum.Barındırılan DB seçeneklerini kullanıyorum.S3 veya muadili vb. kullanıyorum.Tek haneli ödemeler yaparken geriye kalanın kendimi başka bir paradigmanın içine sıkıştırmaya çalışma zahmetine neredeyse hiç değmediğini düşünüyorum. ayda sadece bir EC2 bulut sunucusu üzerinde çalıştırmak içinHerkesin veya her projenin bunu yapamayacağı kesinlikle bir durumdur.Buna nihai hedef olarak takılıp kalmadım.Çalışmadığında hemen uygun ölçeklendirme eylemini gerçekleştiririm.Buna dayanarak herhangi bir şeyi yeniden tasarlamanızı önermiyorum.Sadece söylüyorum, küçümsenecek bir seçenek değil.Çok fazla esnekliğe sahiptir ve faturalandırma oldukça tutarlıdır (veya başka bir deyişle, birdenbire 50x trafiğim olursa, sistemim fark edilir şekilde boğulmaya ve sıçramaya başlar. benden yüzlerce dolar daha fazla ücret almak bir hatadan ziyade benim için bir özelliktir) ve genellikle kendinizi bazı bulut hizmetleri için uygun olan ancak sizin için uygun olmayabilecek bir paradigmaya zorlamak için kendinizi zorlamazsınızHiç bu ortamlardan birini yönetmek zorunda kaldınız mı?Mesele şu ki, birden fazla kişi için temel ölçeklenebilirlik ve uygun devop'lar elde etmek istiyorsanız, o zaman önemli bir faktörle (muhtemelen birikimlerinizi boşa harcayarak) fazla tedarik etmeniz gerekirKaçınılmaz olarak ısmarlama bir çözümle karşılaşacaksınız, bu da yeni katılanların sistemde ustalık kazanmakta zorlanacağı ve şirketten ayrılan önemli kişilerin altyapınızla ilgili derin bilgilerini sisteme taşıyacağı anlamına gelir. onlara.Sığır yerine evcil hayvanlara geri döndünüz.Bazı sunucular özeldir, bir süre sonra otomasyon "burada burada çok sayıda birleştirici kabuk betiği"anlamına gelir ve bir işletim sistemi yükseltmesi, ya yarı altyapının bir süreliğine KO olduğu ya da işletim sistemi yükseltmelerini şu anda yapmadığınız anlamına gelir. tümüVe şanslı durumda ölçeği büyütmeniz gerekir Hoş olmayan sürprizlerle karşılaşabilirsinizVe asla almayın ağ tarafında başladım.Rafınızın tamamını kiralamadığınız ve kendi ağ donanımınızı yerleştirmediğiniz sürece, elde ettiğinizi alırsınız.Gösterişli bir şey yapmadığınızı varsayarsak, işlevsellik veya performans açısından çok zayıf olabilir%100.0000 çalışma süresi istiyorsanız, elbette.Ama genellikle yapmazsın.Bu tür bir çalışma süresi isteyen şirketlerin normalde buna adanmış ekipleri vardır zatenDikey olarak ölçeklendirirseniz ölçeklendirme çıplak metalde de iyi çalışır - tek bir sunucudan alabileceğiniz güç ve verim miktarı hakkında bir fikriniz var mı?Konuşmacı "yatay ölçeklendirme"anlamına geldiğinde "ölçeklendirme"yi duymaya devam etmek ilgi çekicidirGereksinimleriniz "ölçeklendirme"ise, o zaman dikey ölçekleme sizi uzağa götürürGereksinimleriniz "talep üzerine yatay ölçeklendirme"ise, o zaman, bulut sağlayıcıları bu konuda kesinlikle yardımcı olacaktır.Ancak, bu tür bir ölçeklendirmeye çok az yer ihtiyaç duyarÇıplak donanımda %100 çalışma süresinin ucuz olduğunu söylemiyorum, %100 diyorum çalışma süresi genellikle gerekli değildirÇünkü sektör, trendleri ve anahtar kelimeleri kovalayan ve en önemli şeyin bu anahtar kelimeleri özgeçmişlerine eklemek olan insanlarla doluÖlçeklenebilirliği hedefleyen IME, çoğu hizmet/uygulama/her neyse için fazlasıyla yanlıştır.Ve genellikle "ölçeklenebilir"çözümler için o kadar fazla ek masraf ödersiniz ki, bunu telafi etmek için ölçeklendirmeniz gerekirBundan gerçekten şüpheliyim .Hemen hemen her AWS savunucusunda gördüğünüz tek tema, AWS'nin size gerçekten sağladığı garantilerinEvet, elbette.Kimse IBM'den satın aldığı için kovulmazBüyük şirketlerin karar alma konusunda herhangi bir yetkinliği olsaydı, yenilmez olurlardı ve IBM'de başka herhangi bir şey üzerinde çalışmak umutsuz olurdu. Tümü.Yani, evet, bu bir kamu malıKaynak: neredeyse otuz yıllık operasyonlarŞimdiye kadar, eğer daha fazla harcarsam bunu fark etmedim Ayrıca daha fazla ödeme aldığım şirket içinütülerle eşdeğer güvenilirliği elde etmek, "iki adanmış sunucu"kiralamaktan çok daha pahalıdır - şimdi bir sunucu ve bir yedekleme çözümüyle sorun olmayabilir ve bu adil. ancak tüm bunları oluşturacak bir sistem, ilk kurulum için kısa bir sözleşmeyle ve bakım gerektirmeden bile, bulut fiyat farkının çok ötesine geçecektir, özellikle de karışımda bir veritabanı varsa ve bu verileri önemsiyorsanızBugün bulut benzer - daha az hareketli parça olduğundan pazara sunma süresi daha hızlı.Ekonomi çöktüğünde ve büyüme yavaşladığında, fasulye sayaçları devreye girer ve işlerini yaparlarHer seferinde olurBu yalnızca AWS'yi daha zengin yapar şirketlerde ve bulut ekiplerindeDağıtımınızın ölçeğini büyütmesi veya ölçeğini küçültmesi gerekiyorsa saniyeler içinde bir EC2 eşgörünümünün otomatik olarak sağlanması ve sağlanmasının kaldırılması önemsizdir.Bare metal sunucudan temelde farklı kılan da budur
İhtiyaç duyduğunuzdan birkaç tane daha özel sunucu tedarik etmenin AWS ile karşılaştırıldığında hala daha uygun maliyetli olabileceğini inkar etmiyorum, ancak gerçekten öngörülemeyen iş yükleriniz olduğunda buna ayak uydurmak kolay değil
talep eğrisini karşılamak için VM'leri açıp kapatıyorsanız mimarinizde ciddi bir sorun var demektir
Stackoverflow'un nasıl olup da tüm dünyaya hizmet vermek için ~8 özel sunucu kullandığını ve global müşteri talebini karşılamak için VM'leri çalıştırıp kapatmaya gerek duymadığını hiç düşündünüz mü?
--
Bilgi işlem altyapısını planlarken temel bilgilere geri dönmek ve bulut sağlayıcısının propagandasına kanmamak önemlidir.
Kendin söyledin. Tüm uygulamaların tüm dünyaya hizmet vermesi gerekmiyor, bu nedenle insanlar uyuduğunda talep daha düşük olacak
Küresel uygulamalarda bile uygulamaları ve verileri belirli bölgelerde barındırmanızı gerektiren düzenlemeler vardır. Avrupa, Avustralya ve ABD'deki müşterilerin kullandığı bir uygulamayı hayal edin. Bölgesel veri merkezlerinden hizmet verilmesi gerekiyor ve bir küme çalışırken diğeri çoğunlukla uykuda olacak (saat dilimleri nedeniyle). Özel sunucularla kaynaklarınızın %60-70'ini boşa harcarsınız; EC2/Fargate gibi bir şey kullanırken bölgeniz uykudayken neredeyse 0'a kadar ölçeklendirebilirsiniz.
Çılgınlığın bir yöntemi var, işte buna "iş güvenliği odaklı kalkınma"denir
Çünkü bu onların işleri için bir tehdit
Kendi kendine ev sahipliği yapma veya aileleri/arkadaşları/dernekleri/yürüyüş kulüpleri için küçük örneklere ev sahipliği yapma konusunda teknik becerilere sahip bir sürü insan var. Bu küçük marj, bunu uygun hale getirmek istediğiniz için biraz fazladan harcamanıza izin verir, ancak bu kadar fazla ödemeyi ve sıkı bakım için zaman harcamayı haklı gösteremezsiniz. Çoğu durumda ihtiyaç duyulan tek şey, paylaşılan bir Nextcloud'a veya küçük bir web sitesine sahip küçük bir VPS'dir
Bunun için yatak odamda biraz Raspberry Pi 400 bile kullanıyorum
httpsjoeldare.com/private-analtyics-and-my-raspberry-pi-4..
On yıla yakın bir süredir kendi eşyalarımı kendim barındırıyorum. Kimse kurulumumu DDoS yapmayı denemedi, çünkü neden yapsınlar ki? Bundan ne gibi bir fayda elde edebilirler? Etkilenen tek kişi ben olurdum ve bir kez durduklarında iyileşmeleri uzun sürmez
Bırakın internet randevusunu, kişisel bir kutuya DDoS yapma konusunda çok az teşvik vardır veya hiç yoktur
Bir gencin yeteneklerini aşırı derecede abartıyorsunuz
IP'ye tekrar tekrar ping atmak pek bir işe yaramayacaktır. Belki hedef ağın IPS açısından sahip olduğu duruma bağlı olarak bir DoS saldırısı olabilir, ancak o zaman bile size gerçekten saldırma şansı bulamadan bilgisayarlarına virüs bulaştırma olasılıkları daha yüksektir.
Ben şahsen GTA 5'te bir hileciden dolayı bunlardan birinin hedefi oldum. Bu kesinlikle oluyor ve eğlenceli değil
Düzenleme: Görünüşe göre bu otomatik olabilir. Bu biraz araştırmam gereken ilginç bir şey. Muhtemelen benim küçük sunucum için ekstra karmaşıklık, ama aklımda bazı kullanımlar var.
Teknik olarak ana laboratuvarım da statik bir genel IP üzerinde - bu, "gerçekten gerekli"olmaktan çok "bunu yapabilir miyim"alıştırmasıydı, ama yine de harika ve çok mutluyum
Tek takılma, tüneli canlı tutmak için Wireguard'ı yapılandırmam gerekmesiydi, aksi takdirde bazen VPS gelen trafiği alırdı ve laboratuvarım bir süre içinde yardım etmezse (ki, neden ulaşsın ki?) tünel kapanırdı. ve proxy bağlantısı olur. Neyse ki bu yerleşik işlevsellik
Bu nedenle, bir jekyll veya GitHub sayfaları sitesine RSS / Atom beslemeleri eklemek oldukça basit görünüyor
1. httpsgithub.com/jekyll/jekyll-feed
2. httpsdocs.github.com/en/pages/setting-up-a-github-pages-s..
3. httpspages.github.com/versions/
atom 2c/4t, 4 gb ram, 1 tb sürücü, 100 mbit
Bu noktada birkaç yıllık çalışma süresi
Kesintisiz ise: bazı yükseltmelerin zamanı gelmiş olabilir.
Çekirdek güvenlik güncellemeleri bir şeydir
Atomların Linux ile bile dayanılmaz derecede yavaş olduğunu gördüm. Tabii ki web sitelerine hizmet vermek için yeterli, ancak performans göstermemek için ne kadar güç kullandıkları şaşırtıcı.
Kesinlikle. 10 doların altındaki bu VPS bulut sunucuları, uzun sözleşmeler yapmak veya kendi sunucularınızı yönetmekle uğraşmak istemediğiniz küçük projeler için harikadır.
Kar marjlarının çok ince olduğu gerçek bir işletme yürütüyorsanız ve sunucu sorunları ortaya çıkarsa (ne zaman) halletmek için dünyadaki tüm boş zamanınız varsa, bu ~50 $'lık ayrılmış sunucuları keşfetmek ilginç olabilir
Ancak gerçek bir işletme yürütüyorsanız, aylık 10.000 ABD Doları tutarında bir AWS faturası bile, özel sunucularınızı yönetmenize yardımcı olması için başka bir yetenekli geliştiriciyi işe almaktan daha ucuzdur
HN gibi yerlerde bulut maliyetleriyle ilgili tartışmalarda genellikle gözden kaçan şey budur: Evet, bulut pahalıdır, ancak özel altyapıyı yönetmenize yardımcı olması için tek bir ek sysadmin/geliştiriciyi işe almak bile inanılmaz derecede pahalı ve çok daha az esnektir. Bu nedenle, kuramsal olarak, yeterli zaman yatırımıyla ayda 50 ABD Doları değerinde bir sunucuda özel olarak oluşturulabilen bulutta barındırılan bir çözüme varsayımsal olarak ayda 5000 ABD Doları harcamak yine de çok önemli olabilir. Mühendisler pahalıdır ve zaman sınırlıdır
Uhhh, afedersiniz ama bu DevOps denen adama ne kadar ödüyorsunuz? Bu çok Amerikan bir bakış açısı gibi görünüyor, hatta vadi alanı. Avrupa'da bir erkeği işe almak daha ucuza gelirdi
Tam yüklü istihdam maliyetleri, maaş çekinizde eve götürdüğünüzden önemli ölçüde daha yüksektir. Avrupa'da aslında daha kötü. Şu tablolara bir göz atın: httpsaccace.com/the-true-cost-of-an-employee-in-europe/
Birleşik Krallık'ta birine 1000 Euro öderseniz, şirkete toplam 1245 Euro'ya mal olur.
Romanya'da birine 1000 EUR öderseniz, bunun şirkete toplam maliyeti 1747 EUR'dur.
Dolayısıyla, 120.000$'lık tam yüklenmiş bir maliyet, bir AB devops çalışanı için sizi yalnızca 68.000$'lık bir maaş karşılığında satın alabilir.
Ama sadece bir devops kişiye sahip olamazsın. Birinin mola vermesine, tatile gitmesine izin vermek istiyorsanız en az 2'ye ihtiyacınız var.
yaklaşık 3 saat içinde seni bağlayabilirim
AWS, diğer hizmetler (S3,SES,SQS, vb.) için çok uygun maliyetlidir, ancak sanal makineler iyi bir anlaşma değildir. Daha az RAM alırsınız& CPU, sanallaştırma yüküyle birlikte çok daha fazla para öder
Özellikle Postgres için pgbench ile bazı testler yaparsanız sanallaştırma için ödediğiniz cezayı gerçekten görebilirsiniz.
Belki de sistem yöneticisinin kendi altyapınızı kurabilme yeteneği kayıp bir sanat haline geliyor, aksi halde insanların daha az performans için 5 kat ödemeye neden bu kadar aşık olduklarını açıklayamam
Hetzner Avrupa'da ucuz ve güvenilirdir, Kuzey Amerika'daysanız OVH'ye bir göz atın. Özellikle SoYouStart adlı maliyet tasarrufu sağlayan alternatifleri. 4/8 4,5 GHz, 64 RAM ve NVME sürücüsünü 65 $ karşılığında alabilirsiniz
(OVH ile hiçbir bağlantım yok, sadece 100'e yakın sunucuya sahip bir müşteriyim ve bu benim için harika sonuç verdi)
Ayrıca şunu da belirtmeliyim ki yaşlıyım hehe ve ilk işlerimden birinde sitede makul büyüklükte bir veri merkezimiz vardı. SAN'lar, teyp sürücüleri (o zamanlar sunucu olan otomatik teyp döndürücüler vb.) ile uğraşmak büyük bir PITA idi. Teypleri paketleyip konum yedekliliği için başka bir ofise göndermek her zaman eğlenceliydi
Yönettiğim uygulama gerçekten düşük GHz sorunu yaşıyor ve tüm veriler bellekte bulunmuyor. Karşılaştırmaları EC2'de çalıştırdım; ~5 saniyede tamamlanan bazı raporlar, yaklaşık 10 kat daha fazla maliyete sahip benzer bir EC2 bulut sunucusunda bir dakikadan fazla sürebilir. Bu uygulamanın gerçekten ham CPU'ya ihtiyacı var. ve evet, tüm sorguları, endeksleri vb. optimize eden oldukça büyük bir mühendislik ekibimiz var.
Çoğaltma, yedekleme vb. konularda hepsini ben ayarladım ve açıkçası çok da önemli değildi. Postgres kitabında her şeyi çok basit bir şekilde açıklayan, nasıl yapılandırılacağını, sürekli (ve otomatik olarak) test edileceğini vb. açıklayan birkaç kısa bölüm var.
SAN'ların bir kabus olduğuna katılıyorum. Bu yüzden tüm WAL'lerimi (PG yedek dosyaları) S3'e (ve sonunda Glacier'a) gönderiyorum. Böylece bu dosyaları kaybetmeyi düşünmek zorunda kalmıyorum ve çok ucuza mal oluyor
Bu tür konfigürasyonların tek bir mühendisin kuramayacağı kadar karmaşık olduğu ve hiç bitmeyen bakım gerektirdiği konusunda yanlış bir kanı olduğunu düşünüyorum. Gerçekte, hepsini bir haftadan daha kısa bir sürede ayarlayabilirsiniz ve yalnızca Postgres'i yükseltmek istediğinizde gerçekten bakıma ihtiyaç duyar (bazı ayarlar değişmiş olabilir). Bakımın yılda yaklaşık 5 saat süreceğini tahmin ediyorum
Son kilometre teslimatını iyileştirmeye ve fiber erişimini genişletmeye devam ettikçe, self-servis altyapının giderek daha uygulanabilir hale gelmesi muhtemel görünüyor. Bulut kendi kendini yok edecek mi? Kesinlikle belki
Bulutun size sağladığı şey, yerel İSS'nizle özel anlaşmalar yapmak zorunda kalmadan verilerinizi/iş yükünüzü tam merkeze koyma yeteneğidir ve en azından birden fazla 20 ft'lik konteyneriniz dolu olmadığı sürece muhtemelen karşılayabileceğinizden çok daha fazla esnekliğe sahiptir. sunucuların bilgi işlem ihtiyacı ölçeği
httpswww.cloudflare.com/products/tunnel/
httpsgithub.com/cloudflare/cloudflared
httpsdevelopers.cloudflare.com/cloudflare-one/connections..
Düzenleme: Kendi kendine barındırmayla ilgilenen varsa, cloudflared ile bu çok kolaydır. Flask tabanlı bir web sitesi sunan özel bellenim üzerinde Ubuntu çalıştıran bir 2017 Google Pixelbook'um var. Konuk Wi-Fi ağına bağlıyken masamda şarj oluyor. 100/100 Mobil Sayfa Hızı puanı alır ve tamamen yüklenmesi 0,8 saniye sürer
DO'dan güvenilir bir şirketin, ölçeklenebilirliğin, otomatik yedeklemelerin vb. tüm avantajlarından yararlanıyorum. Değiştirmemin hiçbir yolu yok
Hetzner bulutunun artık ABD'de iki konumu var Ancak hâlâ ABD'ye özel sunucular yok; bunlar gerçekten işe yarar. Mevcut bulut teklifleri zaten büyük bulut eşdeğerlerinin fiyatının ~%30'u olsa bile..
Ben de sizin gibi hizmetlerimi kiralık bir fiziksel sunucudan yürütüyorum. Versaweb'i kullanıyordum ama makineleri çok eski. Daha önce Hetzner'ı sevmiyordum çünkü onların sizin yürüttüğünüz şeye müdahale ettiğine dair kötü şeyler duymuştum
Ancak Aralık ayında Versaweb örneğim muhtemelen yaşlılıktan dolayı SSD'den öldüğünde onlara taşındım. Şu anda Versaweb'e ödediğimin %50'sini ödüyorum ve buna benzer 6 Postgres örneğini çalıştırabilirim
Daha sonra, şık bir bulut kullanıcı arayüzü, otomatik yükseltmeler ve yedeklemeler vb. içeren yönetilen bir hizmet için 700 ABD Doları veya 800 ABD Doları ödemeye değer olup olmadığı merak konusu oluyor.
1 kişilik bir gösteri veya küçük bir girişim için öyle olduğunu düşünmüyorum. Mevcut bir hizmeti kullanmak ve yedekleri S3'e veya daha ucuz bir şeye boşaltmak daha ucuzdur
Ben Şirket, B şirketinin tam olarak aynı hizmet için aldığı ücretin dört katı kadar mutlu bir ücret ödeyen A şirketi için çalışıyordum, çünkü A şirketi, faturalama sistemimizle uyumlu bir şekilde üç ayda bir fatura göndermeye istekliydi. Şirketler için, orada burada birkaç yüz dolar tasarruf etmek, çoğu zaman ekstra sürtüşme yaratma zahmetine değmez.
Orada örtülü bir maliyet var. Bunlardan yalnızca bir veya ikisi ise yönetilen hizmetleri alın
Ölçeklemeye başlarsanız, bundan tasarruf etmek için yönetici tipinde bir çalışan edinin
Aksi takdirde, günlüğe kaydedilen PITR yedeklemelerini her zaman hızlı bir şekilde geri yükleyebileceğimizden %100 emin olmak için çok deneyimli birini işe almam/sözleşme yapmam veya zamanımın bir ayını veya daha fazlasını ayırmam (ki bu mümkün değildi) gerekirdi.
Başka yerlerde bulut maliyetlerinden tasarruf edebilirim, ancak güvenilir bir şekilde yönetilen PostgreSQL oldukça kolay bir seçimdi (giriş seviyesi fiyat etiketi beklediğinizden daha fazla olsa bile)
Bir saatlik üretim verisini kaybetmeyi göze alamayan erken bir başlangıç, muhtemelen ayakta kalamayacak kadar kırılgandır.
Bu erken bir başlangıç - hizmette bundan daha büyük kesintiler olacak ve bir saatlik üretim verisi kaybından sonra kaçan herhangi bir müşteri zaten ürüne yeterince değer vermedi.
(Düşündüğüm belirli bir başlangıçta, S3'e tutma zorunlu kılınmış bazı güzel otomatik sık sık DB-çevrimiçi dökümlerim vardı, ancak bunun bu özel senaryo için yeterince iyi olduğunu düşünmedim. Ancak kurtarabileceğimizden emin değilim. PITR/journaling, aksi takdirde birkaç/birkaç yıl içinde 9'dan fazla bir çıkışa sahip olabilecek bir işletmenin başarısı üzerine, yalnızca birkaç yüz kişiyi kurtarmak için yeni bir tek noktalı başarısızlık kumarı eklerdi.)
Ayrıca, daha az zorlu ihtiyaçları olan, ancak müşterilerin/kullanıcıların verilerine yönelik yükümlülükleri konusunda düşüncesiz olan bazı erken girişimlerin, asgari temel uygulamaları hala ihmal ettiğini düşünüyorum.
Belki takdir etmenin sezgisel bir yolu: HN'de, bazı başlangıç operasyonlarında topun düştüğü, başlangıç kurucularının adlarının eklendiği bir iş haberini hayal edin ve hikaye diyor ve iyi yedekleri olmadığı ortaya çıkıyor. Şirketleri çöktüğü için fazla uyumamış olabilecek kurucu ortaklar, "Müşteri verileri erken bir girişimde o kadar önemli değildir; olsaydı, çok kırılgan olurduk"(kurucu ortak o kişinin dizüstü bilgisayarını atmadan önce yazıldı) Yazmalarını durdurmak için odanın karşısında). İyi bir görünüm olmazdı
Bunu en sonunda ele alacağım
>HN'de, başlangıç kurucularının isimlerinin eklendiği, bazı başlangıç operasyonlarında topun düştüğü bir biz haber hikayesi hayal edin ve hikaye diyor ve iyi yedekleri olmadığı ortaya çıkıyor
ITYM ve son bir saati yedeklemedikleri ortaya çıktı
Senaryonuzdaki her şeyi hayal edebiliyorum, kırpılmamış bitleri bile ve "Bizi bir aydır kullanan yeni başlayan müşterilerimiz, verilerinin son saatini kaybettiğimizde hemen ayrıldılar"okumadığınız sürece her şey normal görünüyor.
Bu senaryoyu gerçekten hayal edemiyorum
Şimdi, bunu kullanmanın yararının bir saatlik veri kaybı olmaması olduğu bazı işletmeler var.
IOW, müşteriler herhangi bir veri kaybetmeyeceği için bunu kullanıyor: çevrimiçi belge işbirliği[1], örneğin[2]. Son girilen verilerin bir saatini kaybeden bir erime yaşarsanız, etkilenen tüm mevcut kullanıcıların derhal kaçmasını bekleyin.
[1] Yine de kişisel olarak, geçerli belgeyi düzenlenirken localstorage'da çoğaltarak riski azaltırdım
[2] Belki de borsanın son bir saatlik verileri tutması için sisteme ihtiyacı vardır? Başka ne?
Daha büyük ekipler için bile, bunu iyi yapacak yetkinliğe sahip olduğunuzu varsayarsak, veritabanlarını kendi başınıza yönetmenin mantıklı olabileceğini düşünüyorum. Yönetilen hizmetlerde ters gidebilecek pek çok şey vardır ve bunlar, blok depolama veya nesne depolama gibi şeylerin yaptığı gibi temeldeki uygulamayı gizlemez.
En yüksek performans kesinlikle daha kötü - ama yine de bir şeyin daha uzun sürmesi beni rahatsız etmiyor. Bir sunucunun hazırlanmasında bu kadar çok otomasyona sahip olmak konusunda kesinlikle haklısınız, bu benim fiziksel bir sunucuyla yapmadığım bir şeydi.
Eskiden evcil hayvan projelerim için bir kök sunucum vardı, ama dürüst olmak gerekirse, bu mantıklı değil. Makinelerimde yüksek trafikli, yoğun bilgi işlem SaaS çalıştırmıyorum. Bu sadece statik bir web sitesi ve bazı projeler. Tüm verilerimi depolamak için 1 TB'lık bir saklama kutusu içeren aylık 24 maliyetim var
Gerçek donanım içeren herhangi bir senaryodaki ana sorun, hem donanım hem de Linux/UNIX sistemlerinde yetkin personele ihtiyaç duymanızdır. Birçoğu özgeçmişlerinde olduğunu iddia ediyor ve sonra işte bir kez performans gösteremiyor (zaten benim deneyimime göre). Kanaatimce, bulut dünyasının patlamasının en önemli nedenlerinden biri kesinlikle bu tür ekipleri kurmanın zorluğu ve finansal maliyetiydi. Ek olarak, uygulama geliştiricileri ve sistem çalışanları arasında bir şekilde doğal (ve gerekli) bir sürtüşme vardır. Sistem çalışanları her zaman daha fazla güvenlik, daha fazla süreç ve daha az konuşlandırma için geri adım atmalı ve tartışmalıdır. Geliştirme ekibi her zaman daha fazla esneklik, daha fazla sürüm ve daha az süreç için tartışıyor olmalıdır. İyi yönetim daha sonra ikisi arasındaki orta yolu bulmalıdır. Ne yazık ki, beceriksiz yöneticiler genellikle sistem çalışanlarından kurtulmaya ve işleri AWS alanına taşımaya karar vermişlerdir.
Son olarak, bulut mimarisinin gezegen için kötü olduğunu, çünkü bulut sağlayıcıları tarafından aşırı tedarik gerektirdiğini ve birçok soyutlama katmanından dolayı genel olarak daha fazla bilgisayar gücü gerektirdiğini belirtmek isterim. Herhangi bir proje bu israfın küçük bir kısmından sorumlu olsa da, bir bütün olarak küresel bulutun tamamı çok israflıdır. Bu beni rahatsız ediyor ve görünüşe göre muhtemelen duygusal bir önyargı gibi faktörler (yukarıdakilerin tümü için çok büyük miktarlarda tuz)
Argüman, gelir öncesi fiziksel sunucu kiralamak için bir araç geliştirebileceğiniz, ardından mantıklı olduğunda standart amortismanı kullanabileceğiniz -veya- Kesin satın almalar ve/veya Bölüm 179 kiralamalar hakkında Bölüm 179'u kullanabileceğiniz şeklinde yapılabilir.
Örnek olarak, artıklık için farklı colo tesislerinde tamamen fazla tedarik edilmiş 100.000 $ fiziksel 1U makinelerden oluşan inanılmaz derecede yetenekli bir grup diyelim. XYZ bulut hizmeti, DNS, herhangi bir yayın, ne isterseniz yük dengeleme ve yük devretme için burada her türlü numara var. Tesisi hiç görmeden veya donanıma dokunmadan dünyanın her yerindeki veri merkezlerini işleten çeşitli ortak tesislerle gidebilir, satıcıdan donanımı onlara gönderebilir, ardından Ansible veya ilgilendiğiniz her neyse onları tedarik edebilirsiniz.
Yani artık çoğu bulut sağlayıcısı (özellikle G/Ç için) etrafında kesinlikle döngüler oluşturacak yedekli fiziksel donanıma, mümkün olan tüm bant genişliği gibi sabit maliyetlere (bu, bulut hizmetlerinin %800 işaretlemesine sahip değildir, vb.) sahipsiniz - artık beklemek yok kaçınılmaz 50.000 $ bulut faturası için veya bir ay yerine bir günde yapılandırılmış bulut bütçenizi aşmanıza neden olan şeyin izini sürmeye (panik içinde) çalışmak. Bu arada, $BIGCLOUD tarafından sunulan sanal makineler dışındaki hizmetleri sağlamak ve hatta kullanmak için kendinizi saçma sapan tescilli API'lere kilitlemiyorsunuz.
Herhangi bir makine öğrenimi yapıyorsanız, kendi donanımınızda veya (veya ara sıra bulutta) eğitim alabilir ve NVIDIA A10 gibi şeylerle 7/24 çıkarım yapabilirsiniz. GPU bulut sunucuları için sürekli bulut kiralama inanılmaz derecede pahalıdır ve donanım satın almanın yatırım getirisi genellikle birkaç ay aralığındadır (veya Bölüm 179 ile neredeyse anında çok daha ileridedir). Örnek olarak, geçtiğimiz günlerde hizmet verdiğimiz bir model için Nvidia A10 ile bir kıyaslama yaptım ve FP32'de 10 ms'nin altında gecikmeyle 700'den fazla çıkarım isteği/sn. yapabiliyor. 2800 req/s olan (ve muhtemelen daha fazla ayarlanabilir) dört sağlıklı örnekte kasa başına tek bir A10 ile
Ardından, GERÇEKTEN büyürseniz, dolaplar ve daha fazlasını almaya başlayabilirsiniz. Bahsedildiği gibi donanım arızaları açısından söyleyebileceğim tek şey, çift PS RAID çıkışı, vb. donanım (deneyimlerime göre) son derece güvenilirdir. satıcılar değiştirme için inanılmaz SLA'lar içerecektir. Onlara arızayı bildirirsiniz, bir teknisyen gönderirler.< sekiz saat doğrudan ortak tesise gidin ve diski, PS'yi vs. yanıp sönen ışıkla değiştirin
Deneyimlerime göre, bir (iyi) FTE kaynağı bunu birden çok kabin ölçeğine kadar kolayca yönetebilir. Sizin açınızdan, şu anki sorun, bu insanların birçoğunun büyük bulut sağlayıcıları tarafından ele geçirilmiş olması ve (pazarda) $ 'dan düzinelerce (daha fazla değilse) ürün/hizmet kullanan sınırdaki saçmalıkta gezinebilen kaynaklarla değiştirilmesidir. BÜYÜK BULUT
Ayrıca bu yapılandırmanın aslında çoğu $BIGCLOUD'dan ÇOK daha güvenilir olduğunu buldum. Artık kabul etmeyecekleri (ve üzerinde kesinlikle hiçbir kontrolünüz olmayan) bir $BIGCLOUD kesintisinde neler olup bittiğini merak etmenize gerek yok. Telekom ve sağlık hizmetleri geçmişinden gelen biri olarak, bulut sağlayıcılarla çalışma süresinin gerçekten çok daha kötü hale gelmesi benim için tamamen çılgınca. Genellikle müşterilere "ah, internet bugün sorunlar yaşıyor"diyebilirsiniz çünkü muhtemelen bununla ilgili manşetler göreceklerdir, ancak birçok uygulama için bu tamamen kabul edilemez - ve daha iyisini beklemeliyiz
[0] - httpswww.section179.org/section_179_deduction/
[1] = httpswww.section179.org/section_179_leases/
Yeni bir proje başlatmak istersem veya yeni bir şeye ev sahipliği yapmayı denemek istersem, bu birkaç dakika alır ve komut dosyalarına sahibim. Dağıtımlar hızlı, bakım düşük ve paramın karşılığını fazlasıyla alıyorum
İlgilenen herkes için bu, kullandığım şeyin kaba bir şeklidir:
* Her şeyi yönetmek için Ansible
* Bir gün değiştirebileceğim bazı DNS girişleri için küçük bir terraform parçası
* yedekler için restic, yine ansible tarafından kontrol edilir
* vpn için kuyruk ölçeği (evde çalışan bazı pi'lerim var, önemli bir şey yok ama kuyruk ölçeği bunu kolay ve güvenli hale getiriyor)
* hemen hemen her şey için docker-compose
Ana uygulama Clojure, bu yüzden yerel bir JVM çalıştırıyorum. Veritabanı tamamen dağıtıldı, RethinkDB, şimdi FoundationDB'ye geçmek için çalışıyor
Önemli olan hiçbir şeyi manuel olarak yönetmek değildir, örn. fiziksel sunuculara diğer bulut sunucuları gibi davranın. Fiziksel veya sanallaştırılmış olması farketmemeli
5-10 dolarlık bir vps işe yarayacakken, daha az deneyimli birçok insanın hetzner ve benzerleri için fazla ödeme yaptığını gördüm.
Evet, o noktada kendi donanımınızı destekliyorsunuz. Hayır, büyük bir baş ağrısı değil
Bunun en büyük ek maliyeti, daha fazla IPv4 adresi kiralamaktır; bu, Hetzner'ın şu an için çok az sayıda mevcut olduğu için cömertçe ücretlendiriyor.
Ne yaratırsanız yaratın, 0 kullanıcıyla başlayacak ve alacağınız 0 yük için gerçek bir makinenin tamamı tamamen gereksiz. VPS'nizi bir çift gerçek makineye, ardından küçük bir kiralık kümeye ve ardından bir veri merkezine yükseltirsiniz (eğer birisi bunun altını çizmezse). Hepsinin öngörülebilir faturaları ve fiyatlarına göre en yüksek performansı var
Bir koloda sahip olduğunuz herhangi bir şey de ayda daha fazla olacak. Statik bir IP için ödeme yapabileceğim bağlantılarım olduğunda, bu genellikle ayda 5 dolardı.
Şimdi oldukça düşük kaliteli bir sunucu kiralıyorum, ancak ayda 30 ABD doları. İhtiyacım olan her şeyden çok daha fazlası, ama güzel. Ve desteği veya başka bir şeyi iyileştirmek için fiyatları artırırken işletim sistemim için desteği bırakmadılar. (Başlangıçta değiştirilmesi gereken bazı lapa lapa donanıma sahip olmama rağmen)
sizin de belirttiğiniz gibi, gitmenin yolu çıplak metaldir. bulutun tersi çalışır - başlangıçta biraz daha fazla iş ama sonunda çok daha az masraf
Daha fazla bilgi httpseuropa.eu/youreurope/business/taxation/vat/cross-bor..
Postgres'i kurmak ve yönetmek bir acıdır. Bunu düzeltmenin daha basit bir yolunun olması güzel olurdu
1. VM'ler çökeceği için yapılandırmayı yeniden üretilebilir olmaya zorlar
2. AWS'de acıyı azaltan ağır indirimler alabilirsiniz.
3. Öğeleriniz zaten bulutta olduğunda, sanal makinelerin yanı sıra daha ucuz/hızlı olan erişiminiz olan diğer şeyler
4. Belgelenmiş bir sistem yapılandırmasına (ör. AWS belgeleri) sahip olmak, insanları eğitmekten/şirket içinde hangi özel şeylere sahip olduğunuzu belgelemekten daha kolaydır. Özellikle yeni insanları işe alırken yararlıdır
5. Premesis üzerinde alana veya fazladan güce/internete/vb. ihtiyacınız yoktur. İnsanların dizüstü bilgisayarlarını çalıştırmasına izin verecek kadar
Bundan önce bir VPS kullanıyordum, ancak daha iyi bir anlaşma olduğu ve CPU sınırlamasıyla karşılaşmadığımız için durdum ve fiziksel bir VPS'ye geçtim.
Disk izleme yine de çok zor değil. Sabit diskler için saatte bir smartctl çalıştırın, yeniden tahsis edilen veya beklemede olan sektörler hızla büyüdüğünde veya 100'e ulaştığında uyarı verin. SSD'ler için parmaklarınızı çaprazlayın; birkaç bin kişiyle olan deneyimime göre, otobüsten kaybolana ve bir daha görülmemek üzere kaybolana kadar harika çalışıyorlar. Verilerin çok benzer saat başı güç ile aynı model cihazlarda depolanmasını içermeyen bir veri kurtarma planına sahip olmak
Hetzner, her şeyden önce özel sunucular sipariş etmek için bir API'ye ve bir işletim sistemi kurmak için bir API'ye sahiptir (veya kurtarmak için yeniden başlatmak ve istediğiniz görüntüyü yanıp sönmek için)
Sanırım ticari seçenekleri araştırıyor olsaydım, ofiste ticari bir ISP çözümü, statik IP, iyi bir BT donanımı ile "gövdeyi"sıralardım, ama tam şu anda bildiğim kadarıyla bir müşterinin barındırmaya ihtiyacı varsa ben'd her zaman doğrudan bir vps kiralamaya gidin
O zamanlar daha çok küçük bir geliştiriciydim, bu yüzden belki öyleydim ama hiç özlemiyorum. Teorik olarak söylediklerinize katılıyorum, ancak bir Dockerfile'ı Google Cloud Run gibi bir şeye dağıtmak çok daha kolay. Evet, kendi VPS'mi yönetebileceğimden daha fazlasını ödüyorum ama bence bu, kaydedilen geliştirme saatleriyle fazlasıyla dengeleniyor
- fiziksel donanımda sorun var, örn. fan hatası ->sanal makinem canlı olarak farklı bir ana bilgisayara taşınıyor, fark etmiyorum veya umursamıyorum
- fiziksel donanım patlıyor ->sanal makinem farklı bir ana bilgisayarda yeniden başlatılıyor, fark edebilirim ama umurumda değil
Sanal makinelerle felaket planlaması çok daha kolay (sığır değil evcil hayvanlarda bile)
Yeni başlayanlar için en ucuzu işi halleder
Bulut bilgi işlem geliştikçe, bu tekliflerin daha yaygın hale geleceğinden eminim.
Bulut bilişimin başka bir yönü daha var. Orta ila büyük ölçekli şirketler, maliyet hesaplamalarında bulut bilişimi tek haneli yüzdeler olarak sayar. Bu, yöneticiler ve ekipler tarafından alınan kararların, "kurulumum maliyetli mi yoksa ucuz mu"yerine genellikle güvenilirlik ve ölçeklenebilirlik (sunumlarına koymak için) aradığı anlamına gelir.
İşverenim bulutu dini bir oyun olarak değil, bir iş/finansal oyun olarak benimsedi. Genellikle yeni yapıları buluta yerleştirir ve uygunsa daha sonra bir veri merkezine taşırız
Şirket içi uygulamaların maliyeti yaklaşık %40 daha düşüktür. Bulutta daha uygun maliyetli olan uygulamalar orada kalır
AWS/GCP/Azure'un Avrupa'da maliyet açısından çok rekabetçi teklifler olmadığını düşünüyorum. Benim göremediğim şey ABD için bunun kanıtı
aynı özellik için, elbette. Sanalların her iki uçta da mantıklı olduğunu düşünüyorum - ya büyük N için dinamik ölçeklenebilirlik önemlidir ya da fiziksel bir kutunun yalnızca küçük bir kısmına ihtiyacınız vardır. Ayda 5'te find çalıştıran bir şey için 45/ay ödemek de mantıklı değildir ve yalnızca sunucunuzu kullanmak için bir şeyleri bir araya getirmemek için size daha fazla esneklik sağlar.
Her durumda yedeklerinizi saklayın. Tercihen başka bir sağlayıcıda veya en azından farklı bir fiziksel konumda. Ve tabii ki onları test edin
Ve iyi bir yedekleme rejimi yönetiyorsanız ve yine de verilerinizi/uygulamanızı izliyorsanız, izleme sürücüleri ekstra bir zorluk teşkil ediyor mu?
--
[1] aslında geri yükleme işlemini başka bir konuma otomatikleştirirseniz, ki ben bunu birkaç parçam için yapıyorum, o zaman o düğmeye basıp tamamlandığında DNS'yi güncelleyebilir ve belki biraz daha fazla RAM+çekirdek ayırabilirsiniz (benim testim) aynalar, gerçek kullanım modellerine hizmet etmeleri gerekmediğinden canlı VM'lerden daha küçüktür)
Tam olarak kendim ve müşterilerim için yaptığım şey. Tonlarca doz tasarrufu sağlar
Güncellemek istesem bile, bu sadece en son sürümü docker-compose şablonuna çekmek ve ansible playbook'u yeniden çalıştırmaktan ibaret. Açıkçası, yükseltme daha fazlasını gerektiriyorsa öyle olsun, ancak diğer kurulum işlerinden hiçbir farkı yok
Muhtemelen manuel olarak yapmam gereken tek şey yedeklerimi test etmektir. Ama bunu yapan her proje için bir betiğim var, bu yüzden sadece SSH'yi açıyorum, tek satırı çalıştırıyorum, sonucu kontrol ediyorum ve bitti. Bunu aşağı yukarı ayda bir yapıyorum ama bir yedekleme başarısız olursa e-posta da alıyorum.
Yani hiç zaman olmayabilir. Güncellemeleri yarı düzenli olarak alıyorsam, genellikle muhtemelen ayda 1-2 saattir. Ancak bu, barındırdığınız ve yönettiğiniz daha fazla şeyle ölçeklenir
Diğer bir deyişle, tek fark, sorumlu envanter dosyasının nereden geldiğidir. Ya statik bir IP listesi ya da terraform'dan geliyor
ECC RAM istiyorsanız, bu 60/ay gibi görünüyor ve ayrıca daha güçlü 8 çekirdekli bir CPU'ya çıkıyor.
Ne olursa olsun, "tam bir üretim ortamı ve yinelenen bir hazırlık/yedekleme ortamı"hakkında konuşuyorsak (yanıt verdiğiniz kişiden alıntı yapmak gerekirse), o zaman 60/ay * (2 veya 3), herhangi bir yeni başlayanın AWS'sine kıyasla hala çok ucuz gördüğüm fatura
Kullanım durumları değişebilir, ancak AWS/GCP/Azure'un her sorunun yanıtı olmadığı konusunda hemfikir olma eğilimindeyim
Uygulamasını 4 dolarlık bir VPS'ye sığdırabilen biri için bu, çıplak metal olan her şeyden daha ucuz olacaktır, ancak bulut çoğu durumda çok pahalı bir şekilde ölçeklenir. Bare metal de her sorunun cevabı değildir, ancak sektördeki pek çok insan bunun ne zaman doğru cevap olabileceğini takdir etmiyor gibi görünüyor.
SANAL ÖZEL SUNUCULAR#120
