انتخاب زیرساخت ابری مناسب برای استارت آپ های SaaS 

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

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

استارت آپ های نرم افزار به عنوان سرویس (SaaS) نیز از این قاعده مستثنی نیستند.

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

اگر در حال ساخت یک محصول SaaS هستید، ابتدا باید سخت افزار را خریداری و تهیه کنید. سپس، سیستم عامل را نصب کنید و به دنبال آن runtimes  مانند JVM، v8 و Python را نصب کنید. پس از آن، تمام متعلقات را نصب کرده و در نهایت، کد خود را قرار خواهید داد.

گزینه های زیرساخت ابری

هر گزینه زیرساختی که امروزه در دسترس است،چکیده ای از یک یا دو مورد از موارد زیر است:

ماشین های مجازی ابری (IaaS): آنها در درجه اول لایه سخت افزاری را انتزاعی می کنند، شما نیازی به ارائه هیچ چیز فیزیکی ندارید، اما همچنان باید لایه های دیگری بسازید. این حداکثر کنترل را به شما می‌دهد، اما راه‌اندازی آن به عنوان مثال‌: EC2 ، Azure VMs ، Google Cloud Platform (GCP) زمان میبرد.

پلتفرم به عنوان سرویس (PaaS): لایه دیگری از انتزاع را بر روی سخت افزار ارائه می دهد و نیازی نیست نگران سیستم عامل/کانتینرها، ارتقاء، امنیت و غیره باشید. به عنوان مثال می توان به Azure PaaS، AWS Elastic Beanstalk و GCP PaaS اشاره کرد.

بدون سرور (عملکرد به عنوان سرویس) (FaaS): این PaaS با انتزاع runtime  است. در این مورد نیازی نیست نگران runtime  باشید. نمونه های اصلی AWS Lamda، Azure Function و Google Cloud Functions هستند.

Low Code: همراه با سخت افزار، سیستم عامل و runtime  ، انتزاعی از مدیریت وابستگی ها نیز دریافت می کنید. مثلا parse. شما باید در مورد بهترین شیوه ها فکر جدی کنید.

Kubernetes (K8) (ارکستراسیون کانتینر): اگر در ابتدا روی Kubernetes سرمایه گذاری کنید یا از هر Kubernetes به عنوان یک سرویس (EKS) زمانی که آماده تولید است استفاده کنید، کد خود را به صورت pod ارسال می کنید. از دیدگاه انتزاعی، شبیه به Serverless است اما همچنان کنترل بیشتری را ارائه می دهد.

Zero code: پلتفرم‌ها و سرویس‌هایی وجود دارند که به شما امکان می‌دهند بدون نوشتن کد، برنامه‌های کاربردی ایجاد کنید. با این حال، این بدان معنا نیست که شما به توسعه دهندگان نیاز ندارید. این یک نمونه اولیه سریع، MVP ها و کد اولیه بوت استرپ را ارائه می دهد. برای مثال Zoho یا Quick Base. ما قرار نیست پلتفرم‌های کد صفر را پوشش دهیم.

حالا بیایید در مورد عوامل کلیدی که می توانند بر نتیجه تأثیر بگذارند بحث کنیم.

7 عامل موثر بر زیرساخت یک برنامه SaaS

عامل 1: مخارج اداری

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

اگر محصول عمدتاً توسط شرکت‌ها استفاده می‌شود و نیاز به سفارشی‌سازی دارد، ممکن است لازم باشد چندین بار محصول را اجرا کنید، که می‌تواند به معنای تلاش و زمان بیشتری از طرف مدیران زیرساخت باشد. استقرار می تواند خودکار باشد، اما فرآیند اتوماسیون مستلزم پایداری محصول است. ROI ممکن است برای یک محصول در مراحل اولیه خوب نباشد. توصیه ما در چنین مواردی استفاده از سرویس های مدیریت شده مانند PaaS برای زیرساخت، سرویس های مدیریت شده برای پایگاه داده/مداوم، و معماری FaaS—Serverless برای محاسبات است.

فاکتور 2: زمان به بازار (TTM)

کلید TTM  توسعه سریع، آزمایش و انتشار است. و کلید توسعه سریع برای انتشار، این است که زمان بیشتری را برای کدنویسی و آزمایش صرف کنید تا اینکه برای تهیه و استقرار.  پلتفرم های Less-code و بدون کد برای شروع خوب هستند. Serverless و FaaS برای حل این مشکلات طراحی شده اند. اگر سیستم شما شامل کامپوننت های زیادی است، ساختن باکس های خودتان، زمان و تلاش زیادی را صرف می کند. به همین ترتیب، راه‌اندازی Kubernetes آن را سریع‌تر نمی‌کند.

PaaS هنوز گزینه‌های بهتری نسبت به ماشین‌های مجازی ابری ارائه می‌دهد، اما ممکن است برای افزایش سرعت TTM نیاز به ایجاد پایپ لاین استقرار (CI/CD) داشته باشید. پایپ لاین های CI/CD به طور ضمنی در پلتفرم های با Low-code در دسترس هستند. همچنین ممکن است بخواهید ابزارهایی را انتخاب کنید که ابر آگنوستیک هستند و به شما امکان می دهند بعداً به پلتفرم های دیگر مهاجرت کنید. پلتفرم های Zero code و Less-code ریسک قابل توجهی در این زمینه دارند.

عامل 3: چابکی

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

