Backend، یادگیری ماشین و بدون سرور - جالب ترین چیزهای کنفرانس جولای هابر

کنفرانس هابر یک داستان اولیه نیست. قبلاً رویدادهای نسبتاً بزرگ توستر را برای 300-400 نفر برگزار می کردیم ، اما اکنون تصمیم گرفتیم که جلسات موضوعی کوچکی مرتبط باشد که جهت آن را می توانید مثلاً در نظرات تعیین کنید. اولین کنفرانس این فرمت در ماه جولای برگزار شد و به توسعه باطن اختصاص داشت. شرکت کنندگان به گزارش هایی در مورد ویژگی های انتقال از باطن به ML و در مورد طراحی سرویس Quadrupel در پورتال خدمات دولتی گوش دادند و همچنین در یک میز گرد که به سرور بدون سرور اختصاص داشت شرکت کردند. برای کسانی که نتوانستند حضوری در این مراسم شرکت کنند، در این پست جالب ترین چیزها را به شما می گوییم.

از توسعه Backend تا یادگیری ماشین

مهندسان داده در ML چه می کنند؟ چگونه وظایف یک توسعه دهنده باطن و یک مهندس ML مشابه و متفاوت است؟ چه مسیری را باید طی کنید تا شغل اول خود را به شغل دوم تغییر دهید؟ این را الکساندر پارینوف گفت که پس از 10 سال کار با سیستم، وارد یادگیری ماشینی شد.

الکساندر پارینوف

امروزه الکساندر به عنوان معمار سیستم های بینایی کامپیوتری در گروه خرده فروشی X5 کار می کند و در پروژه های منبع باز مرتبط با بینایی کامپیوتر و یادگیری عمیق مشارکت می کند (github.com/creafz). مهارت های او با حضور او در 100 رتبه برتر جهانی Kaggle Master (kaggle.com/creafz)، محبوب ترین پلتفرم مسابقات یادگیری ماشین تایید می شود.

چرا به یادگیری ماشین تغییر دهید؟

یک سال و نیم پیش، جف دین، رئیس Google Brain، پروژه تحقیقاتی هوش مصنوعی مبتنی بر یادگیری عمیق گوگل، توضیح داد که چگونه نیم میلیون خط کد در Google Translate با شبکه عصبی Tensor Flow که تنها از 500 خط تشکیل شده بود، جایگزین شد. پس از آموزش شبکه، کیفیت داده ها افزایش یافت و زیرساخت ساده تر شد. به نظر می رسد که این آینده روشن ما است: ما دیگر نیازی به نوشتن کد نداریم، کافی است نورون ها را بسازیم و آنها را با داده پر کنیم. اما در عمل همه چیز بسیار پیچیده تر است.

زیرساخت ML در گوگل

شبکه های عصبی تنها بخش کوچکی از زیرساخت هستند (مربع سیاه کوچک در تصویر بالا). برای دریافت داده‌ها، پردازش، ذخیره‌سازی، بررسی کیفیت و غیره به سیستم‌های کمکی زیادی نیاز است، ما به زیرساخت‌هایی برای آموزش، استقرار کد یادگیری ماشین در تولید و آزمایش این کد نیاز داریم. همه این وظایف دقیقا شبیه به کاری است که توسعه دهندگان باطن انجام می دهند.

فرآیند یادگیری ماشینی

تفاوت بین ML و Backend چیست؟

در برنامه نویسی کلاسیک ما کد می نویسیم و این رفتار برنامه را دیکته می کند. در ML، ما یک کد مدل کوچک و داده های زیادی داریم که به مدل پرتاب می کنیم. داده ها در ML بسیار مهم است: یک مدل آموزش داده شده بر روی داده های مختلف می تواند نتایج کاملا متفاوتی را نشان دهد. مشکل این است که داده ها تقریباً همیشه در سیستم های مختلف (پایگاه های اطلاعاتی رابطه ای، پایگاه های داده NoSQL، گزارش ها، فایل ها) پراکنده و ذخیره می شوند.

نسخه سازی داده ها

