بدون سرور، تقاطع فناوری و مردم

اعتراف به تعصب من

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

من می توانم پیشاپیش تعصب خود را بپذیرم که دوست دارم و اغلب ابتدا بدون سرور را انتخاب می کنم. و در نقش فعلی من، تیم‌های من به شدت از Lambdas، SQS، SNS، EventBridge، DynamoDB و بسیاری دیگر از سرورهای بدون سرور AWS استفاده می‌کنند. اما چیزی که می‌خواهم در زیر به شما بگویم این است که انتخاب بدون سرور هنگام ساخت یک محصول می‌تواند تفکر راه‌حل‌های شما را بالا ببرد و افکار شما را حول حل مسئله متمرکز کند که باعث می‌شود کار سنگین بدون تمایز تمرکز شریک شما در AWS باشد.

تعریف خط آب

من فکر می کنم این صرف نظر از اینکه برنامه شما چقدر بزرگ است صادق است، اما معتقدم هر چه برنامه بزرگتر باشد، از این تفکر سود بیشتری خواهید برد. من فکر می کنم با انتخاب خدمات مدیریت شده به عنوان پایه خود، 70 تا 80 درصد از سردرد ناشی از تلاش برای تقویت زیرساخت خود را نجات خواهید داد. حالا قبل از اینکه فکر کنید من «در همه موارد» می گویم، این را نمی گویم، اما به شدت احساس می کنم که این در بیشتر موارد درست است. و چرا؟

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

این هرم زیر نحوه تجسم آن است

بیایید کمی از این لایه ها عبور کنیم

بدون سرور

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

با AWS و بدون سرور، SQS را رها کنید و فوراً یک سیستم صف بسیار در دسترس خواهید داشت که دارای یک SDK برای هر زبان اصلی است که می‌خواهید. و اگر به دلایلی چیزی را انتخاب کنید، نه در منو، HTTP دارید که می توانید با آن ارتباط برقرار کنید.

این رویکرد با لایه های دیگر در برنامه شما پیش می رود. فقط به نام چند مورد در زیر.

• پایگاه داده – DynamoDB/Aurora
• انتشار رویدادها – EventBridge/SNS
• جریان ها – Kinesis
• فضای دیسک – S3

زبان و چارچوب

هنگامی که به عنوان یک حل کننده مشکل بدون سرور فکر می کنید، استانداردسازی برخی از ابزارها و چارچوب ها بسیار منطقی است. ابزار درست ضرب المثل قدیمی برای این کار چیزی است که من در مورد این لایه از هرم دوست دارم. به عنوان مثال، اگر مشکلی به انعطاف پذیری در داده ها نیاز دارد و تیم شما از اعتبارسنجی طرحواره با Joi لذت می برد، ممکن است از TypeScript با زمان اجرا Node.js با لامبداهای خود استفاده کنید. اگر تجربه توسعه‌دهنده و ردپای کوچک و سادگی Go را ترجیح می‌دهید، از زمان اجرا Go 1.x استفاده کنید. ممکن است متوجه شوید که اصلاً به “محاسبات” نیاز ندارید، بنابراین استفاده از توابع ذاتی در ماشین‌های حالت ممکن است زیاد باشد.

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

علاوه بر زبان‌هایی که می‌خواهید انتخاب کنید و چارچوب‌های زبانی که انتخاب می‌کنید، به اعتقاد من باید زیرساخت‌ها را به‌عنوان جهت کدی که می‌خواهید انتخاب کنید، انتخاب کنید. باز هم گزینه های زیادی از اینجا وجود دارد

• سام
• CDK
• SST
• بدون سرور
• Terraform
• CloudFormation

