بنابراین شما می خواهید ارائه دهندگان ابر را تغییر دهید

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

من باید بهتر از این بدانم که در جستجوی خرد به جمعیت اخبار هکر باشم. اخیراً شخصی در HN سوال جالبی پرسید: “آیا تا به حال ابرها را تغییر داده اید؟” با توجه به HN، پاسخ ها چندان جالب نبودند. در واقع، افراد نسبتاً کمی اصلاً به این سؤال پاسخ دادند و ترجیح دادند به جای آن از اجرای برنامه های خود در مراکز داده خصوصی حمایت کنند. دیگران توصیه هایی را برای فروشگاه های کوچک و نه شرکت های بزرگتر ارائه کردند.

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

اعتبارات را به من نشان دهید

وقتی شرکت‌ها تصمیم گرفتند بر روی یک ابر خاص بسازند، چه چیزی آنها را وادار به حرکت می‌کند؟ با خواندن پاسخ های HN، “اعتبارات” یک محرک اصلی هستند. مشخص نیست که چنین هانی‌پات چقدر برای شرکت‌های بزرگ‌تر جذاب است، اما برای جمعیت‌شناسی معین، مهاجرت می‌تواند با «اعتبارات Google Cloud [یا Azure یا AWS] کافی برای ایجاد یک سوئیچ ارزشمند» انگیزه داشته باشد. متأسفانه، همانطور که دیوید لینتیکوم به تفصیل بیان کرده است، این نوع ساده تحلیل هزینه/فایده تمام هزینه های پنهان اجرای در فضای ابری را نادیده می گیرد.

همانطور که GitLab ظاهراً کشف شد، اعتبارها ممکن است مهاجرت را تشویق کنند، اما لزوماً هزینه ای ندارند برای این. همانطور که در نظر HN توضیح داده شد، “در GitLab، ما از AWS به Azure و سپس به Google Cloud رفتیم.” چرا در وهله اول AWS را کنار بگذارید؟ مسئله پول بود، اما نه به این دلیل که AWS ذاتاً گران‌تر بود. در عوض، این یک مشکل با راه‌اندازی بود: «مانند اکثر شرکت‌ها، توجه بسیار کمی به هزینه‌ها، راه‌اندازی و غیره [هنگام شروع با AWS] انجام شد. نتیجه این بود که ما اساساً پول را آتش می زدیم.» در کنار آن، پیشنهادی برای اعتبار رایگان Azure ارائه شد که “می تواند چیزی شبیه به ارزش یک سال در صورتحساب ها (در آن زمان کمی پول) برای ما ذخیره کند.”

عالی به نظر می رسد، درست است؟ “انتقال نسبتاً دردناک بود و … ما اعتبارات رایگان را خیلی سریع جبران کردیم.” سپس شرکت تصمیم گرفت (به دلایل غیرقابل توضیح) به Google Cloud برود و متوجه شد که مهاجرت دوباره یک “فرآیند چالش برانگیز” است.

نظر دهنده از این تجربه چه آموخت؟ «با نگاهی به گذشته، اگر بخواهم شرکتی را راه‌اندازی کنم، احتمالاً به چیزی مانند Hetzner یا یکی دیگر از ارائه‌دهندگان فلزی مقرون‌به‌صرفه پایبند می‌شوم. سرویس‌های ابری عالی هستند اگر از خدمات آن‌ها تا حد ممکن استفاده کنید، اما من در ۹۰٪ موارد مشکوک هستم، بدون اینکه مزایا ارزش آن را داشته باشد، به یک فاکتور هزینه بزرگ تبدیل می‌شود.

از نظر من، این درس دقیقاً اشتباه است.

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

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

Cloud واقعاً هرگز در مورد پس انداز پول نبوده است. این در مورد به حداکثر رساندن انعطاف پذیری و بهره وری است. همانطور که یکی از نظردهنده HN اشاره می‌کند، “من روی یک تیم بسیار کوچک کار می‌کنم. ما چند توسعه‌دهنده داریم که به‌عنوان عملیات‌های عملیاتی عمل می‌کنند. هیچکدام از ما سیسادمین نیستیم و نمیخواهیم باشیم. برای مورد ما، ECS [سرویس کانتینر الاستیک] آمازون یک صرفه جویی عظیم در زمان و پول است. چگونه؟ با حذف توابع sysadmin، تیم قبلاً باید پر می‌کرد. بله، اکثر مشکلاتی که قبلاً داشتیم می‌توانست توسط یک سیس‌ادمین ماهر حل شود، اما این دقیقاً نکته است – استخدام یک sysadmin خوب برای ما بسیار گران‌تر از پرداخت مقداری اضافی به آمازون است و فقط به آنها گفتن «لطفاً این‌ها را اجرا کنید». ظروف با این پیکربندی.’ ”

او کار ابری را درست انجام می دهد.

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

یک شرکت صراحتاً تلاش کرد از قفل شدن در هر ابر خاص اجتناب کند. ما محصول خود را از اولین کامیت توسعه دادیم تا بر روی ۳ (!) ابر مستقر شود: AWS، Azure، IBM. چطور؟ با چسبیدن به کمترین مخرج مشترک که FaaS/IaaS ([AWS] Lambda، [Amazon] S3، [Amazon] API [Gateway]، Kubernetes) بود.» ساده به نظر می رسد، درست است؟ «مطمئناً آسان نبود. ما همچنین ابزارهایی را نادیده گرفتیم که می‌توانستند به ما کمک زیادی کنند [اگر با] یک ابر واحد می‌مانیدیم تا چند ابری باشیم.» ارزشش را داشت؟ «حرکت بین ابرها، با توجه به ویژگی‌های مشترک، امکان‌پذیر است، اما قطعاً چند کلیک یا چند کار جنکینز دور نیست. حرکت بین ابرها یک کار تمام وقت است. یافتن نحوه انجام آن کار کوچک VM که در AWS انجام دادید، اکنون در Azure، به زمان و یادگیری نیاز دارد. و حرکت بین مجوز AWS IAM و Azure [Active Directory]؟ زمان، زمان و زمان.”

به عبارت دیگر، Multicloud آسان نیست، و مهاجرت نیز آسان نیست. آیا این بدان معناست که هیچ کدام در نهایت ارزش آن را ندارند؟ لازم نیست. همانطور که مایلز وارد، مدیر ارشد فناوری SADA (یک شریک کلیدی Google Cloud) آن را توصیف می‌کند، می‌توان دلایل قانع‌کننده‌ای داشت. برای پریدن به ابر دیگری. برای بسیاری از افراد، انجام کارها آسانی استفاده و کارایی است. برای دیگران، توجه و مشارکت است. برای گروه سوم، مزایای هزینه پوچ است. و چهارم، عملکرد و قابلیت اطمینان است.» به این ترتیب، وقتی “مشتریان شکاف هایی را در یک یا بسیاری از آن چهار حوزه می بینند … حرکت می کنند.”

احتمالاً وارد حق است: می‌تواند دلایل قانع‌کننده‌ای برای مهاجرت وجود داشته باشد. فقط مطمئن شوید که یک تجزیه و تحلیل کامل از کل هزینه مالکیت این انتقال انجام دهید، که باید فراتر از این باشد که “ابر X به من اعتبار ۵۰۰۰۰ دلاری ارائه می دهد.” علاوه بر این، قبل از اینکه تصمیم بگیرید ابر خود را راه اندازی کنید، ارزش آن را دارد که هزینه های مربوط به مدیریت تمام زیرساخت های خود را در نظر بگیرید.