На своем блоге в Meidum команда стартаперов HomeAutomation рассказала поучительную историю с относительно счастливым концом о том, как безобидный сервис вроде Firebase может превратиться в западню и как недальновидное планирование на ранних этапах обернулось для компании катастрофой спустя несколько лет.
Начало
«Как и многие другие, наш стартап начался с очень простой идеи. Фактически это был инструмент, созданный, чтобы помочь программистам систем автоматизации для «умного дома» разбираться с возникающими проблемами, интегрировать девайсы и экономить время.
Мы распространяли свой продукт бесплатно, и вскоре он начал завоевывать популярность. Это было так захватывающе! За какие-то несколько месяцев наша аудитория из десяти бета-тестеров в скайп-конференции выросла до сотен, а потом и тысяч пользователей. Мы были на седьмом небе! Помню, как просто сидел и смотрел на статистику Google и Woopra, наблюдая за действиями пользователей.
Я первый готов признать, что на этом этапе мы допустили несколько серьезных ошибок (от которых, надеюсь, сможем предостеречь других). Тогда мы активно создавали и внедряли дополнительные функции, изо всех сил стараясь обрабатывать нескончаемый поток запросов.
Ошибка заключалась не в том, что мы не ознакомились с документацией. И не в том, что выбрали сервисы, у которых какие-то проблемы с функционалом или плохие показатели. Нет, мы допустили мелкую, но опасную оплошность (и я подозреваю, что многие другие разработчики приложений допускают ее в этот самый момент) — мы позволили сервису превратиться в ловушку.
В итоге мы оказались в следующей ситуации: сервис, на который мы всецело полагались, изменил политику и цена их услуг внезапно подскочила в 70 раз. И у нас попросту нет решения, которое можно было бы экстренно применить, чтобы не дать расходам достигнуть суммы в десятки тысяч долларов. В конце концов, мы всего лишь стартап, который сам себя финансирует по модели бутстреппинга.
В ловушке! Начало черной полосы
Началось все в апреле этого года. С тех пор, как Firebase стала частью Google, мы были на тарифном плане «Flame», что обходилось нам в 25 $ в месяц. Пользоваться услугами этой компании мы начали задолго до того, как Google ее купил и превратил в звезду своих инициатив, связанных с мобильными облачными хранилищами.
После очередного платежа прошло всего несколько дней, когда я получил оповещение, что наше приложение отключают за превышение лимита трафика. Что?! Сильно встревожившись, я вошел в систему, чтобы посмотреть, что там стряслось.
Тарифный план Flame от Firebase предоставляет 20 гигабайтов исходящего трафика в месяц за плату в 25 $. Система не допускает превышения заданного лимита, так что дело обходится без неприятных сюрпризов постфактум, что радует. Тем не менее, за эти несколько дней мы, как показывала статистика, израсходовали уже 30 гигабайтов трафика.
Разумеется, допустить, чтобы приложение отключили и наши пользователи оказались лишены возможности им пользоваться, мы не могли. Да и доплатить 10 $ сверху за 10 лишних гигабайтов — не велика беда. Мы немедленно связались с техподдержкой по этому вопросу и, по итогам обсуждения, переключились на другой план, «Pay As You Go» — это была единственная альтернатива, которую они могли нам предложить.
Едва я успел нажать на Enter, как заявленный расход трафика подскочил до 100 гигабайтов. Сами понимаете, мне стало не по себе. Но я махнул рукой и решил, что поговорю на эту тему с техподдержкой завтра.
Придя в офис на следующее утро, я обнаружил, что у нас накачали уже 180 гигабайтов трафика. Учитывая, что мы платили по доллару за гигабайт, можете себе представить, в каком я был ужасе, подсчитав, во что нам это обойдется. Что происходит?! Почему?! Как все исправить?! Что делать?! Это же выльется в тысячи и тысячи долларов незапланированных расходов!
Firebase не предоставляет никакой аналитики или пояснений по расходу трафика; все, что вам доступно — это синяя полоска на графике, которая показывает, что вы потратили столько-то гигабайт.
Бессмыслица какая-то — откуда у нас вдруг взялось такое количество трафика? Почему? Кто все эти люди? К сожалению, Firebase не дает ответов на такие вопросы.
Однако я, на свою беду, обнаружил, что у них имеется инструмент профилирования базы данных. Я запустил его и проверил результаты через час: по его данным выходило, что мы потратили всего несколько мегабайт. При этом аналитика показывала расход в два гигабайта за тот же отрезок времени!
В конце концов, я связался с техподдержкой и они сообщили мне, что они изменили правила расчета трафика: теперь учитывается также превышение SSL запросов , включая неудачные попытки, заблокированные в соответствии с их требованиями безопасности. В этом же разговоре они упомянули, что инструмент профилирования базы данных не отображает данных по по превышению SSL. В моем случае выходило, что ни один из доступных мне инструментов не выявляет абсолютно никаких проблем, а счет за услуги при этом вырос в 70 раз!
По их словам, в большинстве случаев изменение алгоритма никак особо не сказывается… если только не использовать REST API. В нашем приложении исходный код был написан на языке, который не поддерживается, поэтому мы прибегли к REST API, чтобы это скомпенсировать. Все, что он делал — ежеминутно считывает boolean значение, проверяя, нет ли необходимости в дальнейшей обработке. Два года это не вызывало никаких проблем, а тут вдруг стало нас разорять.
Тщательнее изучив ситуацию, сотрудники техподдержки заявили следующее: перерасход трафика был вызван тем, что мы не использовали нечто под названием TLS Tickets (теперь уже используем, но до этого я ни разу не видел, чтобы что-то такое упоминалось в библиотеках или пакетах) и «Keep Alive» у нас не было выставлено как true.
В документации об этом всем ни слова. Думаю, это объясняется тем, что до изменения правил оплаты особых проблем не возникало. Мы же честно прочли документацию и составляли запросы с опорой на нее. Я лично все перечитал раз тридцать, не меньше.
Поначалу нам казалось, что администрация сайта готова идти нам навстречу. Они назначили время, чтобы обсудить с нами ситуацию, заверили, что будут помогать нам в решении проблемы. В телефонном разговоре они сказали, что обо все позаботятся и дадут нам время, чтобы привести приложение в должный вид. Также мы получили письмо, где говорилось, что команда работает над проблемой и в скором времени предоставит нам кредит.
А потом с моей карты сняли деньги. И на наши письма перестали отвечать. Вообще перестали реагировать на попытки выйти на связь, оставляя нам только один выход — отозвать платеж, в результате чего сервис был бы отключен, приложение упало бы, а пользователи — разбежались. У нас был только один канал связи — электронная почта, причем больше месяца наши письма просто игнорировали, никак не реагируя на повторные обращения. Мы оказались в западне, в тупике, без какой-либо возможности действовать.
Подытоживая сказанное:
- Администрация сайта изменила схему расчета трафика, в результате чего с нас стали взимать в 70 раз больше, хотя расход, по сути, остался прежним. И все это случилось, когда мы использовали сервис уже несколько лет.
- Мы не получили никаких оповещений или предупреждений об изменениях в политике — с нами связались только тогда, когда уже собирались отключать приложение.
- Инструменты профилирования, которые они предлагают, не отображают роста расхода трафика — о нем узнаешь только из раздувшегося чека.
На дне
Ну ладно, по крайней мере, исправить положение вроде бы несложно. Если одна какая-то штука все портит, так нужно просто ее поменять! Если бы вы сказали мне это сейчас, когда архитектура приложения уже переработана, я бы ответил: «Не вопрос, через час все будет».
Теперь мы уже не прописываем URL жестко. Вместо этого мы обращаемся к прокси, которые можно модифицировать при необходимости. Мы внедряем как промежуточное звено сторонние API, которые, если вдруг что, позволят нам переключиться на аналогичный сервис, и вообще с каждым днем узнаем все больше полезных техник. Стартап у нас небольшой и на самообеспечении, так что будем рады идеям, советам и предложениям.
Но на тот момент все, увы, было не так просто. Понимаете, речь идет об одной из первых строк кода, которые мы писали, когда еще на первых порах интегрировали все с сервисом Firebase. Это жестко прописано в коде версии 1.0 (грубая ошибка с нашей стороны!) и деплоено на тысячи систем по всему земному шару. Тот фрагмент кода создавался, когда приложение было всего лишь занятной идеей. Долгие годы с ним не возникало никаких проблем, и даже сейчас ни один инструмент профилирования из доступных нам не видит ничего необычного. С самого момента запуска счет за услуги ни разу не превышал 25 $.
Однако, так как все это прописано в первой версии приложения (которая локально скачана в системы автоматизации большинстве стран мира), единственное, что мы можем сделать — это вообще отключить сервис, пока не подготовим новую версию… а это, вне всякого сомнения, лишит нас пользовательской базы, ведь последствия будут катастрофическими — многим придется ехать к клиентам на дом, за сотни миль, чтобы устранить проблему.
Когда приложение стало набирать обороты, мы быстро сообразили, что, намертво связав себя с одним сервисом, можем столкнуться с неприятными последствиями подобного рода. Но мне и в голову не могло прийти, что все произойдет так внезапно и в таком масштабе!
После этого происшествия мы поменяли модель на такую, которая, благодаря архитектуре без серверов, позволит нам динамично вносить необходимые изменения. Она решила бы все наши проблемы, но внедрить ее окончательно мы не можем, пока не выплатим Firebase 5000 — 10 000 $ незапланированных расходов, что нам, к сожалению, в данный момент не по карману.
Поэтому очень ваш прошу… учитесь на наших идиотских и, как теперь выясняется, роковых ошибках.
- Всегда выстраивайте архитектуру так, чтобы избежать ситуации, когда вы «привязаны» к стороннему сервису. Делайте приложение с таким расчетом, чтобы переходить с одного сервиса на другой было как можно проще.
- Всегда помните, что сервисы, которыми вы пользуетесь, в любой момент могут поменять условия предоставления услуг и, если заранее не остеречься, поставить вас в тупиковое положение.
- По возможности полагайтесь на инфраструктуру собственного производства. Модель SaaS кажется выгодной и для клиентов, и для компаний, оказывающих услуги… но, в конечном итоге, все шишки валятся на стартаперов, в то время как компании делают деньги.
- Всерьез рассмотрите варианты с открытым исходным кодом. Когда мы начинали работу над проектом, альтернатив Firebase еще не существовало, но сейчас появились, например, Horizon и Backendless.
Заключение
Поверить не могу, что пишу эту статью. Я не из тех людей, которые любят рассказывать подобные истории и выносить сор из избы. Как и многие здесь, я и моя команда провели долгие часы за обучением, планированием, написанием кода, чтобы запустить стартап своей мечты. Те еще американские горки: взлеты и падения, радостное волнение и тут же — сильнейший стресс.
На самом деле, мне очень стыдно, что мы попали в такую историю. Огромный массив знаний, которым, как кажется со стороны, обладают многие в виртуальной реальности, иногда сильно подавляет. Тяжело было побороть страх, что нас осудят за допущенные ошибки, и заставить себя написать этот текст. Я только надеюсь, что кто-нибудь из вас извлечет пользу из рассказа об этих дурацких ошибках и придумает новые решения для усиливающейся проблемы сервисов-ловушек.
Сложно придумать что-то более жуткое и захватывающее, чем совершить прыжок в неизвестность, бросить работу и принять решение строить карьеру вокруг одной своей безумной идеи. Я без колебаний могу сказать, что это никакое другое событие моей жизни с этим не сравнится. Но само собой, когда учишься чему-то новому, без промашек ни у кого не обходится. К несчастью, от этого не легче, когда такие вот мелкие оплошности аукаются тебе через некоторое время. Особенно когда сервис решает изменить принцип работы без предупреждения.
Это не камень в их огород
Я не обличаю конкретные сервисы и платформы. Firebase не действовали нам назло или с какими-то дурными намерениями. Все произошло из-за того, что незначительное изменение на их стороне обернулось существенным изменением в нашем чеке (в 70 раз!), вследствие которого наша абонентская плата из 25 $ превратилась в целые $1,750, если не больше (сумма продолжает расти).
Чего я хочу — это уберечь вас от наших ошибок. Ошибок, которые сейчас ставят под удар будущее нашего проекта просто потому, что Firebase по-другому стал рассчитывать трафик.
Позаботьтесь о себе: не жалейте времени, чтобы как следует проанализировать сервисы, которые собираетесь внедрять. Учтите, что они способны коренным образом изменить судьбу вашего продукта так, что за считанные часы вся позитивная динамика полетит в тартарары.
UPD: Рад сообщить, что сегодня утром мне позвонили из Firebase. Они принесли свои искренние извинения за сложившуюся ситуацию и подробнее объяснили, что произошло с аккаунтом.
Пока что мы еще достигли окончательного соглашения, однако они приняли к сведению те обстоятельства, которые я описал в этой статье. Многие из озвученных претензий (например, те, что касаются метрик) они обозначили как моменты, которые будут дорабатываться в ближайшем будущем.
Буду держать вас в курсе, если появится что-то новое.
UPD 2: В итоге дальнейшего обсуждения мы разобрались с кредитами и выработали план, чтобы оперативно решить остальные проблемы. Эндрю (основатель Firebase) и его команда очень активно взялись за дело и прокомментировали всю ситуацию вот здесь.
Конечно, для компании любая ситуация, в которой приходится делать официальное заявление, нежелательна, но то, как они подошли к этому, говорит в их пользу. Нам стало намного спокойнее.
UPD 3: Firebase предоставила нам кредит; на этой неделе мы соберемся, чтобы в деталях рассмотреть расход трафика. С тех пор, как я вышел на связь с Алексом и Эндрю, они были на высоте. На мой взгляд, они предложили исчерпывающее решение проблемы и, по моим ощущениям, поняли, как действовать в будущем, чтобы она не коснулась других пользователей».
Автор: nanton
