Lanet olsun Google, tekrar blog yazmak istemedim. Yapacak çok işim var. Blog yazmak zaman, enerji ve yaratıcılık gerektirir; bunları iyi bir şekilde değerlendirebilirim: kitaplarım, , oyunum vb. Ama beni bunu yazmak zorunda bırakacak kadar kızdırdın.
O halde bu işi bitirelim.
Google'da ilk çalışmaya başladığım zamandan kalma kısa ama öğretici bir hikayeyle başlayayım. Son zamanlarda Google hakkında pek çok kötü şey söylediğimi biliyorum, ancak kendi şirketimin düzenli olarak yetersiz iş kararları alması beni üzüyor. Aynı zamanda hakkını da vermeliyiz: Google'ın iç altyapısı gerçekten olağanüstü, bugün bundan daha iyisinin olmadığını rahatlıkla söyleyebiliriz. Google'ın kurucuları benim asla olamayacağım kadar iyi mühendislerdi ve bu hikaye sadece bu gerçeği doğruluyor.
Öncelikle biraz arka plan bilgisi verelim: Google'ın, adında bir veri depolama teknolojisi vardır. . Bu dikkate değer bir teknik başarıydı; ilk (ilk olmasa da) "sonsuzca ölçeklenebilir" anahtar/değer deposundan (K/V) biriydi: aslında NoSQL'in başlangıcıydı. Bu günlerde Bigtable oldukça kalabalık K/V depolama alanında hala iyi durumda, ancak o zamanlar (2005) inanılmaz derecede güzeldi.
Bigtable ile ilgili komik bir şey, tablet sunucuları adı verilen, büyük dizinlere sahip dahili kontrol düzlemi nesnelerine (uygulamanın bir parçası olarak) sahip olmaları ve bir noktada sistemi ölçeklendirirken bir darboğaz haline gelmeleridir. Bigtable mühendisleri ölçeklenebilirliğin nasıl uygulanacağı konusunda kafa yoruyordu ve aniden tablet sunucularını diğer Bigtable depolama birimleriyle değiştirebileceklerini fark ettiler. Yani Bigtable, Bigtable uygulamasının bir parçasıdır. Bu depolama tesisleri her seviyede mevcuttur.
Bir başka ilginç ayrıntı da Bigtable'ın bir süreliğine Google'da popüler hale gelmesi ve her ekibin kendi deposuna sahip olması. Cuma toplantılarından birinde Larry Page sıradan bir şekilde şunu sordu: “Neden birden fazla Bigtable'ımız var? Neden sadece bir tane değil?” Teorik olarak, Google'ın tüm depolama ihtiyaçları için tek bir depolama alanı yeterli olmalıdır. Tabii ki, pratik geliştirme nedenleriyle (potansiyel bir başarısızlığın sonuçları gibi) asla sadece bir tanesine gitmediler, ancak teori ilginçti. Tüm Evren için tek bir depo (Bu arada Amazon'un bunu Sable ile yapıp yapmadığını bilen var mı?)
Neyse işte benim hikayem.
O zamanlar Google'da iki yılı aşkın bir süredir çalışıyordum ve bir gün Bigtable mühendislik ekibinden şunun gibi bir e-posta aldım:
Sevgili Steve,
Bigtable ekibinden merhaba. [Veri merkezi adı]'nda çok çok eski bir Bigtable ikili programı kullandığınızı size bildirmek isteriz. Bu sürüm artık desteklenmiyor ve en son sürüme yükseltmenize yardımcı olmak istiyoruz.
Bu sorun üzerinde birlikte çalışmak için biraz zaman planlayabilirseniz lütfen bana bildirin.
Herşey gönlünce olsun,
Büyük Masa Takımı
Google'da çok fazla posta alıyorsunuz, bu yüzden ilk bakışta şöyle bir şey okudum:
Sayın Alıcı,
Bir takımdan merhaba. Bunu falan filan iletmek istiyoruz. Blah blah blah blah blah ve hemen falan filan.
Değerli zamanınızın bir kısmını filan falan için programlayabilirseniz lütfen bize bildirin.
Herşey gönlünce olsun,
Bir tür komut
Neredeyse hemen siliyordum ama bilincimin bir ucunda acı verici, dırdırcı bir duygu hissettim: gerçekten resmi bir mektuba benziyor ama belli kiBigtable'ı kullanmadığım için alıcının yanıldığını belirttim.
Ama tuhaftı.
Günün geri kalanını dönüşümlü olarak işi ve mikro mutfakta ne tür köpekbalığı eti deneyeceğimi düşünerek geçirdim; bunlardan en az üçü koltuğumdan iyi nişanlanmış bir bisküvi fırlatacak kadar yakındı, ama Yazma düşüncesi bende hiçbir zaman giderek artan hafif bir kaygı duygusu bırakmadı.
Adımı açıkça söylediler. Ve e-posta başkasının adresine değil, benim e-posta adresime gönderildi ve cc: veya bcc: değil. Ton çok kişisel ve net. Belki bu bir çeşit hatadır?
Sonunda merakım galip geldi ve bahsettiği veri merkezindeki Borg konsoluna bakmaya gittim.
Ve tabii ki yönetimim altında BigTable depolama alanım vardı. Üzgünüm, ne? İçeriğine baktım ve vay be! Haziran 2005'te Google'daki ilk haftamda oturduğum Codelab kuluçka makinesinden geliyordu. Codelab, bazı değerleri oraya yazmanız için sizi Bigtable'ı çalıştırmaya zorladı ve görünüşe göre bundan sonra depoyu hiç kapatmadım. Aradan iki yıldan fazla zaman geçmesine rağmen hâlâ çalışıyordu.
Bu hikayenin dikkat çeken birkaç yönü var. Birincisi, Bigtable'ın çalışması Google ölçeğinde o kadar önemsizdi ki, yalnızca iki yıl sonra herhangi biri ekstra depolamayı fark etti ve bunun tek nedeni ikili programın sürümünün güncel olmamasıydı. Karşılaştırma için bir keresinde kullanmayı düşünmüştüm çevrimiçi oyunum için. O zamanlar bu hizmetin maliyeti yılda yaklaşık 16 dolardı. boş GCP'de büyük tablo. Seni dolandırdıklarını söylemiyorum ama kişisel görüşüme göre bu, boş bir veri tabanı için çok fazla para.
Dikkat çeken bir diğer husus ise depolama iki yıl sonra hala çalışıyorum. O NE LAN? Veri merkezleri gelir ve gider; kesintiler yaşıyorlar, planlı bakıma giriyorlar, sürekli değişiyorlar. Donanım güncelleniyor, anahtarlar değiştiriliyor, her şey sürekli geliştiriliyor. Tüm bu değişikliklere rağmen programımı iki yıl boyunca nasıl yürütebildiler? Bu, 2020'de mütevazı bir başarı gibi görünebilir, ancak 2005-2007'de oldukça etkileyiciydi.
Ve en harika yönü, başka bir eyaletteki dışarıdan bir mühendislik ekibinin, Bigtable'ın küçük, neredeyse boş bir örneğinin sahibi olan, bana yaklaşması. sıfır trafik son iki yıldır - ve güncellenmesi için yardım teklif ediyoruz.
Onlara teşekkür ettim, depoyu sildim ve hayat her zamanki gibi devam etti. Ama on üç yıl sonra hala o mektubu düşünüyorum. Çünkü bazen Google Cloud'dan da benzer e-postalar alıyorum. Şuna benziyorlar:
Sayın Google Bulut Kullanıcısı,
Ağustos 2020 itibarıyla [kullandığınız temel hizmet] hizmetini sonlandıracağımızı ve bu tarihten sonra bulut sunucularınızı yükseltemeyeceğinizi hatırlatmak isteriz. Yardımımız sayesinde, beta test aşamasında olan, hiçbir dokümantasyonu olmayan, geçiş yolu bulunmayan ve önceden güncelliğini kaybetmiş olan en son sürüme yükseltmenizi öneririz.
Bu değişikliğin Google Cloud platformunun tüm kullanıcıları üzerinde minimum düzeyde etki yaratmasını sağlamaya kararlıyız.
Sonsuza kadar en iyi arkadaşlar,
Google Bulut Platformu
Ama bu tür mektupları neredeyse hiç okumadım çünkü gerçekte söyledikleri şu:
Sayın Alıcı,
Cehenneme git. Siktir git, siktir et, siktir et. Yaptığınız her şeyi bırakın çünkü önemi yok. Önemli olan zamanımız. Saçmalığımızı sürdürmek için zaman ve para harcıyoruz ve bundan yorulduğumuz için artık onu desteklemeyeceğiz. O yüzden lanet planlarınızı bırakın ve boktan belgelerimizi araştırmaya başlayın, forumlarda kırıntı için yalvarın ve bu arada, yeni saçmalıklarımız eskisinden tamamen farklı, çünkü bu tasarımı oldukça kötü bir şekilde berbat ettik, heh, ama bu sizin sorun bizim değil.
Tüm geliştirmelerinizin bir yıl içerisinde kullanılamaz hale gelmesi için çalışmalarımızı sürdürüyoruz.
Lütfen siktir git
Google Bulut Platformu
Ve gerçek şu ki, bu tür mektupları yaklaşık ayda bir alıyorum. Bu o kadar sık ve sürekli oluyor ki kaçınılmaz olarak uzaklaştırıldı beni GCP'den bulut karşıtı kampa. Artık onların özel geliştirmelerine bağlı kalmayı kabul etmiyorum, çünkü aslında devop'lar için çıplak bir sanal makinede açık kaynaklı bir sistemi sürdürmek, Google'ın "modası geçmiş" ürünleri kapatma politikasına ayak uydurmaya çalışmaktan daha kolaydır.
Google Cloud'a geri dönmeden önce çünkü hatta yakın Onları eleştirmeyi bırakalım, şirketin diğer bazı alanlardaki performansına bakalım. Google mühendisleri yazılım mühendisliği disiplinleriyle gurur duyuyorlar ve aslında sorunlara neden olan da bu. Gurur, tedbirsizler için bir tuzaktır ve pek çok Google çalışanının, kararlarının her zaman doğru olduğunu ve haklı olmanın (bazı muğlak bulanık tanım gereği) müşterileri önemsemekten daha önemli olduğunu düşünmesine yol açmıştır.
Google dışındaki diğer büyük projelerden rastgele örnekler vereceğim ama umarım bu modeli her yerde görürsünüz. Aşağıdaki gibidir: Geriye dönük uyumluluk, sistemleri onlarca yıl boyunca canlı ve güncel tutar.
Geriye dönük uyumluluk, tasarlanmış tüm başarılı sistemlerin tasarım hedefidir. açık yani açık kaynak kodu ve/veya açık standartlarla uygulanır. Herkesin rahatsız olacağı kadar bariz bir şey söylediğimi hissediyorum ama hayır. Bu politik bir konu, dolayısıyla örneklere ihtiyaç var.
Seçeceğim ilk sistem en eskisi olacak: Windows Not Defteri, işletim sistemi çekirdeği ve Uluslararası Uzay İstasyonunun bir nevi melezi olan GNU Emacs. Açıklaması biraz zor ama özetle Emacs, 1976'da (evet, neredeyse yarım yüzyıl önce) sizi daha üretken kılmak için programlama yapmak için oluşturulmuş, ancak bir metin editörü kılığına girmiş bir platformdur.
Emacs'ı her gün kullanıyorum. Evet, ben de IntelliJ'i her gün kullanıyorum, başlı başına güçlü bir işleme platformu haline geldi. Ancak IntelliJ için uzantı yazmak, Emacs için uzantı yazmaktan çok daha iddialı ve karmaşık bir iştir. Daha da önemlisi Emacs için yazılan her şey korunur ebediyen.
1995 yılında Emacs için yazdığım yazılımı hala kullanıyorum. Ve eminim ki birileri Emacs için yazılmış modülleri 80'lerin ortalarında, hatta daha erken bir zamanda kullanıyordur. Zaman zaman biraz ince ayar yapılması gerekebilir, ancak bu gerçekten oldukça nadirdir. Emacs için yazdığım (ve çok yazdım) yeniden mimari gerektiren hiçbir şey bilmiyorum.
Emacs'ın eski varlıklar için eski hale getirme adı verilen bir işlevi vardır. Temel bilgisayar kavramlarına yönelik Emacs terminolojisi ("pencere"nin ne olduğu gibi) genellikle endüstrideki geleneklerden farklıdır çünkü Emacs bunları uzun zaman önce tanıtmıştır. Bu, zamanının ilerisinde olanlar için tipik bir tehlikedir: tüm terimleriniz yanlıştır. Ancak Emacs'ın kendi jargonunda adı geçen bir kullanımdan kaldırma kavramı vardır. eskime.
Ancak Emacs dünyasında farklı bir çalışma tanımı var gibi görünüyor. İsterseniz farklı bir temel felsefe.
Emacs dünyasında (ve aşağıda ele alacağımız diğer birçok alanda), kullanımdan kaldırılan API durumu temel olarak şu anlama gelir: "Bu yaklaşımı gerçekten kullanmamalısınız, çünkü işe yarasa da, bizim de göreceğimiz çeşitli eksikliklere sahiptir. burada listeleyin. Ama günün sonunda seçim sizin."
Google dünyasında eski olmak, "Size olan taahhüdümüzü ihlal ediyoruz" anlamına gelir. Bu doğru. Esasen anlamı budur. Bu seni zorlayacakları anlamına gelir düzenli olarak Onlara inanmanın cezası olarak biraz iş yapın, belki de çok iş yapın : En iyi yazılıma sahibiz. En hızlı! Her şeyi talimatlara göre yaparsınız, uygulamanızı veya hizmetinizi başlatırsınız ve ardından bir veya iki yıl sonra bozulur.
Bu, 1500 km sonra mutlaka bozulacak olan kullanılmış bir arabayı satmak gibidir.
Bunlar “eskimişliğin” tamamen farklı iki felsefi tanımıdır. Google'ın koku tanımı . buna inanmıyorum aslında Apple ile aynı anlamda planlı eskitme. Ancak Google kesinlikle programlarınızı dolambaçlı bir şekilde bozmayı planlıyor. Bunu biliyorum çünkü orada 12 yılı aşkın bir süre yazılım mühendisi olarak çalıştım. Geriye dönük uyumluluğun ne kadar takip edilmesi gerektiğine ilişkin belirsiz dahili yönergeleri vardır, ancak sonuçta bu her bir takıma veya hizmete bağlıdır. Kurumsal veya mühendislik düzeyinde herhangi bir öneri yoktur ve eskime döngüleri açısından en cesur öneri, "müşterilere tüm sistemlerini bozmadan önce yükseltmeleri için 6-12 ay süre vermeye çalışın."
Sorun düşündüklerinden çok daha büyük ve müşteri hizmetleri DNA'larında olmadığı için önümüzdeki yıllarda da devam edecek. Aşağıda bu konuda daha fazla bilgi bulabilirsiniz.
Bu noktada Emacs'ın büyük ölçüde başarılı olduğuna ve hatta başarılı olduğuna dair cesur bir açıklama yapacağım. temel olarak çünkü geriye dönük uyumluluğu çok ciddiye alıyorlar. Aslında makalemizin tezi de bu. Başarılı, uzun ömürlü açık sistemler, başarılarını onlarca yıldır etraflarında yaşayan mikro topluluklara borçludur. uzantılar/eklentiler. Bu ekosistemdir. Platformların doğasından, ne kadar önemli olduklarından ve Google'ın tüm kurumsal geçmişi boyunca Android veya Chrome dışında başarılı bir açık platform yaratmanın ne anlama geldiğini hiçbir zaman anlayamadığından bahsetmiştim.
Aslında Android'den kısaca bahsetmem gerekiyor çünkü muhtemelen düşünüyorsunuz.
İlk olarak, Android Google değil. Birbirleriyle neredeyse hiçbir ortak yanı yok. Android, Temmuz 2005'te Google tarafından satın alınan bir şirkettir; şirketin az çok özerk çalışmasına izin verilmiştir ve aslında aradan geçen yıllarda büyük ölçüde dokunulmadan kalmıştır. Android, kötü şöhretli bir teknoloji yığını ve aynı derecede kötü şöhretli, huysuz bir organizasyondur. Bir Google çalışanının belirttiği gibi, "Android'e öylece giriş yapamazsınız."
Önceki bir makalede, Android'in ilk tasarım kararlarından bazılarının ne kadar kötü olduğunu tartışmıştım. Lanet olsun, ben o makaleyi yazdığımda "hazır uygulamalar" adı verilen saçmalıkları piyasaya sürüyorlardı ve bunlar artık (sürpriz!) Google'ı dinleyip içeriğinizi bu hazır uygulamalara taşıyacak kadar aptal olmanızı da anlıyorum.
Ancak burada bir fark var, önemli bir fark; Android kullanıcıları platformların ne kadar önemli olduğunu gerçekten anlıyorlar, eski Android uygulamalarını çalışır durumda tutmak için ellerinden geleni yapıyorlar. Aslında, geriye dönük uyumluluğu sürdürme çabaları o kadar aşırı ki, birkaç yıl önce Android bölümündeki kısa görevim sırasında ben bile kendimi onları bazı en eski cihazlar ve API'ler için desteği bırakmaya ikna etmeye çalışırken buldum (yanılmışım) , geçmişteki ve günümüzdeki diğer pek çok şeyde olduğu gibi. Üzgünüm Android'ciler! Artık Endonezya'ya gittiğime göre onlara neden ihtiyacımız olduğunu anlıyorum).
Android kullanıcıları geriye dönük uyumluluğu neredeyse hayal bile edilemeyecek uç noktalara zorluyor, sistemlerinde ve araç zincirlerinde büyük miktarda eski teknik borç biriktiriyor. Aman Tanrım, uyumluluk adına derleme sistemlerinde yapmak zorunda oldukları bazı çılgın şeyleri görmelisin.
Bunun için Android'e imrenilen "Sen Google Değilsin" ödülünü veriyorum. Gerçekten dayanıklı platformların nasıl oluşturulacağını bilmeyen Google olmak istemiyorlar ama Android O biliyor, nasıl yapılır. Dolayısıyla Google bir açıdan çok akıllı davranıyor: Android'de insanların işlerini kendi yöntemleriyle yapmalarına izin vermek.
Ancak Android için hazır uygulamalar oldukça aptalca bir fikirdi. Peki nedenini biliyor musun? Çünkü talep ettiler uygulamanızı yeniden yazın ve yeniden tasarlayın! Sanki insanlar iki milyon uygulamayı yeniden yazacakmış gibi. Anlık Uygulamaların bir Google çalışanının fikri olduğunu tahmin ediyorum.
Ama bir fark var. Geriye dönük uyumluluk yüksek bir maliyete sahiptir. Bu maliyetlerin yükünü Android'in kendisi üstleniyor, Google ise bu yükün üstlenilmesinde ısrar ediyor sen, ödeme yapan müşteri.
Android'in geriye dönük uyumluluk konusundaki kararlılığını API'lerinde görebilirsiniz. Kelimenin tam anlamıyla aynı şeyi yapan dört veya beş farklı alt sisteminiz olduğunda, bu, özünde geriye dönük uyumluluk taahhüdünün bulunduğuna dair kesin bir işarettir. Platformlar dünyasında bu, müşterilerinize ve pazarınıza bağlılıkla eş anlamlıdır.
Google'ın buradaki temel sorunu, mühendislik hijyeninden duydukları gururdur. Aynı şeyi yapmanın birçok farklı yolunun olması, eski, daha az arzu edilen yöntemlerin yeni, daha gösterişli yöntemlerin yanında bulunmasından hoşlanmazlar. Sisteme yeni başlayanlar için öğrenme eğrisini artırır, eski API'leri koruma yükünü artırır, yeni özelliklerin hızını yavaşlatır ve en büyük günahı bunun hoş olmamasıdır. Google - Tim Burton'ın Alice Harikalar Diyarında'sındaki Lady Ascot gibi:
Leydi Ascot:
- Alice, en çok neden korkuyorum biliyor musun?
- Aristokrasinin gerilemesi mi?
- Yapacağımdan korkuyordum çirkin torunlar.
Güzel ve pratik arasındaki dengeyi anlamak için üçüncü başarılı platforma (Emacs ve Android'den sonra) bir göz atalım ve nasıl çalıştığını görelim: Java'nın kendisi.
Java'nın birçok eski API'si var. Kullanımdan kaldırma, Java programcıları arasında çok popülerdir, hatta çoğu programlama dilinden daha popülerdir. Java'nın kendisi, çekirdek dil ve kütüphaneler API'leri sürekli olarak kullanımdan kaldırıyor.
Binlerce örnekten sadece birini ele alacak olursak; eskimiş sayılır. Java 1.2'nin Aralık 1998'de piyasaya sürülmesinden bu yana kullanımdan kaldırılmıştır. Bu uygulamanın kaldırılmasının üzerinden 22 yıl geçti.
Ancak üretimdeki asıl kodum hala konuları öldürüyor Her gün. Bunun gerçekten iyi olduğunu mu düşünüyorsun? Kesinlikle! Yani tabi ki bugün kodu yeniden yazsaydım farklı şekilde uygulardım. Ancak son yirmi yılda yüzbinlerce insanı mutlu eden oyunumun kodu, çok uzun süre asılı kalan konuları kapatma işleviyle yazıldı ve ben asla değiştirmek zorunda kalmadım. Sistemimi herkesten daha iyi biliyorum, üretimde onunla çalışma konusunda kelimenin tam anlamıyla 25 yıllık deneyimim var ve şunu kesin olarak söyleyebilirim: benim durumumda, bu belirli işçi iş parçacıklarını kapatmak tamamen değersiz. Bu kodu yeniden yazmak için harcayacağınız zamana ve çabaya değmez ve Larry Ellison'a (muhtemelen) teşekkür ederim ki Oracle beni onu yeniden yazmaya zorlamadı.
Oracle muhtemelen platformlardan da anlıyor. Kim bilir.
Kanyondaki bir buzulun çizgileri gibi eskime dalgalarıyla dolu olan çekirdek Java API'lerinde bunun kanıtları bulunabilir. Java Swing kitaplığında beş veya altı farklı klavye gezinme yöneticisini (KeyboardFocusManager) kolayca bulabilirsiniz. Kullanımdan kaldırılmamış bir Java API bulmak aslında zordur. Ama hâlâ çalışıyorlar! Java ekibinin bir API'yi yalnızca arayüzün göze çarpan bir güvenlik sorunu oluşturması durumunda gerçekten kaldıracağını düşünüyorum.
Olay şu arkadaşlar: Biz yazılımcılar hepimiz çok meşgulüz ve yazılımın her alanında rakip alternatiflerle karşı karşıya kalıyoruz. Herhangi bir zamanda, X dilindeki programcılar Y dilini olası bir alternatif olarak düşünüyorlar. Ah, bana inanmıyor musun? Ona Swift mi demek istiyorsun? Mesela herkes Swift'e göç ediyor ve kimse onu terk etmiyor, değil mi? Vay, ne kadar az şey biliyorsun. Şirketler ikili mobil geliştirme ekiplerinin (iOS ve Android) maliyetlerini hesaplıyorlar ve Flutter ve React Native gibi komik isimler taşıyan bu platformlar arası geliştirme sistemlerinin gerçekten işe yaradığını ve boyutlarının küçültülmesi için kullanılabileceğini fark etmeye başlıyorlar. Mobil ekipler iki kat daha verimli hale gelir veya tam tersi, onları iki kat daha verimli hale getirir. Gerçek para tehlikede. Evet, tavizler var ama diğer yandan para da var.
Varsayımsal olarak, Apple'ın aptalca bir şekilde Guido van Rossum'dan ipucu aldığını ve Python 6.0'ün Python 5.0 ile uyumsuz olduğu gibi Swift 3'ın Swift 2 ile geriye dönük olarak uyumsuz olduğunu ilan ettiğini varsayalım.
Muhtemelen bu hikayeyi yaklaşık on yıl önce anlatmıştım, ancak yaklaşık on beş yıl önce Guido ile O'Reilly'nin Foo Kampına gittim, Paul Graham ve bir grup önemli kişiyle birlikte bir çadırda oturdum. Bunaltıcı sıcakta oturduk ve Larry Page'in kişisel helikopteriyle uçmasını beklerken Guido, herkesin oraya göç etmesi için gereken yıl sayısından sonra adını verdiği "Python 3000" hakkında homurdandı. Ona neden uyumluluğu bozduğunu sormaya devam ettik ve o da şu cevabı verdi: "Unicode." Kodumuzu yeniden yazmak zorunda kalsaydık başka ne gibi faydalar görürdük diye sorduk. Ve o da “Yoooooooooooouuuuuuuniiiiiiicoooooooode” diye cevap verdi.
Google Cloud Platform SDK'sını ("gcloud") yüklerseniz aşağıdaki bildirimi alırsınız:
Sayın Alıcı,
Python 2 desteğinin kullanımdan kaldırıldığını hatırlatmak isteriz, o yüzden canınız cehenneme
… ve benzeri. Yaşam döngüsü.
Ancak mesele şu ki, her geliştiricinin bir seçeneği var. Ve onları kodu yeterince sık yeniden yazmaya zorlarsanız, şunu düşünebilirler: diğer seçenekler. Ne kadar olmalarını isteseniz de onlar sizin rehineleriniz değil. Onlar sizin misafirleriniz. Python hala çok popüler bir programlama dili ama kahretsin, Python 3(000) kendi içinde, topluluklarında ve bu toplulukların kullanıcıları arasında öyle bir karmaşa yarattı ki sonuçları on beş yıldır aydınlatılamadı.
Bu geriye dönük uyumsuzluk nedeniyle Go'da (veya Ruby'de veya başka bir alternatifte) kaç Python programı yeniden yazıldı? Python dışında ne kadar çok yeni yazılım yazıldı? olabilirdi Guido bütün köyü yakmasaydı Python'da mı yazılmıştı? Bunu söylemek zor ama Python açıkça acı çekti. Bu çok büyük bir karmaşa ve herkes kaybediyor.
Yani diyelim ki Apple, Guido'dan ipucu aldı ve uyumluluğu bozdu. Daha sonra ne olacağını düşünüyorsun? Belki geliştiricilerin %80-90'ı mümkünse yazılımlarını yeniden yazacaktır. Başka bir deyişle, kullanıcı tabanının %10-20'si otomatik olarak Flutter gibi rakip bir dile gidiyor.
Bunu birden çok kez yaparsanız kullanıcı tabanınızın yarısını kaybedersiniz. Tıpkı sporda olduğu gibi programlama dünyasında da güncel form önemlidir. tüm. Beş yıl içinde kullanıcılarının yarısını kaybeden herkes Büyük Yağ Kaybeden olarak değerlendirilecek. Platform dünyasında trend olmalısınız. Ancak eski sürümleri desteklememenin sizi zamanla mahvedeceği yer burasıdır. Çünkü bazı geliştiricilerden her kurtulduğunuzda, (a) sözleşmeyi bozduğunuz için size kızdıkları için onları sonsuza kadar kaybedersiniz ve (b) onları rakiplerinize verirsiniz.
İronik bir şekilde, kodun kendisini otomatikleştirmeyi ve düzenlemeyi kolaylaştıran bir kaynak kodu analizi ve anlama sistemi olan Grok'u oluşturduğumda Google'ın geriye dönük uyumluluğu göz ardı eden bir prima donna olmasına da yardımcı oldum - bir IDE'ye benzer, ancak burada bulut hizmeti depolanır Büyük bir veri ambarındaki milyarlarca satırlık Google kaynak kodunun somutlaştırılmış temsilleri.
Grok, Google çalışanlarına kod tabanlarının tamamında (kelimenin tam anlamıyla Google genelinde) otomatik yeniden düzenleme işlemleri gerçekleştirmeleri için güçlü bir çerçeve sağladı. Sistem yalnızca yukarı yöndeki bağımlılıklarınızı (bağımlı olduğunuz) değil, aynı zamanda akıntı yönünde (hangisi size kalmış) yani API'leri değiştirdiğinizde ihlal ettiğiniz herkesi bilirsiniz! Bu şekilde, değişiklik yaptığınızda API'nizi kullanan her tüketicinin yeni sürüme güncellendiğini doğrulayabilirsiniz ve gerçekte çoğunlukla yazdıkları Rosie aracıyla süreci tamamen otomatikleştirebilirsiniz.
Bu, Google'ın kod tabanının dahili olarak neredeyse doğaüstü derecede temiz olmasını sağlar, çünkü robotik hizmetkarlar evin içinde koştururlar ve birisi onun çirkin bir torun olduğuna ve onun ihtiyaçlarının uyutulması gerektiğine karar verdiği için SomeDespicouslyLongFunctionName'i SomeDespicouslyLongMethodName olarak yeniden adlandırırlarsa her şeyi otomatik olarak temizlerler.
Ve açıkçası Google için oldukça iyi çalışıyor... dahili olarak. Demek istediğim, evet, Google'daki Go topluluğu, sürekli yeniden düzenleme alışkanlıklarından dolayı Google'daki Java topluluğuyla epey eğleniyor. Bir şeyi N kez yeniden başlatırsanız, bu sadece N-1 kez batırdığınız anlamına gelmez, aynı zamanda bir süre sonra muhtemelen N'inci denemede de batırdığınız oldukça açık hale gelir. Ancak genel olarak tüm bu telaşın üstünde kalıyorlar ve kodu “temiz” tutuyorlar.
Sorun, bu tutumu bulut istemcilerine ve diğer API kullanıcılarına dayatmaya çalıştıklarında başlıyor.
Sizi Emacs, Android ve Java ile biraz tanıştırdım; Gelin en son başarılı uzun ömürlü platforma bakalım: Web'in kendisine. Yanıp sönen etiketleri kullandığımız 1995'ten bu yana HTTP'nin kaç yinelemeden geçtiğini hayal edebiliyor musunuz? ve web sayfalarında "Yapım Aşamasında" simgeleri.
Ama hâlâ işe yarıyor! Ve bu sayfalar hala çalışıyor! Evet arkadaşlar, tarayıcılar geriye dönük uyumlulukta dünya şampiyonudur. Chrome, kafaları doğru bir şekilde vidalanmış nadir Google platformunun bir başka örneğidir ve tahmin edebileceğiniz gibi Chrome, Google'ın geri kalanından ayrı, korumalı alanlı bir şirket olarak etkili bir şekilde çalışır.
Ayrıca işletim sistemi geliştiricilerindeki arkadaşlarımıza da teşekkür etmek istiyorum: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, vb., başarılı platformlarında geriye dönük uyumluluk konusunda harika bir iş çıkardıkları için (Apple en iyi ihtimalle C alır) dezavantajı, her şeyi iyi bir neden olmadan her zaman bozmalarıdır, ancak topluluk her sürümde bir şekilde bu sorunu aşıyor ve OS X kapsayıcıları hala tamamen eskimiş değil... henüz).
Ama durun diyorsunuz. Elmaları portakallarla karşılaştırmıyor muyuz? Emacs/JDK/Android/Chrome gibi tek bir makinedeki bağımsız yazılım sistemleriyle çoklu sunucu sistemleri ve bulut hizmetleri gibi API'leri karşılaştırmıyor muyuz?
Dün bunun hakkında tweet atmıştım ama Larry Wall'un (Perl programlama dilinin yaratıcısı - yaklaşık per.) tarzında "berbat/kurallar" ilkesine dayanarak kelimeye baktım önerilmiyor Google ve Amazon geliştirici sitelerinde. AWS'nin sahip olmasına rağmen aşağı inmek GCP'den kat daha fazla hizmet teklifi sunan Google'ın geliştirici dokümanlarında, kullanımdan kaldırılmadan yaklaşık yedi kat daha sık bahsediliyor.
Google'dan herhangi biri bunu okuyorsa, muhtemelen her şeyi doğru yaptıklarını ve benim "kullanımdan kaldırılmış kelimesinin geçtiği yer ile kullanımdan kaldırılan kelime sayısı" gibi adil olmayan karşılaştırmalar yapmamam gerektiğini gösteren Donald Trump tarzı çizelgeleri çıkarmaya hazırdırlar. hizmet sayısı" "
Ancak bunca yıldan sonra, Google Cloud hala 3 numaralı hizmettir (2 numara olma girişimiyle ilgili başarısız bir makale yazmadım), ancak içeridekilere inanılacak olursa, bunların yakında 4 numaraya düşebileceğine dair bazı endişeler var. XNUMX numara.
Tezimi "kanıtlayacak" hiçbir ikna edici argümanım yok. Sahip olduğum tek şey, geliştirici olarak 30 yılı aşkın süredir biriktirdiğim renkli örnekler. Bu sorunun derin felsefi doğasından daha önce bahsetmiştim; bazı açılardan geliştirici topluluklarında siyasallaştırılıyor. Bazıları buna inanıyor yaratıcılar platformların uyumluluğa önem vermesi gerekirken diğerleri bunun bir endişe kaynağı olduğunu düşünüyor kullanıcılar (geliştiricilerin kendileri). İkide biri. Aslında ortak sorunların maliyetini kimin üstleneceğine karar vermemiz siyasi bir mesele değil mi?
Yani bu politikadır. Ve muhtemelen konuşmama kızgın tepkiler gelecektir.
Gibi kullanıcı Google Cloud Platform ve iki yıldır (Grab için çalışırken) AWS kullanıcısı olarak, öncelikler söz konusu olduğunda Amazon ile Google'ın felsefeleri arasında büyük bir fark olduğunu söyleyebilirim. AWS'de aktif olarak geliştirme yapmıyorum, bu nedenle eski API'leri ne sıklıkla kaldırdıklarını çok iyi bilmiyorum. Ancak bunun Google'daki kadar sık gerçekleşmediğine dair şüpheler var. GCP'deki bu sürekli tartışma ve hayal kırıklığının, platformun gelişimini engelleyen en büyük faktörlerden biri olduğuna gerçekten inanıyorum.
Artık desteklenmeyen GCP sistemlerine ilişkin belirli örnekleri belirtmediğimi biliyorum. Ağlardan (en eskisinden VPC'ye kadar), depolamaya (Cloud SQL v1-v2), Firebase'e (şimdi tamamen farklı bir API'ye sahip Firestore), App Engine'e (başlamaya bile gerek yok) kadar kullandığım hemen hemen her şeyin olduğunu söyleyebilirim. , bulut uç noktaları Bulut Uç Noktası ve... Bilmiyorum - kesinlikle bunların hepsi Maksimum 2-3 yıl sonra sizi kodu yeniden yazmaya zorladılar ve geçişi sizin için hiçbir zaman otomatikleştirmediler ve sıklıkla . Sanki öyle olması gerekiyordu.
AWS'ye her baktığımda kendime neden hala GCP'de olduğumu soruyorum. Açıkça müşterilere ihtiyaçları yok. İhtiyaçları var покупатели. Aradaki farkı anlıyabiliyor musun? Açıklamama izin ver.
Google Cloud'da İnsanların kendi yazılım çözümlerini önerdiği ve boş restoran etkisini önlemek için burayı bazı tekliflerle doldurmaları gerekiyordu, bu yüzden "tek tıklamayla" dağıtılan bir dizi çözüm oluşturmak için Bitnami adlı bir şirketle sözleşme imzaladılar veya Kendime “çözümler” yazıyorum çünkü bunlar hiçbir şeyi çözmüyor. Bunlar yalnızca onay kutuları, pazarlama doldurucuları olarak varlar ve Google, araçlardan herhangi birinin gerçekten çalışıp çalışmadığını hiçbir zaman umursamadı. Sürücü koltuğunda oturan ürün yöneticilerini tanıyorum ve bu insanların umursamadığına sizi temin ederim.
Örneğin, sözde "tek tıkla" dağıtım çözümünü ele alalım. . Google Cloud SQL saçmalıklarından ölesiye bıkmıştım, bu yüzden alternatif olarak kendi Percona kümemi oluşturmaya başladım. Ve bu sefer Google iyi bir iş çıkarmış gibi görünüyordu; tek bir tıklamayla bana biraz zaman ve emek kazandıracaklardı!
Harika, hadi gidelim. Bağlantıyı takip edip bu butona tıklayalım. Tüm varsayılan ayarları kabul etmek ve kümeyi Google bulut projenize dağıtmak için "Evet"i seçin. Haha, işe yaramıyor. Bu saçmalıkların hiçbiri işe yaramıyor. Araç hiçbir zaman test edilmedi ve ilk dakikadan itibaren çürümeye başladı ve "çözümlerin" yarısından fazlasının tek tıklamayla konuşlandırma olması beni şaşırtmaz (şimdi alıntıların nedenini anlıyoruz) hiç çalışmıyor. Bu, girmemenin daha iyi olduğu kesinlikle umutsuz bir karanlıktır.
Ama Google haklı dürtüler onları kullanacaksın. yapmanı istiyorlar aldığım. Onlar için bu bir işlemdir. Hiçbir şey istemiyorlar desteklemek. Bu Google'ın DNA'sının bir parçası değil. Evet, Bigtable ile olan hikayemin de gösterdiği gibi mühendisler birbirlerini destekliyorlar. Ancak sıradan insanlara yönelik ürün ve hizmetlerde daima acımasızdı Milyonlarca kullanıcısı olsa bile kârlılık çıtasını karşılayamıyor.
Bu da GCP için gerçek bir zorluk teşkil ediyor çünkü tüm bulut tekliflerinin arkasındaki DNA budur. Hiçbir şeyi desteklemeye çalışmıyorlar; Herhangi bir üçüncü taraf yazılımını (yönetilen bir hizmet olarak) barındırmayı reddettikleri iyi bilinmektedir. a kadarAWS de aynısını yapıp bunun etrafında başarılı bir iş kurana ve müşteriler tam anlamıyla aynısını talep edene kadar. Ancak Google'ın bir şeyi desteklemesini sağlamak biraz çaba gerektirir.
Bu destek kültürünün eksikliği, "haydi onu daha güzel hale getirelim" zihniyetiyle birleştiğinde geliştiricileri yabancılaştırıyor.
Uzun ömürlü bir platform oluşturmak istiyorsanız bu iyi bir şey değil.
Google, uyan, kahretsin. Şimdi 2020. Hala kaybediyorsun. Aynaya iyice bakıp bulut işinde gerçekten kalmak isteyip istemediğinize cevap vermenin zamanı geldi.
Eğer kalmak istersen o zaman her şeyi kırmayı bırak. Arkadaşlar siz zenginsiniz. Biz geliştiriciler bunu yapmayız. Dolayısıyla uyumluluk yükünü kimin omuzlayacağına gelince, bu sorumluluğu kendiniz üstlenmelisiniz. Bizim için değil.
Çünkü gerçekten iyi olan en az üç bulut daha var. Çağırıyorlar.
Ve şimdi tüm bozuk sistemlerimi onarmaya başlayacağım. Ah.
Bir sonrakine kadar!
Bu makaledeki bazı tartışmaları okuduktan sonra PS Güncellemesi (tartışmalar harika, bu arada). Firebase desteği kesilmedi ve bildiğim herhangi bir plan da yok. Ancak Java istemcisinin App Engine'de durmasına neden olan kötü bir akış hatası var. Mühendislerinden biri bu sorunu çözmemde bana yardımcı oldu. Google'da çalıştığımda, ancak aslında hatayı hiçbir zaman düzeltmediler, bu yüzden GAE uygulamasını her gün yeniden başlatmak zorunda kalmak gibi berbat bir geçici çözümüm var. Ve bu dört yıldır böyle! Artık Firestore'ları var. Tamamen farklı bir sistem olduğu ve Firebase hatası hiçbir zaman düzeltilmeyeceği için bu sisteme geçmek çok fazla iş gerektirecek. Ne gibi bir sonuç çıkarılabilir? Yardım alabilirsiniz eğer bir şirkette çalışıyorsan. Muhtemelen GAE'de Firebase'i kullanan tek kişi benim çünkü %100 yerel bir uygulamada 100'den az anahtar kaydediyorum ve bilinen bir hata nedeniyle uygulama birkaç günde bir çalışmayı bırakıyor. Riski size ait olmak üzere kullanmaktan başka ne söyleyebilirim? Redis'e geçiyorum.
Ayrıca daha deneyimli bazı AWS kullanıcılarının, AWS'nin genellikle hiçbir hizmeti desteklemeyi asla bırakmadığını söylediğini gördüm ve SimpleDB buna harika bir örnek. AWS'nin Google ile aynı destek sonu hastalığına sahip olmadığına dair varsayımlarım haklı görünüyor.
Ek olarak, 20 gün önce Google App Engine ekibinin kritik bir Go kitaplığının barındırılmasını bozduğunu ve çekirdek Go geliştiricilerinden birinin GAE uygulamasını kapattığını fark ettim. Gerçekten aptalcaydı.
Son olarak, Google çalışanlarının bu konuyu zaten tartıştıklarını ve genel olarak benimle aynı fikirde olduklarını duydum (sizi seviyorum!). Ancak Google'ın kültürünün hiçbir zaman doğru teşvik yapısına sahip olmaması nedeniyle sorunun çözülemez olduğunu düşünüyorlar. Grab'da çalışırken AWS mühendisleriyle çalışırken yaşadığım kesinlikle muhteşem deneyimi tartışmak için biraz zaman ayırmanın iyi olacağını düşündüm. Gelecekte bir gün, umarım!
Ve evet, 2005 yılında 43 numaralı binadaki dev büfede farklı türde köpekbalığı eti vardı ve benim favorim çekiç kafalı köpekbalığı etiydi. Ancak 2006 yılına gelindiğinde Larry ve Sergei tüm sağlıksız atıştırmalıklardan kurtuldular. Yani 2007'deki Bigtable hikayesinde aslında hiç köpekbalığı yoktu ve ben seni aldattım.
Dört yıl önce Cloud Bigtable'a baktığımda (ver ya da al), maliyetin olduğu yer burasıydı. Şu anda biraz düşmüş gibi görünüyor, ancak bu hala boş bir veri ambarı için çok fazla bir rakam, özellikle de ilk hikayem boş bir büyük masanın onların ölçeğinde ne kadar önemsiz olduğunu gösterdiği için.
Apple topluluğunu rahatsız ettiğim ve Microsoft vb. hakkında hoş bir şey söylemediğim için özür dilerim. Haklısınız, bu makalenin yarattığı tartışmayı gerçekten takdir ediyorum! Ama bazen bir tartışma başlatmak için biraz ortalığı karıştırmanız gerekir, anlıyor musunuz?
Okuduğunuz için teşekkürler.
Güncelleme 2, 19.08.2020. Şerit !
Güncelleme 3, 31.08.2020. Cloud Marketplace'ten eski bir arkadaşım olduğu ortaya çıkan bir Google mühendisi benimle iletişime geçti. C2D'nin neden çalışmadığını anlamak istedi ve sonunda bunun benim ağımı yıllar önce kurmuş olmamdan kaynaklandığını ve şablonlarında alt ağ parametresi eksik olduğundan C2D'nin eski ağlarda çalışmadığını anladık. Potansiyel GCP kullanıcılarının Google'da yeterince mühendis tanıdıklarından emin olmalarının en iyisi olacağını düşünüyorum...
Kaynak: habr.com