تصمیم‌های فناوری (Technology decisions)

تصمیم‌گیری درباره فناوری‌هایی که شرکت بر پایه آن‌ها کار خواهد کرد، یکی از مهم‌ترین مسئولیت‌های یک CTO است. ما دوست داریم صنعت خود را سریع، دائماً در حال تغییر و همیشه در حال تکامل ببینیم؛ اما واقعیت این است که یک production system ممکن است دهه‌ها بدون تغییر جدی به کار ادامه دهد. این واقعیت کمی ترسناک است: سیستمی که امروز می‌سازید، شاید زمانی که به بازنشستگی فکر می‌کنید هنوز در حال اجرا باشد.

چرا یک سیستم می‌تواند این‌قدر طولانی عمر کند؟ دلایل رایج عبارت‌اند از:

• technology stack به‌سادگی امکان به‌روزرسانی تدریجی را فراهم نمی‌کند.
• مدیران فنی در طول سال‌ها نمی‌خواهند ــ یا نمی‌دانند چگونه ــ به این «گاو مقدس» دست بزنند.
• مدیریت، تجربه‌ای جز فناوری فعلی ندارد.
• سیستم آن‌قدر حیاتی شده است که جایگزینی یا ارتقای آن، بیش از حد پرریسک یا پرهزینه به نظر می‌رسد.
• غرور فنی: «سیستم بی‌نقص ساخته شده؛ چطور می‌شود چیزی را که کامل است بهتر کرد؟»

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

هنگام انتخاب یک فناوری، دست‌کم این پرسش‌ها را مطرح کنید:

• این فناوری چگونه پیر می‌شود؟
• اگر منسوخ شود یا دیگر پشتیبانی نشود چه اتفاقی می‌افتد؟
• برای کارکرد خود به چه dependencyهایی نیاز دارد و آن dependencyها چگونه پیر می‌شوند؟
• آیا در آینده هنوز افرادی خواهند بود که بخواهند با این فناوری کار کنند؟

نمونه روشن، برنامه‌های قدیمی Visual Basic از میانه دهه ۱۹۹۰ هستند؛ برنامه‌هایی وابسته به کتابخانه‌های third-party که سال‌هاست پشتیبانی نمی‌شوند و روی Windows 95/XP گیر کرده‌اند و انتقالشان به Windows مدرن ممکن نیست. Microsoft در نهایت تلاش برای سازگاری کامل رو به عقب را کنار گذاشت و در Windows 10 یک Windows XP virtual machine کامل ارائه کرد تا دست‌کم مسیری برای ادامه حیات این legacy appها وجود داشته باشد.

نمونه‌های دیگری هم از منسوخ‌شدن فناوری و اجبار شرکت‌ها به اقدام اصلاحی وجود دارد. زمانی browser pluginها بسیار محبوب بودند و با Adobe/Macromedia Flash، Microsoft Silverlight یا Java Applet می‌شد تجربه‌ای شبیه desktop داخل صفحه وب ساخت. با ظهور HTML5 و پیشرفت جدی JavaScript، این pluginها هم از نظر سن و هم از نظر امنیت عقب ماندند و طی چند سال از browserهای جدید حذف شدند.

نتیجه این است که فقط stack داخلی خودتان مهم نیست؛ همه سیستم‌های third-party که به آن‌ها وابسته‌اید نیز باید زیر نظر باشند. به‌روز نگه‌داشتن software حیاتی است؛ موضوعی که در فصل ۱۳ با جزئیات بیشتری بررسی می‌شود.

۸.۱ جلوگیری از قفل‌شدن به فروشنده (Avoid vendor lock-in)

چه انتخاب شما یک vendor باشد، چه یک زبان یا framework، باید از تصمیمی دوری کنید که بدون راه خروج عملی شما را به همان انتخاب قفل کند. هدف این است که بتوانید بخشی از محیط را تغییر دهید، بدون اینکه ناچار به full rewrite شوید.

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

Java نمونه خوبی از یک زبان اصلی با گزینه‌های متعدد است. Java برای حل مسئله تنوع زبان‌های وابسته به processor در embedded development شکل گرفت. با ایجاد یک virtual machine انتزاعی، developer می‌تواند با یک زبان استاندارد و portable کد بنویسد و JVM ارتباط میان hardware/operating system و code را برقرار کند.

Java چندین JVM با performance بالا دارد، از جمله Oracle، IBM، OpenJDK و Amazon، بدون آنکه برای جابه‌جایی میان آن‌ها لازم باشد حتی یک خط Java تغییر کند. چه Java را روی Linux اجرا کنید، چه Windows یا Cloudهای Amazon، Google یا Microsoft، code همان است. در نتیجه روی operating system، virtual machine و environment کنترل دارید، بدون اینکه تیم development را مختل کنید.

اگر solution شما هزینه license دارد، از ابتدا برای افزایش قیمت آن برنامه داشته باشید. آیا افزایش قیمت بودجه را به‌طور جدی به‌هم می‌زند؟ بسیاری از سازمان‌ها بعداً از خرید licenseهای Oracle یا SQL Server پشیمان شده‌اند؛ چون قیمت‌ها بالا رفته، flexibility کمتر شده ــ مثلاً انتقال به Cloud دشوار شده ــ و در نهایت فهمیده‌اند از هیچ قابلیت خاص vendor استفاده نمی‌کنند.

از platform یا softwareی که هیچ جایگزینی ندارد دوری کنید. در چنین مسیری، کاملاً به feature set و pricing همان vendor وابسته می‌شوید. این موضوع درباره ابزارهای back-office مانند Office 365، Google Workspace و Salesforce نیز صدق می‌کند. البته برای بعضی کاربردها این trade-off پذیرفتنی است، به‌خصوص برای vendorهای بزرگی که معمولاً تغییر قیمت ناگهانی و بسیار مخرب ندارند.

هدف این است که چند «راه خروج» داشته باشید؛ شبیه بازیکن خوب poker که همه امید خود را به آمدن یک کارت خاص نمی‌بندد. در برنامه‌ریزی enterprise نیز نمی‌دانید در گوشه بعدی چه چیزی منتظر شماست: شاید کسب‌وکار pivot کند، شاید جهت عوض شود، یا شاید یک تغییر بیرونی کل یک صنعت فرعی را وارد بحران کند. واکنش مناسب به چنین تغییرهایی مسئولیت CTO است. مدیریت و تأمین بودجه upgradeهای کوچک و تدریجی، تقریباً همیشه بهتر از rewrite بزرگ و یک‌باره است.

۸.۲ ساخت در برابر خرید (Build vs. Buy)

در میان بحث‌های کلاسیک فناوری ــ از جمله tabs در برابر spaces ــ یکی از موضوعاتی که خواب را از چشم بسیاری از متخصصان می‌گیرد، انتخاب میان Build و Buy است. اثر این تصمیم فقط به engineering department محدود نمی‌شود و معمولاً تا سطح board نیز درباره آن بحث می‌شود.

در یک سمت، management تصور می‌کند با خرید یک solution می‌توان «یک‌شبه» به نتیجه رسید. در سمت دیگر، technologistها گرفتار سندرم Not Invented Here می‌شوند و باور دارند خودشان می‌توانند محصولی بهتر و ارزان‌تر بسازند. واقعیت معمولاً جایی بین این دو است.

Enterprise software مثل Microsoft Word نیست؛ هیچ off-the-shelf softwareای دقیقاً کسب‌وکار شما را اداره نمی‌کند. اگر چنین نرم‌افزاری وجود داشت، احتمالاً شرکت نیازی به CTO نداشت. یک رستوران معمولی می‌تواند از سرویس‌های آماده مدیریت رستوران و integrationهایی مانند DoorDash و Uber Eats استفاده کند. اما اگر McDonald’s باشید و franchiseهای سراسر جهان را اداره کنید، solution اختصاصی لازم دارید ــ و CTO برای اداره آن.

از سوی دیگر، بازاختراع چرخ هم منطقی نیست. solutionهای واقعاً منعطف زمانی شکل می‌گیرند که بدانید کجا باید نوآوری کنید و بسازید، و کجا باید از tool، service یا open source library آماده استفاده کنید.

ابتدا مشخص کنید IPR یا همان «راز رقابتی» شما کجاست؛ همان‌جا باید استراتژی Build متمرکز شود. این بخش چیزی است که سازمان شما را از رقبا متمایز می‌کند؛ شاید code اختصاصی باشد یا شیوه منحصربه‌فرد integration چند component. هر چیزی بیرون از این حوزه ممکن است فقط حواس‌پرتی و حل دوباره مسئله‌ای باشد که قبلاً حل شده است. با هر گرایشی، لازم است هر دو مسیر را با due diligence یکسان و بدون تعصب ارزیابی کنید.

۸.۲.۱ خرید (Buy)

هنگام ارزیابی مسیر Buy، این موارد را در نظر بگیرید:

• هزینه setup و license، شامل هزینه سالانه یا usage-based
• professional service لازم برای setup
• در صورت self-hosted بودن:
  • هزینه hardware و licenseهای جانبی
  • هزینه IT برای نگهداری hardware و software، backup، security update و موارد مشابه
• زمان لازم برای configuration و customization
• امکان export ساده و دوره‌ای داده‌ها

