Как Snowflake меняет подход к разработке SaaS продуктов

В марте американская компания Snowflake объявила о поглощении open-source фреймворка Streamlit. Сделка была совершена за $800 млн, 80% — стоками Snowflake. Выручка Streamlit едва дотягивает до $100,000 и даже для лучших времен SaaS-рынка, мультипликатор 8,000x выглядит заоблачно.

В мае на конференции Snowflake Summit 2022 в Лас-Вегасе компания огранила инвестиционное видение: фреймворк станет фундаментом разработки современных B2В-сервисов. Поэтому давайте обсудим, зачем это Snowflake, почему покупка Streamlit — продуманный шаг и к чему он может привести. Но для начала — немного о Big Data.

Просто больших данных недостаточно

За последние 10 лет журналисты, инвесторы, предприниматели и высший менеджмент поняли, что в 21 веке без Big Data никуда. Это породило много ожиданий и возбуждения в технологических кругах. Стала, например, популярна метафора «Data is new oil». К сожалению, она упускает из виду путь получения данных, их обработку, хранение и сложность извлечения конечной выгоды. Если завтра Джефф Безос отгрузит мне весь кликстрим Amazon за 2021 год, это не поможет создать «лучший Amazon». Да, определённо, можно будет многое понять о природе клиентского поведения. Но мне эффективнее будет продать этот датасет в Walmart или Target, чтобы они улучшили свой таргетинг или рекомендации.

Или взять разговор про сетевые дата-эффекты. В отличие от социальных сетевых эффектов, здесь каждый новый пользователь только увеличивает стоимость хранения и обработки данных. Представим условный контентный рекомендательный продукт типа онлайн-кинотеатра. Да, разнородные данные помогают улучшать модели машинного обучения и увеличивать удержание и вовлечение. Да, создать клона Netflix с более сильной рекомендательной системой будет очень тяжело. Но, успех бизнеса Netflix в большей степени в лицензировании контента и его производстве. Если я завтра придумаю, как покупать у студий контент за $1 и производить новый за $100, вы можете начинать шортить акции Netflix.  

Масштаб данных дает преимущество и защиту бизнесу, но в них нет ничего про сетевые эффекты. Сложно создать конкурента Google Review или Yelp соревнуясь в количестве отзывов, так как эффект от данных ассимптотичен. 50-й отзыв на Google Reviews имеет меньше marginal value, чем 10-й.

В итоге, мир незаметно перешел в парадигму collect everything. Ее бенефициаром стали облачные компании, вендоры баз данных и школы подготовки специалистов-аналитиков. Однако, в работе с Big Data, поиск рентабельности — долгий и тернистый путь. Потому что описанные примеры упускают главную и простую идею: мало собирать разнородные данные, важно заставлять их работать на благо бизнеса.  

Как возникли облачные хранилища данных

Базы данных и хранилища данных 101

Базы данных принято делить на два типа: транзакционные и аналитические. Транзакционные, например, PostgreSQL или MySQL, используют для апдейта, добавления и удаления данных. Аналитические базы адаптированы под выполнение сложных запросов, затрагивающих несколько таблиц.

Для того чтобы обеспечить аналитикам доступ к данным, компании создают и поддерживают так называемые хранилища данных (data warehouse). Это информационные корпоративные базы данных, предназначенные для подготовки отчетов, анализа бизнес-процессов и поддержки системы принятия решений.

Исторически для бизнес-аналитики использовали On-Premise Data Warehouse инструменты вроде Teradata, IBM Netezza или Vertica.  К началу 2010-х быстро развивающиеся ИТ-гиганты вроде Facebook, Google, Netflix, LinkedIn и Airbnb хорошо научились обрабатывать в реальном времени огромные объемы данных, чтобы поддерживать экосистемы продуктов. Оказалось, что эти метаданные могут быть полезными для Business Intelligence, но конценсусса по том, как обрабатывать данные в индустрии не было. Для анализа неструктурированных больших данных классический сет-ап был такой: данные хранятся в HDFS (Apache Hadoop) на собственных серверах компании и обрабатываются с помощью парадигмы MapReduce.