مطمئنم که یکی را از دست داده ام، اما این موارد کلیدی هستند که در طبیعت دیده ام. من نمی دانم که خیلی مهم است که کدام یک را انتخاب می کنید، اما آنچه مهم است این است که در استفاده یکنواخت باشید. شما 100% نمی خواهید یک سناریوی ClickOps داشته باشید که در آن افراد چیزهایی را در کنسول بسازند. و شما شرایطی را نمی خواهید که مردم از ترکیبی از همه اینها استفاده کنند. با استانداردسازی کارایی به دست می آید و دانش به اشتراک گذاشته می شود. این کمی از مردم بخشی از تقاطع تکنولوژی و مردم است. من از طرفداران بزرگ CDK و SAM هستم. در اینجا چند مقاله وجود دارد که کمی بیشتر به آن می پردازیم

کد شما

من قویاً معتقدم که وقتی خود را با این 2 لایه پایین در این هرم 3 لایه تنظیم کردید، در راه حل خود وارد فضایی شده اید که در آن اجازه خواهید داشت روی مشکل واقعی تمرکز کنید. دو تصمیم اول به طور قطع آسان نیستند، اما عمدتاً فقط تصمیم هستند. ممکن است شواهدی از مفاهیم وجود داشته باشد تا اطمینان حاصل شود که انتخاب‌ها درست هستند و تجربه توسعه‌دهنده قوی است، اما «چیزهایی برای پیکربندی» و «سرورها» برای ایستادن وجود ندارد.

من فکر نمی‌کنم مقایسه‌ای منصفانه باشد که بدون سرور در مقابل هم‌مکانی و طبقه‌بندی تجهیزات خود نگاه کنید، زیرا مقایسه‌ها بسیار از هم دور هستند. اما در مقایسه با EC2 plus، می‌گوییم نصب Kafka خود در مقابل حذف در Kinesis، هنگام انتخاب بدون سرور، عادلانه به نظر می‌رسد، شما زمان آماده شدن برای ساخت را حذف کرده‌اید. و دوباره، تمرکز باید بر روی ساخت و مشکلی باشد که می‌خواهید برای مشتریان خود حل کنید.

متقاطع فناوری و مردم

خوب. تا به حال من بیشتر تمجیدهای بدون سرور را می‌خواندم و تاکید می‌کردم که در چه مواردی تصمیم‌گیری بدون سرور به شما امکان می‌دهد به مشکلات فکر کنید و نه به چیزهایی که ارزش مشتری شما را به ارمغان نمی‌آورد.

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

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

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

بخش افراد در انتخاب بدون سرور آنقدر مهم است که می‌خواهم چند نکته را برای شما در نظر بگیرم.

توسعه دهندگانی که بر حل مسئله تمرکز می کنند

من مدام به این مفهوم “حل مشکل” برمی گردم زیرا فکر می کنم بسیار مهم است. اول از همه، بدون سرور، حل مسئله را در راه حل اختراع نکرده است، من فقط معتقدم که آن را ارتقا می دهد، زیرا زمانی که شما کمتر بر روی بلند کردن وزنه های غیرمتمایز و بیشتر بر روی نوآوری تمرکز می کنید، به افرادی نیاز دارید که فقط می خواهند این کار را انجام دهند. من با بسیاری از توسعه دهندگان بزرگ در حرفه ام کار کرده ام که فقط می خواستند روی چیزهایی در سطوح پایین هرم بالا تمرکز کنند. 100٪ هیچ ایرادی در هیچ یک از اینها وجود ندارد، اما برای من بدون سرور در مورد این تلاقی فناوری و افراد و نوع افراد مهم است.

چیزی که اغلب می‌بینم این است که توسعه‌دهندگانی که بیشتر بر ارزش‌سازی و ارزش مشتری تمرکز می‌کنند، این پرش را به سمت بدون سرور بسیار آسان‌تر می‌کنند. نرم افزار به نظر من باید سرگرم کننده یا مفید باشد و نرم افزاری باشد و هنگام ساختن چیزهایی که برای مشتریان مفید باشد، این بالارفتن تفکر باعث می شود بحث ها سازنده تر شود.

بخش دیگر مولفه حل مسئله این است که با انتزاع کردن زمان‌های اجرا از شما مانند توابع Lambda یا Step، شما به این نوع تفکر محدود نمی‌شوید. ما نمی توانیم xyz را اجرا کنیم زیرا تخصص ما در زمینه تولید محدود به abc است. یا چون مجوز abc نداریم نمی توانیم از xyz استفاده کنیم. آزادی انتخاب ابزار بالاتر از پشته اغلب می تواند به راه حل های بسیار هدفمندتری برای مشتریان منجر شود.

