BaaS-платформы (Backend as a Service) сделали разработку и сопровождение backend'а для мобильных и веб-приложений достаточно простыми и предсказуемыми процессами. Одним из флагманов движения BaaS стала компания Parse, но в 2016 году она заявила о прекращении обслуживания клиентов с 2017 года.
В связи с закрытием их сервиса и отсутствием русскоязычных облачных BaaS, мы решили создать собственный аналог — Scorocode. Об этом под катом.
Расцвет BaaS
Разработка серверной части — самый трудный и непредсказуемый этап создания приложения. Зачастую, при планировании разработки проекта, недооценивается необходимый объём ресурсов и время создания backend'а.
Одна из возможных причин — трата времени на выбор инструментария, базы данных, платформы, операционной системы и т.д. Поэтому реализация даже относительно простых проектов может сильно затянуться, что приведёт к увеличению расходов.
Другая причина заключается в ограниченности доступных команде ресурсов. Чаще всего разрабатывать backend приходится с помощью тех инструментов и технологий, которыми владеют члены команды. Процесс получается долгим, а само приложение — сложным и дорогим в сопровождении.
Долгое время ИТ-индустрия искала способы упрощения разработки backend'а. Многие компании создавали инструменты, облегчающие работу над частными аспектами разработки, но это только затрудняло процесс: разработчикам приходилось разбираться не только в конкретной СУБД или платформе, но и в дополнительных инструментах.
Всё изменилось в 2011 году, когда компания Parse предложила новый подход к созданию backend'а на основе облачного сервиса. Он позволял решить две основные задачи:
- Хранение в облаке и свободное манипулирование структурированными данными;
- Возможность писать серверную бизнес-логику на JavaScript — стабильно популярном языке программирования на протяжении нескольких лет.
Позднее были добавлены другие полезные функции, облегчающие создание backend'а и инструменты для решения рутинных задач.
Идея имела колоссальный успех. В середине 2012 года сервисом пользовалось 20 000 разработчиков, а ежемесячный прирост пользователей составлял 40%. Теперь этап разработки backend'а занимал дни, а не месяцы, и сэкономленные ресурсы можно было направить на разработку и совершенствование frontend'а.
Использование BaaS позволило точнее оценивать сроки разработки и необходимые ресурсы. Сам процесс создания backend'а стал более формализованным, позволяя для разных платформ использовать единую серверную часть, упростилось сопровождение проекта, расходы снизились и стали более прогнозируемы.
Scorocode: начало
Три года назад Facebook приобрёл Parse, и в конце 2015 года социальная сеть решила использовать мощности BaaS монопольно. Все остальные разработчики должны в течение 2016 года мигрировать на другие ресурсы.
Это событие совпало по времени с началом разработки нашей собственной BaaS-платформы. Изначально мы хотели создать сервис, сразу предоставив пользователям как базовую функциональность аналогичных платформ, так и большое количество новых уникальных функций. В результате мы сделали небольшой пивот, и в качестве отправной точки для Scorocode приняли базовую функциональность Parse с возможностью миграции данных из него в наше облако.
Scorocode: техника вопроса
Scorocode — горизонтально масштабируемая система, построенная на принципах кластеризации. Кластеры разделяются по типам: API, СУБД, файлы, статистика. Каждый кластер API, работающий с конечными приложениями, выдерживает нагрузку около 25 тысяч запросов в секунду. С ростом нагрузки количество кластеров наращивается.
Немного о платформах и языках, используемых нами в разработке.
Основная СУБД в Scorocode — MongoDB, в качестве in-memory database используется Redis, а сервер очередей работает под управлением RabbitMQ. Высокопроизводительный API написан «с нуля» на Go. Язык был выбран нами после серии экспериментов с Node.js и С++. Google в последнее время очень активно развивает Go, писать на нём комфортно, код получается компактным, а производительность на уровне С++. Множественные микросервисы платформы тоже разработаны на Go.
Scorocode позволяет исполнять два варианта серверного кода:
- JS-скрипты с бизнес-логикой. Они хранятся и выполняются на наших серверах. Причём выполняются асинхронно — по расписанию или с запуском вручную с клиентов, посредством вызовов через API. Выполнением серверных скриптов занимается движок Google V8.
- Триггеры на JS, то есть обработчики операций с данными. Они выполняются высокоскоростным движком, написанным на Go. В данном случае мы отказались от V8, потому что он достаточно долго стартует, а у каждого обработчика есть всего лишь 500 миллисекунд для выполнения кода.
Чем мы отличаемся от конкурентов?
- Scorocode состоит только из самописных и open source-компонентов. Исключена ситуация, когда в какой-то из компонентов сторонними разработчиками вносятся изменения, с которыми нам придётся мириться. Нам известно устройство и алгоритмы работы каждого элемента системы, поэтому исправление ошибок и реализация новых функций могут выполняться в кратчайшие сроки.
- Корпоративные клиенты могут хранить чувствительные данные в собственном облаке. В этом случае на Scorocode обрабатывается только бизнес-логика, а все запросы к данным перенаправляются на клиентское облако.
- Вся документация на русском языке. Признаемся честно — не всем хватает знания технического английского, чтобы прочитать документацию без затруднений.
- Все серверы и данные находятся на территории РФ. Это позволяет нашим клиентам соблюдать требования законодательства.
Финансовый вопрос
На данный момент у нас действует три тарифных плана:
- Бесплатный “Free”. Если вы начинающий разработчик, то возможностей тарифного плана может хватить для полноценной работы простого приложения.
- Базовый “Indie”. По умолчанию предоставляется в 1,5-2 раза больше возможностей, чем на бесплатном тарифном плане. Этого уже достаточно для небольших студий и команд разработчиков. Можно расширять возможности тарифного плана, приобретая в Marketplace дополнительные опции.
- Корпоративный “Enterprise”. Индивидуальные условия для корпоративных клиентов, отсутствие ограничений, выделенные кластеры, космическая техническая поддержка, и т.д.
С платформой Scorocode можно дополнительно сократить затраты на обслуживание приложений:
- Всем новым разработчикам мы зачисляем при регистрации на счёт платформы по 3000 рублей. Этого достаточно для оплаты одного месяца тарифного плана Indie.
- Всем новым студиям разработки и digital-агентствам после подтверждения мы зачисляем на счёт платформы 10 000 рублей. Их можно потратить по своему усмотрению — либо взять Indie на три месяца, либо докупить в Marketplace дополнительные опции.
Развитие
У нас оптимистичные планы по развитию Scorocode на четыре года вперёд. Инвестиции и поддержку нам оказывает группа компаний PROF-IT GROUP, которая в 2015 году вошла в рейтинг самых быстрорастущих IT-компаний по версии Cnews.
Ближайшие планы развития:
- Интеграция с партнёрскими облачными сервисами для расширения методов обработки данных, хранящихся в Scorocode;
- Фабрика интеллектуальных чат-ботов;
- Поддержка полного цикла разработки — от backend до frontend.
Наш проект недавно стартовал и будет совершенствоваться под влиянием IT-сообщества. Мы готовы прислушиваться к пожеланиям разработчиков, расширять и пересматривать набор предоставляемых возможностей, находить разумный баланс в ценовой политике. Мы готовы к диалогу с пользователями и к конструктивной критике.
Приглашаем поделиться в комментариях своими пожеланиями и впечатлениями от использования Scorocode.
Мы будем регулярно вести блог с циклом статей про Scorocode: примеры его использования, наш опыт разработки платформы и особенности разработки приложений в целом. Будем рады видеть вас в подписчиках.
Поделиться с друзьями
asvechkar
Ну, Слава Богу! Наконец то русский BAAS!
Спасибо Вам! А то я уже на конференции по «облакам» хотел кинуть камень в огород ИТ индустрии :).
Давно надо сделать аналоги GC/Firebase, AWS. А то ФЗ не позволяет пользоваться, а альтернативы нет.
Из пожеланий: хочется не просто MongoDB, а промежуточный слой в виде RealTime DB, аналог Google Firebase и AWS DynamoDB.
Хочется микросервисов для обработки потоков данных, например, написал метод на JS, задеплоил к себе, на него система сформировала адрес, по которому этот метод вызывается. В AWS есть подобные сервисы, но пока в тестовом виде. Да и опять же ФЗ.
Желаю успешного развития!
juggleru
Спасибо большое!
До уровня Google и Amazon будем дотягивать постепенно.
По микросервисам — сейчас есть возможность писать скрипт на JS, который можно вызвать через API с передачей пула параметров. Также можно настроить вызов по расписанию.
Мы очень надеемся активно развиваться вместе с сообществом разработчиков, готовы слушать пожелания и реализовывать востребованные функции.
asvechkar
Еще из пожеланий: хостинг и сохранение файлов. В Firebase недавно появились эти сервисы. Хотелось бы видеть и у Вас.
juggleru
У нас реализовано сохранение файлов с привязкой к полю в коллекции, с последующей возможностью получения временных ссылок на них. Время действия ссылки регулируется пользователем.
Хостинга пока нет, в планах.
tangro
Блин, один человек на полном серьёзе пишет «Наконец то русский BAAS!», другие ему тоже с полностью серьёзным лицом отвечают, что «будут постепенно дотягиваться до уровня Google и Amazon». Вы это всё что, на самом деле?
asvechkar
А что Вы видите в этом плохого? Битрикс написал в свое время хорошую статью о том, как они перевели свои приложения на AWS.
Теперь вышел ФЗ, и, я так понял, Битрикс вернул всё на российские датацентры.
А чем предлагаете пользоваться?
Я, кстати, думал, что BAAS запустит Яндекс или мэйл.ру.
Поэтому решение Scorocode стало приятной новостью.
LLLLLL
Меня тоже резануло в ухо.
Имхо, речь о том, что подтянуть хотя бы частично до уровня Amazon, AWS по API.
Думаю речь не идет о масштабах их датацентров.
InstaRobot
Ну, могу внести свои 5 копеек. Так как этот сервис я уже успел пощупать до появления данной статьи! В целом, поддержка неплохая, но чувствуется что проект имеет в штате не так много работников. Некоторые вещи реализованы но не документированы. Сделал запрос, обновили доки в той части, что мне нужны! За что огромное спасибо!
Понравился аналог CloudCode, пока не знаю точно, но если есть возможность подключения сторонних нодовских библиотек, то цены ему нет, я даже знаю очень хорошее применение этому слою!
Из замечаний, слой данных, в частности user, не совсем корректно может вытянуть токен, хотя поле вроде как есть, но не всегда проходит инициализация и в ответе есть ид сессии, но токен придется все же самому реализовывать. Не работает logout, всегда в ответе «Forbidden».
Еще момент, возможность подтверждения пользователя по мейлу есть и даже доки с ссылкой поправили! А где доки по запросу сброса пароля?
По слою данных «users», сделайте возможность работать с кастомными полями. У вас СДК все асинхронное, это правильно, то тогда при регистрации пользователя в колбеке приходится делать лишний запрос к серверу, в частности тянуть ид созданного пользователя, получать по нему объект, инициировать поля по приннципу KVO и заново его сохранять, а это еще один колбек. Не слишком рационально и безопасно. Причем, смотрел и на ваш REST Api, это не в СДК косяк, а именно севисный слой самого сервера!
juggleru
По серверным скриптам:
В ближайших планах сделать поддержку нодовских библиотек. Есть технические вопросы и вопросы безопасности, решаем.
По user:
Насчет некорректности токена не совсем понятно. Токен генерируется при операции login всегда. Можете пояснить, что не так?
logout не работает из SDK или при прямом вызове API?
По сбросу пароля:
Операции сброса пароля в API нет, поэтому и нет описания. Мы не были уверены в востребованности этой операции, поэтому не стади делать.
По слою данных «users»:
При регистрации вы можете указывать любые кастомные поля для пользователя, если они есть в коллекции users. В ответ на регистрацию приходит документ, содержащий эти поля и сгенерированный _id.
InstaRobot
По сбросу пароля:
juggleru
За сброс паролей спасибо, исправим.
По токену проверим. Если не сложно, напишите, пожалуйста, в поддержку ситуацию, при которой токен остается пустым.
InstaRobot
Сделать регистрацию и авторизацию пользователей, но не быть уверенным в необходимости возможности сброса пароля, как минимум странная логика! А как при забытом пароле доступ к аккаунту пользователя восстановить? Админу руками искать пользователя и ресетить его?
juggleru
Логику сброса пароля в Scorocode можно реализовать самостоятельно. Мы не стали сами придумывать реализацию, так как есть много разных вариантов.
InstaRobot
Прошу прощения конечно, я только порадовался за новый отечественный сервис и с энтузиазмом взялся его пробовать, так как это реально может облегчить жизнь разработчика, особенно на мелких проектах. Но следуя вашей логике, самостоятельно можно реализовать тогда слой пользователей и на своем сервере! Берем в аренду ВДС, накатываем на него node.js && mongoDB, клонируем опенсорсный parse, подрубаем его через forever на постоянный аплоад, после локально строим модель и деплоим на сервер. А еще есть на ноде всякие «кликалки» API. Перечислять их нет смысла, за них итак гуглится все прекрасно. И ведь при таком подходе, разработчик только выиграет: нет ограничений на запросы в сек, других лимитов и так далее. Ну, с хорошим серверным ядром и парой гигов оперативки, очень быстрой нод выдержит и миллион коннектов.
Зачем разработчикам BaaS? Они не умеют код писать? Нет, просто нужно решение из коробки с минимальными затратами времени! За это даже можно платить, я возьму «бокс» и буду его использовать, а не тратить время на разработку серверного кода для бекенд приложения.
Вот почему у нас в стране так? Вроде хорошее и нужное начинание, так обязательно что нить негативное и всплывет! Все же жаль Parse, хоть часть и воссоздали, но как ни крути, равных ему по сей день быть не может!
juggleru
Любой успешный сервис строится по принципу «сделай минимум и запусти», а потом уже развивается. Все Ваши мысли, и предложения многих других разработчиков нами учитываются в планах развития. Для этого существует техническая поддержка проекта, где, как Вы уже проверили на себе, ни одно замечание или предложение не пропадает.
InstaRobot
Вот на это я и надеюсь! Будем наблюдать за вашим развитием. Кстати, было бы неплохо раздавать SDK для swift/objective-c в формате фреймворка, а не инструкции по сборке в Carthage двух ваших явных зависимостей.
Это пожелание, но думаю, что объективное. Есть Carthage и CocoaPods, есть еще Swift Package Manager! Всего пара файлов спецификаций и все выглядит более серьезно, а самое главное упростит подключение
juggleru
Записано. Спасибо!
hellosandrik
Ну, из русских BaaS есть еще, как минимум, reindex.io. Так что не надо тут :) А вообще да — очень радует.
amarao
Ничего не понял. Что такое «backend»? У меня в продакшене инсталляция openstack'а. У него есть dashboard, который предоставляет веб-интерфейс. Сам dashboard ходит в API. API ходит в API, API ходит в API, API ходит в API, API пересылает запросы через rabbitmq в сервис на компьютах, компьют ходит в API, API ходит в API, API дёргает ABI, на выходе имеем сервис для клиента.
И где тут бэкэнд и куда тут ваше решение должно присоседиться?
juggleru
В нашем случае backend — это:
То есть фактически — это удобный конструктор структур данных и API с последующим хостингом.
Openstack используется для создания инфраструктурных облачных сервисов и облачных хранилищ. С его помощью у нас организовано хранение файлов.
Ваше решение более низкоуровневое, предназначено для создания системных облачных решений, наше — для решения прикладных задач.
Примером такой задачи может служить разработка мобильного приложения, которому необходимо хранить и обрабатывать данные на сервере.
amarao
Я понимаю, что у openstack'а уже всё написано. Я спрашиваю, какую его часть вы предлаете (хотя бы гипотетически) переписать с использованием вашей штуки?
Другой пример:
есть панелька управления для заказа космических полётов.
Состоит из мобильного приложения, веб-сайта и бота в IRC. Дальше там API. API ходит в API, API ходит в API, API ходит в API, API пересылает запросы через rabbitmq в сервис на ракетах, который ходит в API, API ходит в API, API дёргает ABI, который дёргает ABI, на выходе имеем ракету в космосе.
Какую часть этой штуки вы предлагаете заменить?
juggleru
Все данные мобильного и WEB приложений, данные бота IRC (например, мы в одном из проектов храним в облаке данные бота Telegram), и все взаимодействие API — API в виде JS-скриптов.
amarao
то есть если мне нужно в рамках API между ракетой и стартовой площадкой слать телеметрию посредством udp-датаграмм, это надо делать через JS-скрипты?
juggleru
Вы правы.
Для решения задач интеграции серверной части систем типа «заказ полета ракеты» и внешними сервисами типа «стартовая площадка» в идеологии облачного сервиса Scorocode применяются серверные JS-скрипты.
amarao
А в качестве транспортного протокола используется tcp с аяксом?
juggleru
HTTPS POST-запросы, формат application/json.
amarao
Для телеметрии ракеты? А если потеряется ip-пакет и tcp устроит retransmit и следующая телеметрия застрянет на 40мс? А если из-за застрявшей телеметрии не пройдёт управляющая команда?
DbLogs
Привет, практически коллегам:) У нас пользователи Orienteer (open source Business Application Platform) используют его в совокупности с Docker (+масштабирование через Docker Cloud) для backend приложений и сайтов.
rockyou
Привет, коллеги ;) Интересно наблюдать, как развиваются и взаимно интегрируются молодые сервисы. А мы планируем интеграции с партнёрскими сервисами для расширения функциональности платформы, чтобы сложные приложения стали проще в реализации.
DbLogs
Кстати, интересно, а есть ли у вас Business Process Management? На той же Camunda например? И так же есть ли поддержка интеграционных фреймворков? Тот же Apache Camel или еще что? Orienteer в beta уже поддерживает.
yurash
Раз вы пишете
то хотелось бы знать почему для миграции надо выбрать вас, а не одну из многочисленных альтернатив на Parse Open Server.Ещё лично мне не понятно почему ограничили триггеры таким малым временем работы 500мс (если с тем же parse сравнить)
rockyou
Приветствуем, yurash! Мы читали ранее ваш поверхностный обзор BaaS-сервисов от 2012 года, вы там писали, что планируете сделать расширенный. Надеемся, что попадём туда, если вы будете делать UPD.
Теперь к вопросам.
Почему выбирать нас? Мы душевнее :) Но если серьезно, то мы как минимум предлагаем альтернативу Parse, а выбор – это ведь хорошо, не так ли? Мы пока не можем похвастаться кил-фичами, но что имеем сейчас для комфортной миграции:
Конечно, нам ещё предстоит развиваться, поэтому мы открыты к предложениям.
Триггеры предназначены для работы со связанными данными (CRUD для зависимого документа в другой коллекции). Учитывая, что пользователь не любит ждать слишком долго ответа от сервера, то нет смысла делать их больше. Для всех более сложных операций, требующих значительного процессорного времени, есть CloudCode, который можно вызвать через API.
mkll
> Почему выбирать нас? Мы душевнее :) Но если серьезно, то мы как минимум предлагаем альтернативу Parse, а выбор – это ведь хорошо, не так ли?
Выбор — это всегда хорошо. Но выбор вашей платформы подразумевает переписывание фронтендов, а выбор других известных альтернатив Parse — нет.
Кроме того, Parse Server находится в open source и его развивает сообщество. В любой момент пользователь может уйти с альтернативного облачного решения на stand-alone, развернув свою инфраструктуру, с минимальными усилиями и изменениями в коде.
Если же пользователь выбрал вас, от уйти от вас уже не получится — ни с минимальными усилиями, ни с максимальными. Ни с какими. Пользователь будет зависеть от вас точно так же, как в свое время он зависел от Parse. Причем «за спиной» Parse стоял Facebook, что внушало определенную уверенность, пользователь был еще «не пуганный». Последующие же события существенно подорвали веру в BaaS вообще как в концепцию, и сейчас уже меньше желающих наступить на те же грабли.
В частности, поэтому многие из альтернативных решений Parse-хостинга дают пользователям куда больше свободы — например, Back4app дает прямой доступ к Mongo.
Стоит, наверное, упомянуть и то обстоятельство, что в случае, если переезжающий с Parse проект ориентирован главным образом на российского потребителя, то это как раз ваша целевая аудитория, но если ориентация на worldwide, то в нынешних политических условиях хостинг бэкенда в России — это, в общем-то, минус.
LLLLLL
> то в нынешних политических условиях хостинг бэкенда в России — это, в общем-то, минус.
Такой же как и итальянский хостинг, например.
)))
mkll
Видите ли, я мало знаю про Италию, так что вам виднее. ;)) Но в любом случае, хоститься там я не собирался.
LLLLLL
ОК.
Испанский хостинг, австрийский, австралийский, шведский…
Да можно все страны мира называть как неподходящие для хостинга.
Выделяются только США, Ирландия (Google), Германия (Хетцнер), Франция (OVH) да Нидерланды.
mkll
Вы, может быть, уже раскроете мысль? Позиция «знаю, но не скажу, буду продолжать намеки», боюсь, не очень подходит для диалога.
LLLLLL
Российский хостинг для проекта ориентированного на Россию — хороший выбор.
Для мирового проекта — дело не в РФ. Ваш выбор — США, Германия, Франция. Ну и почти все.
mkll
Вы просто повторили мысль, но не раскрыли. Впрочем, как хотите.
LLLLLL
Простите, я не заинтересован разговаривать с непонятливыми людьми. Неполиткоректное слово на д или и не стоит здесь употреблять.
mkll
Не удивили — д'Артаньяны все такие. Вы не первый.
mkll
А еще интересно насчет миграции с Parse. Вот мы мигрировали, допустим — что дальше? Я так понимаю, фронтенд нужно переписывать полностью с вашими SDK? Если да, то приятного мало. Если нет, то, следовательно, ваши SDK на уровне API совместимы с Parse SDK. Но это догадки, а где прямые и явные утверждения? Вы говорите потенциальным пользователям — ребята, вы собираетесь куда-то переходить с Parse — давайте к нам! А дальше — молчок. Ведь это неизбежные вопросы, которые возникнут у каждого Parse-юзера, который ищет (если еще не нашел) альтернативу.
rockyou
Спасибо за вопрос. Мы говорим о миграции данных с Parse на Scorocode. Фронт необходимо будет переписывать. Да, это не так удобно, как хотелось бы. Чтобы на уровне API быть совместимыми с Parse SDK, нужно по сути копировать его у себя, а у этого решения есть определённые юридические риски.
mkll
Спасибо за ответ. Вам определенно стОит более однозначно и понятно описать миграцию с Parse на сайте.
LLLLLL
Там BSD лицензия — «бери и делай что хочешь, не забудь упомянуть меня».
Rathil
Прочёл и захотелось что-то подобное попробовать сделать. Завтра попробуем с коллегами продумать архитектуру :)
lexxpavlov
Конкуренция — это хорошо. Делайте! :)