MapReduce и Hadoop развертываются на кластерах стандартных серверов, и кластеры могут расти по мере увеличения объемов данных, в то время как продукты MPP ограничены аппаратным обеспечением. В тот момент сочетание этих двух подходов казалось панацеей. Однако работа инженера была неэффективной: аналитические запросы делались долго, приходилось комбинировать Hadoop для хранения неструктурированных данных и MPP-хранилища для бизнес-аналитики.

Массово-параллельная архитектура

Массово-параллельная архитектура — класс параллельных вычислительных систем. Такие системы состоят из множества узлов, где каждый из них представляет собой автономную, независимую от других единицу. Если применить MPP к хранилищам данных, то лучше всего его смысл будет отражать термин «распределенные базы данных».

Каждый узел в такой распределенной базе данных представляет собой полноценную систему управления базами данных (СУБД), работающую независимо от других.

Самое главное, что MPP-хранилища очень требовательны к специализированному оборудованию, настроенному для производительности процессора, хранилища и сети. Например, IBM Netezza поставляется в виде отдельного оборудования на специальных серверах IBM.

На рубеже 2011 года происходит первый прорыв: MPP-база данных ParAccel придумала, как организовать работу с хранилищами данных на более доступной инфраструктуре. Один из давних клиентов компании, AWS, скопировал и адаптировал это решение под свою экосистему. Так в 2013 году появилось облачное хранилище данных, Redshift.

С Redshift всеми процессами можно было управлять из единой консоли: это позволило разработчику не думать о масштабировании и аварийных восстановлениях системы при сбоях.

На другом конце Сиэтла инженеры Google к этому решению пришли изнутри. Они разработали Dremel — систему обработки запросов в режиме близком к режиму реального времени (near-real-time). Dremel использовали, чтобы анализировать документы, собранные поисковым роботом, отслеживать данные об установке приложений в Android Market, а также применяли в сервисах Google Books и спам-анализе. В 2012 году Google открыл доступ к Dremel для разработчиков через сервис Google BigQuery.

Redshift и BigQuery стали первопроходцами в области Cloud-First Managed Data Warehouse. Разработчику не нужно было менеджерить сервера, переживать за масштабирование. Также «облака» позволили использовать модель usage-based ценообразования, потому что комфортнее платить за продукт по результатам использования. Но Redshift и BigQuery были сложны в менеджменте нагрузки: надо было поднимать кластер под вычисления и хранения данных. Это влечет за собой перераспределение данных, а значит — в той или иной мере даунтайм.

Новый виток развития облачных хранилищ. Преимущества Snowflake

Когда на рынке уже два года были Redshift и BigQuery, из stealth-режима вышел конкурент, основанный выходцами из Oracle: Snowflake.

Snowflake предложил рынку кое-что новенькое: обернуть облачные хранилища данных в SaaS-модель и отсоединить хранение данных от вычислительного слоя. Таким образом, архитектура состоит из трех слоев:

• Слой хранилища данных,
• Слой обработки запросов,
• Сервисный слой аутентификации, метаданных и др.

Snowflake — это SaaS-продукт, который живет за рамками стандартных инфраструктурных задач.

Можно масштабировать облачные ресурсы, не прерывая выполняющиеся запросы

У разных пользователей в организации разные требования по использованию и нагрузке данных. Профессионалы, которые отвечают за BI-дашборды и те, кто занимается моделированием поведения пользователей, имеют разные запросы для ворклоад. Со Snowflake отдел маркетинговой аналитики запустит долгую задачу, а их коллеги продолжат пользоваться продуктом как ни в чем не бывало. То есть команды будут работать продуктивнее.

Пользователь не платит за неактивные ресурсы

Это позволяет существенно экономить, если нагрузка неравномерна в течение дня или система используется лишь эпизодически.

Snowflake не использует собственного облачного хранилища, а разворачивается на AWS, Azure, GCP. Стоимость сервиса складывается из оплаты за объем данных в S3 и почасовой оплаты за используемые виртуальные сервера. То есть, если у клиента 2 виртуальных кластера по 4 сервера, и они работали по 9 часов 3 минуты, то надо будет заплатить за 2×4×10=80 часов работы сервиса. У Snowflake есть договор с облачными провайдерами, по которому новые инстансы они получают в течение 5 минут. Тогда расширение виртуального кластера или создание нового занимает 1–5 минут.