ML نه تنها به نسخه‌سازی کد، مانند توسعه کلاسیک، بلکه به داده‌ها نیز نیاز دارد: باید به وضوح درک کرد که مدل بر روی چه چیزی آموزش داده شده است. برای انجام این کار، می توانید از کتابخانه محبوب Data Science Version Control (dvc.org) استفاده کنید.

نشانه گذاری داده ها

وظیفه بعدی برچسب گذاری داده ها است. به عنوان مثال، تمام اشیاء موجود در تصویر را علامت گذاری کنید یا بگویید متعلق به کدام کلاس است. این کار توسط سرویس های ویژه ای مانند Yandex.Toloka انجام می شود، که کار با آن با وجود یک API بسیار ساده شده است. مشکلات ناشی از "عامل انسانی" است: شما می توانید کیفیت داده ها را بهبود بخشید و با سپردن یک کار به چندین مجری، خطاها را به حداقل برسانید.

تجسم در تابلو تنسور

ثبت آزمایشات برای مقایسه نتایج و انتخاب بهترین مدل بر اساس برخی معیارها ضروری است. مجموعه بزرگی از ابزارها برای تجسم وجود دارد - به عنوان مثال، Tensor Board. اما هیچ راه ایده آلی برای ذخیره آزمایش ها وجود ندارد. شرکت‌های کوچک اغلب به صفحه‌گسترده اکسل بسنده می‌کنند، در حالی که شرکت‌های بزرگ از پلت‌فرم‌های خاصی برای ذخیره نتایج در پایگاه داده استفاده می‌کنند.

پلتفرم های زیادی برای یادگیری ماشین وجود دارد، اما هیچ کدام 70 درصد نیازها را پوشش نمی دهند

اولین مشکلی که هنگام تولید یک مدل آموزش دیده باید با آن مواجه شود مربوط به ابزار مورد علاقه دانشمندان داده - Jupyter Notebook است. هیچ مدولاریتی در آن وجود ندارد، یعنی خروجی آنچنان "دستمال پا" از کد است که به قطعات منطقی - ماژول ها تقسیم نمی شود. همه چیز قاطی شده است: کلاس ها، توابع، تنظیمات، و غیره. نسخه و آزمایش این کد دشوار است.

با این چگونه روبرو میشوید؟ شما می‌توانید مانند نتفلیکس استعفا دهید و پلتفرم خود را ایجاد کنید که به شما امکان می‌دهد این لپ‌تاپ‌ها را مستقیماً در مرحله تولید راه‌اندازی کنید، داده‌ها را به عنوان ورودی به آنها منتقل کنید و نتیجه بگیرید. می توانید توسعه دهندگانی را که در حال تولید مدل هستند مجبور کنید کد را به طور معمول بازنویسی کنند و آن را به ماژول ها تقسیم کنند. اما با این رویکرد اشتباه کردن آسان است و مدل آنطور که در نظر گرفته شده کار نخواهد کرد. بنابراین، گزینه ایده آل ممنوعیت استفاده از نوت بوک Jupyter برای کد مدل است. البته اگر دانشمندان داده با این موافق باشند.

مدل جعبه سیاه

ساده ترین راه برای تولید یک مدل، استفاده از آن به عنوان جعبه سیاه است. شما نوعی کلاس مدل دارید، وزن های مدل به شما داده شده است (پارامترهای نورون های شبکه آموزش دیده) و اگر این کلاس را مقداردهی اولیه کنید (متد پیش بینی را فراخوانی کنید، تصویری را به آن بدهید)، یک مقدار مشخص به دست خواهید آورد. پیش بینی به عنوان یک خروجی آنچه در داخل اتفاق می افتد مهم نیست.

فرآیند سرور جدا با مدل

شما همچنین می توانید یک فرآیند جداگانه را افزایش دهید و آن را از طریق یک صف RPC (با تصاویر یا سایر داده های منبع. در خروجی ما پیش بینی ها را دریافت خواهیم کرد) ارسال کنید.

نمونه ای از استفاده از یک مدل در Flask:

@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)