زمان لازم برای research، shortlist و evaluation را دست‌کم نگیرید. به sales pitchهای حرفه‌ای vendorها با احتیاط نگاه کنید. همان‌طور که در software development فقط روی whiteboard همه‌چیز بدون خطا کار می‌کند، پیش از امضای قرارداد هم solution هر vendor سریع‌ترین، بهترین و ساده‌ترین گزینه دنیا معرفی می‌شود. این مرحله ممکن است ماه‌ها طول بکشد و وقت زیادی از تیم بگیرد.

برای منظم‌کردن ارزیابی، نیازمندی‌ها را فهرست و هر مورد را به must-have یا nice-to-have تقسیم کنید. این فهرست مبنای مقایسه platformها می‌شود و وقتی به دو گزینه نهایی رسیدید، تمرکز لازم برای اجرای Proof of Concept را فراهم می‌کند.

جدول ۸.۱ — مزایا و معایب خرید

یک هشدار: اگر solutionی تقریباً بدون configuration و complication دقیقاً همان کاری را انجام می‌دهد که می‌خواهید و شما را سریع به production می‌رساند، فرض کنید رقیبتان نیز می‌تواند همین کار را انجام دهد. شاید فناوری شما آن‌قدر که فکر می‌کنید IPR منحصربه‌فرد نداشته باشد.

۸.۲.۲ ساخت (Build)

Build یعنی منابع development را به ساخت یک solution اختصاصی برای نیازهای شرکت اختصاص دهید. این مسیر ممکن است زمان بیشتری ببرد، اما در نهایت دقیقاً همان چیزی را می‌سازد که کسب‌وکار نیاز دارد. Build تعهد بزرگی است، به‌خصوص برای سازمانی که منابع لازم را از قبل ندارد. این مسیر برای شرکتی طبیعی‌تر است که infrastructure توسعه و تیم مناسب را در اختیار دارد.

جدول ۸.۲ — مزایا و معایب ساخت

ترکیب خوب این است که هرجا می‌توانید Buy کنید و برای flexibility و customization واقعی Build کنید. Build به معنای ساختن همه‌چیز از صفر نیست. می‌توانید componentهای commodity را integration کنید؛ مثلاً ارسال email را به یک third-party service بسپارید یا analytics پیچیده را به BI solution بدهید و فقط raw data را وارد آن کنید.

در این مسیر نیز از solutionهای Low-code/No-code با احتیاط استفاده کنید. این‌ها نسخه مدرن Visual Basic هستند و به nondeveloper اجازه می‌دهند با point-and-click یا drag-and-drop چیزی بسازند. چنین ابزارهایی خیلی سریع شما را به ۸۰ درصد نتیجه می‌رسانند، اما بستن ۲۰ درصد پایانی ممکن است زمان بسیار بیشتری بگیرد، چون tool انعطاف لازم را ندارد. بدتر آنکه شاید برای توجیه ابزار، نیاز کسب‌وکار را قربانی کنید. سؤال این است: آیا رقیبتان هم همین مصالحه را می‌پذیرد یا با featureهای بهتر از شما عبور می‌کند؟

۸.۲.۳ ملاحظات (Considerations)

گرایش شما به Build یا Buy معمولاً از محیطی می‌آید که در آن تجربه کسب کرده‌اید. این تصور که همه CTOها به‌طور پیش‌فرض عاشق Build هستند، غلط است:

• طرفداران Buy: معمولاً تجربه کم یا هیچ تجربه‌ای در اداره development team ندارند و معتقدند کاهش capability و flexibility با stability بیشتر platform جبران می‌شود.
• طرفداران Build: تجربه اداره development team دارند و می‌دانند چگونه تیم را برای ساخت solution مشخص به‌کار بگیرند. معمولاً محدودیت‌های solutionهای بزرگ و آماده آن‌ها را آزار می‌دهد.

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

هیچ تصمیمی کاملاً binary نیست و همیشه ناحیه خاکستری وجود دارد. platformهایی مانند Salesforce میان دو جهان Build و Buy قرار می‌گیرند: ecosystem بزرگی از componentهای آماده دارند، اما هم‌زمان محیطی کامل برای توسعه code قابل‌توجه فراهم می‌کنند.

قاعده ساده برای چنین platformهایی این است: اگر نمی‌توانید code خود را بردارید، روی platform دیگری بگذارید و اجرا کنید، در عمل Vendor lock-in دارید. موفقیت شما به vendor وابسته است و اگر downtime یا performance degradation رخ دهد، کاری جز صبرکردن ندارید.

۸.۲.۴ چک‌لیست ارزیابی (Evaluation checklist)

برای مقایسه درست Build و Buy باید روشمند باشید و بتوانید تصمیم را برای CEO یا CFO توضیح و دفاع کنید؛ چون برای موفقیت به حمایت آن‌ها نیاز دارید. ابتدا تعیین کنید چه چیزی برای کسب‌وکار مهم است و success criteria این initiative چیست.

جدول ۸.۳ — نمونه ارزیابی ساخت در برابر خرید

اگر جمع‌بندی checklist به سمت Buy است، investigation را روی همان مسیر متمرکز کنید. تصمیم باید data-driven باشد، نه gut-driven.

نکته مهم دیگر این است که Buy معمولاً moat سازمان را کوچک‌تر می‌کند. Moat اصطلاحی در سرمایه‌گذاری است و نشان می‌دهد تقلید از مزیت شرکت برای رقبا چقدر سخت است. اگر toolهای third-party آماده می‌خرید، رقیب نیز می‌تواند همان toolها را بخرد. البته در کسب‌وکاری که IPR آن فناوری نیست، این موضوع شاید اهمیت کمتری داشته باشد.

۸.۳ ابر در برابر زیرساخت داخلی (Cloud vs. on-prem)

برای بسیاری از سازمان‌های امروزی، حتی بحثی درباره خرید و اداره server فیزیکی شکل نمی‌گیرد. در مقابل، بعضی سازمان‌ها سرمایه‌گذاری سنگینی روی hardware موجود دارند و توجیه اقتصادی انتقال به Cloud برایشان دشوار است. در این بخش مزایا و معایب هر دو مسیر، شیوه استفاده بهتر از hardware موجود و خطاهای رایج Cloud را بررسی می‌کنیم.

• Cloud: محیطی که CPU، memory، network و storage را بر اساس مصرف ــ گاهی حتی بر حسب ثانیه ــ دریافت و پرداخت می‌کنید. resourceها ممکن است به‌شکل server یا service ارائه شوند، بدون آنکه لازم باشد درباره hardware فیزیکی زیرین فکر کنید.
• On-prem: محیطی که hardware زیربنایی شامل CPU، memory، network و storage در مالکیت و مدیریت خود شرکت است.

به Cloud مانند برق نگاه کنید. دستگاه را به پریز می‌زنیم، هرقدر لازم است مصرف می‌کنیم و آخر ماه قبض همان مصرف را می‌پردازیم. از نظر اقتصادی و عملیاتی این مدل بسیار ساده‌تر از اداره نیروگاه شخصی است. طی سال‌ها، دستگاه‌ها نیز با یک interface استاندارد ــ همان دوشاخه یا سه‌شاخه برق ــ برای استفاده از این منبع طراحی شده‌اند.

در Cloud، معادل این تکامل را Cloud-native می‌نامیم: application از ابتدا برای استفاده از resourceهای on-demand ساخته شده و می‌تواند به‌صورت خودکار scale up و scale down کند.

بااین‌حال گاهی اداره hardware خودتان منطقی‌تر است:

• مناسب Cloud: workloadهایی با قله و افت مصرف در طول ساعت، روز یا فصل
• مناسب On-prem: workloadهای محاسباتی سنگین که CPU بیشتر زمان را با utilization بالای ۹۰ درصد کار می‌کند؛ مانند data modeling پیچیده، graphics rendering یا حتی bitcoin mining

۸.۳.۱ ابر (Cloud)

در این بخش نقاط قوت و ضعف Cloud را بررسی می‌کنیم.

مقاومت در برابر Cloud

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

• «Cloud امن نیست.» زمانی ردکردن این ادعا دشوار بود، اما پیشرفت monitoring، network isolation، encryption management، container runtime و fine-grained access control وضعیت را تغییر داده است. رسیدن به سطح مشابه امنیت در On-prem معمولاً هزینه و effort زیادی می‌خواهد. البته Cloud به‌خودی‌خود مساوی security نیست؛ mechanismهای امنیتی باید درست design و implement شوند. یک Cloud Architect خوب، security را بخش جدایی‌ناپذیر architecture می‌داند.
• «داده‌هایم گروگان vendor می‌شود.» این ترس مبنای واقعی محکمی ندارد. داده در storage serviceها یا databaseهای Cloud قرار می‌گیرد و از طریق tool و APIهای vendor در دسترس است؛ نه بیشتر از زمانی که روی SAN محلی ذخیره شده باشد. اگر حجم داده بسیار زیاد باشد، download آن network cost دارد، اما این گروگان‌گیری نیست. ترس دیگری هم درباره عقب‌افتادن یک قبض ماهانه وجود دارد؛ در عمل vendorهای بزرگ هفته‌ها اخطار و فرصت می‌دهند و ناگهان داده را حذف نمی‌کنند.
• «خیلی گران است.» بله، اگر با Cloud مانند data center سنتی رفتار کنید، گران می‌شود. در workload دائماً ثابت و سنگین، پس از مدتی economics خرید hardware ممکن است جذاب‌تر باشد ــ البته فقط اگر همه هزینه‌های واقعی را حساب کنید. application درستِ Cloud-native معمولاً سال‌به‌سال صرفه‌جویی قابل‌توجهی ایجاد می‌کند، به‌خصوص با کاهش مداوم قیمت serviceهای Cloud.