К тому же облачная, Serverless-модель предполагает гораздо меньше тюнинга со стороны администратора, что упрощает переход от управления ресурсами к управлению пользователями и их запросами.

Snowflake справляется с задачами, которые невозможны при оригинальном дизайне баз данных

Snowflake — это SaaS-продукт, который живет в рамках стандартных инфраструктурных задач. Для примера:

• Можно сделать Undrop — восстановить утерянные данные или даже привнести версионирование в работе с базой данных.
• Можно поделиться своим датасетом с другим пользователем. Таким образом, он за хранение данных не будет платить, а заплатит только за computation.
• Есть свой инструмент для визуализации, а также возможность подгрузить внешние данные из дата-маркетплейса.
• Инженеру не надо переживать за партицирование данных — разбивать большие таблицы на логические части. Логику Snowflake определяет сам, хотя в некоторых случаях её надо дорабатывать.

У читателя может возникнуть вполне резонный вопрос. Если Snowflake так хорош, почему бы AWS не выгнать их с платформы и не начать продвигать свой Redshift?

Точного ответа нет, но предположу следующее:

• Бизнес Snowflake работает с 65% operating margin. Структура затрат: 68% Sales and Marketing, 43% R&D.
• Допустим, клиент платит Redshift $1 млн/год. Маржинальность EC2 в Redshift — примерно 50% в структуре AWS. Таким образом, AWS получит ~$500 тыс. прибыли.

Если клиент переходит на Snowflake с тем же бюджетом, то AWS получит $400 тыс. и прибыль составит ~$200 тыс. Звучит, неплохо, но это без учета затрат на маркетинг, которые слабо прогнозируются и составляют 60-70% всех костов. Вполне вероятно, что в расчете на клиента они могли бы достигнуть и $200 тыс. Выходит, что AWS зарабатывает примерно столько же, как если бы отключил Snowflake и заменил Redshift.

• Думаю, у облачных вендоров основная стратегия — поддержка и защита самого нижнего уровня производства софта. Там маржинальность и вендор-лок довольно высокие. Любой стартап, который строится на их инфраструктуре, очень приветствуется.
• Если AWS «прогонит» Snowflake, его ликвидности будут рады GCP, или Azure.
• Ну и напоследок, "serverless” не обязательно должен быть дешевле. Авто-масштабирование — это трейд-офф между ценой и желанием менеджерить нагрузку самостоятельно (читай — продуктивность). WeWork перейдя с Redshift на Snowflake платил почти 2х, но был в восторге от Snowflake.

Рынок поверил

В 2022 году для создания аналитической платформы уже не нужно несколько месяцев. Большие объемы данных можно загрузить в облачное хранилище и начать работать с ними в считанные дни. Более того, SaaS-бизнес модель снижает порог входа в дата-инженерию: не требуется досконально разбираться в монолитных технологиях типа Hadoop, Spark, Teradata, Informatica, Vertica и в теории распределенных вычислений и хранения данных.

Snowflake начал с SMB сегмента, подключая один стартап за другим. В стартапе появлялся Snowflake, почти сразу как в компанию приходил первый аналитик. Поднять свое хранилище он мог за неделю, не отвлекая системных администраторов и разработчиков. В итоге к 2018 году стали появляться первые корпоративные клиенты, и Go-To-Market-стратегия немного изменилась: получилась комбинация self-service использования и прямых продаж через Sales-команду.

Cloud-agnostic-природа Snowflake — отсутствие привязки к конкретной облачной инфраструктуре — помогла и в продажах Enterprise-клиентам, особенно банкам, которые невероятно щепетильны относительно multi-cloud.

Как следствие, Snowflake провел самое дорогое публичное размещение в 2020 году. IPO было таким успешным, что даже Уоррен Баффет изменил своим принципам не заходить в IPO-сделки и проинвестировал в Snowflake (это позволило инвестору довольно быстро заработать 800 миллионов долларов).

К этому моменту Snowflake имел впечатляющую статистику:

