Habr konfransı debüt hekayəsi deyil. Əvvəllər biz 300-400 nəfər üçün kifayət qədər böyük Toaster tədbirləri keçirirdik, lakin indi qərara gəldik ki, kiçik tematik görüşlər aktual olacaq, istiqamətini, məsələn, şərhlərdə təyin edə bilərsiniz. Bu formatın ilk konfransı iyul ayında keçirilib və backend inkişafına həsr olunub. İştirakçılar Dövlət Xidmətləri portalında “backend”dən ML-yə keçidin xüsusiyyətləri və “Quadrupel” xidmətinin dizaynı haqqında məruzələri dinləyiblər, həmçinin “Serverless”ə həsr olunmuş dəyirmi masada iştirak ediblər. Tədbirdə şəxsən iştirak edə bilməyənlər üçün bu yazıda sizə ən maraqlı şeyləri danışırıq.
Backend inkişafından maşın öyrənməsinə qədər
Məlumat mühəndisləri ML-də nə edirlər? Backend developer və ML mühəndisinin vəzifələri necə oxşar və fərqlidir? İlk peşənizi ikinci peşəyə dəyişmək üçün hansı yolu tutmalısınız? Bunu 10 illik backend işindən sonra maşın öyrənməsinə keçən Alexander Parinov deyib.
Aleksandr Parinov
Bu gün Alexander X5 Retail Group-da kompüter görmə sistemlərinin memarı kimi işləyir və kompüter görmə və dərin öyrənmə ilə bağlı Açıq Mənbə layihələrinə töhfə verir (github.com/creafz). Onun bacarıqları maşın öyrənmə yarışları üçün ən populyar platforma olan Kaggle Master-in (kaggle.com/creafz) dünya reytinqinin ilk 100-lüyündə iştirakı ilə təsdiqlənir.
Niyə maşın öyrənməsinə keçin
Bir il yarım əvvəl Google-un dərin öyrənmə əsaslı süni intellekt tədqiqat layihəsi olan Google Brain-in rəhbəri Ceff Din Google Translate-də yarım milyon sətir kodun cəmi 500 sətirdən ibarət Tensor Flow neyron şəbəkəsi ilə necə əvəz edildiyini təsvir etdi. Şəbəkənin təlimindən sonra məlumatların keyfiyyəti yüksəldi və infrastruktur sadələşdi. Deyəsən, bu bizim parlaq gələcəyimizdir: artıq kod yazmağa ehtiyacımız yoxdur, neyronlar yaratmaq və onları məlumatlarla doldurmaq kifayətdir. Ancaq praktikada hər şey daha mürəkkəbdir.
Google-da ML infrastrukturu
Neyron şəbəkələr infrastrukturun yalnız kiçik bir hissəsidir (yuxarıdakı şəkildəki kiçik qara kvadrat). Məlumatları qəbul etmək, emal etmək, saxlamaq, keyfiyyəti yoxlamaq və s. üçün daha bir çox köməkçi sistemlər tələb olunur, bizə təlim, maşın öyrənmə kodunu istehsalda yerləşdirmək və bu kodu sınaqdan keçirmək üçün infrastruktur lazımdır. Bütün bu vəzifələr tam olaraq backend tərtibatçılarının etdiklərinə bənzəyir.
Maşın öyrənmə prosesi
ML və backend arasındakı fərq nədir?
Klassik proqramlaşdırmada biz kod yazırıq və bu proqramın davranışını diktə edir. ML-də kiçik bir model kodumuz və modelə atdığımız bir çox məlumatımız var. ML-də məlumatlar çox vacibdir: fərqli məlumatlar üzərində öyrədilmiş eyni model tamamilə fərqli nəticələr göstərə bilər. Problem ondadır ki, verilənlər demək olar ki, həmişə səpələnir və müxtəlif sistemlərdə saxlanılır (relational verilənlər bazası, NoSQL verilənlər bazası, jurnallar, fayllar).
Məlumatların versiyalaşdırılması
ML klassik inkişafda olduğu kimi təkcə kodun deyil, həm də verilənlərin versiyalaşdırılmasını tələb edir: modelin nəyə öyrədildiyini aydın şəkildə başa düşmək lazımdır. Bunun üçün məşhur Data Science Version Control kitabxanasından (dvc.org) istifadə edə bilərsiniz.
Məlumat işarələməsi
Növbəti vəzifə məlumatların etiketlənməsidir. Məsələn, şəkildəki bütün obyektləri qeyd edin və ya onun hansı sinfə aid olduğunu söyləyin. Bu, Yandex.Toloka kimi xüsusi xidmətlər tərəfindən həyata keçirilir, onunla işləmək API-nin olması ilə çox sadələşdirilmişdir. Çətinliklər "insan amili" səbəbindən yaranır: eyni tapşırığı bir neçə ifaçıya həvalə etməklə məlumatların keyfiyyətini yaxşılaşdıra və səhvləri minimuma endirə bilərsiniz.
Tensor lövhəsində vizuallaşdırma
Nəticələri müqayisə etmək və bəzi ölçülərə əsaslanaraq ən yaxşı modeli seçmək üçün təcrübələrin qeydiyyatı lazımdır. Vizuallaşdırma üçün çoxlu alətlər dəsti var - məsələn, Tensor Board. Ancaq təcrübələri saxlamaq üçün ideal yollar yoxdur. Kiçik şirkətlər tez-tez Excel cədvəli ilə məşğul olur, böyük şirkətlər isə nəticələri verilənlər bazasında saxlamaq üçün xüsusi platformalardan istifadə edirlər.
Maşın öyrənməsi üçün çoxlu platformalar var, lakin onların heç biri ehtiyacların 70%-ni ödəmir
Hazırlanmış modeli istehsala qoyarkən qarşılaşmalı olduğu ilk problem data alimlərinin sevimli aləti olan Jupyter Notebook ilə bağlıdır. Bunun heç bir modulluğu yoxdur, yəni çıxış məntiqi hissələrə - modullara bölünməyən kodun belə bir "ayaq örtüyü"dür. Hər şey qarışıqdır: siniflər, funksiyalar, konfiqurasiyalar və s. Bu kodun versiyası və sınaqdan keçirilməsi çətindir.
Bununla necə məşğul olmaq olar? Netflix kimi özünüzü istefaya göndərə və bu noutbukları birbaşa istehsalda işə salmağa, məlumatları daxil olaraq onlara ötürməyə və nəticələr əldə etməyə imkan verən öz platformanızı yarada bilərsiniz. Modeli istehsala təqdim edən tərtibatçıları kodu normal şəkildə yenidən yazmağa, modullara bölməyə məcbur edə bilərsiniz. Ancaq bu yanaşma ilə səhv etmək asandır və model nəzərdə tutulduğu kimi işləməyəcək. Buna görə də ideal variant model kodu üçün Jupyter Notebook istifadəsini qadağan etməkdir. Əlbəttə ki, məlumat alimləri bununla razılaşarsa.
Qara qutu kimi model
Modeli istehsala daxil etməyin ən asan yolu onu qara qutu kimi istifadə etməkdir. Sizin bir növ model sinifiniz var, sizə modelin çəkiləri (təlim edilmiş şəbəkənin neyronlarının parametrləri) verilmişdir və bu sinfi işə salsanız (proqnozlaşdırma metodunu çağırın, ona şəkil verin) müəyyən bir nəticə əldə edəcəksiniz. çıxış kimi proqnoz. İçəridə baş verənlərin əhəmiyyəti yoxdur.
Model ilə server prosesini ayırın
Siz həmçinin müəyyən bir ayrı prosesi qaldırıb onu RPC növbəsi ilə göndərə bilərsiniz (şəkillər və ya digər mənbə məlumatları ilə. Çıxışda biz proqnozlar alacağıq.
Flask-da bir modeldən istifadə nümunəsi:
@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 yanaşma ilə bağlı problem performans məhdudiyyətidir. Deyək ki, məlumat alimləri tərəfindən yavaş yazılmış Phyton kodumuz var və biz maksimum performansı sıxmaq istəyirik. Bunu etmək üçün kodu yerli dilə çevirən və ya istehsal üçün uyğunlaşdırılmış başqa bir çərçivəyə çevirən vasitələrdən istifadə edə bilərsiniz. Hər çərçivə üçün belə alətlər var, lakin ideal olanlar yoxdur, onları özünüz əlavə etməli olacaqsınız.
ML-də infrastruktur adi backenddəki kimidir. Docker və Kubernetes var, yalnız Docker üçün NVIDIA-dan iş vaxtını quraşdırmalısınız ki, bu da konteyner daxilindəki proseslərə hostdakı video kartlara daxil olmağa imkan verir. Kubernetes video kartları olan serverləri idarə edə bilməsi üçün plaqinə ehtiyac duyur.
Klassik proqramlaşdırmadan fərqli olaraq, ML vəziyyətində infrastrukturda yoxlanılmalı və sınaqdan keçirilməli olan çoxlu müxtəlif hərəkətli elementlər var - məsələn, məlumatların işlənməsi kodu, model təlimi boru kəməri və istehsal (yuxarıdakı diaqrama baxın). Boru kəmərlərinin müxtəlif hissələrini birləşdirən kodu sınamaq vacibdir: bir çox hissə var və modul sərhədlərində problemlər çox vaxt yaranır.
AutoML necə işləyir
AutoML xidmətləri məqsədlərinizə uyğun optimal modeli seçməyi və onu öyrətməyi vəd edir. Ancaq başa düşməlisiniz: ML-də məlumatlar çox vacibdir, nəticə onun hazırlanmasından asılıdır. İşarələmə insanlar tərəfindən aparılır, bu da səhvlərlə doludur. Ciddi nəzarət olmadan nəticə zibil ola bilər və prosesi avtomatlaşdırmaq hələ mümkün deyil, mütəxəssislər - məlumat alimləri tərəfindən yoxlama lazımdır. AutoML-in dağıldığı yer budur. Lakin bu, arxitekturanın seçilməsi üçün faydalı ola bilər - siz artıq məlumatları hazırladığınız zaman və ən yaxşı modeli tapmaq üçün bir sıra təcrübələr keçirmək istədiyiniz zaman.
Maşın öyrənməsinə necə daxil olmaq olar
ML-ə daxil olmağın ən asan yolu, bütün dərin öyrənmə çərçivələrində (və adi çərçivələrdə) istifadə olunan Python-da inkişaf etməyinizdir. Bu dil bu fəaliyyət sahəsi üçün praktiki olaraq məcburidir. C++ bəzi kompüter görmə tapşırıqları üçün, məsələn, özünü idarə edən avtomobillərin idarəetmə sistemlərində istifadə olunur. JavaScript və Shell - vizuallaşdırma və brauzerdə bir neyron işləmək kimi qəribə şeylər üçün. Java və Scala Big Data ilə işləyərkən və maşın öyrənməsi üçün istifadə olunur. R və Julia riyazi statistikanı öyrənən insanlar tərəfindən sevilir.
Başlamaq üçün praktiki təcrübə əldə etməyin ən əlverişli yolu Kaggle-dadır; platformanın müsabiqələrindən birində iştirak nəzəriyyəni öyrənmək üçün bir ildən çox vaxt verir. Bu platformada siz başqasının dərc edilmiş və şərh edilmiş kodunu götürə və onu təkmilləşdirməyə, məqsədləriniz üçün optimallaşdırmağa cəhd edə bilərsiniz. Bonus - Kaggle dərəcəniz maaşınıza təsir edir.
Digər seçim isə ML komandasına backend developer kimi qoşulmaqdır. Həmkarlarınıza problemlərini həll etməkdə kömək edərək təcrübə qazana biləcəyiniz çoxlu maşın öyrənmə startapları var. Nəhayət, siz data alim icmalarından birinə - Open Data Science (ods.ai) və digərlərinə qoşula bilərsiniz.
Natiq mövzu ilə bağlı əlavə məlumatı linkdə yerləşdirib
"Quadrupel" - "Dövlət Xidmətləri" portalının ünvanlı bildirişlər xidməti
Yevgeni Smirnov
Növbəti çıxış e-hökumət infrastrukturunun inkişafı şöbəsinin müdiri Yevgeni Smirnov olub və “Dördlük” haqqında məlumat verib. Bu, Runet-də ən çox ziyarət edilən hökumət resursu olan Gosuslugi portalı (gosuslugi.ru) üçün məqsədyönlü bildiriş xidmətidir. Gündəlik auditoriya 2,6 milyondur, ümumilikdə saytda 90 milyon qeydiyyatdan keçmiş istifadəçi var, onlardan 60 milyonu təsdiqlənib. Portal API-də yük 30 min RPS-dir.
Dövlət Xidmətlərinin arxa hissəsində istifadə olunan texnologiyalar
“Quadrupel” məqsədyönlü bildiriş xidmətidir, onun köməyi ilə istifadəçi xüsusi bildiriş qaydaları quraraq onun üçün ən uyğun anda xidmət təklifi alır. Xidməti inkişaf etdirərkən əsas tələblər çevik parametrlər və poçt göndərişləri üçün adekvat vaxt idi.
Quadrupel necə işləyir?
Yuxarıdakı diaqram, sürücülük vəsiqəsinin dəyişdirilməsi zərurəti ilə bağlı vəziyyətin nümunəsindən istifadə edərək Quadrupel-in işləmə qaydalarından birini göstərir. Birincisi, xidmət müddəti bir aydan sonra bitən istifadəçiləri axtarır. Onlara müvafiq xidməti almaq təklifi olan banner göstərilir və e-poçt vasitəsilə mesaj göndərilir. Son müddəti artıq başa çatmış istifadəçilər üçün banner və e-poçt dəyişir. Uğurlu hüquq mübadiləsindən sonra istifadəçi digər bildirişlər alır - şəxsiyyətdəki məlumatları yeniləmək təklifi ilə.
Texniki nöqteyi-nəzərdən bunlar kodun yazıldığı gözəl skriptlərdir. Giriş məlumatdır, çıxış doğrudur/yalandır, uyğundur/uyğun deyil. Ümumilikdə 50-dən çox qayda var - istifadəçinin ad gününün müəyyən edilməsindən (cari tarix istifadəçinin doğum tarixinə bərabərdir) mürəkkəb vəziyyətlərə qədər. Hər gün bu qaydalar bir milyona yaxın uyğunluğu müəyyənləşdirir - xəbərdar edilməli olan insanlar.
Dördlü bildiriş kanalları
Quadrupel-in başlığı altında istifadəçi məlumatlarının saxlandığı verilənlər bazası və üç proqram var:
- Işçi məlumatların yenilənməsi üçün nəzərdə tutulub.
- İstirahət API bannerləri özləri götürüb portala və mobil proqrama çatdırır.
- Planlaşdırma bannerlərin və ya kütləvi göndərişlərin yenidən hesablanması üzrə işlərə başlayır.
Məlumatı yeniləmək üçün arxa uç hadisə ilə idarə olunur. İki interfeys - istirahət və ya JMS. Bir çox hadisələr var, yadda saxlamadan və emal etməzdən əvvəl lazımsız sorğular etməmək üçün birləşdirilir. Verilənlər bazasının özü, verilənlərin saxlandığı cədvəl, əsas dəyər anbarına bənzəyir - istifadəçinin açarı və dəyərin özü: müvafiq sənədlərin mövcudluğunu və ya olmamasını göstərən bayraqlar, onların etibarlılıq müddəti, xidmətlərin sırası ilə bağlı ümumi statistika. bu istifadəçi və s.
Məlumatları saxladıqdan sonra JMS-də bir tapşırıq qoyulur ki, bannerlər dərhal yenidən hesablansın - bu dərhal internetdə göstərilməlidir. Sistem gecə başlayır: tapşırıqlar istifadəçi intervalları ilə JMS-ə atılır, buna görə qaydaların yenidən hesablanması lazımdır. Bu, yenidən hesablamada iştirak edən prosessorlar tərəfindən götürülür. Bundan sonra, emal nəticələri növbəti növbəyə keçir, bu növbə ya bannerləri verilənlər bazasında saxlayır və ya istifadəçinin bildiriş tapşırıqlarını xidmətə göndərir. Proses 5-7 saat çəkir, hər zaman ya işləyicilər əlavə edə və ya yeni işləyicilərlə nümunələri qaldıra bildiyiniz üçün asanlıqla miqyaslanır.
Xidmət olduqca yaxşı işləyir. Lakin istifadəçilərin sayı artdıqca məlumatların həcmi artır. Bu, verilənlər bazasında yükün artmasına gətirib çıxarır - hətta Rest API-nin replikaya baxdığını nəzərə alsaq. İkinci məqam JMS-dir, məlum oldu ki, yüksək yaddaş istehlakı səbəbindən çox uyğun deyil. JMS-in sıradan çıxmasına və emalın dayandırılmasına səbəb olan növbənin daşması riski yüksəkdir. Bundan sonra logları təmizləmədən JMS-i qaldırmaq mümkün deyil.
Problemlərin verilənlər bazasına yükü balanslaşdırmağa imkan verən sharding vasitəsilə həll edilməsi planlaşdırılır. Məlumatların saxlanması sxeminin dəyişdirilməsi və JMS-in Kafkaya dəyişdirilməsi də planlaşdırılıb - yaddaş problemlərini həll edəcək daha səhvlərə dözümlü həll.
Xidmət kimi arxa uç Vs. Serversiz
Soldan sağa: Aleksandr Borqart, Andrey Tomilenko, Nikolay Markov, Ara İsraelyan
Backend xidmət və ya Serversiz həll kimi? Dəyirmi masada bu aktual məsələnin müzakirəsində iştirak edənlər:
- Ara İsrailyan, CTO CTO və Scorocode-un qurucusu.
- Nikolay Markov, Aligned Research Group-un baş məlumat mühəndisi.
- Andrey Tomilenko, RUVDS inkişaf şöbəsinin müdiri.
Söhbətə baş tərtibatçı Alexander Borgart moderatorluq etdi. Dinləyicilərin də iştirak etdiyi debatları ixtisarla təqdim edirik.
— Anlayırsınız ki, Serversiz nədir?
Andrew: Bu hesablama modelidir - nəticənin yalnız verilənlərdən asılı olması üçün məlumatları emal etməli olan Lambda funksiyasıdır. Termin ya Google, ya da Amazon və onun AWS Lambda xidmətindən gəldi. Provayderin bu funksiyanı yerinə yetirməsi onun üçün tutum ehtiyatı ayırmaqla daha asandır. Fərqli istifadəçilər eyni serverlərdə müstəqil olaraq uçota alına bilər.
Nicholas: Sadə dillə desək, biz İT infrastrukturumuzun və biznes məntiqimizin bir hissəsini buludlara, autsorsinqə köçürürük.
Macaw: Tərtibatçılar tərəfindən - resurslara qənaət etmək üçün yaxşı cəhd, marketoloqlar tərəfindən - daha çox pul qazanmaq.
— Serverless mikroservislərlə eynidirmi?
Nicholas: Xeyr, Serverless daha çox memarlıq təşkilatıdır. Mikroservis bəzi məntiqin atom vahididir. Serversiz bir yanaşmadır, "ayrı bir qurum" deyil.
Macaw: Serversiz funksiya mikroservisə paketlənə bilər, lakin bu artıq Serversiz olmayacaq, Lambda funksiyası olmaqdan çıxacaq. Serverless-də funksiya yalnız tələb olunduğu anda işə başlayır.
Andrew: Onlar həyat müddətində fərqlənirlər. Lambda funksiyasını işə saldıq və onu unutduq. O, bir neçə saniyə işlədi və növbəti müştəri öz sorğusunu başqa fiziki maşında emal edə bilər.
- Hansı tərəzi daha yaxşıdır?
Macaw: Üfüqi miqyasda, Lambda funksiyaları tam olaraq mikroservislərlə eyni davranır.
Nicholas: Təyin etdiyiniz replikaların sayı nə olursa olsun, onların çoxu olacaq; Serversizin miqyasda heç bir problemi yoxdur. Kubernetes-də bir nüsxə dəsti hazırladım, 20 nümunəni “haradasa” işə saldım və 20 anonim keçid sizə qaytarıldı. İrəli!
— Serverless-də backend yazmaq mümkündürmü?
Andrew: Nəzəri cəhətdən, lakin heç bir mənası yoxdur. Lambda funksiyaları tək repozitoriyaya güvənəcək - zəmanəti təmin etməliyik. Məsələn, əgər istifadəçi müəyyən bir əməliyyat həyata keçiribsə, növbəti dəfə əlaqə saxladıqda görməlidir: əməliyyat həyata keçirilib, vəsait daxil olub. Bütün Lambda funksiyaları bu zəngdə bloklanacaq. Əslində, bir dəstə Serversiz funksiyalar verilənlər bazasına bir darboğaz giriş nöqtəsi ilə vahid xidmətə çevriləcəkdir.
— Hansı hallarda serversiz arxitekturadan istifadə etmək məntiqlidir?
Andrew: Paylaşılan yaddaş tələb etməyən tapşırıqlar - eyni mədənçilik, blokçeyn. Harada çoxlu hesablamalar etmək lazımdır. Çox hesablama gücünüz varsa, o zaman "orada bir şeyin hashını hesablayın..." kimi bir funksiya təyin edə bilərsiniz, lakin siz, məsələn, Amazon-dan Lambda funksiyalarını və onların paylanmış yaddaşını götürərək məlumatların saxlanması ilə bağlı problemi həll edə bilərsiniz. . Və belə çıxır ki, siz adi bir xidmət yazırsınız. Lambda funksiyaları yaddaşa daxil olacaq və istifadəçiyə bir növ cavab verəcək.
Nicholas: Serverless-də işləyən konteynerlər resurslar baxımından son dərəcə məhduddur. Yaddaş azdır və başqa hər şey var. Ancaq bütün infrastrukturunuz tamamilə hansısa buludda - Google, Amazonda yerləşdirilibsə və onlarla daimi müqaviləniz varsa, bütün bunlar üçün büdcə var, o zaman bəzi tapşırıqlar üçün Serversiz konteynerlərdən istifadə edə bilərsiniz. Bu infrastrukturun içərisində olmaq lazımdır, çünki hər şey müəyyən bir mühitdə istifadə üçün hazırlanmışdır. Yəni hər şeyi bulud infrastrukturuna bağlamağa hazırsınızsa, təcrübə edə bilərsiniz. Üstünlük ondadır ki, bu infrastrukturu idarə etmək məcburiyyətində deyilsiniz.
Macaw: Serverless-in sizdən Kubernetes, Docker-i idarə etməyi, Kafkanı quraşdırmağı və sair tələb etməməsi özünü aldatmadır. Eyni Amazon və Google bunu quraşdırır. Başqa bir şey, SLA-nız olmasıdır. Özünüz kodlaşdırmaqdansa, hər şeyi kənardan əldə edə bilərsiniz.
Andrew: Serverless özü ucuzdur, lakin siz digər Amazon xidmətləri üçün çoxlu pul ödəməlisiniz - məsələn, verilənlər bazası. İnsanlar API qapısı üçün dəli miqdarda pul tələb etdikləri üçün onları artıq məhkəməyə veriblər.
Macaw: Əgər puldan danışırıqsa, onda bu məqamı nəzərə almaq lazımdır: bütün kodu Serverless-ə ötürmək üçün şirkətdəki bütün inkişaf metodologiyasını 180 dərəcə çevirməli olacaqsınız. Bu, çox vaxt və pul alacaq.
— Amazon və Google-dan ödənişli Serverless-ə layiqli alternativlər varmı?
Nicholas: Kubernetes-də siz bir növ işə başlayırsınız, o işləyir və ölür - bu, memarlıq baxımından tamamilə Serversizdir. Əgər növbələr və verilənlər bazası ilə həqiqətən maraqlı biznes məntiqi yaratmaq istəyirsinizsə, o zaman bu barədə bir az daha düşünməlisiniz. Bütün bunlar Kubernetesdən ayrılmadan həll edilə bilər. Mən əlavə tətbiqi sürükləməkdən narahat olmazdım.
— Serverless-də baş verənləri izləmək nə dərəcədə vacibdir?
Macaw: Sistem arxitekturasından və biznes tələblərindən asılıdır. Əslində, provayder devops komandasına mümkün problemləri başa düşməyə kömək edəcək hesabat təqdim etməlidir.
Nicholas: Amazon-da Lambda-dan olanlar da daxil olmaqla bütün qeydlərin yayımlandığı CloudWatch var. Qeydlərin yönləndirilməsini inteqrasiya edin və baxmaq, xəbərdarlıq etmək və s. üçün ayrıca alətdən istifadə edin. Başladığınız qablara agentləri doldura bilərsiniz.
- Gəlin yekunlaşdıraq.
Andrew: Lambda funksiyaları haqqında düşünmək faydalıdır. Özünüz bir xidmət yaratsanız - mikroservis deyil, sorğu yazan, verilənlər bazasına daxil olan və cavab göndərən xidmətdir - Lambda funksiyası bir sıra problemləri həll edir: çoxillik, genişlənmə və s. Əgər məntiqiniz bu şəkildə qurulubsa, gələcəkdə siz bu Lambdaları mikroservislərə köçürə və ya Amazon kimi üçüncü tərəf xidmətlərindən istifadə edə biləcəksiniz. Texnologiya faydalıdır, ideya maraqlıdır. Bunun biznes üçün nə dərəcədə əsaslı olması hələ də açıq sualdır.
Nikolay: Serversiz bəzi iş məntiqini hesablamaqdansa əməliyyat tapşırıqları üçün daha yaxşı istifadə olunur. Mən həmişə bunu hadisənin işlənməsi kimi düşünürəm. Amazonda varsa, Kubernetesdəsinizsə, bəli. Əks halda, Serverless-i təkbaşına işə salmaq üçün çox səy göstərməli olacaqsınız. Konkret bir iş vəziyyətinə baxmaq lazımdır. Məsələn, indi mənim tapşırıqlarımdan biri belədir: fayllar diskdə müəyyən formatda görünəndə onları Kafkaya yükləməliyəm. Mən WatchDog və ya Lambda istifadə edə bilərəm. Məntiqi nöqteyi-nəzərdən hər iki variant uyğundur, lakin həyata keçirilməsi baxımından Serversiz daha mürəkkəbdir və mən Lambdasız daha sadə üsula üstünlük verirəm.
Macaw: Serversiz maraqlı, tətbiq oluna bilən və texniki cəhətdən çox gözəl bir fikirdir. Gec-tez texnologiya o yerə çatacaq ki, hər hansı funksiya 100 millisaniyədən az müddətdə işə salınacaq. Onda, prinsipcə, gözləmə müddətinin istifadəçi üçün kritik olub-olmaması sualı olmayacaq. Eyni zamanda, Serverless-in tətbiqi, həmkarların artıq dediyi kimi, tamamilə biznes problemindən asılıdır.
Bizə çox kömək edən sponsorlarımıza təşəkkür edirik:
- İT konfrans sahəsi «» konfrans saytı üçün.
- İT tədbirlərinin təqvimi və nəşri"» məlumat dəstəyi və xəbərlər üçün.
- «"hədiyyələr üçün.
- birgə yaradıcılıq üçün.
- "Elektron Rabitə Assosiasiyası" iştirak və təcrübə üçün.
- Baş sponsor - hamı üçün!
Mənbə: www.habr.com