Cloud نیز مانند هر ابزار دیگری برای نتیجه‌دادن به skill مناسب نیاز دارد و درمان همه مشکلات نیست.

۱۰ علامت هشدار که نشان می‌دهد از Cloud درست استفاده نمی‌کنید

بعضی سازمان‌ها با افتخار می‌گویند «روی Cloud هستیم»، اما کمی که دقیق شوید می‌بینید فقط serverهای خود را به data center یک vendor منتقل کرده‌اند؛ نه مزایای واقعی Cloud را گرفته‌اند و نه لزوماً هزینه کمتری می‌پردازند. موارد زیر زنگ خطرند:

• Cloud bill هر ماه تقریباً یکسان است. در کسب‌وکاری با دوره‌های مصرف کم و زیاد، قبض ثابت معمولاً یعنی از elasticity استفاده نمی‌کنید و resource را همیشه روشن نگه داشته‌اید.
• برای هر release به downtime نیاز دارید. این نشانه استفاده static از serverهاست؛ software روی همان machineها update می‌شود. در practice مدرن Cloud، با release جدید instance یا containerهای تازه ــ مانند Docker container ــ ساخته می‌شوند، traffic پس از validation به آن‌ها منتقل و instanceهای قبلی حذف می‌شوند.
• نمی‌توانید متناسب با load، scale up یا scale down کنید. Warren Buffett گفته است با باردارکردن نه زن نمی‌شود یک نوزاد را در یک ماه به دنیا آورد؛ اما در Cloud می‌توانید resourceهای بیشتری parallel اضافه کنید. اگر application چنین قابلیتی ندارد، Cloud-ready نیست.
• disk space تمام می‌شود. این یعنی serverها static هستند و maintenance دستی می‌خواهند. application خوبِ Cloud از storage تقریباً نامحدود و pay-as-you-go استفاده می‌کند.
• داده از دست می‌رود. جز حذف عمدی کاربر، در architecture درست Cloud نباید data loss عادی باشد. چنین رخدادی معمولاً از single point of failure و نبود elasticity یا redundancy خبر می‌دهد.
• فرض می‌کنید server مجازی fail نمی‌شود. hardware هنوز زیر Cloud وجود دارد و هرچند failure کم‌رخداد است، صفر نیست. اگر failure یک component کل architecture را زمین می‌زند، system بیش از حد tightly coupled و بدون redundancy است.
• serviceهای commodity را خودتان روی server اجرا می‌کنید. برای مثال load balancer، logging، caching یا configuration service. Cloud provider معمولاً managed service مناسب دارد. اگر همه این موارد را خودتان اداره می‌کنید، دلیلش را بررسی کنید؛ شاید تیم از serviceهای موجود آگاهی کافی ندارد.
• security practice مربوط به data center را بدون تغییر در Cloud پیاده کرده‌اید. firewall دستی روی هر server و نبود network segmentation، یعنی از لایه‌های امنیتی Cloud استفاده نکرده‌اید.
• DR هنوز بر پایه hot-swap و یک مجموعه server آماده و بیکار است. اگر DR را صرفاً محیطی می‌بینید که روز حادثه به آن switch می‌کنید، Cloud-native نیستید. در architecture درست Cloud، resilience و DR در design روزمره قرار دارند.
• چند service را روی یک server اجرا می‌کنید. در hardware سنتی به‌دلیل قیمت بالا، اجرای stackهایی مانند Linux/Apache/MySQL/PHP روی یک machine رایج بود. این محدودیت در Cloud همان معنا را ندارد. هر unit باید سبک، replaceable، maintainable و scalable باشد.

اگر Cloud را مثل data center و فقط مجموعه‌ای از serverها ببینید، نه flexibility می‌گیرید و نه صرفه‌جویی. بسیاری از deploymentهای Cloud فقط به‌دلیل برداشت اشتباه از ماهیت Cloud، گران‌تر از hardware معادل تمام می‌شوند.

Private Cloud و Hybrid Cloud

اکثر افراد Cloud را با Public Cloud یکی می‌دانند، اما برای سازمانی که hardware زیادی در اختیار دارد، Private Cloud می‌تواند مسیر مناسبی باشد. با نصب Cloud OS و مدیریت resourceها به‌صورت pool و usage-based، می‌توان عمر مفید hardware را افزایش داد. solutionهای commercial و open source مختلفی وجود دارد.

این مسیر فقط زمانی پیشنهاد می‌شود که منابع و skill لازم برای اداره pool خصوصی را داشته باشید. stability و reliability بهتر می‌شود، زیرا workload را می‌توان از hardware معیوب دور کرد؛ اما overhead نگهداری hardware همچنان باقی است.

گام طبیعی بعدی Hybrid Cloud است: ترکیب Private و Public Cloud. وقتی resourceهای Private Cloud کافی نیست، Public Cloud می‌تواند کمبود را به‌صورت شفاف جبران کند.

ساختن یک Cloud موفق

برای کسی که با hardware سنتی بزرگ شده، Cloud می‌تواند غریبه و ترسناک باشد، اما skillهای قبلی از بین نمی‌روند؛ فقط سؤال را باید دوباره frame کرد: «این مسئله را در hardware چگونه حل می‌کردم و معادل درست آن در Cloud چیست؟»

سه اصل اساسی:

• Security تضمین‌شده نیست. هر component باید با security design شود. صرف deploy شدن service هیچ تضمینی ایجاد نمی‌کند. misconfiguration بارها باعث incident شده است؛ بنابراین test کنید.
• Failure اتفاق می‌افتد. Cloud محیط بدون خطا نیست. برای failure برنامه‌ریزی کنید، system را با فرض failure بسازید و سناریوها را تمرین کنید. architecture خوب می‌تواند بسیاری از failureها را بدون disruption محسوس تحمل کند.
• خراب‌کاری آسان‌تر است. ساختن resource در Cloud ساده است و حذف‌کردنش هم به همان اندازه ساده. برچسب «production» برای vendor فقط یک نام است؛ اگر از API یا console بخواهید production database را حذف کند، فرض می‌کند می‌دانید چه می‌کنید.

Cloud بسیاری از مشکلات hardware سنتی را حذف می‌کند، اما کار را لزوماً آسان‌تر نمی‌کند؛ فقط جنس مسئله‌ها تغییر می‌کند.

۸.۳.۲ زیرساخت داخلی (On-prem)

On-premises اصطلاحی کلی برای خرید، provision و مدیریت hardware فیزیکی موردنیاز سازمان است. این hardware الزاماً در office نیست و ممکن است در data center اختصاصی یا colocation قرار داشته باشد. در این بخش هم ایجاد محیط جدید و هم نگهداری محیط موجود را بررسی می‌کنیم.

در گذشته، اداره hardware تنها روش تأمین چندین server بود. برآورد ظرفیت نیز دشوار بود: شرکت یا hardware بیش از حد می‌خرید و بخش بزرگی بلااستفاده می‌ماند، یا کمتر از نیاز می‌خرید و در زمان load بالا هم hardware و هم کارکنان تحت فشار قرار می‌گرفتند. server باید سفارش داده شود، تحویل برسد، provision و install شود؛ فرایندی که هفته‌ها زمان می‌برد. scaling on-demand سریع نیست و پیش از همه این‌ها باید CFO را برای capital expenditure قانع کنید.

امروز Private Cloud می‌تواند بخشی از این مشکل را کاهش دهد. hardware در یک pool قرار می‌گیرد و بر اساس نیاز تقسیم می‌شود. مثلاً هنگام کمپین آنلاین، می‌توان چند server داخلی کم‌اهمیت را خاموش و resource آن‌ها را به frontline service داد. بااین‌حال pool شما محدود است و فقط به اندازه hardware موجود ظرفیت دارید.

محل میزبانی

برای physical hosting دو انتخاب اصلی دارید:

• Office building: hardware در همان ساختمان کارکنان، داخل server room، کمد یا ــ در بدترین حالت ــ زیر میز developer قرار دارد.
• Remote data center: hardware داخل rackهای یک data center تخصصی میزبانی می‌شود.

server مانند گیاهی است که برای زنده‌ماندن به منابع مشخص نیاز دارد؛ فقط به‌جای نور و آب، power، cooling و network می‌خواهد. hardware جدید نسبت به نسل‌های قدیمی گرمای کمتری تولید می‌کند، اما همچنان cooling لازم است. اگر server را در کمد بدون A/C بگذارید، هنگام بازکردن در با دیواری از گرما روبه‌رو می‌شوید.

Power نیز معمولاً دست‌کم گرفته می‌شود. فقط اتصال به پریز کافی نیست؛ باید circuit تحمل load را داشته باشد، برق از spike آسیب‌زا پاک باشد و هنگام قطع شبکه برق، UPS یا منبع جایگزین وجود داشته باشد.

