نگاهی به فناوری دهه گذشته

توجه داشته باشید. ترجمه: این مقاله که در Medium محبوب شد، مروری است بر تغییرات کلیدی (2010-2019) در دنیای زبان های برنامه نویسی و اکوسیستم فناوری مرتبط (با تمرکز ویژه بر Docker و Kubernetes). نویسنده اصلی آن Cindy Sridharan است که در ابزارهای توسعه‌دهنده و سیستم‌های توزیع‌شده متخصص است - به‌ویژه او کتاب «Resectability Systems Distributed» را نوشت - و در فضای اینترنت در بین متخصصان فناوری اطلاعات، به ویژه علاقه‌مند به موضوع بومی ابر، بسیار محبوب است.

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

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

تایپ‌سازی جواب می‌دهد

یکی از مثبت ترین روندهای دهه 2010، احیای زبان های تایپ ایستا بود. با این حال، چنین زبان هایی هرگز ناپدید نشدند (C++ و جاوا امروزه مورد تقاضا هستند؛ آنها ده سال پیش غالب بودند)، اما زبان های تایپ پویا (دینامیک) پس از ظهور جنبش Ruby on Rails در سال 2005، محبوبیت قابل توجهی را تجربه کردند. . این رشد در سال 2009 با منبع باز Node.js به اوج خود رسید که جاوا اسکریپت روی سرور را به واقعیت تبدیل کرد.

با گذشت زمان، زبان های پویا بخشی از جذابیت خود را در زمینه ایجاد نرم افزار سرور از دست داده اند. زبان Go که در طول انقلاب کانتینر رایج شد، برای ایجاد سرورهایی با کارایی بالا و منابع کارآمد با پردازش موازی (که با آن موافقم خود خالق Node.js).

Rust که در سال 2010 معرفی شد، شامل پیشرفت هایی در نظریه های نوع در تلاش برای تبدیل شدن به یک زبان امن و تایپ شده. در نیمه اول دهه، استقبال صنعت از Rust نسبتاً ولرم بود، اما محبوبیت آن در نیمه دوم به طور قابل توجهی افزایش یافت. موارد استفاده قابل توجه برای Rust شامل استفاده از آن برای جیب جادویی در Dropbox, Firecracker توسط AWS (ما در مورد آن صحبت کردیم این مقاله - تقریبا ترجمه.)، یک کامپایلر اولیه WebAssembly لوست از Fastly (در حال حاضر بخشی از bytecodealliance) و غیره. با توجه به اینکه مایکروسافت امکان بازنویسی برخی از قسمت های سیستم عامل ویندوز در Rust را در نظر گرفته است، می توان به جرات گفت که این زبان آینده درخشانی در دهه 2020 دارد.

حتی زبان های پویا نیز ویژگی های جدیدی مانند انواع اختیاری (انواع اختیاری). آنها ابتدا در TypeScript پیاده سازی شدند، زبانی که به شما امکان می دهد کد تایپ شده ایجاد کرده و آن را در جاوا اسکریپت کامپایل کنید. PHP، Ruby و Python سیستم های تایپ اختیاری خود را دارند (mypy, مزدور) که با موفقیت در استفاده می شوند تولید.

برگرداندن SQL به NoSQL

NoSQL فناوری دیگری است که در ابتدای دهه بسیار محبوبتر از اواخر دهه بود. من فکر می کنم دو دلیل برای این وجود دارد.

اولاً، مدل NoSQL، با فقدان طرحواره، تراکنش‌ها و ضمانت‌های سازگاری ضعیف‌تر، پیاده‌سازی دشوارتر از مدل SQL بود. که در پست وبلاگ با عنوان "چرا باید هر زمان که ممکن است ثبات قوی را ترجیح دهید" (چرا هر زمان که ممکن است باید قوام قوی را انتخاب کنید) گوگل می نویسد:

