Radius مایکروسافت و آینده توسعه ابری

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

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

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

ما در این راه گام های مختلفی برداشته ایم. ابزارهای Infrastructure-as-code (IaC) مانند Terraform و Azure Resource Manager به شما امکان می‌دهند مدیریت خدمات زیرساخت و پلتفرم‌ها را خودکار کنید، شبکه‌ها و سرورها را تعریف و سپس بسازید. و خدمات مورد نیاز کد شما. این ابزارها به طور فزاینده‌ای بالغ می‌شوند و می‌توانند مستقیماً علیه APIهای مدیریت سرویس ابری کار کنند و نحوی آشنا را با رویکردهای اعلامی و برنامه‌ای برای تعاریف زیرساخت ارائه می‌دهند.

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

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

معرفی Radius

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

من یک مکالمه ایمیلی با مارک روسینوویچ مدیر ارشد فناوری Azure در مورد Radius، نحوه توسعه آن و نقش آن در توسعه بومی ابری داشتم. او به من گفت،

ما می‌خواهیم توسعه‌دهندگان بتوانند بهترین شیوه‌های هزینه، عملیات و امنیت را دنبال کنند، اما از مشتریان آموختیم که تلاش برای آموزش تفاوت‌های ظریف در مورد نحوه عملکرد Kubernetes یا گزینه‌های پیکربندی Redis به توسعه‌دهندگان، کارساز نبود. ما به راه بهتری برای توسعه‌دهندگان نیاز داشتیم تا «در چاله موفقیت بیفتند».

روسینوویچ به یک راننده دیگر اشاره کرد، یعنی رشد رشته های جدید:

“ما ظهور مهندسی پلتفرم را به عنوان یک رشته مشاهده کردیم. ما فکر می‌کنیم که Radius می‌تواند با ارائه نوعی پلت‌فرم سلف‌سرویس کمک کند که در آن توسعه‌دهندگان می‌توانند بهترین شیوه‌های شرکت را با استفاده از دستور العمل‌ها دنبال کنند، و دستور العمل‌ها فقط پوششی در اطراف ماژول‌های Terraform هستند که شرکت‌ها از قبل دارند. اگر این را درست انجام داده باشیم، فکر می‌کنیم این به تیم‌های فناوری اطلاعات و توسعه کمک می‌کند تا بهترین شیوه‌های مهندسی پلتفرم را پیاده‌سازی کنند، در حالی که به توسعه‌دهندگان کمک می‌کند روی چیزی که دوست دارند، یعنی کدنویسی تمرکز کنند.»

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

شروع با Radius

برای اجرای Radius به یک خوشه Kubernetes نیاز دارید که به عنوان یک برنامه Kubernetes اجرا می شود . با این حال، بیشتر عملیات Radius از طریق خط فرمانی انجام می شود که در زیر اکثر پوسته ها نصب می شود، از جمله پشتیبانی از هر دو ویندوز زیر سیستم برای Linux و PowerShell، و همچنین macOS. پس از نصب، می توانید با اجرای نسخه rad نصب را بررسی کنید. اکنون آماده شروع ساخت اولین برنامه تحت مدیریت Radius خود هستید.

از rad init دستور برای شروع Radius در زمینه فعلی خوشه توسعه، افزودن فضای نام آن و راه‌اندازی یک محیط برای شروع کار در همان زمان، rad init یک برنامه پیش‌فرض Radius را راه‌اندازی می‌کند و یک برنامه Bicep ایجاد می‌کند که یک ظرف آزمایشی را از مخزن Azure Radius بارگیری می‌کند. برای اجرای کانتینر آزمایشی، از دستور rad run برای راه‌اندازی برنامه زیرساخت Bicep استفاده کنید. این سرور Kubernetes را پیکربندی می‌کند و ظرف آزمایشی را که حاوی یک وب سرور اصلی است که یک برنامه وب ساده را اجرا می‌کند، راه‌اندازی می‌کند.

شما قفل استفاده از خط فرمان را ندارید، زیرا Radius با مجموعه‌ای از پسوندهای Visual Studio Code نیز کار می‌کند. واضح‌ترین قدم اول، افزودن پسوند Radius Bicep است. با پشتیبانی از منابع Azure و AWS. توجه داشته باشید که این با افزونه کامل Bicep یکسان نیست و با آن سازگار نیست. مایکروسافت قصد دارد پشتیبانی Radius را با افزونه رسمی Bicep ادغام کند، اما این کار کمی طول می‌کشد. می‌توانید از افزونه رسمی HashiCorp Terraform برای ایجاد و ویرایش دستور غذاها استفاده کنید.