Network خون حیاتی server است. فقط وصل‌کردن کابل RJ45 کافی نیست. باید مطمئن شوید فقط traffic امن وارد می‌شود و برای قطع ارتباط Internet نیز راه جایگزین دارید. architectureهای چندserverه پیچیده‌ای وجود دارند که در نهایت همه به یک کابل بیرونی وابسته‌اند؛ شکوه architecture، روی یک single point of failure باریک.

Data center تخصصی این موارد را مدیریت می‌کند و متناسب با آن هزینه می‌گیرد. pricing معمولاً بر دو معیار است:

• فضای فیزیکی rack بر حسب U؛ هر U برابر ۱.۷۵ اینچ است.
• bandwidth یا ظرفیت network provisionشده

هزینه power معمولاً در قیمت لحاظ می‌شود. serverهای rack-ready بلند و تخت‌اند تا عمودی و فشرده نصب شوند و به‌دلیل ظاهرشان گاهی pizza box نامیده می‌شوند. این مدل‌ها معمولاً از serverهای tower گران‌ترند.

Data center همچنین network equipment، private network و redundancy برای Internet فراهم می‌کند. در office، خودتان باید router، switch یا hub، firewall، cooling و backup power آن‌ها را design و نگهداری کنید.

Provisioning و Maintenance

پیش از خرید hardware باید configuration شامل CPU، memory و disk را مشخص کنید و تا حد امکان امکان upgrade آینده را در نظر بگیرید. پس از تحویل باید operating system نصب شود، softwareهای غیرضروری حذف شوند، security protocolها اعمال و جایگاه machine در network تعریف شود. همه این مراحل زمان می‌برد.

اگر self-host می‌کنید، room اختصاصی، قفل‌شونده، دارای ventilation و power مستقل در نظر بگیرید. چیدمان hardware باید منطقی باشد و cableها واضح label و مهار شوند.

برای hardware inventory یک سیستم داشته باشید؛ حتی اگر در شروع فقط نوشتن روی box با marker یا چسباندن barcode باشد. اطلاعات مهم عبارت‌اند از:

• تاریخ خرید و نصب: hardware چه زمانی خریداری و چه زمانی روشن شد؟
• منبع خرید: از کجا تهیه شده و contact detail فروشنده چیست؟
• Configuration: مشخصات داخل unit، slotهای خالی و ظرفیت upgrade چیست؟ اطلاعات باید آن‌قدر دقیق باشد که برای فهمیدن آن مجبور به بازکردن دستگاه نشوید.
• Expected time to failure: manufacturer چه طول‌عمری اعلام کرده است؟ componentهای متحرک مانند fan و hard disk بالاخره fail می‌شوند.
• Access detail: console دارد؟ روی کدام network است؟ username/password در کجا به‌صورت امن نگهداری می‌شود؟

ثبت این داده‌ها مدیریت hardware و preventive maintenance را ساده می‌کند. مستندسازی هنگام نصب، زمانی که همه اطلاعات جلوی دست شماست، بسیار آسان‌تر از چند سال بعد است.

اداره serverهای خودتان ــ حتی serverهای Cloud ــ maintenance می‌خواهد. updateهای operating system آشنا هستند، اما software و firmware خود hardware اغلب فراموش می‌شود. SAN، router، server blade chassis و deviceهای مشابه console و firmware دارند و باید مرتب update شوند.

maintenance hardware دشوارتر است. جایگزینی componentی که هنوز fail نشده، از نظر مالی سخت توجیه می‌شود؛ اما بهتر است دست‌کم replacement آن را از قبل تهیه یا source کنید. hardware سریع از بازار خارج می‌شود و backward compatibility آن کمتر از چیزی است که تصور می‌کنیم؛ به همین دلیل بعضی شرکت‌ها برای spare part به بازار دست‌دوم و eBay پناه می‌برند.

inventory دقیق، نیاز بودجه آینده را روشن می‌کند و هنگام درخواست fund از CFO برای replacement، غافلگیری کمتری وجود خواهد داشت.

۸.۴ بازیابی بحران (Disaster recovery)

ابتدا تعریف کنیم Disaster Recovery (DR) چیست. اگر از دسترس خارج‌شدن enterprise ــ به هر دلیل ــ آسیب جدی به مشتریان می‌زند، DR یعنی برای زمان وقوع حادثه برنامه‌ای داشته باشید تا یک محیط جایگزین operation را ادامه دهد. معمولاً این محیط در location جغرافیایی متفاوتی از primary قرار می‌گیرد تا حادثه‌هایی مانند آتش‌سوزی، سیل یا سرقت هر دو محیط را هم‌زمان درگیر نکند.

در یک application واقعاً Cloud-native و درست architectشده، DR تا حد زیادی در خود architecture تعبیه شده و event جداگانه‌ای به نام «فعال‌کردن DR» وجود ندارد. اما صرف حضور در Cloud به معنای آمادگی در برابر disaster نیست. بحث این بخش بیشتر درباره applicationهای non-cloud-native است.

CTO مسئول تداوم operation فناوری در شرایط خوب و بد است. DR ساده نیست. بسیاری از سازمان‌ها strategy ضعیف ــ یا عملاً هیچ strategy ــ ندارند. بعضی هم تصور می‌کنند DR خوبی دارند، اما هرگز آن را test نکرده‌اند؛ در نتیجه چیزی جز placebo و یک safety net بدون اتصال واقعی نیست.

سه سؤال پایه strategy شما را شکل می‌دهد:

• downtime قابل‌تحمل چقدر است؟
• در recovery mode به full service نیاز دارید یا partial service کافی است؟
• قرار است fail forward کنید و backup را primary جدید بدانید، یا بعداً به primary قبلی bounce back کنید؟

برای بحث، دو zone را فرض کنیم: zone فعال و zone backup که آماده تحویل‌گرفتن operation است. البته می‌توان چند backup zone داشت. به خاطر داشته باشید اگر فقط یک backup دارید، از لحظه‌ای که روی آن اجرا می‌شوید دیگر backup دیگری برای همان backup وجود ندارد.

۸.۴.۱ تحمل زمان قطعی (Downtime tolerance)

برای CEO آسان است که zero downtime بخواهد؛ اما چنین هدفی بسیار گران و پیچیده است، به‌خصوص وقتی بعضی componentهای enterprise قابلیت اجرای چند instance هم‌زمان را ندارند.

Database نمونه کلاسیک است. بسیاری از سازمان‌ها table و keyهای خود را برای real-time redundancy طراحی نکرده‌اند. اگر به primary keyهای auto-increment وابسته‌اید و از GUID یا strategy مناسب distributed استفاده نمی‌کنید، synchronization میان zoneها سخت‌تر می‌شود. legacy systemها و architectureهای ضعیف معمولاً برای یک نسخه duplicate آماده takeover ساخته نشده‌اند.

در دو zone جغرافیایی، دو مسئله اصلی complexity و cost DR را تعیین می‌کند:

• synchronized نگه‌داشتن داده میان zoneها
• switch کردن traffic و userها به active zone جدید

Synchronization واقعی زمان می‌برد؛ data باید از network عبور کند. حتی latency حدود ۵۰ تا ۱۰۰ میلی‌ثانیه می‌تواند در replication database اثر بزرگی داشته باشد. هنگام انتخاب locationهای DR، peering مستقیم میان data centerها را بررسی کنید؛ چنین ارتباطی congestion مسیر عمومی Internet را کاهش می‌دهد.

Databaseهای مدرن مانند SQL Server و Oracle قابلیت‌های replication قدرتمندی دارند ــ معمولاً با license گران‌تر ــ اما آن‌ها نیز محدود به سرعت network هستند. بنابراین ممکن است zero downtime از نظر فنی یا اقتصادی ممکن نباشد. در آن صورت باید همراه CEO تعیین کنید مشتری چه مقدار outage را تحمل می‌کند: چند دقیقه، چند ساعت یا چند روز؟ این تصمیم باید پس از ارائه cost و consequence هر سطح گرفته شود.

دو configuration رایج عبارت‌اند از:

• Hot standby: گران‌تر است؛ serverها همیشه روشن و synchronized هستند و با رسیدن traffic سریع takeover می‌کنند. در مقابل power، bandwidth و عمر hardware backup مصرف می‌شود.
• Cold standby: حداقل machineها روشن‌اند و هنگام failover، serverها boot و data sync می‌شوند. هزینه کمتر است، اما recovery کندتر خواهد بود. برای بعضی سیستم‌ها همین سطح از DR کاملاً کافی و مقرون‌به‌صرفه است.

۸.۴.۲ سرویس کامل یا جزئی (Full or partial service)

هنگام disaster همیشه لازم نیست همه قابلیت‌ها را با ظرفیت کامل ارائه دهید. بررسی کنید کدام service می‌تواند موقتاً unavailable یا read-only شود.

مثلاً اگر Twitter را با budget محدود اداره می‌کنید، partial service می‌تواند tweetهای قبلی را نمایش دهد اما انتشار tweet جدید را موقتاً متوقف کند. در ecommerce می‌توان مشاهده محصول و افزودن به cart را فعال نگه داشت، اما checkout را بست. در اغلب enterpriseها می‌توان بخشی را برای مدت محدود با ظرفیت کمتر اجرا کرد.

در partial mode ممکن است componentهایی را موقتاً از دست بدهید که user مستقیماً نمی‌بیند؛ مانند logging، reporting یا scheduled administrative task.