مشکل این رویکرد محدودیت عملکرد است. فرض کنید کد Phyton را داریم که توسط دانشمندان داده نوشته شده است که کند است و می‌خواهیم حداکثر عملکرد را کاهش دهیم. برای انجام این کار، می توانید از ابزارهایی استفاده کنید که کد را به بومی تبدیل می کند یا آن را به فریمورک دیگری که برای تولید طراحی شده است، تبدیل می کند. چنین ابزارهایی برای هر چارچوبی وجود دارد، اما هیچ ابزار ایده آلی وجود ندارد؛ شما باید خودتان آنها را اضافه کنید.

زیرساخت در ML مانند یک باطن معمولی است. Docker و Kubernetes وجود دارند، فقط برای Docker باید زمان اجرا را از NVIDIA نصب کنید، که به فرآیندهای داخل کانتینر اجازه می‌دهد به کارت‌های ویدیویی در میزبان دسترسی داشته باشند. Kubernetes به یک پلاگین نیاز دارد تا بتواند سرورها را با کارت های ویدئویی مدیریت کند.

برخلاف برنامه نویسی کلاسیک، در مورد ML عناصر متحرک زیادی در زیرساخت وجود دارد که باید بررسی و آزمایش شوند - به عنوان مثال، کد پردازش داده، خط لوله آموزش مدل و تولید (نمودار بالا را ببینید). آزمایش کدی که قطعات مختلف خطوط لوله را به هم وصل می کند بسیار مهم است: قطعات زیادی وجود دارد و مشکلات اغلب در مرزهای ماژول ایجاد می شود.

AutoML چگونه کار می کند

خدمات AutoML وعده انتخاب مدل بهینه برای اهداف شما و آموزش آن را می دهد. اما باید درک کنید: داده ها در ML بسیار مهم هستند، نتیجه به آماده سازی آن بستگی دارد. نشانه گذاری توسط افراد انجام می شود که مملو از خطا است. بدون کنترل دقیق، نتیجه ممکن است زباله باشد، و هنوز امکان خودکارسازی فرآیند وجود ندارد؛ تأیید توسط متخصصان - دانشمندان داده - مورد نیاز است. اینجاست که AutoML خراب می شود. اما می تواند برای انتخاب یک معماری مفید باشد - زمانی که داده ها را از قبل آماده کرده اید و می خواهید یک سری آزمایش برای پیدا کردن بهترین مدل انجام دهید.

چگونه وارد یادگیری ماشین شویم

ساده ترین راه برای ورود به ML این است که در پایتون توسعه دهید، که در تمام چارچوب های یادگیری عمیق (و فریمورک های معمولی) استفاده می شود. این زبان عملا برای این زمینه فعالیت اجباری است. C++ برای برخی از وظایف بینایی کامپیوتری، به عنوان مثال، در سیستم های کنترل خودروهای خودران استفاده می شود. جاوا اسکریپت و شل - برای تجسم و موارد عجیبی مانند اجرای یک نورون در مرورگر. جاوا و اسکالا هنگام کار با داده های بزرگ و برای یادگیری ماشین استفاده می شوند. R و جولیا توسط افرادی که آمار ریاضی مطالعه می کنند دوست دارند.

راحت ترین راه برای کسب تجربه عملی برای شروع، در Kaggle است؛ شرکت در یکی از مسابقات پلت فرم بیش از یک سال مطالعه تئوری را به همراه دارد. در این پلتفرم می توانید کد ارسال شده و نظر دیگران را بگیرید و سعی کنید آن را بهبود ببخشید، آن را برای اهداف خود بهینه کنید. پاداش - رتبه Kaggle شما بر حقوق شما تأثیر می گذارد.

گزینه دیگر پیوستن به تیم ML به عنوان یک توسعه دهنده باطن است. بسیاری از استارت‌آپ‌های یادگیری ماشینی وجود دارند که می‌توانید با کمک به همکاران خود در حل مشکلاتشان، تجربه کسب کنید. در نهایت، می‌توانید به یکی از انجمن‌های دانشمندان داده بپیوندید - Open Data Science (ods.ai) و دیگران.

سخنران اطلاعات تکمیلی در مورد موضوع را در لینک ارسال کرد https://bit.ly/backend-to-ml