برای داده ها، سرویس های داده Serverless مانند AWS Aurora یا Azure’s Cosmos DB انتخاب های عالی هستند. اگر در حال ایجاد یک گردش کار یا پردازش داده هستید، خدمات آنلاین مانند توابع پله ای راه حل  خوبی هستند. همچنین برای برنامه های کاربردی، Serverless یا FaaS یک انتخاب عالی است. شما همچنین می توانید سیستم چند مستاجر را با Kubernetes بسازید، اما این نقطه شروع خوبی نیست زیرا ممکن است نیاز به نگهداری بسیاری از نسخه های برنامه، داده ها و عملکرد داشته باشید. معماری Serverless ممکن است گزینه مناسبی برای شروع باشد.

عامل 4: کنترل

این که فکر کنید چقدر بر زیرساخت کنترل خواهید داشت مسئله مهمی است شما کنترل بیشتری نیاز خواهید داشت اگر:

• الف) تعداد زیادی برنامه، پایگاه های داده و خدمات زیادی وجود داشته باشد.
• ب) سیستمی است که در آن باید برای مشتری خود سخت افزار تهیه کنید (MongoDB Atlas).
• ج) باید داده ها یا زمان اجرا یا هر دو را برای مستاجران خود جدا کنید.
• د) این یک سرویس یا API آنلاین است و USP شما برای صرفه جویی در هزینه مجوز، سخت افزار و مدیریت، برای مشتریان شما است.

حداکثر کنترل را با یک ماشین فیزیکی یا قفسه شخصی خود خواهید داشت، اما اینها دیگر استفاده نمی شوند—بنابراین بهترین موردبعدی برای حفظ سطح بالای کنترل، نمونه های اختصاصی پیشرفته است. پلتفرم های Serverless ، Less-code و No-code کمترین میزان کنترل را ارائه می دهند.

Kubernetes زمان و تلاش زیادی را صرف خواهد کرد، اما از منظر کنترل بلندمدت، معامله خوبی است. تا حد امکان از خدمات آنلاین خودداری کنید و به یاد داشته باشید که در حال ساختن آن هستید.

عامل 5: هزینه

هزینه یکی از مهمترین عوامل است. برآورد هزینه اولیه همیشه دشوار است، اما اجازه دهید با یک مثال شروع کنیم:

برای 10 هزار درخواست در ساعت در روز، یک زیرساخت Serverless برای شما بسیار بیشتر از ماشین های مجازی ابری هزینه خواهد داشت. اما اگر بار ناهمگن باشد و برای برخی از ساعات تصادفی 10K و برای برخی دیگر 1K باشد، راه‌اندازی نمونه‌های ماشین مجازی ابری ممکن است پرهزینه باشد زیرا در بیشتر مواقع از آن‌ها استفاده ناکافی می‌شود و در زمان بی‌حرکتی هیچ ارزشی نخواهند داشت. .

برای شروع، شما سعی می کنید تا زمانی که ممکن است از هرگونه هزینه ثابت جلوگیری کنید. اما برای استفاده بهتر، باید نقاط سربه سر را پیدا کنید و به سطح پایین تر (Low-code به برنامه Serverless یا Serverless به برنامه کانتینری) برگردید. از بهینه سازی زودرس خودداری کنید و در ابتدا اصلا دنبال بهینه سازی یا تعادل نباشید. ارزان ترین اشتراک را انتخاب کنید و بعداً به سراغ امکانات بهتر بروید

عامل 6: مهاجرت

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

به عنوان مثال، اگر اجزای مختلفی برای دسترسی به سایر مؤلفه‌ها دارید و تیم DevOps شما این مدیریت دسترسی را کاملاً بر اساس نقش IAM طراحی کرده است، در این صورت مهاجرت از AWS به GCP می‌تواند سخت‌تر باشد. به طور مشابه، اگر باید یک لایه محاسباتی کامل را روی سرور Serverless بسازید، مهاجرت به یک ماشین مجازی ممکن است ساده نباشد.

عامل 7: یکپارچگی

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

با ادغام، ممکن است چندین نمونه نقطه یا چندین نمونه Serverless را در مدت زمان کوتاهی برای جمع‌آوری/ارائه داده‌ها از سایر APIها برای غلبه بر محدودیت‌های throttling و نرخ API ایجاد کنید. Serverless در اینجا کمک بزرگی است. گره های Kubernetes با مقیاس خودکار نیز خوب هستند. اگر یک نمونه ماشین مجازی ابری را انتخاب می‌کنید، باید مدتی زمان و تلاش خود را صرف ارائه خودکار کنید.

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

چارچوب تصمیم گیری

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

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

• آسان: می توانید یک پیکربندی ساده را انجام دهید و کارتان تمام شده است. با تلاش و زمان کمتر می توانید به فاکتور مورد نیاز دست یابید.
• متوسط: ممکن است برای دستیابی به یک عامل خاص نیاز به پیکربندی/تنظیم بیشتری داشته باشید، که ممکن است راه ساده ای نباشد.
• سخت: برای دستیابی به عامل، ممکن است نیاز به سرمایه گذاری زمان و تلاش با استفاده از یک استراتژی صریح داشته باشید. ممکن است به تخصص خاصی نیز نیاز داشته باشید.

نظریه

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

شما باید خود را از پلتفرم‌های کم‌کد/بدون کد دور نگه دارید، زیرا ممکن است شروع آن‌ها آسان به نظر برسد، اما میدان‌های مین برای آینده هستند، آنها در سه عامل مهم به شما کمک نخواهند کرد: هزینه زیرساخت، هزینه مدیریت فناوری اطلاعات، و هزینه لایسنس. هزینه PaaS  تا حدودی قابل قبول است، اما در صورت ارتقا سطح سیستم عامل، برخی مسدودکننده ها را نیز ارائه خواهد کرد.