• $532 млн Annualized Run-Rate Revenue (ARRR) с YoY-ростом 121%.
• 146 компаний из списка Fortune 500 и 3 117 клиентов, включая Doordash, Square, Adobe, Instacart, Sony и Sega.
• Средний клиент платил ~ $160 тыс., что довольно много для публичной SaaS-компании. Количество клиентов с $1 млн — 56, YoY-рост: 154%.
• На апрель 2022, согласно Q1 2023, Snowflake имеет 6 300 покупателей, 206 из них платят больше $1 млн в год, NDR 177%.

Следующий шаг: экосистема Snowflake

Пока Big Data превращались из модного словечка, звучащего на советах директоров, в осязаемую технологию, дата-инженеры становились программистами, одержимыми данными: уже не инфраструктурой, а моделированием, первичной обработкой и не только.

Базы данных и так имеют высокий switching cost, но экосистема их только усиливает.  Еще 5 лет назад казалось, что весь рынок data-инструментов будет консолидирован главными облачными вендорами: Google Cloud, Azure и AWS. Компании пытались создать инструменты под весь supply chain работы с данными, начиная от их выгрузки (ETL/ELT) до визуализации и машинного обучения.

Однако популярность и доступность Snowflake и Databricks изменили конъюнктуру рынка и сделали его менее связанным. Сегодня инженеры могут быстро заменить один инструмент на другой с минимальным vendor-lock.

Snowflake быстро начал строить партнерскую сеть, создав бесшовную интеграцию с другими продуктами для работы с данными прямо из интерфейса приложения. По клику под вас создается виртуальная машина для любимого дата-инжинирингового продукта и на почту просто приходят параметры доступа.  

Как итог, Snowflake понимает, что у него есть невероятный ресурс. Поэтому следующий для них логичный шаг — заставить абстрактные биты информации работать на благо бизнеса. Чем больше ценности клиент Snowflake видит от накапливающихся данных, тем дольше он останется на платформе.

Будущее Snowflake: Streamlit, Native Application Framework, Unistore

Streamlit — это open-source библиотека Python. Она позволяет с легкостью создавать красивые веб-приложения для инженеров машинного обучения — всего за несколько минут и пару строк кода. Данные можно очень просто визуализировать, а контроллеры на дашборде напрямую меняют питоновские переменные.

На конференции Snowflake Summit 2022 в Лас-Вегасе компания представила два продукта, которые ограняют покупку  Streamlit – Native Application Framework и Unistore.  Native Application Framework позволяет провайдерам строить приложения с использованием функциональности Snowflake. Unistore — попытка расширить арсенал Snowflake до написания приложения. Пока мало что известно, кроме глобального видения по созданию хранилища: оно может использоваться как для аналитики, так и для поддержки бэкенда продукта.

Запуск приложений внутри базы данных может изменить понятие базы данных — так же, как iPhone изменил понятие телефонов. Data-app в экосистеме Snowflake пока слишком обощенное понятие, это инструмент для ETL, какой-нибудь хитрый ML-алгоритм для кластеризации ленты, инструмент визуализации данных и алгоритм для сегментации email-рассылки и даже целая CDP-платформа.

Главная идея, вокруг которой строится эта эволюция — демократизация ценности данных для каждого сотрудника компании.

За последние 3 месяца я познакомился с основателями компаний, которые делают приложения поверх Snowflake.

• Vero и Supergrain создают альтернативу Mailchimp на Snowflake. Лично мне инструменты предоставили удобную сегментацию пользователей в зависимости от того, что они делают в продукте.
• Hunters and Panther помогают компаниям уйти от Splunk и строить свой SIEM сразу на Snowflake.
• Calixa и Heads Up дают дополнительную продуктовую аналитику по домену для B2B-стартапов. Отчасти это заход на территорию CDP.
• Eppo помогает делать и анализировать A/B эксперименты.
• Avenue делает операционную аналитику.

Кто-то может сказать: «Очнись, это просто коннектор в DWH и интеграция  дата-слоя через драйвер и несколько SQL-запросов». Да, пока что это так. Но именно поэтому Snowflake покупает Streamlit.

