🔵 عنوان مقاله
Most Cloud-Native Roles are Software Engineers

🟢 خلاصه مقاله:
این مقاله بازار کار cloud-native در سال ۲۰۲۵ را بررسی می‌کند و نشان می‌دهد که حدود ۴۷٪ از موقعیت‌های مرتبط با Kubernetes به عنوان Software Engineer آگهی می‌شوند؛ در حالی‌که نقش‌های DevOps، Platform، DevSecOps و SRE سهم کمتری دارند. این روند بیانگر استخدامِ مهندس‌محور و حرکت به‌سمت shift-left است: از توسعه‌دهندگان انتظار می‌رود علاوه بر توسعه، با Kubernetes و بخشی از زیرساخت، امنیت و تحویل نیز درگیر باشند. برای متقاضیان، تسلط بر Kubernetes همراه با مهارت‌های CI/CD، IaC، observability و اصول امنیت ضروری‌تر شده است و در عین حال همکاری نزدیک با تیم‌های DevOps/Platform/SRE همچنان اهمیت دارد.

#CloudNative #Kubernetes #SoftwareEngineering #DevOps #SRE #DevSecOps #PlatformEngineering #TechJobs2025

🟣لینک مقاله:
https://ku.bz/q44QpvhQ6

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Inside Duolingo's FinOps Journey: Turning Cloud Spend into Engineering Insight (3 minute read)

🟢 خلاصه مقاله:
خلاصه‌ای از مسیر FinOps در Duolingo نشان می‌دهد که این شرکت با وارد کردن آگاهی مالی به جریان کاری مهندسی، هزینه‌های ابری را به بینشی عملی برای توسعه‌دهندگان تبدیل کرده است. با نمایش بلادرنگِ اثر مالی تغییرات در کنار متریک‌های عملیاتی، استفاده از تگ‌گذاری و مالکیت منابع، هشدارهای خودکار و گاردریل‌های بودجه، و حتی مقایسه «cost diff» در CI/CD، تیم‌ها می‌توانند پیش از استقرار، پیامدهای هزینه‌ای انتخاب‌های معماری و کد را بسنجند. این رویکرد فرهنگ سازمان را به سمتی برده که «کارایی» هم‌سطح «عملکرد» و «پایداری» به‌عنوان یک معیار اصلی کیفیت دیده می‌شود و تصمیم‌گیری‌ها—از برنامه‌ریزی ظرفیت تا آزمایش و بازطراحی—با زبانی مشترک میان مهندسی و مالی انجام می‌گیرد. نتیجه، کاهش اتلاف، پیش‌بینی‌پذیری بهتر و سیستم‌هایی سریع، پایدار و آگاه از هزینه است.

#FinOps #CloudCost #Duolingo #CostOptimization #DevOps #EngineeringExcellence #CloudOps #SoftwareQuality

🟣لینک مقاله:
https://www.infoq.com/news/2025/10/duolingo-finops-engineering/?utm_source=tldrdevops

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
SR-IOV Network Device Plugin

🟢 خلاصه مقاله:
این افزونه با بهره‌گیری از SR-IOV امکان تخصیص مستقیم VFهای یک NIC فیزیکی به Podها را در Kubernetes فراهم می‌کند تا به کارایی نزدیک به سخت‌افزار، تأخیر پایین و سربار CPU کم برسند. افزونه به‌صورت DaemonSet روی نودها اجرا می‌شود، دستگاه‌های SR-IOV را کشف کرده و از طریق Device Plugin API به‌عنوان منابع قابل‌درخواست در اختیار kubelet می‌گذارد؛ با درخواست Pod یک VF به‌طور انحصاری تخصیص می‌یابد و جداسازی و پیش‌بینی‌پذیری کارایی تضمین می‌شود. پیکربندی شبکه با SR-IOV CNI و معمولاً Multus انجام می‌شود و بسته به نیاز، VF می‌تواند به درایورهایی مانند vfio-pci برای DPDK یا درایورهای کرنلی متصل شود؛ همچنین در صورت پشتیبانی سخت‌افزار، RDMA قابل استفاده است. استقرار نیازمند فعال‌سازی SR-IOV و IOMMU، NIC سازگار، ایجاد VFها و Linux است و در بسیاری از سناریوها SR-IOV Network Operator مدیریت خودکار و سیاست‌گذاری را ساده می‌کند. این راهکار برای CNFها، NFV، تحلیل بلادرنگ و محیط‌های با حساسیت بالا به تأخیر کاربردی است و به‌صورت استاندارد با اکوسیستم CNI در Kubernetes ادغام می‌شود.

#SRIOV #Kubernetes #CNI #Multus #DPDK #NFV #Networking #CloudNative

🟣لینک مقاله:
https://ku.bz/jVg_1VS-k

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

چجوری بفهمیم ایمیج‌های Docker کی نسخه جدید میدن

خیلی وقتا سرویس‌های داکری روی نسخه‌های قدیمی ایمیج می‌مونن و کسی هم به این زودی متوجه نمی‌شه!