وقتی به دنبال استخدام یک تیم یا تیم هایی از افراد برای فکر کردن و ساختن بدون سرور هستم، همیشه با این مفهوم شروع می کنم. من مصاحبه هایم را حول آن جهت می دهم. من فرآیند سوار شدن را حول آن جهت می دهم. و در جلسات طراحی با تیم های محصول، این یک مفهوم جلو و مرکزی است. نتیجه ای که می خواهیم به آن برسیم چیست؟

توسعه دهندگانی که به شکست فکر می کنند

فناوری بدون سرور، تفکر طراحی رویداد محور را به دنیای شما معرفی می کند. و با تفکر رویداد محور شکست می آید. هنگامی که راه حل خود را به دسته ای از قطعات کوچک تقسیم می کنید، آن بخش ها همیشه اتصال را برقرار نمی کنند، بنابراین چگونه تضمین می کنید که راه حل شما می تواند پس از شکست بهبود یابد؟

توسعه‌دهنده‌ای که ذهنیت‌اش حول محور آن چیزی است که «زمانی» اتفاق می‌افتد، ادغام بیشتر تلاقی بین فناوری و مردم است. در یک برنامه سبک بزرگتر و یکپارچه، استدلال زنجیره درخواست ساده است. در یک برنامه کاربردی سبک توزیع شده و بدون سرور که همیشه اینطور نیست. اما چیزی که من متوجه شدم این است که توسعه دهندگانی که به طور طبیعی به شکست فکر می کنند، این تفکر را به تجربه کاربری مشتری شما منتقل می کنند. بنابراین این یک برد/برد برای تیم است.

مالکیت عملیات و اجرا

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

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

همکاری بین تیمی

بنابراین، این آخرین نکته در تقاطع بین فناوری و مردم، به عنوان یک رهبر فناوری، به نظر من جالب‌ترین نکته است.

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

و هنگامی که به دلیل آن فکر می کنم، به دو چیز برمی گردد.

1. افرادی که من با آنها کار می کنم مانند کسانی هستند که در بالا توضیح دادم
2. هر دو دامنه از هرم بالا استفاده می‌کنند و در 2 بلوک پایین استاندارد شده‌اند و مشارکت را برای توسعه‌دهندگان آسان‌تر می‌کند.

من نمی توانم به اندازه کافی بر این موضوع تأکید کنم زیرا صادقانه بگویم که در تجربه قبلی خود هرگز چنین چیزی را ندیده ام. من چیزهای “نزدیک” را دیده ام اما نه در این سطح از کارایی و با این کشش اندک. با انتخاب بدون سرور و انتخاب استانداردسازی ابزار، تیم ها می توانند برای حل مشکلاتی که زودتر به مشتریان ارزش می دهد و مدل عملیاتی یکسانی را در دو حوزه دارند، با یکدیگر همکاری کنند.

بسته بندی

تصمیم برای بدون سرور چیزی فراتر از فناوری است. این تصمیمی است که حول محور تلاقی افراد و فناوری است. این تقاطع مستلزم آن است که مسئولین راه حل ابتدا

• تصمیم بگیرید بدون سرور از اهرم استفاده کنید
• ابزارها و چارچوب ها را استاندارد کنید
• نوآوری و ارائه ارزش

از آنجا باید مدل عملیاتی را بپذیرید که بدون سرور است و به ابزار، استقرار و هزینه ها متمایل شوید.

همانطور که در بالا ذکر کردم، هیچ معماری کاملی وجود ندارد، بلکه تنها معماری مناسب برای افراد شما، نتایج مطلوب و راحتی با تکنولوژی وجود دارد.

من امیدوارم که این مقاله به شما نکات بیشتری را در هنگام ساخت برنامه بعدی یا استفاده از آن ویژگی های جدید به شما داده باشد.