یکی از چیزهایی که در گوگل آموخته ایم این است که وقتی مهندسان می توانند برای مدیریت تراکنش های پیچیده و مرتب نگه داشتن داده ها به فضای ذخیره سازی موجود اعتماد کنند، کد برنامه ساده تر و زمان توسعه کوتاه تر است. برای نقل قول از مستندات اصلی Spanner، "ما معتقدیم که بهتر است برنامه نویسان با مشکلات عملکرد برنامه به دلیل سوء استفاده از تراکنش ها به عنوان گلوگاه ها مقابله کنند، نه اینکه دائماً عدم وجود تراکنش ها را در نظر داشته باشند."

دلیل دوم به دلیل ظهور پایگاه‌های داده SQL توزیع‌شده «مقیاس‌شده» است (مانند آچار ابری и AWS شفق قطبی) در فضای ابر عمومی، و همچنین جایگزین های منبع باز مانند CockroachDB (ما در مورد او نیز صحبت می کنیم писали - تقریبا ترجمه.)، که بسیاری از مشکلات فنی را حل می کند که باعث می شد پایگاه داده های SQL سنتی "مقیاس" نشوند. حتی MongoDB که زمانی مظهر جنبش NoSQL بود، در حال حاضر است پیشنهادات معاملات توزیع شده

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

کل جریان

آپاچی کافکا بدون شک یکی از مهم ترین اختراعات دهه گذشته است. کد منبع آن در ژانویه 2011 باز شد، و در طول سال ها، کافکا روش کار تجارت با داده ها را متحول کرده است. کافکا در هر شرکتی که من در آن کار کرده ام، از استارت آپ ها گرفته تا شرکت های بزرگ، استفاده شده است. تضمین‌ها و موارد استفاده‌ای که ارائه می‌کند (pub-sub، جریان‌ها، معماری‌های رویداد محور) در وظایف مختلفی، از ذخیره‌سازی داده‌ها تا نظارت و تجزیه و تحلیل جریان، مورد تقاضا در بسیاری از زمینه‌ها مانند امور مالی، مراقبت‌های بهداشتی، بخش عمومی، استفاده می‌شوند. خرده فروشی و غیره

ادغام مداوم (و تا حدی استقرار مداوم)

ادغام مداوم در 10 سال گذشته ظاهر نشد، اما در دهه گذشته ظاهر شد تا این حد گسترش یافته است، که بخشی از گردش کار استاندارد شد (آزمایش ها را روی همه درخواست های کششی اجرا کنید). ایجاد GitHub به عنوان یک پلت فرم برای توسعه و ذخیره کد و مهمتر از آن، توسعه یک گردش کار بر اساس جریان GitHub به این معنی است که اجرای تست ها قبل از پذیرش یک درخواست کشش به استاد است تک تک گردش کار در توسعه، آشنا برای مهندسانی که در ده سال گذشته کار خود را آغاز کرده اند.

استقرار پیوسته (استقرار هر commit در زمانی که به master برخورد می کند) به اندازه ادغام پیوسته گسترده نیست. با این حال، با وجود انبوهی از APIهای ابری مختلف برای استقرار، محبوبیت روزافزون پلتفرم‌هایی مانند Kubernetes (که یک API استاندارد شده برای استقرار ارائه می‌کنند)، و ظهور ابزارهای چند پلتفرمی و چند ابری مانند Spinnaker (ساخته شده در بالای موارد استاندارد شده) APIها)، فرآیندهای استقرار خودکار، ساده‌تر، و به طور کلی امن‌تر شده‌اند.

ظروف

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

کانتینرها محبوب شده اند نه به این دلیل که بهترین راه برای اجرای برنامه ای هستند که نیازهای جامعه توسعه دهندگان جهانی را برآورده می کند. کانتینرها به این دلیل محبوب شدند که با موفقیت در یک درخواست بازاریابی برای ابزار خاصی قرار می گیرند که یک مشکل کاملاً متفاوت را حل می کند. داکر معلوم شد خارق العاده یک ابزار توسعه که مشکل سازگاری فوری را حل می کند ("روی ماشین من کار می کند").

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

بدون سرور