Full-service failover بسیار پیچیده‌تر است. system جدید باید بداند primary دقیقاً در چه stateی متوقف شده است. آیا taskهایی دوباره اجرا و duplicate می‌شوند؟ آیا بخشی کاملاً گم می‌شود؟ مثلاً اگر failure وسط ارسال batch email رخ دهد، از کجا می‌فهمید کدام emailها ارسال شده‌اند؟ شاید پذیرش چند email تکراری از تلاش برای تشخیص دقیق، ارزان‌تر و کم‌ریسک‌تر باشد.

بسته به design سیستم، failover تمیز ممکن است بدون مقدار قابل‌توجهی database و file manipulation دستی ممکن نباشد.

یک هشدار درباره partial solution: باید امکان تبدیل‌شدن آن به full solution وجود داشته باشد. در outage برق احتمالاً انتظار دارید power برگردد؛ اما پس از آتش‌سوزی، سیل یا سرقت، partial backup ممکن است برای مدت طولانی primary شود. DR را مانند لامپی ببینید که نباید خاموش شود؛ شاید مدتی کم‌نورشدن آن قابل‌تحمل باشد، اما تاریکی کامل نه.

۸.۴.۳ حرکت رو به جلو یا بازگشت (Fail forward vs. bounce back)

فرض کنید به backup zone failover کرده‌اید. وقتی primary قبلی دوباره در دسترس شد، چه می‌کنید؟ اگر این پرسش تازه برایتان مطرح می‌شود، احتمالاً DR event را هرگز تجربه یا تمرین نکرده‌اید. برنامه فقط نباید تا لحظه عبور از disaster باشد؛ باید rebuild پس از آن را نیز پوشش دهد.

اگر backup و primary از نظر capacity و capability مشابه‌اند، شاید بهتر باشد backup فعلی را primary جدید کنید. چرا بدون نیاز، یک switch دیگر انجام دهید؟ سپس zone خراب قبلی را repair و به backup جدید تبدیل کنید. این fail-forward configuration است: به عقب برنمی‌گردید.

اگر setupها like-for-like نیستند ــ مثلاً backup فقط partial service ارائه می‌دهد ــ باید پس از repair به primary قبلی bounce back کنید. مزیت این است که لازم نیست فوراً برگردید؛ می‌توانید outage دوم را در زمانی مناسب مانند آخرهفته یا نیمه‌شب برنامه‌ریزی کنید.

۸.۴.۴ مدیریت رخداد بازیابی بحران (Managing the DR event)

تا اینجا درباره configuration صحبت کردیم، اما logistics تصمیم برای switch نیز حیاتی است. شبیه rainy-day fund، سؤال دشوار این است که «آیا آن‌قدر باران آمده که باید از صندوق اضطراری استفاده کنیم؟» رفتن به DR zone event کوچکی نیست و نباید بی‌دلیل انجام شود.

بعضی triggerها واضح‌اند: hardware failure کامل، آتش‌سوزی، سیل یا سرقت. اما بعضی مبهم‌اند: power مدام قطع و وصل می‌شود و UPS به‌سختی serverها را نگه داشته؛ یا upstream provider می‌گوید network «خیلی زود» برمی‌گردد. «زود» دقیقاً یعنی چه؟

Switching strategy باید ambiguity را حذف کند. معیارهایی مانند serviceهای affected و مدت outage را مشخص کنید تا همه بدانند چه زمانی باید switch انجام شود.

پس از trigger، logistics سطح بالا شامل این موارد است:

• contactها، network detailها و passwordها در محل امن و فوراً accessible باشند.
• serviceهای لازم در cold standby مشخص باشند و با جدیدترین data populate شوند.
• همه network addressها و public/private DNSهایی که باید تغییر کنند فهرست شوند. propagation تغییر DNS به TTL وابسته است و باید در زمان recovery لحاظ شود.
• roleها، configurationها، testها و owner هر مرحله برای validation recovery zone مشخص باشند.
• در bounce-back configuration، reverse plan برای بازگشت به primary نیز نوشته شود.

Document باید در محل شناخته‌شده و در دسترس باشد. بدترین زمان برای پیدا‌کردن password console، وسط failover است.

این procedure را در ساعت کم‌مصرف به‌طور منظم test کنید. enterprise تغییر می‌کند، service اضافه و حذف می‌شود و DR نیز باید نماینده وضعیت فعلی باشد. disaster معمولاً از قبل خبر نمی‌دهد.

بهتر است حداقل هفته‌ای یک‌بار health و data flow مربوط به DR بررسی شود. هر سه تا شش ماه یک full switchover تمرین کنید تا افراد با process آشنا شوند و DR دیگر event عجیب و وحشتناکی نباشد. practice واقعاً تفاوت ایجاد می‌کند.

۸.۴.۵ استفاده از ابر در بازیابی بحران (Cloud and DR)

حتی اگر application Cloud-native نیست، می‌توانید Cloud را بخشی از DR کنید. Cloud به‌عنوان data center موقت و on-demand گزینه‌ای عملی و مقرون‌به‌صرفه است.

Cloud برای hot یا cold standby مناسب است؛ می‌توانید data را stream کنید و تا پیش از disaster عمدتاً هزینه storage را بپردازید. ساخت infrastructure مشابه primary نیز ساده‌تر است، چون resource را فقط هنگام نیاز فعال می‌کنید. علاوه بر این، test کردن configurationهای مختلف با budget محدود آسان‌تر می‌شود.

۸.۵ مدیریت داده (Data management)

Data خون جاری صنعت ماست. وارد سازمان می‌شود، خارج می‌شود، درباره خودش data بیشتری تولید می‌کند و به dataهای دیگر تبدیل می‌شود؛ همه این‌ها باید sort، translate، store و process شوند. Data فقط file روی disk یا row داخل table نیست؛ معنا، context و value دارد. در عین حال می‌تواند بی‌ارزش، پرهزینه و حواس‌پرت‌کن باشد. هنر اصلی، تشخیص تفاوت این دو است.

در گذشته storage گران و از نظر logistics دشوار بود. امروز در الگوی storage تقریباً نامحدود Cloud، نگهداری data هرگز این‌قدر ساده و ارزان نبوده و هزینه همچنان کاهش می‌یابد. دو پرسش اصلی ایجاد می‌شود:

• آیا باید همه‌چیز را نگه داریم؟
• چگونه data را سازمان‌دهی کنیم تا بعداً accessible و قابل‌استفاده باشد؟

مدیریت و secure کردن data کار ساده‌ای نیست. Security در فصل دیگری بررسی می‌شود، بنابراین اینجا فقط اشاره‌ای کوتاه خواهیم داشت. CTO در نهایت steward اصلی data شرکت است. تجربه نشان می‌دهد بسیاری از CTOها این asset را آن‌طور که باید مدیریت نمی‌کنند؛ یا ارزش واقعی آن را نمی‌شناسند یا از tool و techniqueهای موجود آگاه نیستند.

در این بخش storage mechanismهای رایج، نوع dataهای تحت مسئولیت و موضوعات ownership، compliance و security را مرور می‌کنیم. در طول بحث، چند buzzword بازار data نیز روشن می‌شود.

۸.۵.۱ ذخیره‌سازی (Storage)

وقتی به data فکر می‌کنیم، معمولاً file و folder به ذهنمان می‌رسد. بسیاری از C-level executiveها ــ با پیشینه مالی ــ data را در قالب Excel spreadsheet تصور می‌کنند. حتی وقتی از database حرف می‌زنند، ممکن است در ذهنشان فقط یک Excel بزرگ‌تر باشد. بخشی از وظیفه CTO این است که value این asset را فراتر از spreadsheet توضیح دهد و برای محل و ساختار بلندمدت data برنامه‌ریزی کند.

امروز بهانه‌ای برای دورریختن data فقط به‌دلیل هزینه storage وجود ندارد. اما storageهای مختلف برای مسئله‌های متفاوت مناسب‌اند:

• Files/Folders: file مجموعه‌ای self-contained از data با نام مشخص روی یک medium است. formatهایی مانند JSON، XML، CSV و TXT تقریباً با همه toolها قابل‌خواندن‌اند. file به‌سادگی copy، encrypt، move و share می‌شود و می‌تواند هر نوع data را نگه دارد.
• Relational Store یا SQL Database: dataهایی با attributeهای مشترک در column و relationهای مشخص در row و table قرار می‌گیرند. tableها به هم link می‌شوند و مجموعه آن‌ها database را می‌سازد. SQL برای query، return، update یا create کردن data استفاده می‌شود. این مدل برای حجم زیاد data با structure مشابه بسیار رایج است.
• NoSQL Store: NoSQL یا document store محدودیت structure یکسان را کاهش می‌دهد. فقط fieldهایی ذخیره می‌شوند که واقعاً وجود دارند و documentهای یک collection می‌توانند با هم تفاوت زیادی داشته باشند.
• Data Lake: محلی برای ذخیره حجم عظیم file با structure و size متفاوت؛ مناسب backup، تحلیل آینده یا staging dataهایی که هنوز home دائمی ندارند.
• Data Warehouse: databaseای تخصصی برای analytics و BI. data به‌شکلی arrange می‌شود که report و year-over-year analysis سریع باشد.