"Quadrupel" - خدمات اعلان های هدفمند پورتال "خدمات دولتی"

اوگنی اسمیرنوف

سخنران بعدی، رئیس بخش توسعه زیرساخت های دولت الکترونیک، اوگنی اسمیرنوف بود که در مورد Quadruple صحبت کرد. این یک سرویس اطلاع رسانی هدفمند برای پورتال Gosuslugi (gosuslugi.ru)، پربازدیدترین منبع دولتی در Runet است. تعداد مخاطبان روزانه 2,6 میلیون نفر است، در مجموع 90 میلیون کاربر ثبت نام شده در سایت وجود دارد که 60 میلیون نفر تایید شده اند. بار روی API پورتال 30 هزار RPS است.

فن آوری های مورد استفاده در بخش خدمات دولتی

"Quadrupel" یک سرویس اطلاع رسانی هدفمند است که به کمک آن کاربر با تنظیم قوانین اعلان ویژه، پیشنهاد یک سرویس را در مناسب ترین لحظه برای خود دریافت می کند. ملزومات اصلی در هنگام توسعه این سرویس تنظیمات انعطاف پذیر و زمان کافی برای ارسال بود.

Quadrupel چگونه کار می کند؟

نمودار بالا یکی از قوانین عملکرد کوادروپل را با استفاده از مثال وضعیتی با نیاز به تعویض گواهینامه رانندگی نشان می دهد. ابتدا این سرویس به دنبال کاربرانی می گردد که تاریخ انقضای آنها یک ماه دیگر به پایان می رسد. بنری با پیشنهاد دریافت خدمات مناسب به آنها نشان داده می شود و پیامی از طریق ایمیل ارسال می شود. برای آن دسته از کاربرانی که مهلت آنها قبلاً به پایان رسیده است، بنر و ایمیل تغییر می کند. پس از تبادل موفقیت آمیز حقوق، کاربر اعلان های دیگری را دریافت می کند - با پیشنهاد به روز رسانی داده ها در هویت.

از نقطه نظر فنی، اینها اسکریپت های groovy هستند که کد در آنها نوشته شده است. ورودی داده است، خروجی درست/نادرست، مطابقت دارد/منطبق نیست. در کل بیش از 50 قانون وجود دارد - از تعیین تاریخ تولد کاربر (تاریخ فعلی برابر با تاریخ تولد کاربر است) تا موقعیت های پیچیده. هر روز، این قوانین حدود یک میلیون مسابقه را شناسایی می کند - افرادی که باید به آنها اطلاع داده شود.

کانال های اطلاع رسانی چهارگانه

در زیر کاپوت Quadrupel یک پایگاه داده وجود دارد که اطلاعات کاربر در آن ذخیره می شود و سه برنامه کاربردی: 

• کارگر برای به روز رسانی داده ها در نظر گرفته شده است.
• استراحت API خود بنرها را برمی دارد و به پورتال و اپلیکیشن موبایل تحویل می دهد.
• زمان بند کار بر روی محاسبه مجدد بنرها یا ارسال های انبوه را راه اندازی می کند.

برای به روز رسانی داده ها، backend مبتنی بر رویداد است. دو رابط - استراحت یا JMS. رویدادهای زیادی وجود دارد؛ قبل از ذخیره و پردازش، آنها را جمع آوری می کنند تا درخواست های غیر ضروری نداشته باشند. خود پایگاه داده، جدولی که داده ها در آن ذخیره می شوند، مانند یک ذخیره ارزش کلیدی به نظر می رسد - کلید کاربر و خود مقدار: پرچم هایی که وجود یا عدم وجود اسناد مربوطه را نشان می دهد، مدت اعتبار آنها، آمار جمع آوری شده در مورد ترتیب خدمات توسط این کاربر و غیره

