تجربه توسعه‌دهنده نباید در قسمت جلویی متوقف شود

توسعه دهندگان Back-end به تهیه و مدیریت زیرساخت ساده تری نیاز دارند تا ساخت محیط ساده و قابل تکرار را واقعاً فعال کنند. کمک در راه است.

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

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

برنامه‌نویس‌های بک‌اند می‌توانند از یک استراحت استفاده کنند—یا به طور خاص، از یک تجربه توسعه‌دهنده بهتر. خوشبختانه سازندگان ابزار برای تهیه آن عجله دارند. از پایین آوردن نوار به زیرساخت به عنوان کد، به هموارسازی گردش‌های کاری Kubernetes و استقرار برنامه‌های توزیع‌شده، تا چرخش فضاهای کاری توسعه‌دهندگان در فضای ابری بر اساس تقاضا، موج جدیدی از پروژه‌ها نوید زندگی را برای توسعه‌دهندگانی که در سمت سرور زحمت می‌کشند، آسان‌تر می‌کند.< /p>

مهندسین پشتیبان نیز احساساتی دارند

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

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

جیمز گاورنر، تحلیلگر RedMonk، به InfoWorld گفت: «این طبیعی است که ببینیم ارائه دهندگان این کارها را برای توسعه دهندگان آسان تر می کنند و اینجاست که ما وارد توسعه نرم افزار جلسه زیرساخت می شویم. “در پایان روز، شما به پلتفرم هایی نیاز دارید که به شما امکان می دهد بدون برخورد دستی با نمودارهای Helm، اپراتورها یا YAML بهره وری بیشتری داشته باشید.”

بهبود تجربه توسعه دهندگان Back-end می تواند بیشتر از بهبود زندگی توسعه دهندگان back-end باشد. ارائه ابزارهای بهتر و شهودی‌تر می‌تواند به توسعه‌دهندگان پشتیبان کمک کند کارهای بیشتری انجام دهند، در حالی که موانع را کاهش می‌دهد تا گروه وسیع‌تری از توسعه‌دهندگان بتوانند زیرساخت‌های خود را از طریق انتزاع‌های متفکرانه مدیریت کنند.

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

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

Pulumi: آوردن تجربه توسعه دهنده به سرزمینی فراموش شده

Pulumi را انتخاب کنید، که هدف آن این است که کار پیکربندی زیرساخت را به کاری تبدیل کند که هر توسعه‌دهنده‌ای می‌تواند با کار در زبان برنامه‌نویسی دلخواه خود انجام دهد، به جای چیزی مانند CloudFormation برای خدمات وب آمازون (AWS)، Bicep. برای Microsoft Azure یا YAML برای Kubernetes. منبع باز موتور پولومی سپس زیرساخت مجازی و نقاط پایانی را برای قرار دادن کد پیکربندی می‌کند.

Pulumi اساساً گزینه دیگری برای ارائه زیرساخت به عنوان کد است، اما نوید منحنی یادگیری کم‌عمق‌تری را نسبت به ابزارهایی مانند CloudFormation یا HashiCorp’s Terraform می‌دهد.

هنگامی که بیش از یک دهه در مایکروسافت بر روی ابزارهای توسعه‌دهنده کار می‌کرد، جو دافی، بنیان‌گذار و مدیر عامل Pulumi، متوجه این موضوع شد که “هیچ کس از سطح مراقبت و عشق به فضای زیرساخت استفاده نکرده است” آن‌طور که مجبور بودند به صورت فرانت‌اند انجام دهند. توسعه. او به InfoWorld گفت: «ابر یک فکر بعدی خسته کننده و کثیف بود.

دافی گفت: «بهترین فناوری ما Terraform بود، که یک فناوری اختصاصی است، در حالی که من فقط یک IDE می‌خواستم و از زبان مورد علاقه‌ام استفاده می‌کردم، اما همچنان از ابر به طور کامل استفاده می‌کردم.

به گفته دافی، تجربه توسعه‌دهنده برای Pulumi «خود زندگی» است. ما می‌خواهیم یک تجربه توسعه‌دهنده عالی را به فضایی بیاوریم که نداشت. به همین دلیل است که ما از زبان‌های هدف عمومی استفاده می‌کنیم.» “ما می خواهیم این تجربه لذت بخش و خسته کننده نباشد.”

برای مهندسین زیرساخت، پلت‌فرم، و توسعه‌دهنده‌هایی که در محیط‌های پراکنده قدیمی کار می‌کنند، Pulumi این امکان را فراهم می‌کند که زیرساخت‌های قابل استفاده مجدد را با خط‌مشی‌ها و آزمایش به‌عنوان کد برای توسعه‌دهندگان قرار دهد. Pulumi اخیرا یک نسخه Business Critical را برای مشتریان سازمانی از این نوع معرفی کرده است.

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