پیش از Cloud، اداره هم‌زمان همه این storageها بسیار گران بود و در هر مرحله data برای نیاز همان روز کوچک می‌شد. اگر بعداً business به detail بیشتری نیاز پیدا می‌کرد، فقط data جدید در دسترس بود و history از بین رفته بود.

File و relational database تقریباً در همه سازمان‌ها وجود دارند؛ SQL Server، Postgres، MySQL یا Oracle. بااین‌حال architecture data در بسیاری از شرکت‌ها ضعیف است. مثلاً همان database هم website customer-facing را drive می‌کند و هم report سنگین مدیریتی را پاسخ می‌دهد. بهتر است databaseها بر اساس domain یا business area جدا شوند و data لازم با process مشخص replicate شود. در این صورت وقتی CFO report بزرگ پایان فصل را اجرا می‌کند، website از کار نمی‌افتد.

NoSQL databaseهایی مانند MongoDB، CouchDB، DynamoDB و Elasticsearch به‌خصوص در ابتدای development که schema هنوز روشن نیست محبوب‌اند. performance آن‌ها رشد کرده و با semistructure مناسب می‌تواند با relational system رقابت کند.

اما افراط نکنید. بعضی تیم‌ها همه‌چیز را NoSQL می‌سازند و data inconsistency افزایش می‌یابد؛ مثلاً یک document مقدار عددی را به‌صورت string یعنی "2" و دیگری به‌صورت integer یعنی 2 ذخیره می‌کند. NoSQL ذاتاً data integrity یا structure را enforce نمی‌کند؛ این مسئولیت application و governance است.

Data Lakeهایی مانند Apache Hadoop یا Amazon S3 در ظاهر یک storage بزرگ برای file هستند، اما toolهایی برای پیمایش و استخراج elementهای موردنیاز دارند. log fileهای production مثال خوبی‌اند. format می‌تواند در طول زمان evolve کند و بعداً با crawl کردن fileها keyword یا pattern موردنظر را پیدا کنید؛ این رویکرد معمولاً با مفهوم Map/Reduce همراه است.

Data Warehouseهایی مانند Amazon Redshift یا SQL Server در نقش warehouse، محل data مخصوص reporting هستند. data معمولاً aggregate، anonymize و براساس سؤال‌های business design می‌شود. warehouse زمانی ارزش زیادی پیدا می‌کند که حجم قابل‌توجهی data جمع شده باشد. relational database معمولی در شروع جواب می‌دهد، اما در نقطه‌ای برای analytics سنگین به محدودیت می‌رسد.

در دنیای Cloud، همه این storage serviceها را بدون اداره server و license زیربنایی مصرف می‌کنید. بسیاری از تیم‌ها با انتقال storage به Cloud از scaling on-demand، حذف نگرانی کمبود disk و toolهای امنیتی استاندارد بهره برده‌اند.

حداقل، سازمان باید نوعی Data Lake داشته باشد. آن را انباری data تصور کنید: جایی برای چیزهایی که فعلاً home دائمی ندارند اما نمی‌خواهید دور بریزید، چون شاید روزی لازم شوند. ممکن است پیدا‌کردنشان کمی زمان ببرد، اما دست‌کم وجود دارند.

۸.۵.۲ انواع داده (Data types)

همه dataهای سازمان ارزش، حساسیت و کاربرد یکسان ندارند. این موضوع بدیهی به نظر می‌رسد، اما بسیاری از شرکت‌ها آن را به‌صورت عملی در policy و architecture منعکس نکرده‌اند. برای شروع، data را می‌توان در bucketهای زیر قرار داد:

• System of Record: data اصلی و مرجع شرکت، معمولاً داخل database. این bucket «حقیقت» رسمی یک entity است.
• Sensitive/Secure: data نیازمند security بیشتر؛ مانند Social Security Number، گواهینامه، اطلاعات بانکی یا credit card.
• Transactional: data تولیدشده در جریان ارائه core product یا operation؛ معمولاً operational data نامیده می‌شود.
• Business Intelligence: data مورد استفاده برای analytics و reporting؛ اغلب نسخه aggregate یا anonymized از transactional data است.
• Log: data تولیدشده توسط systemها و softwareها برای debugging، forensic analysis، audit و performance analysis.

برای هر classification باید ruleهای متناسب با enterprise تعریف شود. لازم نیست در شروع بیش از حد جزئی شوید، اما هر bucket را از این زاویه‌ها بررسی کنید:

• Ownership: مالک واقعی data کیست؟ ممکن است instinct اولیه این باشد که شرکت مالک است، اما شاید فقط steward data کاربر یا client باشید. ownership واقعی تعیین می‌کند آیا می‌توانید data را بفروشید، حذف کنید، public کنید یا فقط برای purpose محدود استفاده کنید. بعضی datasetها یا mailing listها حتی برای مدت مشخص اجاره می‌شوند.
• Retention: data تا چه زمانی نگهداری می‌شود؟ این policy هم operational store و هم backup را شامل می‌شود، البته فقط اگر ownership اجازه دهد. aging policy مشخص می‌کند data چه زمانی به storage بلندمدت و ارزان‌تر منتقل شود و چه business triggerی باید همه نسخه‌ها، حتی backup، را حذف کند؛ مثلاً پایان رابطه با client.
• Visibility: چه کسی در داخل یا خارج سازمان data را می‌بیند و چه controlهایی مانند encryption و access list اعمال می‌شود؟ وقتی data از یک classification به دیگری می‌رود ــ مثلاً operational data به analytics ــ transformation لازم مانند anonymization باید تعریف شود.
• Compliance: آیا data تحت regulation یا standard خاص است؟ Personal، health و financial data معمولاً audit، retention و security ویژه می‌خواهد و ruleها ممکن است بر اساس region جغرافیایی متفاوت باشند.

Data یکی از باارزش‌ترین assetهای شرکت است و هرچه بیشتر جمع شود، data بیشتری نیز از آن تولید خواهد شد. mapping جریان data باعث می‌شود از نظر اخلاقی، حقوقی و عملیاتی غافلگیر نشوید.

به dataهای تحت compliance توجه ویژه کنید. PII، HIPAA، PCI و استانداردهای مشابه با تفاوت‌های خود، در اصل یک هدف دارند: data را secure و محترمانه مدیریت کنید. بهتر است best practice امنیتی را فقط برای data اجباری اعمال نکنید، بلکه آن را culture عمومی تیم قرار دهید. در این صورت audit به حادثه‌ای نمایشی و ترسناک تبدیل نمی‌شود. طراحی security و auditability از ابتدا، هم تصمیم درست امروز است و هم بیمه‌ای برای تغییر direction فردا.

۸.۶ میکروسرویس در برابر معماری یکپارچه (Microservices vs. monolithic)

در enterprise development دو اصل طراحی بزرگ وجود دارد: Monolithic و Microservices؛ هرچند بسیاری از سیستم‌ها hybrid هستند. Microservices به‌دلیل مزیت‌های توسعه، deployment و maintenance به انتخاب محبوب architecture مدرن تبدیل شده است.

در Monolithic، کل enterprise یا بخش بزرگی از آن به‌صورت یک entity واحد build و deploy می‌شود. codebase معمولاً یک unit بزرگ، tightly coupled و با code reuse محدود است.

جدول ۸.۴ — نشانه‌های معماری یکپارچه

اگر پاسخ سه مورد یا بیشتر «Yes» است، احتمالاً architecture شما Monolithic است.

Microservices یعنی enterprise را به mini applicationهای مستقل و narrow-scope تقسیم کنید که هرکدام action یا role مشخصی دارند. آن‌ها از طریق API، service bus یا message queue تعامل می‌کنند. microservice قوی entity مستقلی است با data store، execution environment و release cycle خودش؛ language و library هر service می‌تواند متناسب با همان مسئله انتخاب شود.

جذابیت اصلی Microservices کاهش risk و استفاده از tool مناسب برای هر task است. این pattern زمانی عملاً محبوب شد که remote API call از نظر performance به‌اندازه کافی سریع شد.

برای CTO، Microservices امکان می‌دهد enterprise را به unitهای کوچک‌تر و مستقل تقسیم کند. هر unit با schedule خود update می‌شود. بخش‌هایی که به‌ندرت تغییر می‌کنند، از unintended consequence release بخش‌های دیگر در امان می‌مانند.

در Monolithic legacy، تغییر کوچک پرریسک است؛ حتی upgrade یک library ظاهراً بی‌ضرر می‌تواند به‌دلیل coupling زیاد ripple effect ایجاد کند.

دام رایج این است که microservice بدون governance به mini-monolith تبدیل شود. service در طول زمان مسئولیت‌های بیشتری می‌گیرد و هرچند تیم همچنان نام Microservices را استفاده می‌کند، architecture فقط در اسم microservice باقی می‌ماند.

Microservices همچنین تصمیم فناوری را future-proof می‌کند یا دست‌کم به تعویق می‌اندازد. با API قوی و consistent، implementation service می‌تواند در زمان مناسب evolve شود.

مثلاً فرض کنید همه enterprise به ذخیره و بازیابی file نیاز دارد. یک File Microservice تعریف می‌کنید با API ساده برای upload و retrieval. در ابتدا implementation ممکن است file را روی directory محلی backupشده نگه دارد. با رشد نیاز، به SAN منتقل شود و بعدتر از Amazon S3 استفاده کند. مصرف‌کننده‌ها تغییری نمی‌کنند، چون logistics storage پشت API پنهان شده است.

Microservice شبیه code library در granularity بزرگ‌تر است و اجازه می‌دهد unitهای enterprise با سرعت متناسب با business evolve شوند.

Monolithic هنوز جای خود را دارد. در Proof of Concept یا startup، ممکن است مهم‌ترین سؤال این باشد که «آیا ایده کار می‌کند و value دارد؟» نه اینکه architecture نهایی چگونه باشد. اما اگر برای هر upgrade مجبورید بخش بزرگی از enterprise را down کنید، در بلندمدت به شرکت آسیب می‌زنید.

در modernization legacy، شکستن componentهای قابل‌جداسازی به unit مستقل یکی از بهترین مسیرهای خروج از آشفتگی است، حتی اگر rewrite کامل ممکن نباشد.

Microservices روی team structure نیز اثر دارد. هر team می‌تواند owner یک unit باشد و development، maintenance و operation آن را مدیریت کند. در سازمان‌های بزرگ، userهای API همان customerهای داخلی یا خارجی team محسوب می‌شوند.

Cloud providerهای مدرن دقیقاً همین مدل را دارند. AWS مجموعه‌ای از microserviceهاست که functionality را از طریق API و pay-as-you-go ارائه می‌کند. بخش بزرگی از AWS از serviceهایی رشد کرد که ابتدا برای ecommerce اصلی Amazon ساخته شده بودند. وقتی library داخلی آن‌ها بالغ شد، همان capabilityها به developerهای بیرونی فروخته شد.

ممکن است شما AWS بعدی نباشید، اما API ecosystem قوی می‌تواند client را به شما نزدیک‌تر کند و اجازه دهد solution خود را بر پایه serviceهای شما بسازد.

۸.۷ متن‌باز (Open source)

Open source به codeای گفته می‌شود که برای استفاده جامعه منتشر شده و دست‌کم امکان مشاهده آن وجود دارد؛ اما بسته به license، استفاده و incorporation آن محدودیت‌هایی دارد. تفاوت ظریف licenseها مهم است، چون بعضی شرکت‌ها بدون شناخت دقیق آن‌ها بعداً هنگام فروش product یا همکاری با client با مشکل حقوقی روبه‌رو شده‌اند.

Open source یک منبع بزرگ از commodity software است و با reuse کردن componentها، development را سریع‌تر می‌کند. نمونه‌ها از operating system کامل مانند Linux و databaseهایی مثل MySQL و Postgres تا desktop applicationهایی مانند Firefox و OpenOffice و libraryهایی مثل jQuery و Gson را شامل می‌شوند. تقریباً در هر لایه‌ای گزینه‌ای open source وجود دارد.

۸.۷.۱ انواع مجوز (License types)

صرف اینکه source code را روی web می‌بینید، به این معنا نیست که می‌توانید آن را بردارید و مالکیتش را ادعا کنید. همان‌طور که توانایی اجرای یک آهنگ روی piano اجازه فروش recording بدون پرداخت royalty را نمی‌دهد، source code نیز می‌تواند copyright داشته باشد.

Open source معمولاً با licenseای منتشر می‌شود که دقیقاً تعیین می‌کند چه کارهایی مجاز و چه کارهایی ممنوع است. دو خانواده کلی وجود دارد:

• Copyleft
• Permissive

Licenseهای Copyleft معمولاً برای استفاده business محدودکننده‌ترند. معروف‌ترین نمونه GPL است. در بسیاری از سناریوها اگر software شما GPL code را به‌شکلی مشمول license استفاده کند، خود software و modificationهای مرتبط نیز باید تحت GPL منتشر شوند. بنابراین اگر secret-sauce algorithm شما به GPL code وابسته باشد، ممکن است از نظر حقوقی موظف شوید source code را در اختیار درخواست‌کنندگان، از جمله competitor، قرار دهید.

Licenseهای Permissive مانند BSD، MIT و Apache انعطاف بیشتری دارند. معمولاً اجازه می‌دهند commercial software از open source استفاده یا آن را extend کند و work نهایی را proprietary و closed source نگه دارد؛ به همین دلیل برای business مناسب‌ترند.

بعضی licenseهای Permissive می‌خواهند استفاده از library و copyright notice آن را در product نهایی اعلام کنید. در بخش About بسیاری از deviceها، از جمله Android phone، فهرست open source libraryهای استفاده‌شده دیده می‌شود.

Licenseها درباره copyright، patent protection و derivative work متن دقیق دارند. تفاوت‌ها زمانی جدی می‌شوند که modification قابل‌توجه انجام دهید یا work جدیدی بر پایه source اصلی بسازید.

نسخه سبک‌تر GPL، یعنی LGPL، در بعضی شرایط اجازه می‌دهد code خود را open source نکنید، به‌خصوص وقتی library را به‌صورت dynamic link استفاده می‌کنید و modification خاصی روی آن انجام نداده‌اید. این مدل معمولاً business-friendlyتر از GPL است.

این بخش بررسی حقوقی کامل نیست. برای استفاده مهم یا مبهم، research دقیق و نظر legal counsel لازم است.

۸.۷.۲ راهنمای استفاده (Usage guidelines)

استفاده از Open source باید تشویق شود، به‌خصوص در ecosystemهای Java، JavaScript و Python که تجربه و utility عظیمی در GitHub و SourceForge وجود دارد. بااین‌حال پیش از رهاکردن کامل تیم، guidelineهای زیر را مشخص کنید:

• فهرست licenseهای قابل‌قبول را اعلام کنید؛ معمولاً Apache، MIT و BSD انتخاب‌های اصلی‌اند.
• library باید به‌عنوان یک dependency مشخص استفاده شود. برداشتن بخشی از code و جا زدن آن به‌عنوان code تولیدشده داخل شرکت قابل‌قبول نیست.
• یک registry مرکزی برای همه third-party libraryها داشته باشید؛ حتی یک spreadsheet مشترک می‌تواند شروع خوبی باشد.
• برای هر dependency حداقل این اطلاعات را ثبت کنید:
  • نام library
  • website یا repository URL
  • license type
  • component یا service مصرف‌کننده

Guideline روشن به تیم اطمینان می‌دهد که سازمان استفاده مسئولانه از Open source را حمایت و تشویق می‌کند.

۸.۷.۳ انتشار متن‌باز (Publishing open source)

راه دیگر مشارکت، انتشار work خودتان برای استفاده دیگران است. دلایل ممکن عبارت‌اند از:

• پس از سال‌ها استفاده از work دیگران، چیزی به community برگردانید.
• با کمک contributorهای بیرونی bugها را سریع‌تر پیدا و software را robustتر کنید.
• در یک niche استاندارد ایجاد کنید و با جذب contributor، development را شتاب دهید.

شرکت‌های بزرگی مانند Google، Oracle، Microsoft، IBM، Netflix و Amazon پروژه‌های زیادی را با licenseهای مختلف open source کرده‌اند. Microsoft مالک GitHub است؛ یکی از بزرگ‌ترین platformهای hosting پروژه‌های Open source.

اگر library ساخته‌شده توسط تیم را open source می‌کنید، صرفاً آن را در Internet رها نکنید. پروژه open source باید maintain و update شود. libraryی که سال‌ها update نشده باشد contributor جذب نمی‌کند. پروژه موفق همانند internal library جدی گرفته می‌شود: bug fix، feature و documentation آن ادامه دارد.

پیش از publish کردن حتی یک line روی account رسمی GitHub شرکت، هدف و دلیل کار باید برای CEO و legal team روشن باشد. مشخص کنید دقیقاً چه codeای، با چه packaging و چه licenseای منتشر می‌شود. مطمئن شوید company IPR، trade secret، credential یا data حساس در repository نیست و خود شرکت حق انتشار code را دارد.

candidate مناسب برای open source معمولاً library کوچک و عمومی‌ای است که در مسیر ساخت product بزرگ‌تر ایجاد شده است. مواجه‌شدن با project مشابه نیز می‌تواند نشان دهد مسئله واقعی است و design شما در مسیر قابل‌قبولی قرار دارد.

۸.۷.۴ استفاده از کد موجود در وب (Using code from the web)

هر development team در مقطعی برای حل مسئله browser را باز می‌کند؛ برای فهم رفتار یک library، یادگیری syntax یا یافتن implementation نمونه. پاسخ ظاهراً آماده است: CTRL+C و بعد CTRL+V در IDE. اما صرف وجود code در Stack Overflow، blog یا article به معنای مجازبودن copy نیست.

code تولیدشده توسط team، asset و intellectual property شرکت محسوب می‌شود. بنابراین باید بتوانید با حسن‌نیت بگویید code بدون نقض copyright و بدون copy غیرمجاز ساخته شده است.

با guidelineهای commonsense می‌توان risk را کاهش داد:

• copy کردن snippetهای کوتاه آموزشی از developer forum معمولاً مسئله کمتری دارد، زیرا اغلب فقط نحوه استفاده از API یا library را نشان می‌دهد.
• برای blockهای بزرگ‌تر از حدود ۵ تا ۱۰ line، algorithm و ایده را بفهمید و implementation خودتان را بنویسید. فقط rename کردن variableها بازنویسی واقعی نیست.
• code از open source project فقط در صورتی استفاده شود که license اجازه دهد و همانند استفاده از کل library ثبت و مدیریت شود.

۸.۸ زبان‌ها و فریم‌ورک‌ها (Languages and frameworks)

انتخاب language و framework یکی دیگر از تصمیم‌های مهم CTO است و ممکن است اثر آن بسیار بیشتر از مدت حضور خود CTO در شرکت باقی بماند. در بسیاری از مواقع انتخاب قبلاً انجام شده، چون stack را از مدیر قبلی تحویل گرفته‌اید.

Business معمولاً اهمیتی نمی‌دهد enterprise با چه languageای اجرا می‌شود؛ تا زمانی که problem را حل کند و client راضی باشد. اما عوض‌کردن language یا حتی framework کار کوچکی نیست. سرمایه‌گذاری روی development team، training، deployment process، operational knowledge و support همگی به stack فعلی وابسته‌اند. تغییر language می‌تواند به rewrite بخش‌های بزرگ منجر شود، بدون اینکه value مستقیم قابل‌توجهی برای business داشته باشد.

بسیاری از انتخاب‌های اولیه language تصمیم آگاهانه نبوده‌اند. در companyهای founder-led، founder یا CTO اولیه همان languageی را که می‌دانسته برای همه‌چیز استفاده کرده و آن را برای taskهایی که برایشان design نشده خم کرده است. انتخاب واقعی وجود نداشته؛ فقط همان گزینه آشنا بوده است.

Framework مجموعه‌ای از library و standard روی language است که taskهای تکراری را ساده می‌کند؛ مانند authentication user یا file handling. نمونه‌ها شامل Java Enterprise Standard یا Spring روی Java، ReactJS برای JavaScript و Express.js برای Node.js هستند.

Framework scope بزرگ‌تری از language دارد و می‌تواند محدودکننده‌تر باشد. developerی که در framework خاصی متخصص است، حتی با شناخت language زیربنایی، ممکن است برای انتقال به framework دیگر همان language زمان بخواهد. بنابراین expertise مربوط به framework به‌اندازه language اهمیت دارد.

Language و framework مد می‌شوند و از مد می‌افتند. frameworkها سریع‌تر منسوخ می‌شوند، چون روی language سوارند و جایگزینی‌شان آسان‌تر است. اگر company بخش بزرگی از plumbing خود را روی framework خاصی ساخته و آن framework چند سال بعد متوقف شود، مجبور می‌شود هم product و هم خود framework را support کند.

Languageها نیز منسوخ می‌شوند، اما معمولاً در بازه طولانی‌تر. risk بیشتر برای languageهایی است که به یک company خاص و بدون independent standards body وابسته‌اند. اگر company خریداری، ورشکسته یا بی‌علاقه شود، language نیز ممکن است رها شود. Gupta، PowerBuilder و Delphi نمونه‌هایی از technologyهایی هستند که در دوره‌ای بسیار مطرح بودند و بعد بازارشان کوچک شد.

هنگام انتخاب language دست‌کم افق پنج‌ساله را ببینید. قرار است developer استخدام کنید، knowledge بسازید، deployment process و coding standard تعریف کنید و امیدوار باشید ecosystem language همچنان رشد کند.

۸.۸.۱ زبان‌های قدیمی (Legacy languages)

اگر language یا framework وارد حالت life support شده، یکی از taskهای مهم برنامه‌ریزی برای جایگزینی آن است. اما فقط به‌دلیل ناآشنایی خودتان آن را حذف نکنید. landscape را با چند factor بررسی کنید؛ از جمله سلامت recruitment market.

اگر development team در حال پیرشدن است و نیروی جوانی برای ادامه skill وارد بازار نمی‌شود، با technology رو به مرگ روبه‌رو هستید.

جایگزینی language effort و resource زیادی می‌خواهد. یکی از بهترین strategyها، جداکردن بخش‌هایی است که می‌توان به Microservice مستقل refactor کرد. به این ترتیب enterprise را piece-by-piece نوسازی می‌کنید و مجبور به full rewrite یک‌باره نیستید.

۸.۸.۲ انتخاب زبان یا فریم‌ورک بعدی

خبر خوب و بد این است که پاسخ واحدی وجود ندارد. صنعت دائماً «جدیدترین و بهترین» technology را معرفی می‌کند و آن را بسیار بهتر از گزینه‌های موجود نشان می‌دهد. احتمال Buyer’s Remorse وجود دارد، اما اگر research خوبی انجام داده باشید، تصمیم شما برای زمان خودش می‌تواند درست باشد.

هر candidate را با این پرسش‌ها ارزیابی کنید:

• چه کسی پشت آن است؟ اگر یک company نیروی اصلی است، موفقیت language چه سهمی از revenue و strategy آن company دارد؟ اگر market تغییر کند، project چگونه survive می‌کند؟ languageهای دارای independent standards committee معمولاً candidate بلندمدت بهتری‌اند.
• چند سال عمر دارد؟ maturity مهم است. هدف شما champion شدن technology نیست؛ باید solution پایدار برای client بسازید. معمولاً technology کمتر از دو سال را برای core enterprise انتخاب نکنید تا bugها، weaknessها و آینده ecosystem روشن‌تر شود.
• Community چقدر فعال است؟ developer هنگام سؤال به search engine مراجعه می‌کند. تعداد resultها، user groupهای فعال، Open source community، frequency release و تعداد کتاب‌ها یا courseها نشانه‌های مهم‌اند.
• آیا در university تدریس می‌شود؟ university مجبور است افق بلندمدت‌تری ببیند، چون graduate باید چند سال بعد نیز relevant باشد. languageهای وابسته به یک company معمولاً کمتر در curriculum پایدار جا می‌گیرند.
• بازار job چقدر بزرگ است؟ اگر فردا به یک team بزرگ نیاز داشته باشید، می‌توانید آن را recruit کنید؟ job boardها و agencyها را بررسی کنید؛ هم تعداد companyهای hiring و هم تعداد candidateها مهم است. ورود بیش از حد زودهنگام به lifecycle ممکن است شما را به پرداخت premium برای pool بسیار کوچک expertها مجبور کند.

تصمیم درست همیشه آسان نیست، اما تصمیم غلط معمولاً خیلی زود نشانه‌های خود را نشان می‌دهد. زمان بگذارید و عاقلانه انتخاب کنید. صرف اینکه Proof of Concept با یک technology ساخته شده، دلیل مناسبی برای productionalize کردن همان technology نیست؛ چیزی که برای demo سریع جواب می‌دهد لزوماً در scale واقعی مناسب نیست.

جمع‌بندی (Summary)

• تصمیم‌های فناوری اثر بسیار بلندمدت دارند.
• solutionی انتخاب کنید که شما را به یک vendor خاص قفل نکند.
• تشخیص زمان درست Build یا Buy همیشه واضح نیست و باید data-driven باشد.
• vendorها تلاش می‌کنند solution خود را پاسخ همه problemهای شما نشان دهند.
• Cloud به maturity قابل‌توجهی رسیده و در صورت استفاده درست flexibility و cost saving ایجاد می‌کند.
• On-prem برای requirementهای خاص هنوز جایگاه دارد، اما دامنه مناسب آن کوچک‌تر شده است.
• DR خارج از architecture واقعی Cloud-native، دشوارتر و تخصصی‌تر از چیزی است که بسیاری از businessها تصور می‌کنند.
• strategy fail forward و bounce back باید پیش از disaster روشن باشد.
• Data یکی از مهم‌ترین assetهای شرکت است و باید classification مناسبی داشته باشد.
• classification data تعریف ownership، aging، retention، visibility و security را ممکن می‌کند.
• Microservices راهی برای تقسیم enterprise به unitهای کوچک و قابل‌مدیریت است.
• Monolithic هنوز در بعضی موقعیت‌ها، به‌خصوص Proof of Concept، انتخاب قابل‌قبولی است.
• Open source سرعت و capability زیادی می‌دهد، اما license می‌تواند اثر حقوقی مهمی بر company داشته باشد.
• مشارکت در Open source شکل‌های مختلفی دارد و می‌تواند به ایجاد standard و community کمک کند.
• انتخاب language و framework روی recruitment، maintenance و growth آینده اثر مستقیم دارد؛ stack باید تا حد ممکن future-proof باشد.

چک‌لیست نهایی (Final checklist)

چند مورد از این موارد را واقعاً پوشش داده‌اید؟

• برای component حیاتی enterprise به یک vendor واحد وابسته نیستیم.
• برای تصمیم Build vs. Buy comparison matrix نوشته‌ایم.
• هیچ‌یک از ۱۰ Cloud warning sign در environment ما وجود ندارد یا برای رفع آن plan داریم.
• اگر hardware خودمان را اداره می‌کنیم، در data center تخصصی یا حداقل room جدا و ایمن قرار دارد.
• DR strategy شامل trigger، failover، fail forward یا bounce back نوشته شده است.
• DR plan در ۱۲ ماه گذشته عملاً تمرین شده است.
• همه data flowها و classificationها همراه security، visibility و retention policy map شده‌اند.
• team با تفاوت licenseهای Open source آشناست و dependency registry داریم.
• فهرست کوچک و روشن language/frameworkهای core همراه standardهای quality و production نگهداری می‌شود.