پس از ذخیره داده ها، وظیفه ای در JMS تنظیم می شود تا بنرها بلافاصله دوباره محاسبه شوند - این باید بلافاصله در وب نمایش داده شود. سیستم در شب شروع می شود: وظایف در فواصل زمانی کاربر به JMS پرتاب می شود که طبق آن قوانین باید دوباره محاسبه شوند. این توسط پردازنده های درگیر در محاسبه مجدد برداشت می شود. سپس، نتایج پردازش به صف بعدی می‌رود، که یا بنرها را در پایگاه داده ذخیره می‌کند یا وظایف اعلان کاربر را به سرویس ارسال می‌کند. این فرآیند 5-7 ساعت طول می کشد، به راحتی مقیاس پذیر است، زیرا همیشه می توانید کنترل کننده ها را اضافه کنید یا نمونه هایی را با کنترل کننده های جدید افزایش دهید.

سرویس کاملاً خوب کار می کند. اما حجم داده ها با تعداد کاربران بیشتر در حال افزایش است. این منجر به افزایش بار در پایگاه داده می شود - حتی با در نظر گرفتن این واقعیت که Rest API به ماکت نگاه می کند. نکته دوم JMS است که همانطور که مشخص شد به دلیل مصرف بالای حافظه چندان مناسب نیست. خطر بالای سرریز صف وجود دارد که باعث از کار افتادن JMS و توقف پردازش می شود. افزایش JMS بعد از این بدون پاک کردن گزارش ها غیرممکن است.

برنامه ریزی شده است که مشکلات را با استفاده از شاردینگ حل کند، که به تعادل بار در پایگاه داده اجازه می دهد. همچنین برنامه‌هایی برای تغییر طرح ذخیره‌سازی داده‌ها و تغییر JMS به Kafka وجود دارد - راه‌حلی با تحمل خطا بیشتر که مشکلات حافظه را حل می‌کند.

Backend-as-a-Service در مقابل. بدون سرور

از چپ به راست: الکساندر بورگارت، آندری تومیلنکو، نیکولای مارکوف، آرا اسرائیلیان

Backend به عنوان یک سرویس یا راه حل بدون سرور؟ شرکت کنندگان در بحث درباره این موضوع مبرم در میزگرد عبارت بودند از:

• آرا اسرائیلیان، CTO CTO و بنیانگذار Scorocode.
• نیکولای مارکوف، مهندس ارشد داده در گروه تحقیقاتی Aligned.
• آندری تومیلنکو، رئیس بخش توسعه RUVDS. 

گفتگو توسط الکساندر بورگارت توسعه دهنده ارشد مدیریت شد. مناظره هایی را که شنوندگان نیز در آن شرکت داشتند به صورت اختصاری ارائه می کنیم.

- بدون سرور در درک شما چیست؟

اندرو: این یک مدل محاسباتی است - یک تابع Lambda که باید داده ها را پردازش کند تا نتیجه فقط به داده ها بستگی داشته باشد. این اصطلاح یا از گوگل یا از آمازون و سرویس AWS Lambda آن آمده است. برای یک ارائه دهنده راحت تر است که چنین عملکردی را با تخصیص ظرفیت برای آن مدیریت کند. کاربران مختلف را می توان به طور مستقل در سرورهای یکسان به حساب آورد.
نیکلاس: به بیان ساده، ما بخشی از زیرساخت فناوری اطلاعات و منطق تجاری خود را به ابر، به برون سپاری منتقل می کنیم.
آرا: از سوی توسعه دهندگان - تلاش خوبی برای صرفه جویی در منابع، از طرف بازاریابان - برای کسب درآمد بیشتر.

- آیا سرور بدون سرور همان میکروسرویس است؟

نیکلاس: نه، سرور بدون سرور بیشتر یک سازمان معماری است. یک میکروسرویس یک واحد اتمی منطقی است. بدون سرور یک رویکرد است، نه یک "موجود جداگانه".
آرا: یک تابع بدون سرور را می توان در یک میکروسرویس بسته بندی کرد، اما این تابع دیگر بدون سرور نخواهد بود، بلکه تابع Lambda نیست. در سرور بدون سرور، یک تابع تنها زمانی شروع به کار می کند که درخواست شود.
اندرو: در طول عمر با هم فرق دارند. ما تابع Lambda را راه اندازی کردیم و آن را فراموش کردیم. برای چند ثانیه کار کرد و مشتری بعدی می‌تواند درخواست خود را روی یک ماشین فیزیکی دیگر پردازش کند.