“من می‌خواستم راه‌حلی پیدا کنم که ما را قادر می‌سازد زیرساخت را مدل‌سازی کنیم، نه با نوشتن کد پیکربندی و اجرای یک اسکریپت، بلکه به عنوان یک فرآیند توسعه نرم‌افزار، از طریق کد و یک جریان کاری مبتنی بر Git، اندی دانگ، مهندس ارشد سابق AWS و یکی از بنیانگذاران استارت آپ مشاهده پذیری WhyLabs، به InfoWorld گفت.

WhyLabs پس از اینکه دنگ گزینه‌های زیرساختی موجود مانند CloudFormation و Terraform را بسیار پیچیده یافت، به Pulumi روی آورد و خاطرنشان کرد که CloudFormation به طور خاص “برای مصرف انسان نوشته نشده است.”

در عوض، دانگ می‌خواست تیم‌های مهندسی و توسعه‌دهندگان ناب در WhyLabs بتوانند «میزان دانش زیرساختی مورد نیاز تیم را کاهش دهند، به طوری که آنها بتوانند بهترین تمرکز را بر روی بخش خاص خود داشته باشند».

HashiCorp Waypoint: ایجاد یک گردش کار برنامه‌نویس سازگار

یکی دیگر از شرکت‌هایی که در اینجا وارد معارضه می‌شوند، HashiCorp، خالق ابزار محبوب Terraform زیرساخت به عنوان کد است. HashiCorp با هدف هموارسازی مسیر توسعه دهندگان برای ساخت و استقرار برنامه های کاربردی خود در Kubernetes و سرویس کانتینر الاستیک آمازون (ECS)، Waypoint را راه اندازی کرد. در سال ۲۰۲۰.

چانگ لی، مدیر بازاریابی محصول در HashiCorp، به InfoWorld گفت: «ما معتقدیم که توسعه‌دهندگان فقط می‌خواهند توسعه دهند.

برای کمک به آنها در انجام این کار، Waypoint یک لایه انتزاعی و رابط کاربر پسند را برای توسعه دهندگان و اپراتورها ارائه می دهد. برای توسعه دهندگان، این به معنای اجرای ساده فرآیندهای ساخت و انتشار است، در حالی که اپراتورها یکپارچگی و استانداردسازی بسیار مورد نیاز را در محیط های مختلف به دست می آورند، همه با استفاده از یک فرمان واحد: waypoint up.

لی گفت: «مخاطبان اصلی ما اپراتورها هستند. «در مقیاس سازمانی، تیم‌های عملیاتی برای استانداردسازی یک گردش کار برای مقیاس‌پذیری در چندین پلتفرم فشار را احساس می‌کنند. آنها به طور سنتی از ابزارهای CI/CD مانند Jenkins یا Spinnaker استفاده می‌کنند و آنها را خیلی سنگین می‌دانند.”

برای HashiCorp، «Waypoint می‌تواند جایگزینی برای آن دست‌نوشته‌ها یا گردش‌های کاری CI/CD سفارشی‌شده باشد،» لی گفت. “این باید یک تجربه ساده، بدون تعامل پیچیده با زیرساخت های اساسی باشد.”

این همان ناامیدی از ابزارهای CI/CD موجود است که بنیانگذار Docker Solomon Hykes را به تلاش کرده و با پروژه منبع باز خود، Dagger، CI/CD را برای توسعه‌دهندگان سازگارتر کند است.

>

Render: ترکیبی از گزینه های میزبانی Goldilocks

آنوراگ گوئل، رئیس سابق ریسک در Stripe، Render تأسیس شد و هدف آن ارائه ترکیبی از میزبانی Goldilocks به توسعه دهندگان است. گزینه‌هایی که بین پلتفرم‌های بسیار معتبری مانند Heroku و پیچیدگی نامحدود AWS قرار می‌گیرند.

پس از ترک استرایپ، گوئل در اوقات فراغت خود با یادگیری ماشینی مشغول بود. او در حین یادگیری ساخت مدل‌های یادگیری ماشین، دانشمندان داده را دید که روزها را صرف آماده کردن محیط‌های نوت بوک Jupyter خود می‌کنند. در عوض، Goel می‌خواست «تامین با یک کلیک در فضای ابری» و تجربه‌ای که منعکس‌کننده تجربه یکپارچه‌سازی پرداخت‌ها با استفاده از Stripe API باشد.

او به InfoWorld گفت: “من مدام به سمت زیرساخت ها و بهره وری توسعه دهندگان جذب می شدم.” “در هسته خود، Render در حال خودکار کردن deops است.”

در عمل، توسعه‌دهندگان می‌توانند مخزن GitHub یا GitLab خود را به Render متصل کنند، که سپس دستوراتی را برای ساخت و شروع برنامه شما پیشنهاد می‌کند. Render یک سرویس اختصاصی است و در حال حاضر در بالای AWS و Google Cloud اجرا می‌شود، و به زودی از فلز کاملاً پشتیبانی می‌کند.