زیر سرپوش یک نمودار Helm است که استقرار در سرورهای Kubernetes شما را مدیریت می کند، که شعاع از تعریف برنامه شما ایجاد می شود. این رویکرد به شما امکان می دهد با استفاده از فرآیندهای Helm موجود، برنامه ها را در Kubernetes مستقر کنید، حتی اگر از Radius برای مدیریت توسعه برنامه استفاده می کنید. می‌توانید برنامه‌ها و زیرساخت‌ها را با استفاده از Radius بسازید، خروجی‌ها را در یک رجیستری سازگار با OCI ذخیره کنید و از ابزارهای استقرار موجود برای ارائه کد در زیرساخت جهانی خود استفاده کنید. Radius بر اساس تعاریف Bicep، Helm YAML را برای شما تولید می کند.

اینها تقریباً برای یک برنامه اصلی ابری ساده است، جایی که می توانید از ابزارهای انتخابی خود برای ساخت ظروف و محتویات آنها استفاده کنید. با این حال، چیزی که با Radius جالب می شود زمانی است که شما شروع به اضافه کردن چیزی که مایکروسافت “دستور پخت” می نامد است. a> به کد Bicep. دستور العمل ها نحوه اتصال ظروف خود را به سرویس های پلت فرم معمول یا منابع خارجی، مانند پایگاه های داده، مشخص می کنند.

مدیریت خدمات پلت فرم با دستور العمل های Radius

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

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

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

Radius خارج از جعبه، مجموعه ای محلی از دستور العمل های اولیه را برای خدمات رایج ارائه می دهد. برای مثال، اگر می‌خواهید برنامه‌ای را به Azure OpenAI متصل کنید، یا یک فروشگاه شی تعریف کنید، یا به یک سرویس پرداخت پیوند دهید، می‌توانید از این‌ها به عنوان الگوهایی برای ساختن دستور العمل‌های خود استفاده کنید.

یک گزینه جالب استفاده از Radius برای ساخت داربست برای یک برنامه Dapr است. در اینجا شما برنامه خود را به عنوان یک منبع Dapr تعریف می کنید، با استفاده از دستور Radius برای پیوست کردن یک فروشگاه حالت با استفاده از پایگاه داده دلخواه خود. تعدادی ظروف نمونه Dapr را در مخزن Radius پیدا خواهید کرد تا به شما در شروع کار کمک کند.

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

رام کردن غرب وحشی بومی ابر

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

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

ما جستجوی Radius و بازیابی نمودار کامل برنامه را آسان می کنیم. یک شخص ثالث می تواند نمودار برنامه ما را با منبع داده دیگری مانند داده های تله متری یا داده های شبکه یکپارچه کند. دیدن این نمودارها در ارتباط با یکدیگر می تواند واقعاً قدرتمند باشد.

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

برای مثال، می‌توانیم به نحوه تعریف برنامه توسط یک توسعه‌دهنده در مقابل نحوه استقرار برنامه در تولید نگاه کنیم. […] داشتن یک نمودار برنامه به این تیم ها امکان می دهد تا در مورد نحوه تعریف برنامه و همچنین نحوه استقرار آن با هم کار کنند. هزینه یک بخش است، زیرساخت بخشی دیگر است، اما می‌توانیم همپوشانی‌های دیگری مانند عملکرد، نظارت و تجزیه و تحلیل ردیابی را تصور کنیم.

توسعه بومی ابری باید از دنیای کدهای دست ساز، به همان اندازه زیبا، به دنیایی که در آن بتوانیم اصول مهندسی قابل اعتماد و قابل اعتماد را به عنوان بخشی از کار روزمره خود اعمال کنیم، حرکت کند. به همین دلیل است که ورود پلتفرم هایی مانند Radius مهم است. نه تنها از مایکروسافت می آید، بلکه توسط Comcast، BlackRock، و بانک پرتغالی Millennium BCP، توسعه و استفاده می شود. به عنوان یک پروژه منبع باز در GitHub.

در پایان مکالمه ایمیل ما، مارک روسینوویچ نشان داد که چگونه پلتفرم Radius ممکن است تکامل یابد، همراه با مشارکت جامعه از طریق بنیاد محاسبات بومی ابری (CNCF). او گفت:

Radius چندین نقطه پسوند دارد. ما دوست داریم شرکای مانند Confluent یا MongoDB را ببینیم که در دستور العمل های Radius که Radius را با خدمات خود ادغام می کنند، مشارکت می کنند. ما همچنین فکر می‌کنیم که ارائه‌دهندگان ابری مانند AWS یا GCP می‌توانند نحوه کار Radius با ابرهای خود را گسترش دهند و پشتیبانی چند ابری را که ذاتی Radius است، بهبود بخشند. در نهایت، ما برنامه‌های افزودنی را برای پشتیبانی از محاسبات بدون سرور مانند نمونه‌های AWS Fargate و Azure Container تصور می‌کنیم.