Для дизайнера B2B-SaaS-продукта получится набор компонент или целый фреймворк. Проведу паралелли с веб-разработкой. Django, Ruby-on-Rails готовыми компонентами закрывают основные потребности: как подключиться к базе данных, как провалидировать форму и так далее. Для описания логики понадобится свой язык, отличный от SQL. Streamlit в этой системе становится не просто фреймворком для написания дата-приложений, а платформенным языком, вроде Swift.

Более того, по моему мнению, все усилия Snowflake приведут к low- или no-code-опыту. Я не сторонник идеи, что no-code заберет хлеб у программиста, а вижу его помощником, коллегой за $15/месяц. Поэтому предлагаю думать про no-code как про кодогенератор, который формирует код, интегрированный во все современные инженерные практики: CI/CD, PR и прочие.

Сможет ли Snowflake глобально переосмыслить проектирование B2B-приложений? Возможно, бурный рост Snowflake и будет началом массовой адаптации data mesh парадигмы проектирования. Может, в этом направлении появятся решения от AWS, Oracle или Google, и нам понадобятся кросс-вендорные фреймворки. Вполне возможно, конкуренцию на этом поле мы увидим от data-lake-вендоров или вендоров популярных OLTP баз данных.
Можно обратить внимание на такие вертикальные кейсы, как машинное обучение, и в итоге покажется, что еще некий абстарктынй key-value storage, который ближе к «железу», чем к Snowflake, более подходит для таких задач.

Для разработчиков платформа пока не открыта. Да и после презентаици остаются вопросы про параллельность UDF или уровень изоляции Unistore. Тем не менее, оснований не писать приложения под экосистему Snowflake в будущем я не вижу: игроков в маркетплейсе пока мало, плюс будет активное продвижение от самой платформы. Когда компания платит за Snowflake $160 тысяч ежегодно, отдать еще $12 тысяч за ваш продукт гораздо проще.

Бонус

Попрбуем задизайнить CRM-систему  на Snowflake и разобраться, почему это может иметь смысл. Из личной практики скажу, что удобной CRM-системы для B2B SaaS self-service бизнеса нет. Классические CRM выстроены вокруг сделок, но в self-service важно «растить» контакт, чтобы в определенный момент подключать Sales-специалиста.

Сейчас я использую целый «зоопарк» сервисов для того, чтобы занести данные об использовании продукта (reverse-ETL) в Hubspot. Это и самописный микросервис, слушающий webhook-продукта, и workflow automation-инструменты, и оркестраторы над хранилищем данных.

Представим, что CRM использует Snowflake как бэкенд. Основные функции я могу реализовать с помощью существующих drag and drop-модульных компонент, элементов визуализации, прогнозирования, алертинга и так далее. Под основные сущности CRM (контакты, сделки, компании) создаются таблицы в Snowflake через Unistore.

Для того, чтобы дата-сайентист сделал renewal forecasting-прогноз не надо выгружать данные в ноутбук, можно просто взять Streamlit и построить нужный опыт внутри приложения. Любые логики алертинга можно описать декларативно. Можно создать приложение или воркфлоу в зависимости от его взаимодействия с продуктом. Лимиты кастомизации почти безграничны.

Хранение данных в центральном хранилище делает любые интеграции проще: информация по Google Ads, Facebook Ads, Stripe, Zendesk, Intercom, Mixpanel уже доступна в CRM, истории про reverse-ETL уходят в прошлое.

Как разработчик, я могу создать комфортный дата-опыт для аккаунт-менеджмента, сотрудников службы поддержки и маркетологов без смены контекста.

Критики моего решения могут возразить, что эта задача решается и в Salesforce, но забывают, что Salesforce в свое время стал флагманом «облачной революции». Сейчас концепция привычная, но тогда возбуждала и пугала многих профессионалов своего времени. В On-Premise-инструментах той эпохи нельзя было видеть, что делает каждый сейлз, нельзя вести отчеты по всем менеджерам, маршрутизировать потенциальных клиентов. Опыт Salesforce достигается за счет большой команды интеграторов и разработчиков их платформы, что для SMB не подходит из-за цены, гибкости и скорости.

Если вам понравилась статья, и интересно думать в этом направлении про будущее SaaS продуктов, пишите в телеграмм.