برای همین ابزاری هست به اسم DIUN که کارش فقط یه چیزه:
بفهمه ایمیجی که داری استفاده می‌کنی، نسخه جدید داده یا نه.

حالا DIUN چطوری اینو تشخیص می‌ده؟

خیلی ساده:
به docker.sock وصل می‌شه، می‌فهمه چه کانتینرهایی داری و از چه ایمیج‌هایی استفاده می‌کنی. بعد Digest همونا رو با Digest رجیستری مقایسه می‌کنه :)))
اگر فرق داشت، یعنی نسخهٔ جدید منتشر شده.

برای استفاده هم فقط کافیه یه کانتینر DIUN کنار سرویس‌هات بیاری بالا.

حالا DIUN میتونه خروجی رو به هرجایی که API میده بفرسته:
تلگرام، Slack و...

جزئیاتش اینجاست:
https://hashbang.nl/blog/receive-notifications-when-updates-to-docker-images-are-released-using-diun

البته تو محیط‌های بزرگ تر معمولاً از ابزارهایی مثل Renovate یا watchtower استفاده می‌کنن،
ولی DIUN یه گزینه راحت و کار راه اندازه برای اینکه سریع بفهمی ایمیج جدید اومده یا نه!

@ | <Amir Haji Mohammad Sadegh/>

🔵 عنوان مقاله
Using LLMs to filter out false positives from static code analysis (5 minute read)

🟢 خلاصه مقاله:
**Datadog قابلیت فیلتر هوشمند «مثبت کاذب» را به ابزار Static Code Analysis اضافه کرده است. این ویژگی با تکیه بر Bits AI و LLMها، یافته‌های امنیتی را به «احتمالاً واقعی» یا «احتمالاً مثبت کاذب» دسته‌بندی می‌کند تا نویز کاهش یابد، تریاژ سریع‌تر شود و تیم‌های توسعه و امنیت بتوانند روی آسیب‌پذیری‌های واقعاً مهم تمرکز کنند و رفع آن‌ها را سریع‌تر پیش ببرند.

#StaticCodeAnalysis #Datadog #BitsAI #LLM #DevSecOps #ApplicationSecurity #CodeScanning #FalsePositives

🟣لینک مقاله:
https://www.datadoghq.com/blog/using-llms-to-filter-out-false-positives/?utm_source=tldrdevops

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
How We Rebuilt Our Vault Architecture with Raft, Snapshots, and DR

🟢 خلاصه مقاله:
ما معماری Vault را با تکیه بر سه رکن Raft، Snapshots و DR بازطراحی کردیم تا پیچیدگی عملیاتی را کاهش دهیم، وابستگی‌های بیرونی را حذف کنیم و تاب‌آوری را افزایش دهیم. با مهاجرت به ذخیره‌سازی یکپارچه مبتنی بر Raft، کلاستر ساده‌تر و قابل‌اعتمادتر شد و مسیر مهاجرت با محیط staging، تمرین‌های بازیابی، معیارهای rollback و پایش لحظه‌ای کنترل شد. Snapshots به‌طور خودکار زمان‌بندی و رمزنگاری شدند، در فضای ذخیره‌سازی ایمن نگهداری و با تمرین‌های دوره‌ای بازیابی راستی‌آزمایی شدند تا RPO شفاف و بازیابی قابل پیش‌بینی باشد. برای DR یک کلاستر ثانویه در دامنه خرابی جدا راه‌اندازی و با تکرار DR، برنامه failover با RTO مشخص و مانیتورینگ تأخیر تکرار، سلامت Raft و تازگی Snapshotها پیاده‌سازی شد. با امنیت لایه‌به‌لایه، least-privilege برای مقصد پشتیبان، مستندسازی و خودکارسازی بررسی‌ها، به عملیات پایدارتر و بازیابی سریع‌تر رسیدیم و اطمینان به سکوی مدیریت اسرار افزایش یافت.

#Vault #Raft #DisasterRecovery #Snapshots #DevOps #SRE #HighAvailability #Infrastructure

🟣لینک مقاله:
https://ku.bz/zPwwpmMyV

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Debugging the One-in-a-Million Failure: Migrating Pinterest’s Search Infrastructure to Kubernetes

