Имеет ли смысл решать вопрос нагрузки в приложении?
Решил рассказать про опыт разработки приложения для оптового дистрибьютора цветов в Краснодаре и вопросе нагрузки на БД. Отличие от большинства «цветочных» приложений в том, что оно сделано не для конечных покупателей, а для розничных продавцов, которые оформляют заказ удалённо, либо приезжая на базу.
Мой голословный ответ на заголовок поста.
Для b2b проекта на ранней стадии преждевременные оптимизации естественно не имеют смысла. Тем более, что в адекватном проекте клиент всегда будет иметь встроенную телеметрию, которая не даст проспать момент ухода латенси бэка в красную зону. В этом случае, пожалуйста, хоть десять облаков, saas, paas, faas, maas и любой ass на выбор создателей. Вероятность выжить все равно в районе 5%.
Все становится намного интереснее когда ты изучаешь разбивку костов более-менее популярного проекта, который уже вроде бы и выжил, но развивал кодовую базу в упоре на облака. Опуская постоянную борьбу ops-стафа с латенси на чужой бесконтрольной территории с узлами имеющими отвратительный интерконнект и неспособными обработать единый стэйт проекта на одном узле, мы увидим шокирующие адекватного CFO счета от ажура, авса и прочих гулов в 30-35% от operational costs. Упс, технологический и экономический тупик для любителей облаков.
И когда ты считаешь затраты на серверную стойку пусть даже не нового железа, но с сильным интерконнектом на 40 Gbe для изначально правильно выбранной архитектуры с in-memory db и даже пусть отстающей персистенцией на энергонезависимые носители, то понимаешь, что ее срок окупаемости - 1 месяц начислений от облаков. Полный и быстрый контроль над всей инфраструктурой и правильный Ux для клиентов, как минимум с точки зрения латенси. Как же хорошо жить! В мечтах.
Но эффективные менеджеры как всегда хайпанули, избавились от изначального головняка создания правильной архитектуры, и теперь вопрос выживаемости - это очередная подачка кэша от инвесторов вечно убыточному проекту. Тех. долг он такой - предъявит вексель в самый ненужный момент.
Вы всё круто написали, но пример из статьи - это офлайн бизнес, а не сферический стартап в вакууме.
Я и показывал, что если заказы идут, то не жалко и на облако, а если нет, то нужно либо оптимизировать запросы, либо идею.
На одном теряешь,на другом выигрываешь.
Облака и managed инфраструктура значительно снижает затраты на админов и повышает надежность.
На небольших нагрузках стоимость исчезающе мала, на больших позволяет гибко скалироваться исходя из потребностей. Кто мне будет на выходные демонтировать стойку в хейтцнере?
И кучи кучи других многократно описанных преимуществ клауда по сравнению со своим железом.
Если вы уже не ИП Пупкин, который может позволить себе упавший на день сайт, но ещё не гигант, который может позволить себе несколько своих датацентров и армию админов, то прямая дорога в iaas, baas, faas и другие *aas.
есть дешёвые облака, у того же хетцнера они по цене как обычные сервера. а всякие aws стартапы используют за счёт бесплатного tier для стартапов, там 100 тыщ выдаётся. прожираешь их и тогда уже уходишь на свои мощности :)
С одной стороны облака дороже сейчас но если смотреть лет на 5-10 вперёд то скорее всего обычного хостинга не останется а хостингом станет облако. Лучше начинать готовится заранее. Например какой то ентерпрайс до сих пор может пользоваться Java 1.6-1.7 и платить Ораклу огромные деньги за поддержку потому что вовремя не перешли на новую версию не видя в этом пользы. Так же точно с меинфреймами которые выбирались потому что когда то были выгодней обычных серверов а сейчас их поддержка обходится миллионы. Универсальное решение найти сложно.