من شرط می بندم که ظهور محاسبات "بدون سرور" حتی مهم تر از کانتینرها است زیرا واقعا رویای محاسبات بر اساس تقاضا را به واقعیت تبدیل می کند. (بر اساس تقاضا). در طول پنج سال گذشته، من دیدم که رویکرد بدون سرور به تدریج با افزودن پشتیبانی از زبان‌ها و زمان‌های اجرا جدید گسترش یافته است. به نظر می رسد ظهور محصولاتی مانند Azure Durable Functions گام درستی برای اجرای عملکردهای حالت دار (در عین حال تعیین کننده) باشد. برخی از مشکلاتمربوط به محدودیت های FaaS). من با علاقه تماشا خواهم کرد که چگونه این پارادایم جدید در سال های آینده توسعه می یابد.

اتوماسیون

شاید بزرگترین ذینفع از این روند، جامعه مهندسی عملیات باشد، زیرا مفاهیمی مانند زیرساخت به عنوان کد (IaC) را به واقعیت تبدیل کرده است. علاوه بر این، اشتیاق به اتوماسیون با ظهور «فرهنگ SRE» همزمان شده است، که هدف آن اتخاذ رویکرد نرم‌افزار محور به عملیات است.

افسانه جهانی API

یکی دیگر از ویژگی های جالب دهه گذشته، API-fication وظایف توسعه مختلف بوده است. APIهای خوب و منعطف به توسعه‌دهنده اجازه می‌دهند تا گردش‌های کاری و ابزارهای نوآورانه ایجاد کند که به نوبه خود به نگهداری و بهبود تجربه کاربر کمک می‌کند.

علاوه بر این، API-fication اولین گام به سمت SaaS-fication برخی از قابلیت ها یا ابزارها است. این روند همچنین با افزایش محبوبیت میکروسرویس‌ها همزمان شد: SaaS به سرویس دیگری تبدیل شده است که می‌توان از طریق API به آن دسترسی داشت. در حال حاضر ابزارهای SaaS و FOSS زیادی در زمینه‌هایی مانند نظارت، پرداخت‌ها، تعادل بار، ادغام مداوم، هشدارها، سوئیچینگ ویژگی‌ها در دسترس هستند. (پرچم گذاری ویژگی)، CDN، مهندسی ترافیک (به عنوان مثال DNS)، و غیره، که در دهه گذشته شکوفا شده اند.

قابلیت مشاهده

شایان ذکر است که امروز ما به آن دسترسی داریم بسیار پیشرفته تر ابزارهایی برای نظارت و تشخیص رفتار برنامه از هر زمان دیگری. شاید بتوان سیستم نظارتی Prometheus را که در سال 2015 وضعیت منبع باز دریافت کرد بهترین سیستم نظارت از کسانی که با آنها کار کرده ام. این کامل نیست، اما تعداد قابل توجهی از چیزها دقیقاً به روش صحیح اجرا می شوند (به عنوان مثال، پشتیبانی از اندازه گیری ها [بعدی] در مورد معیارها).

ردیابی توزیع شده فناوری دیگری بود که در دهه 2010 به لطف ابتکاراتی مانند OpenTracing (و جانشین آن OpenTelemetry) وارد جریان اصلی شد. اگرچه هنوز اعمال ردیابی بسیار دشوار است، برخی از آخرین پیشرفت‌ها این امیدواری را ایجاد می‌کند که پتانسیل واقعی آن را در دهه 2020 باز کنیم. (توجه: ترجمه مقاله را در وبلاگ ما نیز بخوانیدردیابی توزیع شده: ما همه آن را اشتباه انجام دادیم"توسط همان نویسنده.)

نگاه به آینده

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

حل مسئله قانون مور

پایان قانون مقیاس بندی دنارد و عقب ماندن از قانون مور نیاز به نوآوری های جدیدی دارد. جان هنسی در سخنرانی او توضیح می دهد که چرا معتادان مشکل دارند (مخصوص دامنه) معماری هایی مانند TPU ممکن است یکی از راه حل های مشکل عقب ماندن از قانون مور باشد. جعبه ابزار مانند MLIR به نظر می رسد گوگل در حال حاضر گام خوبی به جلو در این مسیر است:

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

CI / CD

در حالی که افزایش CI به یکی از بزرگترین روندهای دهه 2010 تبدیل شده است، جنکینز هنوز استاندارد طلایی برای CI است.

این فضا نیاز مبرمی به نوآوری در زمینه های زیر دارد:

• رابط کاربری (DSL برای رمزگذاری مشخصات تست)؛
• جزئیات پیاده سازی که آن را واقعاً مقیاس پذیر و سریع می کند.
• ادغام با محیط های مختلف (استیجینگ، تولید، و غیره) برای اجرای اشکال پیشرفته تر تست.
• آزمایش و استقرار مداوم

ابزارهای توسعه دهنده

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

ویرایش مشارکتی و از راه دور (از طریق ssh) محبوبیت زیادی به دست آورد، اما هرگز به روش استاندارد جدید توسعه تبدیل نشد. اگر شما هم مثل من این ایده را رد کنید نیاز اتصال دائمی به اینترنت فقط برای اینکه بتوانید برنامه نویسی کنید، بعید است که کار از طریق ssh روی یک ماشین راه دور مناسب شما باشد.

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

همچنین جالب است که مفهوم "محیط های قابل حمل" را به سایر زمینه های توسعه مانند تولید مثل باگ (یا تست های پوسته پوسته شدن) که تحت شرایط یا تنظیمات خاصی رخ می دهد.

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

محاسبات (آینده PaaS)

به دنبال هیاهوی تبلیغاتی پیرامون کانتینرها و بدون سرور در دهه 2010، طیف راه حل ها در فضای ابری عمومی در چند سال اخیر به طور قابل توجهی گسترش یافته است.

این چند سوال جالب را ایجاد می کند. اول از همه، لیست گزینه های موجود در ابر عمومی به طور مداوم در حال افزایش است. ارائه‌دهندگان خدمات ابری کارکنان و منابع لازم را دارند تا به راحتی با آخرین پیشرفت‌ها در جهان منبع باز همراه شوند و محصولاتی مانند "غلاف‌های بدون سرور" (من گمان می‌کنم صرفاً با سازگاری با زمان اجرا FaaS خود با OCI) یا چیزهای دیگر مشابه منتشر کنند.

فقط می توان به کسانی که از این راه حل های ابری استفاده می کنند حسادت کرد. در تئوری، پیشنهادات ابری Kubernetes (GKE، EKS، EKS در Fargate، و غیره) APIهای مستقل از ارائه دهنده ابر را برای اجرای بارهای کاری ارائه می دهند. اگر از محصولات مشابه (ECS، Fargate، Google Cloud Run و غیره) استفاده می‌کنید، احتمالاً در حال حاضر از جالب‌ترین ویژگی‌های ارائه‌شده توسط ارائه‌دهنده خدمات استفاده می‌کنید. علاوه بر این، با ظهور محصولات جدید یا پارادایم های محاسباتی، مهاجرت به احتمال زیاد ساده و بدون استرس خواهد بود.

با توجه به سرعت تکامل دامنه چنین راه حل هایی (من بسیار شگفت زده خواهم شد اگر چند گزینه جدید در آینده نزدیک ظاهر نشوند)، تیم های کوچک "پلتفرم" (تیم های مرتبط با زیرساخت ها و مسئول ایجاد پلت فرم های داخلی برای در حال اجرا شرکت‌های دارای حجم کاری) رقابت از نظر عملکرد، سهولت استفاده و قابلیت اطمینان کلی بسیار دشوار خواهد بود. در دهه 2010 Kubernetes به عنوان یک ابزار PaaS (پلتفرم به عنوان یک سرویس) دیده می شد، بنابراین برای من منطقی نیست که یک پلتفرم داخلی مبتنی بر Kubernetes بسازم که همان انتخاب، سادگی و آزادی را در دسترس عموم قرار دهد. فضای ابری قاب‌بندی PaaS مبتنی بر کانتینر به‌عنوان «استراتژی Kubernetes» به منزله اجتناب عمدی از خلاقانه‌ترین قابلیت‌های ابر است.

اگر به موجودی نگاه کنید امروز با قابلیت‌های محاسباتی، بدیهی است که ایجاد PaaS خود را صرفاً بر اساس Kubernetes به‌مثابه ترسیم کردن خود در گوشه‌ای است (نه یک رویکرد آینده‌نگر، نه؟). حتی اگر کسی امروز تصمیم بگیرد یک PaaS کانتینری بر روی Kubernetes بسازد، چند سال دیگر در مقایسه با قابلیت‌های ابری قدیمی به نظر می‌رسد. اگرچه Kubernetes به عنوان یک پروژه منبع باز شروع به کار کرد، جد و الهام بخش آن یک ابزار داخلی گوگل است. با این حال، در ابتدا در اوایل / اواسط دهه 2000 توسعه یافت، زمانی که چشم انداز محاسباتی کاملاً متفاوت بود.

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

در نهایت، من احساس می کنم که ما به عنوان یک صنعت کمی پسرفت کرده ایم تجربه تعامل (UX). Heroku در سال 2007 راه اندازی شد و هنوز هم یکی از بهترین هاست آسان برای استفاده بستر، زمینه. نمی توان انکار کرد که Kubernetes بسیار قدرتمندتر، توسعه پذیرتر و قابل برنامه ریزی است، اما من دلتنگ آسانی شروع و استقرار در Heroku هستم. برای استفاده از این پلتفرم فقط باید Git را بشناسید.

همه اینها من را به این نتیجه می رساند: ما برای کار به انتزاعات بهتر و سطح بالاتر نیاز داریم (این به ویژه برای انتزاعات بالاترین سطح).

API مناسب در بالاترین سطح

داکر یک مثال عالی از نیاز به تفکیک بهتر نگرانی ها در همان زمان است اجرای صحیح API بالاترین سطح.

مشکل داکر این است که (حداقل) در ابتدا این پروژه اهداف بسیار گسترده ای داشت: همه به خاطر حل مشکل سازگاری ("روی ماشین من کار می کند") با استفاده از فناوری کانتینر. Docker یک فرمت تصویر، یک زمان اجرا با شبکه مجازی خود، یک ابزار CLI، یک دیمون در حال اجرا به عنوان روت و بسیاری موارد دیگر بود. در هر صورت تبادل پیام بود بیش گیج کننده، بدون ذکر "VM های سبک وزن"، cgroup ها، فضاهای نام، مسائل امنیتی متعدد و ویژگی های آمیخته با فراخوان بازاریابی برای "ساخت، ارائه، اجرای هر برنامه در هر کجا".

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

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

داکر بود (و هنوز هم هست) سرد ابزار توسعه، با وجود تمام کاستی هایش. در تلاش برای همگام شدن با همه "خرگوش ها" به طور همزمان، توسعه دهندگان آن موفق به پیاده سازی صحیح شدند انتزاع در بالاترین سطح. منظور من از انتزاع در بالاترین سطح است زیرمجموعه عملکردی که مخاطب هدف (در این مورد، توسعه دهندگانی که بیشتر وقت خود را در محیط های توسعه محلی خود سپری می کنند) واقعاً به آن علاقه مند بودند و به خوبی کار می کرد..

ابزار Dockerfile و CLI docker باید نمونه ای از نحوه ایجاد یک "تجربه کاربری در بالاترین سطح" خوب باشد. یک توسعه‌دهنده معمولی می‌تواند بدون اطلاع از پیچیدگی‌ها، کار با Docker را شروع کند پیاده سازی هایی که به تجربه عملیاتی کمک می کنندمانند فضاهای نام، cgroup ها، محدودیت های حافظه و CPU و غیره. در نهایت، نوشتن Dockerfile تفاوت زیادی با نوشتن یک اسکریپت پوسته ندارد.

Kubernetes برای گروه های هدف مختلف در نظر گرفته شده است:

• مدیران خوشه؛
• مهندسان نرم افزاری که روی مسائل زیرساخت کار می کنند، قابلیت های Kubernetes را گسترش می دهند و پلتفرم هایی بر اساس آن ایجاد می کنند.
• کاربران نهایی در حال تعامل با Kubernetes از طریق kubectl.

رویکرد "یک API متناسب با همه" Kubernetes یک "کوه پیچیدگی" به اندازه کافی محصور نشده و هیچ راهنمایی در مورد چگونگی مقیاس آن ارائه نمی دهد. همه اینها منجر به طولانی شدن مسیر یادگیری غیر قابل توجیه می شود. چگونه می نویسد: آدام جیکوب، «Docker یک تجربه کاربری متحول کننده به ارمغان آورد که هرگز از آن فراتر نرفت. از هر کسی که از K8 استفاده می کند بپرسید که آیا مایل است مانند اولین آنها کار کند docker run. پاسخ مثبت خواهد بود":

من استدلال می‌کنم که بیشتر فناوری‌های زیرساختی امروزی بسیار سطح پایین هستند (و بنابراین "بیش از حد پیچیده" در نظر گرفته می‌شوند). Kubernetes در سطح نسبتاً پایینی پیاده سازی شده است. ردیابی در آن توزیع شده است فرم فعلی (بسیاری از دهانه ها به هم دوخته شده اند تا یک نمای ردیابی را تشکیل دهند) نیز در سطح بسیار پایین پیاده سازی شده است. ابزارهای توسعه‌دهنده‌ای که «بالاترین سطوح انتزاعی» را پیاده‌سازی می‌کنند، موفق‌ترین هستند. این نتیجه‌گیری در تعداد شگفت‌انگیزی از موارد صادق است (اگر استفاده از فناوری بسیار پیچیده یا دشوار است، «بالاترین سطح API/UI» برای آن فناوری هنوز کشف نشده است).

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

تجارت خرده فروشی

در دهه 2010، تجربه خرده فروشی دیجیتال تا حد زیادی بدون تغییر باقی ماند. از یک طرف، سهولت خرید آنلاین باید به فروشگاه های خرده فروشی سنتی ضربه می زد، از طرف دیگر، خرید آنلاین اساساً در یک دهه تقریباً بدون تغییر باقی مانده است.

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

روزنامه نگاری

من به طور فزاینده ای از وضعیت روزنامه نگاری جهانی سرخورده می شوم. یافتن منابع خبری بی طرف که به طور عینی و دقیق گزارش می دهند، روز به روز دشوارتر می شود. خیلی اوقات مرز بین خود اخبار و نظرات در مورد آن مبهم است. به عنوان یک قاعده، اطلاعات به شیوه ای مغرضانه ارائه می شود. این امر به ویژه در برخی از کشورها که از نظر تاریخی هیچ گونه جدایی بین اخبار و نظر وجود نداشته است، صادق است. در مقاله ای که اخیراً پس از آخرین انتخابات سراسری بریتانیا منتشر شد، آلن راسبریجر، سردبیر سابق گاردین، می نویسد::

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

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

شبکه های اجتماعی

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

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

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

نمی دانم آیا می توان یک پلتفرم «بهتر» ایجاد کرد که بحث های با کیفیت بهتری را ترویج کند؟ به هر حال، این چیزی است که باعث "تعامل" می شود که اغلب سود اصلی را برای این پلتفرم ها به ارمغان می آورد. چگونه می نویسد: کارا سویشر در نیویورک تایمز:

امکان توسعه تعاملات دیجیتالی بدون برانگیختن نفرت و عدم تحمل وجود دارد. دلیل اینکه اکثر سایت‌های رسانه‌های اجتماعی بسیار سمی به نظر می‌رسند این است که به‌جای محتوا و دقت، برای سرعت، ویروسی بودن و توجه ساخته شده‌اند.

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

PS از مترجم

در وبلاگ ما نیز بخوانید:

• «تحول Docker: فروش Docker Enterprise به Mirantis و یک مسیر به روز شده"؛
• «گذشته، حال و آینده Docker و سایر زمان‌های اجرای کانتینر در Kubernetes"؛
• «آمار جدید CNCF در مورد کانتینرها، ابر بومی و Kubernetes"؛
• «چند نفر از توسعه دهندگان فکر می کنند که یکپارچه سازی مداوم مورد نیاز نیست؟'.

منبع: www.habr.com