🟢 خلاصه مقاله:
** این مقاله روایت مهاجرت زیرساخت جست‌وجوی Pinterest به Kubernetes است و چگونگی برخورد تیم با یک خطای بسیار نادر را شرح می‌دهد؛ خطایی که در محیط‌های آزمایشی دیده نمی‌شد اما در بار واقعی تولید، به‌صورت افزایش‌های مقطعی در تاخیر و تایم‌اوت‌های پراکنده بروز می‌کرد. تیم با تقویت مشاهده‌پذیری، هم‌بند کردن لاگ‌ها، متریک‌ها و تریس‌ها، و اجرای آزمایش‌های کنترل‌شده و تدریجی روی پیکربندی‌ها، مسئله را مانند یک معمای سیستم‌های توزیع‌شده واکاوی کرد. نتیجه نشان داد مشکل ناشی از برهم‌کنش چند عامل بود: زمان‌بندی ارکستریشن، محدودیت‌های منابع، و سیاست‌های retry/timeout که در شرایط خاص همدیگر را تقویت می‌کردند. راه‌حل شامل مجموعه‌ای از بهبودهای کوچک اما مکمل بود—از تنظیم دقیق درخواست/سقف منابع و آماده‌سازی سرویس تا هموار کردن رفتار autoscaling، بهینه‌سازی زمان‌بندی readiness، و مقاوم‌سازی سیاست‌های backoff و فشار معکوس. درس‌های کلیدی نیز بر مهاجرت‌های مبتنی بر SLO، آینه‌سازی ترافیک تولید، آزمایش خرابی متمرکز بر رخدادهای Kubernetes، و اتوماسیون علائم هشداردهنده برای تشدیدهای نادر تاکید دارند. در نهایت، مهاجرت مزایای مقیاس‌پذیری و یکنواختی استقرار را به‌همراه داشت و نشان داد که در مقیاس بزرگ، رخدادهای «یک در میلیون» باید به‌طور نظام‌مند دیده، سنجیده و مهار شوند.

#Kubernetes #Pinterest #SearchInfrastructure #DistributedSystems #Debugging #ReliabilityEngineering #Migration #ProductionIncidents

🟣لینک مقاله:
https://ku.bz/BS18f9fpM

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

مدل opus 4.5 دیروز اومد. بینظیره. بهترین مدل دنیا برای coding با اختلاف زیاد.
یک اتفاق مهم دیگه اینکه Anthropic برای اولین بار قیمت بهترین مدل خودش رو به یک سوم تا یک پنجم قیمت قبلی کاهش داده!!
هر میلیون اینپوت از ۲۵ دلار شده ۵ دلار و هر میلیون output هم از ۷۵ دلار شده ۱۵ دلار!

<Amin Anvary/>

👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0

🔵 عنوان مقاله
How to Prevent Failures with Kubernetes Topology Spread Constraints

🟢 خلاصه مقاله:
این مقاله نشان می‌دهد چرا استفاده از Pod Topology Spread Constraints در زمان rolling updates می‌تواند باعث توزیع ناعادلانه پادها شود و در پایان استقرار، یک یا چند ناحیه بیش‌ازحد شلوغ بماند. علت این است که Scheduler در هنگام جای‌گذاری پادهای جدید، پادهای قدیمی و جدید را با هم در نظر می‌گیرد؛ بنابراین پادهای تازه را به نواحی «فعلاً» کم‌تراکم می‌فرستد، اما با حذف تدریجی پادهای قدیمی، همان نواحی از نسخه جدید اشباع می‌شوند.

راه‌حل پیشنهادی استفاده از matchLabelKeys (برای نمونه با کلید pod-template-hash) است تا Scheduler هر نسل از پادها را فقط نسبت به هم‌نسل‌های خودش پخش کند. بدین ترتیب هر ReplicaSet به‌طور مستقل متعادل می‌شود و چون نسل قبلی نیز از قبل متعادل بوده، مجموع پادها در طول و پس از rollout یکنواخت باقی می‌ماند.

برای اجرای درست، از پشتیبانی Kubernetes v1.25+ نسبت به matchLabelKeys مطمئن شوید، topologyKey مناسب (مثلاً topology.kubernetes.io/zone) و maxSkew معقول انتخاب کنید و سیاست whenUnsatisfiable را بسته به نیاز سخت‌گیرانه (DoNotSchedule) یا منعطف (ScheduleAnyway) تنظیم کنید.

#Kubernetes #PodTopologySpreadConstraints #TopologySpread #RollingUpdates #DevOps #SRE #HighAvailability #matchLabelKeys

🟣لینک مقاله:
https://ku.bz/RypzHZTrM

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Bringing Node.js HTTP servers to Cloudflare Workers (4 minute read)

🟢 خلاصه مقاله:
** Cloudflare Workers با افزودن APIهای client و server از طریق node:http و با فعال‌سازی پرچم nodejs_compat، امکان اجرای مستقیم برنامه‌های Node.js را فراهم کرده است. این قابلیت پلی بین مدل سرورهای سبک Node.js (مانند http.createServer و الگوی req/res) و مدل رسیدگی به درخواست در Workers می‌سازد؛ در این روش، شماره پورت به‌عنوان شناسه برای نگاشت سرور Node.js به خط لوله داخلی درخواست‌ها استفاده می‌شود. نتیجه این است که برنامه‌های مبتنی بر Express.js و Koa می‌توانند بدون بازنویسی اساسی، به‌صورت سراسری روی لبه اجرا شوند و از مزایای zero cold start و مقیاس‌پذیری خودکار بهره ببرند.

#CloudflareWorkers #Nodejs #Express #Koa #Serverless #EdgeComputing #HTTP #JavaScript

🟣لینک مقاله:
https://blog.cloudflare.com/bringing-node-js-http-servers-to-cloudflare-workers/?utm_source=tldrdevops

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon