وقتی قراره یه کار جدید شروع کنیم که احتیاج به سرور داره، همون اول کار، خریدن یا اجاره کردن یه سرور با بهترین کانفیگ، منطقی و اقتصادی نیست. اصلا معلوم نیست کار به جایی بکشه که ما نیازمند اون مقدار از Resource باشیم، اما باید طوری عمل کنیم که اگر روزی بیزینس Viral شد، برای تحمل کردن حجم زیاد درخواست‌ها سریعا بتونیم واکنش نشون بدیم و فرصت رو از دست ندیم.
در صنعت ما باید واقع‌گرا باشیم، همیشه یک سری تمایلات درونی داریم که ما رو تحریک می‌کنن که تحت تاثیر fact هایی مثل «فلان زیرساخت خیلی خفنه»، «فلان زبان خیلی Benchmark خوبی داره» و «فلان فریم ورک خیلی قابلیت های ویژه‌ای داره» قرار بگیریم. خیلی از ما و حتی خود من خیلی جاها تحت تاثیر این موارد قرار گرفتیم.
برای یک پروژه‌ی شخصی کوچیک که قرار نیست بزرگ بشه، تجربه کردن اصلا بد نیست بلکه شدیدا توصیه می‌کنم که با همه‌ی تکنولوژی‌های جدید آشنا بشید. اما برای یک شرکت بزرگ و به ویژه یک استارتاپ کوچک که پلن اش بزرگ شدنه خیلی باید دقت کرد.
در زیر می خواهم تجاربی رو که طبق تلاش های چند ساله‌ام در Quiz of Kings (که به یکی از بزرگترین بازی‌های ایرانی دانستنی آنلاین در ایران بدل شده) به دست آوردم به طور خلاصه توضیح بدم.
در انتخاب زبان، تکنولوژی، زیرساخت و … باید به موارد زیر توجه کرد:
۱- نحوه‌ی توزیع نیروی انسانی متخصص به تکنولوژی مربوطه در کشور
۲- سهولت کار کردن با تکنولوژی مورد نظر و داکیومنت با کیفیت داشتن آن تکنولوژی
۳- فعال بودن Community برای تکنولوژی مورد نظر
۴- قابل توسعه بودن تکنولوژی مد نظر با هزینه منطقی
۵- دارا بودن Benchmark مناسب
۶- دارا بودن شرایط Disaster Recovery
اکنون به بررسی خلاصه‌ای از شرح هر یک از موارد بپردازیم:
۱- نحوه‌ی توزیع نیروی انسانی متخصص به تکنولوژی در کشور
چه آینده‌ای برای کار خود متصورید، آیا به این فکر کردید که با پا گرفتن استارتاپ شما، احتمالا نیروهای فنی اولیه، دیگر به تنهایی قادر به اداره‌ی امور نخواهند بود و احتیاج به توسعه‌ی تیم فنی خود دارید؟
خب، وقتی تیم فنی‌تون نیاز به توسعه پیدا کرد، اگر به این مورد توجه نکرده باشید، به این راحتی‌ها نیروی کار پیدا نخواهید کرد.
فرض کنید که شما تکنولوژی‌ای را انتخاب کرده‌اید که تنها ۱۰ درصد اکوسیستم فنی به آن مسلط هستند، آیا فورا با گذاشتن آگهی شغلی، این ۱۰ درصد از وجود شما مطلع میشوند؟ اگر مطلع شوند آیا تمایل به همکاری با شما دارند؟
فرض بگیریم که نیروی کار هم پیدا شد، یکی از عوامل اصلی برای قیمت گذاری را می‌توان عرضه و تقاضا بر شمرد، وقتی که عرضه کم باشد، آیا به نظرتان با یک عدد حقوقی عرف بازار می‌توانید این افراد را جذب کنید؟ خیر!
وقتی نیروی کار برای بخش کاری مد نظر شما کم باشد، به توافق رسیدن سخت می‌شود و شاید اگر متوسط حقوقی دریافتی بازار برای Position مورد نظر را X تومان در نظر بگیریم، شما برای راضی کردن آن افراد به پیوستن به شرکت خود مجبور به پرداخت 1.5X تا 2X تومان شوید. این تازه در شرایط خوشبینانه است که نیرو پیدا شود، اما شدیدا توصیه می‌کنم این عامل را اصلا نادیده نگیرید و همیشه به آن توجه کنید که در کشور شما چقدر نیروی کار متخصص برای آن نیرو وجود دارد؟
شاید در ایران توسعه دهنده‌ی PHP خیلی زیاد باشد و در کشور دیگری خیلی کم، در ایران انتخاب زبان PHP برای توسعه از منظر این فاکتور معقول به نظر می‌رسد اما در آن یکی کشور یک انتخاب غیرمنطقی و پرخطر!
۲- سهولت کار کردن با تکنولوژی مورد نظر و داکیومنت با کیفیت داشتن
سهولت، یکی از مهم‌ترین عواملی است که باید در نظر بگیرید.
سهولت کار کردن با تکنولوژی باعث میشه که نیروهایی که با این تکنولوژی کار نکردن به سرعت کار کردن باهاش رو یاد بگیرن. پس از طرفی اگر نیرویی استخدام کردید که کار با این تکنولوژی رو بلد نبود، به راحتی می‌تونه با خوندن داکیومنت‌ها، اون تکنولوژی رو یاد بگیره و از طرف دیگه سهولت باعث میشه که تعداد نیروهای آشنا با تکنولوژی در بازار هم زیاد بشه.
وجود داکیومنتیشن با کیفیت برای تکنولوژی مورد نظر هم باعث افزایش سرعت در یادگیری میشه و باعث میشه در صورتی که در کار به مشکلی برخوردید به راحتی با استفاده از آن، مشکل را برطرف کنید.
۳- فعال بودن Community برای تکنولوژی مورد نظر
این نکته بسیار حائز اهمیته که تکنولوژی‌ای که قراره ازش استفاده کنید و باهاش کار کنید «زنده» باشه!
یعنی وقتی به GitHub پروژه مراجعه کردید از آخرین Commitاش زمان زیادی نگذشته باشه و پیوسته در حال به روز شدن باشه.
این باعث میشه وقتی به یک باگ در اون پروژه برخورد کردید، بتونید گزارشش کنید، با سایر افراد درباره‌اش گفتگو کنید که در نتیجه، هم یه راه حل موقت براش پیدا می‌کنید و هم اینکه مطمئن می‌شید در آپدیت های بعدی، اون مشکل اصلاح میشه.
اخیرا می‌خواستیم از یک Library مشهور استفاده کنیم، با چک کردن Communityاش متوجه شدیم توسعه دهنده مدت زیادیه به مشکلات پاسخ نمیده! اون Library فقط توسط یک نفر ساپورت میشد که فوت کرده بود و دیگه روند توسعه‌اش متوقف شده بود، برای همین از خیر استفاده از این Library گذشتیم.
یک نکته مهم که باید در این باره بهش توجه کنید اینه که اگر خواستید از یک Library استفاده کنید و چندین انتخاب داشتید که یکی از اونها مربوط به یک شرکت رسمی بود، Library مربوط به شرکت رسمی رو تو اولویت بگذارید.
مثلا ما در Golang برای تست نوشتن از یک پروژه استفاده کرده بودیم که متعلق به خود Golang نبود ولی کار کردن باهاش راحت تر بود، بعد از مدتی پروژه کنسل شد و عملا تستهایی که باهاش نوشته بودیم دیگه با آپدیت کردن Go قابل استفاده نبودند!
۴- قابل توسعه بودن تکنولوژی مد نظر با هزینه منطقی
در یک سری مواقع تکنولوژی مورد نظر فاکتورهای بالا رو داره، اما قابلیت Scale شدن رو نداره، یعنی می‌توان اون تکنولوژی رو تنها روی یک سرور پیاده کرد و نمی‌توان آن را روی چند سرور به صورت توزیع شده بالا آورد تا بار درخواست‌ها به آن بین چندین سرور تقسیم بشه.
اگر یک تکنولوژی این قابلیت رو نداره همون اول از انتخابش صرف نظر کنید، چون وقتی تعداد کاربران شما و در نتیجه بار روی سرور حاوی این زیرساخت زیاد شد، باید در یک شرایط بحرانی و در یک مدت زمان کم اون زیرساخت رو تعویض کنید. پس بهتره از همون اول در انتخاب دقت کنید.
گاهی اوقات یک زیرساخت Scale پذیر هست اما نه به صورت رایگان بلکه به صورت Enterprise.
با توجه به قیمت ارز در کشور ما این شرایط اصلا نمی‌صرفه، پس توی این شرایط هم باید از انتخاب اون زیرساخت صرف نظر کرد.
به عنوان مثال ما در کوییز می‌تونستیم Mysql رو با استفاده از شرکتهایی که خدمات Enterprise می‌دادند Scale کنیم و به ازای هر Instance از Mysql مبلغ بالایی به دلار پرداخت می‌کردیم. الان نزدیک ۲۰۰ تا node از mysql داریم. اگر راه‌حل Enterprise رو انتخاب می‌کردیم الان شرکت کاملا در ضرر بود.
۵- دارا بودن Benchmark مناسب
وقتی می‌خواهید یک زیرساخت یا زبان رو برای کار خود انتخاب کنید باید پیش‌بینی کنید که حداکثر لود سیستم روی اون زیرساخت چقدر خواهد شد.
این موارد با توجه به نوع کار شما قابل پیش‌بینی هستند.
مثلا یک شرکت می‌خواهد یک فروشگاه اینترنتی راه بندازه، بار یک فروشگاه اینترنتی اصلا با یک بازی آنلاین قابل مقایسه نیست. پس اصلا نباید اولویت ما خیلی رو مباحث Performance ای متمرکز بشه که وقتی Load سیستم خیلی بالا میره تفاوتش حس میشه.
به طور دقیق‌تر مثلا وقتی فکر می‌کنید که یک زبان نسبت به دیگری اولویت داره و Benchmark هاشون رو مقایسه می‌کنید، دقت کنید که آیا اصلا این برتری برای کاربران شما محسوس هست یا نه؟
به عنوان مثال در یک فروشگاه اینترنتی اگر شما برای باز کردن هر صفحه ۱ ثانیه منتظر بشید این مشکلی نداره و از دید کاربر چندان اهمیتی نداره، اما برای یک بازی این می‌تونه کاملا اعصاب کاربر رو خرد کنه.
پس مسائل مربوط به Performance رو باید با توجه به جایگاهی که قرار هست ازش استفاده بشه در نظر گرفت.
۶ - دارا بودن شرایط Disaster Recovery
هنگام انتخاب زیرساخت به این مورد دقت کنید که زیرساخت مورد نظر دارای قابلیت Replication هست یا خیر.
وقتی برای یک زیرساخت، در چندین سرور Replica بالا بیاورید، در صورتی که سرور اصلی که Master Node روی آن است از دسترس خارج شود، به راحتی می‌توان Replica را جایگزین آن کرد و از Down شدن سیستم جلوگیری کرد.
نکته دیگر اینکه فرض کنید هیچ Replica ای ندارید، اگر فرضا دیتابیس MySql شما کرش کرد و دیگر بالا نیامد باید بتوانید از روی فایل های binlog آن دیتاهای خود را برگردانید، در حالی که در MongoDB دیتاها به صورت فایل JSON ذخیره میشوند. در شرایط مشابه بین MySql و مانگو، بازیابی دیتای MongoDB آسان تر از MySQL است چون افراد زیادی با ساختار JSON آشنایی دارند در حالی که سر و کار افراد خیلی کم به فایل های binlog می‌افتد.
این نوشته، یک چکیده از مواردی بود که به طور کلی برای انتخاب تکنولوژی‌های فنی بایستی آنها را در نظر گرفت.
در آینده، با مثال هایی چندین زبان یا تکنولوژی را با معیارهای بالا با یکدیگر مقایسه خواهیم کرد.
از شما بابت وقتی که برای خواندن این نوشته صرف کردید، متشکرم.
