Комментарии 4
С Firebase на Supabase? Да тут попахивает FlutterFlow батенька и прочими дартами)
Тоже относительно недавно переехали на Firebase на self-hosted Supabase, впечатления пока очень хорошие
факт в том, что на сегодняшний день мелким и средним бизнесам ВООБЩЕ не нужна распределенка, k8s и прочие гадости:
Большинство enterprise-scale архитектур основаны на предположении, что одной машины недостаточно для обработки требуемой рабочей нагрузки. Большинство облачных решений, особенно serverless, основаны на той же предпосылке: если вам нужно что-то масштабировать, то оно должно быть distributed! Вторым вопросом является отказоустойчивость: в распределенной, масштабируемой системе легче обработать отказ одного компонента и, таким образом, увеличить uptime.
Сколько операционных данных хранит ваше бизнес-приложение? 1 мегабайт на клиента? Тогда 1 миллион клиентов потребуют всего 1 ТБ. И у нас еще осталось довольно много свободного пространства — в оперативной памяти! 1000 запросов в секунду к in-memory database? Я почти гарантирую вам, что у вас больше, чем несколько ядер CPU будет простаивать. 10 000 запросов (40 на ядро в секунду) или даже 50 000 звучит более правдоподобно.
А как насчет отказоустойчивости? Все постоянно выходит из строя, верно? По крайней мере, так сказал Werner Vogels, но это было в 2008 году, когда AWS была немного больше, чем S3, SQS и EC2, последний из которых только что вышел из публичной бета-версии и получил SLA — возможно, это взаимосвязано. Современные серверы имеют избыточные, сменные блоки питания и вентиляторы, диски с возможностью горячей замены, а некоторые, как утверждается, даже имеют сменную оперативную память! Тем не менее, вы не будете хранить все свои данные только в оперативной памяти, а будете писать в persistent log, который позволит вам восстановить состояние системы в случае сбоя. Для большого сервера это может занять некоторое время. Например, если у вас будет 2 сбоя оборудования в год и время восстановления составляет 30 минут, то вы все равно получите 4 девятки, примерно столько же, сколько вам обещает большинство облачных сервисов. В действительности вы, вероятно, разобьете свою систему на более мелкие компоненты: на высокодоступные, и другие, которые могут позволить себе немного более длительное MTTR.
вот ссылка, если нужны подробности: https://www.linkedin.com/pulse/past-constraints-you-never-thought-sergey-derevyago-ien3f
А что мешает взять для стартапа несколько vps или bare metal серверов в разных зонах и развернуть на них кластер куба? Про нагрузки в статье в целом понятно, а про отказоустойчивость?
Как чужая ошибка в коде сожгла $100,000 на Firebase: спасаем стартап и разбираемся, какой сервер вам реально нужен