“مردم به ما مراجعه می‌کنند زیرا فکر می‌کنند Kubernetes خیلی پیچیده است، اما ویژگی‌هایی که آنها نیاز دارند در Render هستند، زیرا ما بر روی Kubernetes به‌گونه‌ای ساخته‌ایم که فقط خواسته‌های آنها را نشان می‌دهد، گوئل گفت.

از آنجایی که Render با سایر گزینه‌های میزبانی Backend-as-a-Service (BaaS) متفاوت است این است که نظری در مورد نحوه ساخت و اجرای برنامه‌های شما نمی‌دهد، خواه یک سایت ثابت، کار Cron یا هر چیز دیگری باشد. در ظرف داکر گوئل گفت: “ما یک ایدئولوژی خاص در مورد نحوه ساخت برنامه ها را تحت فشار قرار نمی دهیم.”

Render در رویکرد توسعه‌دهنده محور خود به BaaS نیز تنها نیست. پروژه متن باز Appwrite در حال کار بر روی یک پلت فرم خود میزبانی برای توسعه دهندگان است تا به راحتی وب، تلفن همراه و برنامه ها را از طریق مجموعه ای از API های مدیریت شده.

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

Encore قصد دارد با مراحل پیکربندی دستی خودکار برای تدارک، به توسعه‌دهندگان کمک کند تا در حالت جریان باقی بمانند. زیرساخت ابری، تولید کد دیگ بخار، ابزار دقیق برنامه، و ایجاد مستندات. سپس توسعه‌دهندگان می‌توانند در AWS، Azure یا Google Cloud مستقر شوند.

این پروژه در سال ۲۰۲۱ توسط مهندسان سابق Spotify، آندره اریکسون، مارکوس کولبرگ، و هوریا جورکو، همراه با مهندس سابق مونزو، دومینیک بلک و مهندس سابق گوگل، استفان اکرفلت، تأسیس شد. بنیانگذاران می‌گویند که Encore در نتیجه ناامیدی‌های مشترک آنها ایجاد شده است که زیرساخت‌های بک‌اند توزیع‌شده پیچیده و تکرار مداوم برخی از وظایف بک‌اند را تشکیل می‌دهد.

اریکسون به InfoWorld گفت:

Encore تلاش می‌کند “قسمت‌های خوب ابر را حفظ کند و آنچه را که توسعه‌دهندگان روی آن کار می‌کنند تغییر دهد، و به آنها اجازه می‌دهد محصولاتی بسازند و در باتلاق‌های YAML و لوله‌کشی غرق نشوند.”

این استارت‌آپ سرمایه‌ای ۳ میلیون دلاری به رهبری شرکای کرین ونچر جمع‌آوری کرد و موتور توسعه بک‌اند منبع باز خود را ایجاد کرد. /a> عموماً در آوریل ۲۰۲۲ در دسترس است.

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

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

>

Gitpod با یک فایل YAML شروع می‌شود که توضیح می‌دهد که محیط توسعه‌دهنده چگونه باید به نظر برسد، از IDE گرفته تا پایگاه داده، همراه با کامپایلرها، سرورهای زبان و سیستم عامل. لندگراف گفت: “هر چیزی که روی رایانه محلی شما قرار دارد، ما با همان تجربه ای که توسعه دهندگان به آن عادت کرده اند، به ابر منتقل می کنیم.”

Gitpod با GitHub، GitLab و Bitbucket ادغام می شود و هر زمان که کد به مخزن شما فشار داده می شود، همه پروژه های شما را از پیش می سازد، مانند یک سرور یکپارچه سازی مداوم. وقتی توسعه‌دهندگان یک محیط را می‌چرخانند، همه چیز از قبل مقداردهی شده و آماده اجرا است. آنها مجبور نیستند منتظر بارگیری وابستگی ها و ساخت اسکریپت ها بمانند.

لندگراف گفت:

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

پروژه منبع باز قبلاً رونق خوبی داشته است، به‌زودی GitHub با راه‌اندازی محیط توسعه مبتنی بر ابر خود به نام Codespaces در سال ۲۰۲۱، همین روند را دنبال کرد.

همه مهندسان GitHub اکنون در Codespaces کار می کنند به گفته کوری ویلکرسون، مدیر ارشد مهندسی GitHub، که در آن “محیط های توسعه بر اساس تقاضا برای کار در دست تهیه می شوند” و توسعه دهندگان می توانند “کد فضاهای قابل اعتماد، از پیش پیکربندی شده، آماده و آماده برای توسعه GitHub.com در ۱۰ ثانیه ایجاد کنند.” p>

چگونه AWS، Azure و Google Cloud ساخت‌های زیرساخت را ساده می‌کنند

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