Summarize this content to 400 words in Persian Lang
در طول دو دهه گذشته، روندهای زیرساختی مختلفی ظهور کرده و هر چند سال یک بار با موارد جدید جایگزین شده است. در ابتدا، ما به سرورهای فلزی خالی که در زیرزمین‌های شرکت قرار داشتند، تکیه کردیم و از ما می‌خواستند سخت‌افزار بخریم، دیسک‌های سخت خراب را جایگزین کنیم، و قطع برق را مدیریت کنیم. با ظهور مجازی سازی و ارائه دهندگان ابر، ما تمرکز خود را در درجه اول به مدیریت نرم افزار معطوف کردیم، اگرچه هنوز مجبور بودیم سیستم عامل ها را اصلاح کنیم. کانتینرها تعمیر و نگهداری را بیشتر کاهش دادند و مقیاس پذیری را افزایش دادند، اما ما مسئول مدیریت محیط زمان اجرا باقی ماندیم. رویکرد بدون سرور این را یک گام فراتر برداشته است و به ما اجازه می‌دهد تا تنها بر روی کد برنامه و وابستگی‌های خود تمرکز کنیم، در حالی که ارائه‌دهنده ابر بقیه موارد را مدیریت می‌کند.
AWS Lambda 10 ساله می شود
در re:Invent 2014، AWS لامبدا را معرفی کرد که نشانگر آغاز پارادایم زیرساخت بدون سرور بود. در حالی که بسیاری از سرویس‌های AWS، مانند SQS و S3، از ابتدا بدون سرور بودند، لامبدا این تغییر معماری را تسریع کرد و اصطلاح «بدون سرور» را رایج کرد. در طول دهه گذشته، اکوسیستم به طور قابل توجهی بالغ شده و به جریان اصلی تبدیل شده است. استارت آپ های جدید، از جمله ما، با افتخار تمام زیرساخت های خود را بر روی اجزای بدون سرور ایجاد می کنند.
یک دهه در فناوری زمان طولانی است و نوآوری بی وقفه است. ظهور یک روند جدید اجتناب ناپذیر بود و به نظر من این طور شده است. ما فقط یک کلمه کلیدی برای آن نداریم. قبل از شروع به حدس و گمان در مورد آنچه بعد از بدون سرور می آید، بیایید در مورد اینکه برنامه مدرنی که در AWS اجرا می شود در سال 2024 چگونه به نظر می رسد، بحث کنیم.
پشته برنامه مدرن
از منظر ساده شده، اکثر برنامه های کاربردی وب و موبایل شباهت های اساسی در باطن دارند. آنها معمولاً احراز هویت را ارائه می کنند، اشکال مختلف ورودی کاربر را می پذیرند، آن اطلاعات را از طریق API ها ارسال می کنند و در یک پایگاه داده ذخیره می کنند. سپس این داده ها تبدیل یا تجمیع می شوند و به کاربر ارائه می شوند.
این الگو در تجارت الکترونیک، سیستم های CRM، بانکداری اینترنتی، حسابداری و بسیاری از کاربردهای دیگر مشهود است. با وجود این مشترکات، هر نرم افزار دارای ویژگی های منحصر به فردی است که برای کاربران ارزش افزوده ایجاد می کند. علاوه بر این، عناصری مانند مدل‌های یادگیری ماشین، ادغام با سایر سیستم‌ها و تراکنش‌های ارزهای دیجیتال ارزش برنامه‌های مدرن را بیشتر می‌کنند. با این حال، بدون اجزای اصلی ورودی کاربر، APIها و پایگاه‌های داده، این برنامه‌ها تا حد زیادی ناکارآمد خواهند بود.
هنگام ساخت یک برنامه جدید، ممکن است از لامبدا برای میکروسرویس های رویداد محور (EDA) خود (Authenticator، API، Notifier، …) استفاده کنید. در ترکیب با DynamoDB، این انتخاب ها برای یک سیستم مبتنی بر ابر مدرن جریان اصلی و ایمن هستند.
اما اگر جایگزینی وجود داشته باشد چه؟
جایگزین های لامبدا
خوشبختانه، ما دیگر نیازی به توسعه همه این میکروسرویس ها نداریم زیرا AWS راه حل های بدون سرور را برای بسیاری از سناریوهای رایج ارائه می دهد:
Authenticator – شناخته شده است
API – API Gateway، AppSync
میزبانی استاتیک – S3 + CloudFront
مشاغل Async – StepFunctions
پایگاه داده – DynamoDB
…
ایجاد این خدمات به صورت مستقل می تواند به راحتی بیش از 50 درصد از زمان پروژه شما را مصرف کند. این تلاش، که به عنوان “بالا بردن سنگین غیرمتمایز” شناخته می شود، ضروری است اما برنامه شما را از رقبا متمایز نمی کند. استفاده از خدمات موجود به شما این امکان را می دهد که منابع را روی مناطقی متمرکز کنید که برنامه شما ارزش منحصر به فردی دارد.
مورد استفاده واقعی برنامه
برنامه‌ای واقعاً بدون سرور را تصور کنید که صرفاً با یکپارچه‌سازی سرویس‌های AWS موجود ساخته شده است، حتی تا آنجا پیش می‌رود که یک تابع Lambda را حذف می‌کند. من با «واقعاً بدون سرور» به مانیفست اصلی بدون سرور اشاره می‌کنم که از انعطاف‌پذیری، قیمت‌گذاری پرداخت به ازای استفاده، توانایی مقیاس‌سازی به صفر و موارد دیگر حمایت می‌کند.
فرقی نمی‌کند REST API یا GraphQL را انتخاب کنید، تغییرات معماری ممکن است کمی متفاوت باشد، اما مفاهیم اصلی ثابت هستند. به لطف توانایی API Gateway برای ایجاد درخواست های سفارشی HTTP با استفاده از زبان قالب VTL، می توانید مستقیماً با سرویس هایی مانند DynamoDB تماس بگیرید تا پرس و جوهای پیچیده را حل کنید، داده ها را بازیابی کنید و رکوردها را ایجاد یا به روز کنید. طرح OpenAPI قوانین اعتبار سنجی را برای هر نقطه پایانی تعریف می کند، در حالی که ادغام با Cognito مجوزها و امنیت را مدیریت می کند.
AppSync یک تجربه مشابه اما با چند پیشرفت قابل توجه ارائه می دهد. این شامل حل‌کننده‌های جاوا اسکریپت علاوه بر حل‌کننده‌های استاندارد VTL و Pipeline برای اجرای دنباله‌ای از مراحل در یک جستار یا جهش خاص GraphQL است. AppSync همچنین از اشتراک‌های GraphQL پشتیبانی می‌کند و امکان برقراری ارتباط بی‌درنگ با ظاهر شما از طریق WebSockets را فراهم می‌کند. در حالی که شبیه قابلیت‌های API Gateway است، AppSync دسترسی آسان‌تر و جامع‌تری به WebSocket در مقایسه با پیاده‌سازی‌های REST API فراهم می‌کند. علاوه بر این، همه سرویس‌های AWS دارای یک API HTTP هستند که به شما امکان می‌دهد از خدماتی مانند AWS Rekognition برای تشخیص شی در تصاویر یا Bedrock برای درخواست LLM استفاده کنید.
پردازش داده های ناهمزمان یک نیاز معمول برنامه است. به طور معمول، این شامل یک تابع Lambda می شود که پیام ها را از یک صف SQS یا EventBridge مصرف می کند. با این حال، در مورد ما، ما از توابع Step برای مدیریت وظایفی مانند زنجیره‌ای کردن تماس‌های DynamoDB، اجرای تماس‌های API موازی به S3 یا ارسال اعلان‌ها به کاربر از طریق SNS و موارد دیگر استفاده می‌کنیم.
Step Function، همراه با API Gateway یا AppSync، می تواند کارهای همزمان را نیز انجام دهد، اما شما تا به حال این ایده را دریافت کرده اید، درست است؟ عملکردهای لامبدا عالی هستند، اما در بسیاری از موارد، تنها با “چسباندن” سرویس های AWS موجود، می توانید بدون آنها به همان نتیجه برسید.
ما می توانیم بدون لامبدا زندگی کنیم، اما چرا باید زندگی کنیم؟
همانطور که می بینید، ما می توانیم با این رویکرد بسیار فاصله داشته باشیم. صادقانه بگویم، با توجه به تجربه چندین ساله من در تلاش برای ساخت برنامه های بدون Lambdaless، باید بگویم که این خوشایندترین تجربه توسعه دهنده نیست. خوشبختانه، با هر Re:Invent بهتر می شود. اما اگر نوشتن یک تابع ساده لامبدا بتواند بدون سردرد به همان نتیجه برسد، چرا باید این همه شلوغی را انجام داد؟
خوشحالم که پرسیدی من به شما پیشنهاد نمی کنم استفاده از Lambdas را در جایی که منطقی است کنار بگذارید. در عوض، من جایگزینی را برجسته می کنم که ارزش آن را در هنگام طراحی زیرساخت های جدید در نظر بگیرید. Lambdas استفاده از فناوری‌ها، کتابخانه‌ها و چارچوب‌های آشنا را امکان‌پذیر می‌کند و احتمالاً شما را سریع‌تر به نتیجه دلخواه می‌رساند. با این حال، این سرعت با هزینه های طولانی مدت نگهداری همراه است.
زمان‌های اجرا Lambda به طور منظم به‌روزرسانی و منسوخ می‌شوند، کتابخانه‌ها و چارچوب‌ها وصله‌ها و بهبودهای امنیتی دریافت می‌کنند، و پشته فناوری به سرعت در حال تکامل است. به روز نگه داشتن همه چیز، به ویژه در معماری های پیچیده، یک کار مهم است. با این حال، بسیاری از برنامه های داخلی یک بار برای یک مورد خاص توسعه داده می شوند و انتظار می رود با حداقل تعمیر و نگهداری برای سال ها کار کنند که منجر به بدهی فنی می شود – یک مسئله پرهزینه و دست و پا گیر.
در مقابل، سرویس‌های AWS دارای APIهای پایدار با حداقل تغییرات شکستگی هستند. در صورت بروز مشکل امنیتی، AWS معمولاً سریع‌تر از آنچه توسعه‌دهندگان فردی می‌توانند برای یک کتابخانه یا چارچوب مدیریت کنند، به آن رسیدگی می‌کند. به عنوان یک عارضه جانبی، شما در نهایت به پیکربندی سرویس‌های AWS موجود برای اکثر برنامه‌های خود به جای برنامه‌نویسی به روش سنتی، ختم می‌شوید. در حالی که تبدیل شدن به یک توسعه دهنده YAML ممکن است کمتر هیجان انگیز به نظر برسد، حفظ پیکربندی در طول زمان بسیار آسان تر از مدیریت یک پروژه پایتون یا جاوا اسکریپت است.
با “چسباندن” سرویس های AWS، قابلیت پیش بینی عملیات، زمان به کارگیری و قابلیت اطمینان را بهبود می بخشید. سرویس‌های بومی ترافیک را به خوبی مدیریت می‌کنند و مسائل مقیاس‌پذیری اغلب جنبه‌های معماری دارند تا فناوری. علاوه بر این، هزینه های عملیاتی شما با استفاده واقعی مطابقت دارد، که کسب و کارها از آن استقبال می کنند. در حالی که لامبداها به سرعت مستقر می شوند، نگهداری آنها در طول زمان ممکن است پرهزینه باشد. اتکای صرف به سرویس‌های AWS ممکن است در ابتدا گران‌تر باشد، اما در بلندمدت ارزان‌تر است. فوایدش عالیه سوال این است که آیا مایلید امنیت و آشنایی با زبان های برنامه نویسی استاندارد را با تعمیر و نگهداری کمتر عوض کنید؟
بازگشت به واقعیت
این احتمال وجود دارد که گهگاه به یک تابع لامبدا یا حتی یک ظرف نیاز داشته باشید و این کاملاً خوب است. زمانی که مفاهیم بدون سرور تقریباً یک دهه پیش ظهور کردند، بعید به نظر می رسید که سیستم های کاملاً بدون سرور به واقعیت تبدیل شوند. با این حال، امروزه حتی بخش‌های بهداشت و درمان و مالی به طور قابل توجهی به معماری‌های بدون سرور متکی هستند و استارت‌آپ‌ها در حال ساخت برنامه‌های کاملاً بدون سرور هستند.
من قویاً معتقدم که با بهبود مداوم تجربه توسعه‌دهندگان در مورد سرویس‌های AWS، نیاز به نوشتن Lambdas خودمان برای کارهای سنگین بلند کردن متمایز نشده کاهش می‌یابد. در عوض، ما این «بلوک‌های LEGO» آماده را در صورت نیاز برای اکثر موارد استفاده با هزینه‌های تعمیر و نگهداری بسیار کمتر و همزمان قابلیت اطمینان افزایش می‌دهیم. این ما را قادر می‌سازد تا به سرعت برنامه‌های کاربردی را بدون نیاز به بازسازی‌های اساسی در آینده، نمونه‌سازی کنیم. من شما را تشویق می‌کنم که به این ایده‌ها فرصت دهید و به دقت بررسی کنید که آیا واقعاً به عملکرد بعدی Lambda خود نیاز دارید یا خیر.
پس در مورد کلمه سرزنش چطور؟
بی پایان، Backend به عنوان یک سرویس، و Backend به عنوان پیکربندی تعدادی از پیشنهادات من هستند که اگرچه کامل نیستند، اما ممکن است جرقه الهام بخش باشند. اگر با واژه‌ای جذاب برای این سبک معماری مواجه شدید، لطفاً آن را در نظرات به اشتراک بگذارید.
در طول دو دهه گذشته، روندهای زیرساختی مختلفی ظهور کرده و هر چند سال یک بار با موارد جدید جایگزین شده است. در ابتدا، ما به سرورهای فلزی خالی که در زیرزمین‌های شرکت قرار داشتند، تکیه کردیم و از ما می‌خواستند سخت‌افزار بخریم، دیسک‌های سخت خراب را جایگزین کنیم، و قطع برق را مدیریت کنیم. با ظهور مجازی سازی و ارائه دهندگان ابر، ما تمرکز خود را در درجه اول به مدیریت نرم افزار معطوف کردیم، اگرچه هنوز مجبور بودیم سیستم عامل ها را اصلاح کنیم. کانتینرها تعمیر و نگهداری را بیشتر کاهش دادند و مقیاس پذیری را افزایش دادند، اما ما مسئول مدیریت محیط زمان اجرا باقی ماندیم. رویکرد بدون سرور این را یک گام فراتر برداشته است و به ما اجازه می‌دهد تا تنها بر روی کد برنامه و وابستگی‌های خود تمرکز کنیم، در حالی که ارائه‌دهنده ابر بقیه موارد را مدیریت می‌کند.
AWS Lambda 10 ساله می شود
در re:Invent 2014، AWS لامبدا را معرفی کرد که نشانگر آغاز پارادایم زیرساخت بدون سرور بود. در حالی که بسیاری از سرویس‌های AWS، مانند SQS و S3، از ابتدا بدون سرور بودند، لامبدا این تغییر معماری را تسریع کرد و اصطلاح «بدون سرور» را رایج کرد. در طول دهه گذشته، اکوسیستم به طور قابل توجهی بالغ شده و به جریان اصلی تبدیل شده است. استارت آپ های جدید، از جمله ما، با افتخار تمام زیرساخت های خود را بر روی اجزای بدون سرور ایجاد می کنند.
یک دهه در فناوری زمان طولانی است و نوآوری بی وقفه است. ظهور یک روند جدید اجتناب ناپذیر بود و به نظر من این طور شده است. ما فقط یک کلمه کلیدی برای آن نداریم. قبل از شروع به حدس و گمان در مورد آنچه بعد از بدون سرور می آید، بیایید در مورد اینکه برنامه مدرنی که در AWS اجرا می شود در سال 2024 چگونه به نظر می رسد، بحث کنیم.
پشته برنامه مدرن
از منظر ساده شده، اکثر برنامه های کاربردی وب و موبایل شباهت های اساسی در باطن دارند. آنها معمولاً احراز هویت را ارائه می کنند، اشکال مختلف ورودی کاربر را می پذیرند، آن اطلاعات را از طریق API ها ارسال می کنند و در یک پایگاه داده ذخیره می کنند. سپس این داده ها تبدیل یا تجمیع می شوند و به کاربر ارائه می شوند.
این الگو در تجارت الکترونیک، سیستم های CRM، بانکداری اینترنتی، حسابداری و بسیاری از کاربردهای دیگر مشهود است. با وجود این مشترکات، هر نرم افزار دارای ویژگی های منحصر به فردی است که برای کاربران ارزش افزوده ایجاد می کند. علاوه بر این، عناصری مانند مدل‌های یادگیری ماشین، ادغام با سایر سیستم‌ها و تراکنش‌های ارزهای دیجیتال ارزش برنامه‌های مدرن را بیشتر می‌کنند. با این حال، بدون اجزای اصلی ورودی کاربر، APIها و پایگاه‌های داده، این برنامه‌ها تا حد زیادی ناکارآمد خواهند بود.
هنگام ساخت یک برنامه جدید، ممکن است از لامبدا برای میکروسرویس های رویداد محور (EDA) خود (Authenticator، API، Notifier، …) استفاده کنید. در ترکیب با DynamoDB، این انتخاب ها برای یک سیستم مبتنی بر ابر مدرن جریان اصلی و ایمن هستند.
اما اگر جایگزینی وجود داشته باشد چه؟
جایگزین های لامبدا
خوشبختانه، ما دیگر نیازی به توسعه همه این میکروسرویس ها نداریم زیرا AWS راه حل های بدون سرور را برای بسیاری از سناریوهای رایج ارائه می دهد:
- Authenticator – شناخته شده است
- API – API Gateway، AppSync
- میزبانی استاتیک – S3 + CloudFront
- مشاغل Async – StepFunctions
- پایگاه داده – DynamoDB
- …
ایجاد این خدمات به صورت مستقل می تواند به راحتی بیش از 50 درصد از زمان پروژه شما را مصرف کند. این تلاش، که به عنوان “بالا بردن سنگین غیرمتمایز” شناخته می شود، ضروری است اما برنامه شما را از رقبا متمایز نمی کند. استفاده از خدمات موجود به شما این امکان را می دهد که منابع را روی مناطقی متمرکز کنید که برنامه شما ارزش منحصر به فردی دارد.
مورد استفاده واقعی برنامه
برنامه‌ای واقعاً بدون سرور را تصور کنید که صرفاً با یکپارچه‌سازی سرویس‌های AWS موجود ساخته شده است، حتی تا آنجا پیش می‌رود که یک تابع Lambda را حذف می‌کند. من با «واقعاً بدون سرور» به مانیفست اصلی بدون سرور اشاره می‌کنم که از انعطاف‌پذیری، قیمت‌گذاری پرداخت به ازای استفاده، توانایی مقیاس‌سازی به صفر و موارد دیگر حمایت می‌کند.
فرقی نمی‌کند REST API یا GraphQL را انتخاب کنید، تغییرات معماری ممکن است کمی متفاوت باشد، اما مفاهیم اصلی ثابت هستند. به لطف توانایی API Gateway برای ایجاد درخواست های سفارشی HTTP با استفاده از زبان قالب VTL، می توانید مستقیماً با سرویس هایی مانند DynamoDB تماس بگیرید تا پرس و جوهای پیچیده را حل کنید، داده ها را بازیابی کنید و رکوردها را ایجاد یا به روز کنید. طرح OpenAPI قوانین اعتبار سنجی را برای هر نقطه پایانی تعریف می کند، در حالی که ادغام با Cognito مجوزها و امنیت را مدیریت می کند.
AppSync یک تجربه مشابه اما با چند پیشرفت قابل توجه ارائه می دهد. این شامل حل‌کننده‌های جاوا اسکریپت علاوه بر حل‌کننده‌های استاندارد VTL و Pipeline برای اجرای دنباله‌ای از مراحل در یک جستار یا جهش خاص GraphQL است. AppSync همچنین از اشتراک‌های GraphQL پشتیبانی می‌کند و امکان برقراری ارتباط بی‌درنگ با ظاهر شما از طریق WebSockets را فراهم می‌کند. در حالی که شبیه قابلیت‌های API Gateway است، AppSync دسترسی آسان‌تر و جامع‌تری به WebSocket در مقایسه با پیاده‌سازی‌های REST API فراهم می‌کند. علاوه بر این، همه سرویس‌های AWS دارای یک API HTTP هستند که به شما امکان می‌دهد از خدماتی مانند AWS Rekognition برای تشخیص شی در تصاویر یا Bedrock برای درخواست LLM استفاده کنید.
پردازش داده های ناهمزمان یک نیاز معمول برنامه است. به طور معمول، این شامل یک تابع Lambda می شود که پیام ها را از یک صف SQS یا EventBridge مصرف می کند. با این حال، در مورد ما، ما از توابع Step برای مدیریت وظایفی مانند زنجیره‌ای کردن تماس‌های DynamoDB، اجرای تماس‌های API موازی به S3 یا ارسال اعلان‌ها به کاربر از طریق SNS و موارد دیگر استفاده می‌کنیم.
Step Function، همراه با API Gateway یا AppSync، می تواند کارهای همزمان را نیز انجام دهد، اما شما تا به حال این ایده را دریافت کرده اید، درست است؟ عملکردهای لامبدا عالی هستند، اما در بسیاری از موارد، تنها با “چسباندن” سرویس های AWS موجود، می توانید بدون آنها به همان نتیجه برسید.
ما می توانیم بدون لامبدا زندگی کنیم، اما چرا باید زندگی کنیم؟
همانطور که می بینید، ما می توانیم با این رویکرد بسیار فاصله داشته باشیم. صادقانه بگویم، با توجه به تجربه چندین ساله من در تلاش برای ساخت برنامه های بدون Lambdaless، باید بگویم که این خوشایندترین تجربه توسعه دهنده نیست. خوشبختانه، با هر Re:Invent بهتر می شود. اما اگر نوشتن یک تابع ساده لامبدا بتواند بدون سردرد به همان نتیجه برسد، چرا باید این همه شلوغی را انجام داد؟
خوشحالم که پرسیدی من به شما پیشنهاد نمی کنم استفاده از Lambdas را در جایی که منطقی است کنار بگذارید. در عوض، من جایگزینی را برجسته می کنم که ارزش آن را در هنگام طراحی زیرساخت های جدید در نظر بگیرید. Lambdas استفاده از فناوری‌ها، کتابخانه‌ها و چارچوب‌های آشنا را امکان‌پذیر می‌کند و احتمالاً شما را سریع‌تر به نتیجه دلخواه می‌رساند. با این حال، این سرعت با هزینه های طولانی مدت نگهداری همراه است.
زمان‌های اجرا Lambda به طور منظم به‌روزرسانی و منسوخ می‌شوند، کتابخانه‌ها و چارچوب‌ها وصله‌ها و بهبودهای امنیتی دریافت می‌کنند، و پشته فناوری به سرعت در حال تکامل است. به روز نگه داشتن همه چیز، به ویژه در معماری های پیچیده، یک کار مهم است. با این حال، بسیاری از برنامه های داخلی یک بار برای یک مورد خاص توسعه داده می شوند و انتظار می رود با حداقل تعمیر و نگهداری برای سال ها کار کنند که منجر به بدهی فنی می شود – یک مسئله پرهزینه و دست و پا گیر.
در مقابل، سرویس‌های AWS دارای APIهای پایدار با حداقل تغییرات شکستگی هستند. در صورت بروز مشکل امنیتی، AWS معمولاً سریع‌تر از آنچه توسعه‌دهندگان فردی می‌توانند برای یک کتابخانه یا چارچوب مدیریت کنند، به آن رسیدگی می‌کند. به عنوان یک عارضه جانبی، شما در نهایت به پیکربندی سرویس‌های AWS موجود برای اکثر برنامه‌های خود به جای برنامه‌نویسی به روش سنتی، ختم می‌شوید. در حالی که تبدیل شدن به یک توسعه دهنده YAML ممکن است کمتر هیجان انگیز به نظر برسد، حفظ پیکربندی در طول زمان بسیار آسان تر از مدیریت یک پروژه پایتون یا جاوا اسکریپت است.
با “چسباندن” سرویس های AWS، قابلیت پیش بینی عملیات، زمان به کارگیری و قابلیت اطمینان را بهبود می بخشید. سرویس‌های بومی ترافیک را به خوبی مدیریت می‌کنند و مسائل مقیاس‌پذیری اغلب جنبه‌های معماری دارند تا فناوری. علاوه بر این، هزینه های عملیاتی شما با استفاده واقعی مطابقت دارد، که کسب و کارها از آن استقبال می کنند. در حالی که لامبداها به سرعت مستقر می شوند، نگهداری آنها در طول زمان ممکن است پرهزینه باشد. اتکای صرف به سرویس‌های AWS ممکن است در ابتدا گران‌تر باشد، اما در بلندمدت ارزان‌تر است. فوایدش عالیه سوال این است که آیا مایلید امنیت و آشنایی با زبان های برنامه نویسی استاندارد را با تعمیر و نگهداری کمتر عوض کنید؟
بازگشت به واقعیت
این احتمال وجود دارد که گهگاه به یک تابع لامبدا یا حتی یک ظرف نیاز داشته باشید و این کاملاً خوب است. زمانی که مفاهیم بدون سرور تقریباً یک دهه پیش ظهور کردند، بعید به نظر می رسید که سیستم های کاملاً بدون سرور به واقعیت تبدیل شوند. با این حال، امروزه حتی بخش‌های بهداشت و درمان و مالی به طور قابل توجهی به معماری‌های بدون سرور متکی هستند و استارت‌آپ‌ها در حال ساخت برنامه‌های کاملاً بدون سرور هستند.
من قویاً معتقدم که با بهبود مداوم تجربه توسعه‌دهندگان در مورد سرویس‌های AWS، نیاز به نوشتن Lambdas خودمان برای کارهای سنگین بلند کردن متمایز نشده کاهش می‌یابد. در عوض، ما این «بلوک‌های LEGO» آماده را در صورت نیاز برای اکثر موارد استفاده با هزینه‌های تعمیر و نگهداری بسیار کمتر و همزمان قابلیت اطمینان افزایش می‌دهیم. این ما را قادر می‌سازد تا به سرعت برنامه‌های کاربردی را بدون نیاز به بازسازی‌های اساسی در آینده، نمونه‌سازی کنیم. من شما را تشویق می‌کنم که به این ایده‌ها فرصت دهید و به دقت بررسی کنید که آیا واقعاً به عملکرد بعدی Lambda خود نیاز دارید یا خیر.
پس در مورد کلمه سرزنش چطور؟
بی پایان، Backend به عنوان یک سرویس، و Backend به عنوان پیکربندی تعدادی از پیشنهادات من هستند که اگرچه کامل نیستند، اما ممکن است جرقه الهام بخش باشند. اگر با واژه‌ای جذاب برای این سبک معماری مواجه شدید، لطفاً آن را در نظرات به اشتراک بگذارید.