- کدام ترازو بهتر است؟

آرا: هنگام مقیاس بندی افقی، عملکردهای لامبدا دقیقاً مانند میکروسرویس ها عمل می کنند.
نیکلاس: هر تعداد کپی که تنظیم کنید، تعداد آنها به تعداد زیاد خواهد بود؛ بدون سرور مشکلی در مقیاس بندی ندارد. من یک مجموعه ماکت در Kubernetes ساختم، 20 نمونه را "در جایی" راه اندازی کردم، و 20 پیوند ناشناس به شما بازگردانده شد. رو به جلو!

- آیا امکان نوشتن یک Backend در سرور بدون سرور وجود دارد؟

اندرو: از نظر تئوری، اما معنی ندارد. توابع لامبدا به یک مخزن تکی خواهند داشت - ما باید تضمین کنیم. به عنوان مثال، اگر کاربر تراکنش خاصی را انجام داده باشد، دفعه بعد که تماس می گیرد باید ببیند: تراکنش انجام شده است، وجوه اعتبار شده است. همه توابع Lambda در این تماس مسدود خواهند شد. در واقع، دسته ای از توابع بدون سرور به یک سرویس واحد با یک نقطه دسترسی تنگنا به پایگاه داده تبدیل می شوند.

- در چه شرایطی استفاده از معماری بدون سرور منطقی است؟

اندرو: وظایفی که به ذخیره سازی مشترک نیاز ندارند - همان استخراج، بلاک چین. جایی که باید شمارش زیادی انجام دهید. اگر قدرت محاسباتی زیادی دارید، می توانید تابعی مانند "محاسبه هش چیزی در آنجا..." تعریف کنید، اما می توانید مشکل ذخیره سازی داده را با استفاده از توابع Lambda از آمازون و ذخیره سازی توزیع شده آنها حل کنید. . و معلوم می شود که شما در حال نوشتن یک سرویس معمولی هستید. توابع لامبدا به فضای ذخیره سازی دسترسی خواهند داشت و نوعی پاسخ را به کاربر ارائه می دهند.
نیکلاس: کانتینرهایی که در سرور بدون سرور اجرا می شوند، منابع بسیار محدودی دارند. حافظه کم است و هر چیز دیگری. اما اگر کل زیرساخت شما به طور کامل بر روی برخی از ابرها - گوگل، آمازون - مستقر شده باشد و با آنها قرارداد دائمی داشته باشید، بودجه ای برای همه اینها وجود دارد، پس برای برخی کارها می توانید از کانتینرهای بدون سرور استفاده کنید. حضور در این زیرساخت ضروری است، زیرا همه چیز برای استفاده در یک محیط خاص طراحی شده است. یعنی اگر آماده اید همه چیز را به زیرساخت ابری گره بزنید، می توانید آزمایش کنید. مزیت این است که شما مجبور نیستید این زیرساخت را مدیریت کنید.
آرا: این واقعیت که سرور بدون نیاز به مدیریت Kubernetes، Docker، نصب Kafka و غیره از شما نیست خودفریبی است. همون آمازون و گوگل دارن اینو نصب میکنن. نکته دیگر این است که شما یک SLA دارید. ممکن است به جای اینکه خودتان آن را کدنویسی کنید، همه چیز را برون سپاری کنید.
اندرو: خود بدون سرور ارزان است، اما برای سایر خدمات آمازون - به عنوان مثال، پایگاه داده، باید هزینه زیادی بپردازید. مردم قبلاً از آنها شکایت کرده اند زیرا آنها مبالغ دیوانه کننده ای برای دروازه API دریافت کرده اند.
آرا: اگر در مورد پول صحبت می کنیم، پس باید این نکته را در نظر بگیرید: برای انتقال همه کدها به سرور بدون سرور، باید کل روش توسعه در شرکت را 180 درجه بچرخانید. این کار زمان و هزینه زیادی را می طلبد.

- آیا هیچ جایگزین شایسته ای برای سرورهای پولی از آمازون و گوگل وجود دارد؟

