Habr konferansı bir başlangıç hikayesi değil. Daha önce, 300-400 kişilik oldukça büyük Ekmek Kızartma etkinlikleri düzenledik, ancak şimdi yönünü örneğin yorumlarda belirleyebileceğiniz küçük tematik toplantıların alakalı olacağına karar verdik. Bu formatın ilk konferansı Temmuz ayında yapıldı ve arka uç geliştirmeye adandı. Katılımcılar, Devlet Hizmetleri portalında arka uçtan makine öğrenimine geçişin özelliklerine ve Quadrupel hizmetinin tasarımına ilişkin raporları dinlediler ve ayrıca Sunucusuz'a özel bir yuvarlak masa toplantısına katıldılar. Etkinliğe bizzat katılamayanlar için bu yazıda size en ilginç şeyleri anlatıyoruz.
Arka uç geliştirmeden makine öğrenimine
Veri mühendisleri makine öğreniminde ne yapar? Bir arka uç geliştiricinin ve bir makine öğrenimi mühendisinin görevleri nasıl benzer ve farklıdır? İlk mesleğinizi ikinci mesleğinize dönüştürmek için nasıl bir yol izlemeniz gerekiyor? Bu, 10 yıllık arka uç çalışmasının ardından makine öğrenimine geçen Alexander Parinov tarafından söylendi.
Alexander Parinov
Bugün Alexander, X5 Retail Group'ta bilgisayarlı görü sistemleri mimarı olarak çalışıyor ve bilgisayarlı görü ve derin öğrenmeyle ilgili Açık Kaynak projelerine katkıda bulunuyor (github.com/creafz). Becerileri, makine öğrenimi yarışmalarının en popüler platformu olan Kaggle Master'ın (kaggle.com/creafz) dünya sıralamasında ilk 100'e girmesiyle doğrulandı.
Neden makine öğrenimine geçmelisiniz?
Bir buçuk yıl önce, Google'ın derin öğrenme tabanlı yapay zeka araştırma projesi Google Brain'in başkanı Jeff Dean, Google Çeviri'deki yarım milyon satırlık kodun yerini nasıl yalnızca 500 satırdan oluşan bir Tensor Flow sinir ağının aldığını anlattı. Ağın eğitimi sonrasında verinin kalitesi arttı ve altyapı daha basit hale geldi. Görünüşe göre bu bizim parlak geleceğimiz: Artık kod yazmamıza gerek yok, nöronlar oluşturmak ve onları verilerle doldurmak yeterli. Ancak pratikte her şey çok daha karmaşıktır.
Google'da makine öğrenimi altyapısı
Sinir ağları altyapının yalnızca küçük bir kısmıdır (yukarıdaki resimdeki küçük siyah kare). Veriyi almak, işlemek, depolamak, kaliteyi kontrol etmek vb. için çok daha fazla yardımcı sisteme ihtiyaç vardır; eğitim, makine öğrenimi kodunun üretimde dağıtılması ve bu kodun test edilmesi için altyapıya ihtiyacımız vardır. Tüm bu görevler, arka uç geliştiricilerin yaptıklarına tamamen benzer.
Makine öğrenimi süreci
ML ve arka uç arasındaki fark nedir?
Klasik programlamada kod yazarız ve bu, programın davranışını belirler. ML'de küçük bir model kodumuz ve modele attığımız birçok veri var. ML'de veriler çok önemlidir: farklı veriler üzerinde eğitilen aynı model tamamen farklı sonuçlar gösterebilir. Sorun, verilerin neredeyse her zaman dağınık olması ve farklı sistemlerde (ilişkisel veritabanları, NoSQL veritabanları, günlükler, dosyalar) saklanmasıdır.
Veri sürümü oluşturma
ML, klasik geliştirmede olduğu gibi yalnızca kodun değil aynı zamanda verilerin de versiyonlanmasını gerektirir: modelin ne üzerinde eğitildiğini açıkça anlamak gerekir. Bunu yapmak için popüler Veri Bilimi Sürüm Kontrolü kitaplığını (dvc.org) kullanabilirsiniz.
Veri işaretleme
Bir sonraki görev veri etiketlemedir. Örneğin resimdeki tüm nesneleri işaretleyin veya hangi sınıfa ait olduğunu söyleyin. Bu, bir API'nin varlığıyla işi büyük ölçüde basitleştiren Yandex.Toloka gibi özel hizmetler tarafından yapılır. "İnsan faktörü" nedeniyle zorluklar ortaya çıkıyor: Aynı görevi birkaç icracıya vererek veri kalitesini artırabilir ve hataları en aza indirebilirsiniz.
Tensör Kartında Görselleştirme
Sonuçları karşılaştırmak ve bazı ölçümlere göre en iyi modeli seçmek için deneylerin günlüğe kaydedilmesi gerekir. Görselleştirme için geniş bir araç seti vardır - örneğin Tensor Board. Ancak deneyleri saklamanın ideal bir yolu yoktur. Küçük şirketler genellikle bir Excel elektronik tablosuyla yetinirken, büyük şirketler sonuçları bir veritabanında depolamak için özel platformlar kullanır.
Makine öğrenimi için pek çok platform var ancak hiçbiri ihtiyaçların %70'ini karşılamıyor
Eğitilmiş bir modeli üretime koyarken karşılaşılması gereken ilk sorun, veri bilimcilerin en sevdiği araç olan Jupyter Notebook ile ilgilidir. İçinde modülerlik yoktur, yani çıktı, mantıksal parçalara - modüllere bölünmeyen bir kod "ayak örtüsüdür". Her şey karışık: sınıflar, işlevler, konfigürasyonlar vb. Bu kodun sürümü ve test edilmesi zordur.
Bununla nasıl başa çıkılır? Netflix gibi kendiniz istifa edebilir ve bu dizüstü bilgisayarları doğrudan üretime sokmanıza, bunlara girdi olarak veri aktarmanıza ve sonuç almanıza olanak tanıyan kendi platformunuzu oluşturabilirsiniz. Modeli üretime aktaran geliştiricileri kodu normal şekilde yeniden yazmaya, onu modüllere ayırmaya zorlayabilirsiniz. Ancak bu yaklaşımla hata yapmak kolaydır ve model amaçlandığı gibi çalışmayacaktır. Bu nedenle ideal seçenek Jupyter Notebook'un model kodu için kullanımını yasaklamaktır. Tabii veri bilimcileri de bunu kabul ederse.
Kara kutu olarak model
Bir modeli üretime sokmanın en kolay yolu onu kara kutu olarak kullanmaktır. Bir tür model sınıfınız var, size modelin ağırlıkları verildi (eğitimli ağdaki nöronların parametreleri) ve bu sınıfı başlatırsanız (tahmin yöntemini çağırın, ona bir resim verin), belirli bir değer elde edeceksiniz. çıktı olarak tahmin. İçeride olup bitenlerin hiçbir önemi yok.
Sunucu sürecini modelle ayırın
Ayrıca belirli bir ayrı süreci başlatabilir ve bunu bir RPC kuyruğu aracılığıyla gönderebilirsiniz (resimler veya diğer kaynak verilerle birlikte). Çıktıda tahminleri alacağız.
Flask'ta bir model kullanmanın bir örneği:
@app.route("/predict", methods=["POST"])
def predict():
image = flask.request.files["image"].read()
image = preprocess_image(image)
predictions = model.predict(image)
return jsonify_prediction(predictions)
Bu yaklaşımın sorunu performans sınırlamasıdır. Diyelim ki veri bilimcileri tarafından yazılmış yavaş bir Phyton kodumuz var ve maksimum performansı elde etmek istiyoruz. Bunu yapmak için kodu native'e dönüştüren veya üretime özel başka bir çerçeveye dönüştüren araçları kullanabilirsiniz. Her çerçeve için bu tür araçlar vardır, ancak ideal olanlar yoktur; bunları kendiniz eklemeniz gerekir.
ML'deki altyapı normal arka uçtakiyle aynıdır. Docker ve Kubernetes var, yalnızca Docker için NVIDIA'dan çalışma zamanı yüklemeniz gerekiyor, bu da kapsayıcı içindeki işlemlerin ana bilgisayardaki video kartlarına erişmesine olanak tanıyor. Kubernetes'in video kartlı sunucuları yönetebilmesi için bir eklentiye ihtiyacı var.
Klasik programlamanın aksine, makine öğrenimi durumunda altyapıda kontrol edilmesi ve test edilmesi gereken birçok farklı hareketli öğe vardır; örneğin veri işleme kodu, model eğitim hattı ve üretim (yukarıdaki şemaya bakın). Boru hatlarının farklı parçalarını birbirine bağlayan kodu test etmek önemlidir: çok sayıda parça vardır ve modül sınırlarında sıklıkla sorunlar ortaya çıkar.
AutoML nasıl çalışır?
AutoML hizmetleri, amaçlarınıza en uygun modeli seçip eğitme sözü verir. Ancak şunu anlamalısınız: ML'de veriler çok önemlidir, sonuç onun hazırlanmasına bağlıdır. İşaretleme, hatalarla dolu olan insanlar tarafından yapılır. Sıkı kontrol olmadan sonuç çöp olabilir ve süreci otomatikleştirmek henüz mümkün değildir; uzmanların - veri bilimcilerin - doğrulamasına ihtiyaç vardır. AutoML'in çöktüğü yer burasıdır. Ancak, verileri zaten hazırladığınızda ve en iyi modeli bulmak için bir dizi deney yapmak istediğinizde, bir mimari seçerken yararlı olabilir.
Makine öğrenimine nasıl girilir?
Makine öğrenimine girmenin en kolay yolu, tüm derin öğrenme çerçevelerinde (ve normal çerçevelerde) kullanılan Python'da geliştirme yapmaktır. Bu dil, bu faaliyet alanı için pratik olarak zorunludur. C++ bazı bilgisayarlı görme görevlerinde, örneğin sürücüsüz arabaların kontrol sistemlerinde kullanılır. JavaScript ve Shell - görselleştirme ve tarayıcıda bir nöron çalıştırmak gibi garip şeyler için. Büyük Veri ile çalışırken ve makine öğrenimi için Java ve Scala kullanılır. R ve Julia, matematiksel istatistik okuyan insanlar tarafından seviliyor.
Başlangıç olarak pratik deneyim kazanmanın en uygun yolu Kaggle'dır; platformun yarışmalarından birine katılmak, bir yıldan fazla teorik çalışma olanağı sağlar. Bu platformda başka birinin gönderdiği ve yorumladığı kodu alıp onu geliştirmeye, amaçlarınıza göre optimize etmeye çalışabilirsiniz. Bonus - Kaggle sıralamanız maaşınızı etkiler.
Diğer bir seçenek de ML ekibine arka uç geliştirici olarak katılmaktır. Meslektaşlarınızın sorunlarını çözmelerine yardımcı olarak deneyim kazanabileceğiniz birçok makine öğrenimi girişimi var. Son olarak, veri bilimci topluluklarından birine (Açık Veri Bilimi (ods.ai) ve diğerleri) katılabilirsiniz.
Konuşmacı, konuyla ilgili ek bilgileri bağlantıda yayınladı
"Quadrupel" - "Devlet Hizmetleri" portalının hedeflenen bildirimlerinin bir hizmeti
Evgeny Smirnov
Bir sonraki konuşmacı, Quadruple hakkında konuşan e-devlet altyapı geliştirme departmanı başkanı Evgeny Smirnov'du. Bu, Runet'te en çok ziyaret edilen hükümet kaynağı olan Gosuslugi portalına (gosuslugi.ru) yönelik hedefli bir bildirim hizmetidir. Günlük izleyici sayısı 2,6 milyon olup, sitede 90 milyonu onaylanmış olmak üzere toplam 60 milyon kayıtlı kullanıcı bulunmaktadır. Portal API'sindeki yük 30 bin RPS'dir.
Devlet Hizmetlerinin arka ucunda kullanılan teknolojiler
“Quadrupel”, özel bildirim kuralları oluşturularak kullanıcının kendisi için en uygun anda hizmet teklifi aldığı, hedefe yönelik bir bildirim hizmetidir. Hizmeti geliştirirken temel gereksinimler esnek ayarlar ve postalama için yeterli zamandı.
Quadrupel nasıl çalışır?
Yukarıdaki şema, sürücü belgesini değiştirme ihtiyacı olan bir durum örneğini kullanarak Quadrupel'in çalışma kurallarından birini göstermektedir. Hizmet ilk olarak, son kullanma tarihi bir ay içinde dolacak kullanıcıları arar. Onlara uygun hizmeti alma teklifini içeren bir banner gösterilir ve e-posta yoluyla bir mesaj gönderilir. Son tarihi zaten dolmuş kullanıcılar için banner ve e-posta değişir. Başarılı bir hak alışverişinden sonra kullanıcı, kimlikteki verileri güncelleme teklifiyle birlikte başka bildirimler alır.
Teknik açıdan bakıldığında bunlar, kodun yazıldığı harika komut dosyalarıdır. Giriş veridir, çıkış doğru/yanlış, eşleşti/eşleşmedi. Kullanıcının doğum gününün belirlenmesinden (geçerli tarih kullanıcının doğum tarihine eşittir) karmaşık durumlara kadar toplamda 50'den fazla kural vardır. Bu kurallar her gün yaklaşık bir milyon eşleşmeyi, yani bilgilendirilmesi gereken kişileri belirler.
Dörtlü bildirim kanalları
Quadrupel'in başlığı altında kullanıcı verilerinin saklandığı bir veritabanı ve üç uygulama bulunmaktadır:
- Işçi Verileri güncellemek için tasarlanmıştır.
- Dinlenme API bannerları kendisi alıp portala ve mobil uygulamaya teslim eder.
- Zamanlayıcı Banner veya toplu postaların yeniden hesaplanmasına yönelik çalışmaları başlatır.
Verileri güncellemek için arka uç olay odaklıdır. İki arayüz - dinlenme veya JMS. Çok fazla olay var; kaydetmeden ve işlemeden önce gereksiz isteklerde bulunmayacak şekilde bir araya getiriliyorlar. Veritabanının kendisi, verilerin depolandığı tablo, bir anahtar değer deposuna benziyor - kullanıcının anahtarı ve değerin kendisi: ilgili belgelerin varlığını veya yokluğunu gösteren bayraklar, bunların geçerlilik süreleri, hizmetlerin sırasına ilişkin toplu istatistikler bu kullanıcı vb.
Verileri kaydettikten sonra, JMS'de banner'ların hemen yeniden hesaplanması için bir görev ayarlanır - bunun hemen web'de görüntülenmesi gerekir. Sistem gece başlar: JMS'ye kullanıcı aralıklarla görevler atılır ve buna göre kuralların yeniden hesaplanması gerekir. Bu, yeniden hesaplamaya dahil olan işlemciler tarafından alınır. Daha sonra işleme sonuçları, banner'ları veritabanına kaydeden veya kullanıcı bildirim görevlerini hizmete gönderen bir sonraki kuyruğa gider. İşlem 5-7 saat sürer, her zaman işleyici ekleyebileceğiniz veya örnekleri yeni işleyicilerle yükseltebileceğiniz için kolayca ölçeklenebilir.
Servis oldukça iyi çalışıyor. Ancak kullanıcı sayısı arttıkça veri hacmi de artıyor. Bu, Rest API'sinin kopyaya baktığı gerçeğini hesaba katarak bile veritabanındaki yükün artmasına neden olur. İkinci nokta, yüksek bellek tüketimi nedeniyle pek uygun olmadığı ortaya çıkan JMS'dir. JMS'nin çökmesine ve işlemenin durmasına neden olan yüksek bir kuyruk taşması riski vardır. Bundan sonra günlükleri temizlemeden JMS'yi yükseltmek mümkün değildir.
Veritabanı üzerindeki yükün dengelenmesini sağlayacak sharding kullanılarak sorunların çözülmesi planlanıyor. Ayrıca veri depolama düzenini değiştirme ve JMS'yi, bellek sorunlarını çözecek, hataya daha dayanıklı bir çözüm olan Kafka'ya değiştirme planları da var.
Hizmet Olarak Arka Uç Vs. Sunucusuz
Soldan sağa: Alexander Borgart, Andrey Tomilenko, Nikolay Markov, Ara Israelyan
Hizmet olarak arka uç mu yoksa Sunucusuz çözüm mü? Yuvarlak masada bu acil konunun tartışılmasına katılanlar şunlardı:
- Ara Israelyan, CTO CTO ve Scorocode'un kurucusu.
- Nikolay Markov, Aligned Research Group Kıdemli Veri Mühendisi.
- Andrey Tomilenko, RUVDS geliştirme departmanı başkanı.
Konuşmanın moderatörlüğünü üst düzey geliştirici Alexander Borgart yaptı. Dinleyicilerin de katıldığı tartışmaları kısaltılmış haliyle sunuyoruz.
— Sizin anlayışınıza göre Sunucusuz nedir?
Andrew: Bu bir bilgi işlem modelidir; sonucun yalnızca verilere bağlı olması için verileri işlemesi gereken bir Lambda işlevi. Terim ya Google'dan ya da Amazon'dan ve onun AWS Lambda hizmetinden geldi. Bir sağlayıcının böyle bir işlevi, bunun için bir kapasite havuzu ayırarak yerine getirmesi daha kolaydır. Farklı kullanıcılar aynı sunucularda bağımsız olarak hesaplanabilir.
Nicholas: Basitçe söylemek gerekirse, BT altyapımızın ve iş mantığımızın bir kısmını buluta, dış kaynak kullanımına aktarıyoruz.
Amerika papağanı: Geliştiriciler açısından, kaynakları korumak, pazarlamacılar açısından ise daha fazla para kazanmak için iyi bir girişim.
— Sunucusuz mikro hizmetlerle aynı şey midir?
Nicholas: Hayır, Serverless daha çok bir mimari organizasyondur. Mikro hizmet, bazı mantığın atomik birimidir. Sunucusuz bir yaklaşımdır, "ayrı bir varlık" değil.
Amerika papağanı: Sunucusuz bir işlev bir mikro hizmete paketlenebilir, ancak bu artık Sunucusuz olmayacak, Lambda işlevi olmaktan çıkacak. Sunucusuz'da bir işlev ancak istendiği anda çalışmaya başlar.
Andrew: Yaşam süreleri farklıdır. Lambda fonksiyonunu başlattık ve unuttuk. Birkaç saniye çalıştı ve bir sonraki müşteri isteğini başka bir fiziksel makinede işleyebilir.
— Hangi terazi daha iyi?
Amerika papağanı: Yatay ölçeklendirme sırasında Lambda işlevleri mikro hizmetlerle tamamen aynı şekilde davranır.
Nicholas: Ayarladığınız replika sayısı ne kadar olursa olsun, o kadar çok olacaktır; Serverless'ın ölçeklendirme konusunda hiçbir sorunu yoktur. Kubernetes'te bir kopya seti oluşturdum, "bir yerde" 20 örnek başlattım ve 20 anonim bağlantı size geri gönderildi. İleri!
— Sunucusuz'a arka uç yazmak mümkün mü?
Andrew: Teorik olarak ama hiçbir anlamı yok. Lambda işlevleri tek bir depoya dayanacaktır; garantiyi sağlamamız gerekir. Örneğin, bir kullanıcı belirli bir işlemi gerçekleştirdiyse, bir sonraki bağlantı kurduğunda şunu görmelidir: işlem gerçekleştirildi, para yatırıldı. Bu çağrıda tüm Lambda işlevleri engellenecektir. Aslında, bir grup Sunucusuz işlev, veritabanına tek bir darboğaz erişim noktasıyla tek bir hizmete dönüşecek.
— Hangi durumlarda sunucusuz mimariyi kullanmak mantıklıdır?
Andrew: Paylaşılan depolama gerektirmeyen görevler - aynı madencilik, blockchain. Çok fazla sayma yapmanız gereken yer. Çok fazla bilgi işlem gücünüz varsa, "oradaki bir şeyin karmasını hesapla..." gibi bir işlev tanımlayabilirsiniz. Ancak veri depolamayla ilgili sorunu, örneğin Amazon'un Lambda işlevlerini ve bunların dağıtılmış depolamasını alarak çözebilirsiniz. . Ve düzenli bir hizmet yazdığınız ortaya çıktı. Lambda işlevleri depolamaya erişecek ve kullanıcıya bir tür yanıt sağlayacaktır.
Nicholas: Sunucusuz olarak çalışan konteynerlerin kaynakları son derece sınırlıdır. Çok az hafıza ve diğer her şey var. Ancak altyapınızın tamamı tamamen bir bulutta (Google, Amazon) konuşlandırılmışsa ve onlarla kalıcı bir sözleşmeniz varsa, tüm bunlar için bir bütçe vardır, o zaman bazı görevler için Sunucusuz konteynerleri kullanabilirsiniz. Bu altyapının içinde olmak gerekiyor çünkü her şey belli bir ortamda kullanıma göre tasarlandı. Yani her şeyi bulut altyapısına bağlamaya hazırsanız deneme yapabilirsiniz. Avantajı bu altyapıyı yönetmek zorunda olmamanızdır.
Amerika papağanı: Sunucusuz'un Kubernetes, Docker'ı yönetmenizi, Kafka'yı kurmanızı vb. gerektirmemesi, kendini kandırmaktır. Bunu aynı Amazon ve Google yüklüyor. Başka bir şey de bir SLA'nızın olmasıdır. Kendiniz kodlamak yerine her şeyi dışarıdan temin edebilirsiniz.
Andrew: Sunucusuzun kendisi ucuzdur, ancak diğer Amazon hizmetleri için (örneğin veritabanı) çok para ödemeniz gerekir. API kapısı için çılgın miktarlarda para talep ettikleri için insanlar onlara zaten dava açtı.
Amerika papağanı: Paradan bahsediyorsak o zaman şu noktayı dikkate almanız gerekiyor: tüm kodu Sunucusuz'a aktarmak için şirketteki tüm geliştirme metodolojisini 180 derece döndürmeniz gerekecek. Bu çok zaman ve para gerektirecektir.
— Amazon ve Google'ın sunduğu ücretli Sunucusuz alternatiflere layık alternatifler var mı?
Nicholas: Kubernetes'te bir tür işi başlatırsınız, çalışır ve ölür; mimari açıdan bu oldukça Sunucusuzdur. Kuyruklar ve veritabanları ile gerçekten ilginç iş mantığı oluşturmak istiyorsanız bu konu üzerinde biraz daha düşünmeniz gerekir. Bunların hepsi Kubernetes'ten ayrılmadan çözülebilir. Ek uygulamayı uzatmaktan rahatsız olmazdım.
— Sunucusuz'da olup bitenleri izlemek ne kadar önemli?
Amerika papağanı: Sistem mimarisine ve iş gereksinimlerine bağlıdır. Temel olarak sağlayıcı, devops ekibinin olası sorunları anlamasına yardımcı olacak raporlama sağlamalıdır.
Nicholas: Amazon, Lambda'dan gelenler de dahil olmak üzere tüm günlüklerin akışını sağlayan CloudWatch'a sahiptir. Günlük yönlendirmeyi entegre edin ve görüntüleme, uyarı verme vb. için ayrı bir araç kullanın. Ajanları başlattığınız konteynerlere doldurabilirsiniz.
- Özetleyelim.
Andrew: Lambda fonksiyonlarını düşünmek faydalıdır. Kendi başınıza bir hizmet oluşturursanız (mikro hizmet değil, istek yazan, veritabanına erişen ve yanıt gönderen bir hizmet), Lambda işlevi bir dizi sorunu çözer: çoklu iş parçacığı, ölçeklenebilirlik vb. ile. Mantığınız bu şekilde oluşturulmuşsa gelecekte bu Lambdaları mikro hizmetlere aktarabilecek veya Amazon gibi üçüncü taraf hizmetleri kullanabileceksiniz. Teknoloji kullanışlı, fikir ilginç. Bunun iş açısından ne kadar haklı olduğu hala açık bir sorudur.
Nikolay: Sunucusuzun bazı iş mantığını hesaplamak yerine operasyon görevleri için kullanılması daha iyidir. Bunu her zaman olay işleme olarak düşünürüm. Amazon'da varsa, Kubernetes'teyseniz evet. Aksi takdirde, Sunucusuz'u kendi başınıza çalışır duruma getirmek için oldukça fazla çaba harcamanız gerekecektir. Belirli bir iş durumuna bakmak gerekir. Örneğin şu anki görevlerimden biri şu: Dosyalar diskte belirli bir formatta göründüğünde, bunları Kafka'ya yüklemem gerekiyor. WatchDog veya Lambda'yı kullanabilirim. Mantıksal açıdan her iki seçenek de uygundur ancak uygulama açısından Sunucusuz daha karmaşıktır ve ben Lambda olmadan daha basit yolu tercih ederim.
Amerika papağanı: Sunucusuz ilginç, uygulanabilir ve teknik açıdan çok güzel bir fikir. Teknoloji er ya da geç herhangi bir fonksiyonun 100 milisaniyeden daha kısa sürede başlatılabileceği noktaya ulaşacak. O zaman prensipte bekleme süresinin kullanıcı için kritik olup olmadığı sorusu ortadan kalkacaktır. Aynı zamanda Serverless'ın uygulanabilirliği, meslektaşlarımızın da söylediği gibi, tamamen iş sorununa bağlıdır.
Bize çok yardımcı olan sponsorlarımıza teşekkür ederiz:
- BT konferans alanı «» konferans sitesi için.
- BT etkinlikleri takvimi ve yayın "» bilgi desteği ve haberler için.
- «"hediyeler için.
- birlikte yaratım için.
- "Elektronik Haberleşme Derneği" Katılım ve deneyim için.
- Ana sponsor - hepsi için!
Kaynak: habr.com