نیکلاس: در Kubernetes شما نوعی کار را راه‌اندازی می‌کنید، اجرا می‌شود و می‌میرد - این از نقطه نظر معماری کاملاً بدون سرور است. اگر می‌خواهید با صف‌ها و پایگاه‌های اطلاعاتی منطق تجاری جالبی ایجاد کنید، باید کمی بیشتر در مورد آن فکر کنید. همه اینها بدون خروج از Kubernetes قابل حل است. من حوصله طولانی کردن اجرای اضافی را ندارم.

- نظارت بر آنچه در سرور بدون سرور اتفاق می افتد چقدر مهم است؟

آرا: به معماری سیستم و الزامات تجاری بستگی دارد. اساساً، ارائه‌دهنده باید گزارش‌هایی ارائه کند که به تیم توسعه‌دهنده کمک کند تا مشکلات احتمالی را درک کند.
نیکلاس: آمازون دارای CloudWatch است، جایی که همه گزارش‌ها، از جمله گزارش‌های Lambda، در آن پخش می‌شوند. ارسال گزارش را یکپارچه کنید و از یک ابزار جداگانه برای مشاهده، هشدار و غیره استفاده کنید. می توانید عوامل را در ظرف هایی که شروع می کنید قرار دهید.

- بیایید خلاصه کنیم.

اندرو: فکر کردن در مورد توابع Lambda مفید است. اگر به تنهایی یک سرویس ایجاد کنید - نه یک میکروسرویس، بلکه سرویسی که درخواستی بنویسد، به پایگاه داده دسترسی پیدا کند و پاسخی ارسال کند - تابع Lambda تعدادی از مشکلات را حل می کند: با چند رشته، مقیاس پذیری و غیره. اگر منطق شما به این شکل ساخته شده باشد، در آینده می توانید این لامبداها را به میکروسرویس ها منتقل کنید یا از خدمات شخص ثالث مانند آمازون استفاده کنید. فناوری مفید است، ایده جالب است. اینکه چقدر برای تجارت توجیه می شود هنوز یک سوال باز است.
نیکولای: بدون سرور برای کارهای عملیاتی بهتر از محاسبه منطق تجاری استفاده می شود. من همیشه به آن به عنوان پردازش رویداد فکر می کنم. اگر آن را در آمازون دارید، اگر در Kubernetes هستید، بله. در غیر این صورت، باید تلاش زیادی را برای راه اندازی و راه اندازی بدون سرور به تنهایی انجام دهید. نگاهی به یک مورد خاص تجاری ضروری است. به عنوان مثال، یکی از وظایف من در حال حاضر این است: وقتی فایل ها با فرمت خاصی روی دیسک ظاهر می شوند، باید آنها را در کافکا آپلود کنم. من می توانم از WatchDog یا Lambda استفاده کنم. از نظر منطقی هر دو گزینه مناسب هستند اما از نظر پیاده سازی سرور بدون سرور پیچیده تر است و من راه ساده تر را بدون لامبدا ترجیح می دهم.
آرا: بدون سرور ایده جالب، کاربردی و از نظر فنی بسیار زیبایی است. دیر یا زود، فناوری به نقطه ای می رسد که هر عملکردی در کمتر از 100 میلی ثانیه راه اندازی می شود. سپس، در اصل، هیچ سوالی وجود نخواهد داشت که آیا زمان انتظار برای کاربر حیاتی است یا خیر. در عین حال، کاربردی بودن سرور بدون سرور، همانطور که همکاران قبلاً گفته اند، کاملاً به مشکل تجاری بستگی دارد.

ما از حامیان مالی خود که بسیار به ما کمک کردند تشکر می کنیم:

• فضای کنفرانس فناوری اطلاعات «بهار» برای سایت کنفرانس.
• تقویم رویدادهای فناوری اطلاعات Runet-ID و انتشار"اینترنت به تعداد» برای پشتیبانی اطلاعات و اخبار.
• «آکرونیس"برای هدیه
• آویوتیو برای خلق مشترک
• "انجمن ارتباطات الکترونیک" RAEC برای مشارکت و تجربه
• حامی اصلی RUVDS - برای همه!

منبع: www.habr.com