Люди с песьими головами или эта ваша аналитика глазами CTO
Расскажу об одном разговоре с моим тогдашним СТО, который многое для меня сделал понятным.
СТО был прекрасный, на 146% на своем месте. Трудились мы в небольшой компании, которая разрабатывала подписочный SaaS продукт. Главная задача СТО в такой компании - поддержание продукта работоспособным и быстрая выкатка новых фич, которые растят ARPU.
И тут появляется аналитика. Далее - описание процесса из глаз СТО, практически цитата.
Приходят какие-то люди с песьими головами. Говорят что-то непонятное, что-то просят, и довольно много. Я честно, не понимаю в этих ваших КХД, ETL, Data Governance, и почему все так сложно и дорого. Я другими вещами занят, у меня SLA продукта должен быть 100%, потому что каждое падение это отток подписок. Мне выкатки без багов нужны, у меня беклог на 4 года вперед, а вилки на разработчиков низкие, потому что мы маленькие и живем скромно.
Объясни, пожалуйста, что вам надо на уровне разумного минимума, чтобы ваши хотелки были удовлетворены, и ко мне не приставали больше с этой ерундой.
Договорились мы в итоге, что по минимуму у нас будет а) Postgres на 5 ТБ, так как в компании есть компетенции постгресовых ДБА, б) сервисы для Airflow, Jupyter для ETL, Аналитиков и простого BI (!), в) небольшая квота DevOps+DBA для поддержания и развития этого стека. С тем и прожили следующие 2 года, до тех пор как команда аналитиков не стала 20 человек, и появились некоторые бюджеты на более взрослые системы и решения.
«Люди с песьими головами» остались со мной навсегда.
Вы, бывает, варитесь в своем пузыре, вам кажется, что все понимают и разделяют ваши проблемы. Метрики-отчеты и пайплайны, а теперь и ЛЛМ, очевидны и понятны в своей ценности - кажется вам. Но для большинства ваших технических коллег вы непонятные Псоглавцы (Кинокефалы). А главная ваша ценность глазами высоких менеджеров - это «чтобы от меня отстали с этой ерундой».
Расскажу об одном разговоре с моим тогдашним СТО, который многое для меня сделал понятным.
СТО был прекрасный, на 146% на своем месте. Трудились мы в небольшой компании, которая разрабатывала подписочный SaaS продукт. Главная задача СТО в такой компании - поддержание продукта работоспособным и быстрая выкатка новых фич, которые растят ARPU.
И тут появляется аналитика. Далее - описание процесса из глаз СТО, практически цитата.
Приходят какие-то люди с песьими головами. Говорят что-то непонятное, что-то просят, и довольно много. Я честно, не понимаю в этих ваших КХД, ETL, Data Governance, и почему все так сложно и дорого. Я другими вещами занят, у меня SLA продукта должен быть 100%, потому что каждое падение это отток подписок. Мне выкатки без багов нужны, у меня беклог на 4 года вперед, а вилки на разработчиков низкие, потому что мы маленькие и живем скромно.
Объясни, пожалуйста, что вам надо на уровне разумного минимума, чтобы ваши хотелки были удовлетворены, и ко мне не приставали больше с этой ерундой.
Договорились мы в итоге, что по минимуму у нас будет а) Postgres на 5 ТБ, так как в компании есть компетенции постгресовых ДБА, б) сервисы для Airflow, Jupyter для ETL, Аналитиков и простого BI (!), в) небольшая квота DevOps+DBA для поддержания и развития этого стека. С тем и прожили следующие 2 года, до тех пор как команда аналитиков не стала 20 человек, и появились некоторые бюджеты на более взрослые системы и решения.
«Люди с песьими головами» остались со мной навсегда.
Вы, бывает, варитесь в своем пузыре, вам кажется, что все понимают и разделяют ваши проблемы. Метрики-отчеты и пайплайны, а теперь и ЛЛМ, очевидны и понятны в своей ценности - кажется вам. Но для большинства ваших технических коллег вы непонятные Псоглавцы (Кинокефалы). А главная ваша ценность глазами высоких менеджеров - это «чтобы от меня отстали с этой ерундой».
❤14👍8
В Spark 4.1 появлся ... Airflow
В документации версии Spark 4.1-Preview появились так называемые Spark Declarative Pipelines (SDP)
На борту:
1️⃣ Несколько видов датасетов: Материализованные, Стриминговые, Временные
2️⃣ Пайплайн как объект. Описывается через YAML файл с SQL, Python кодом и необходимыми конфигами Спарка. Также объявляется каталог (Hive, Iceberg), с которым можно взаимодействовать и в который складывать результаты.
3️⃣ Команда spark-pipelines init с интерфейсом и аргументами как у Spark Submit. Отдельная команда spark-pipelines run.
Удобство
Пример нового кода на PySpark, который читает Kafka топик и складывает данные в таблицу в каталоге. По сути это декларативное описание (не как-сделать, а что-сделать) а-ля DAG.
К объявленной таким способом таблице можно обращаться дальше по пайплайну.
На SQL и того проще
Или пример с несколькими синками
Осталось разобраться, как в этом всем провязаны семантики доставки (exactly-once, at-least-once), и куда это все полетит при смене схемы источника (Dead Letter). И понять, как устроить мониторинги и алерты работающих или сломавшихся пайплайнов.
Но ясно, что в четвертом Спарке сделать такую операцию как стриминг подхват из топиков Кафки в таблицы Айсберга будет сильно проще, чем сейчас. А то и вовсе - декларативно. Что не может не радовать.
Насладиться примерами можно в офф доке превью версии
В документации версии Spark 4.1-Preview появились так называемые Spark Declarative Pipelines (SDP)
На борту:
Удобство
Пример нового кода на PySpark, который читает Kafka топик и складывает данные в таблицу в каталоге. По сути это декларативное описание (не как-сделать, а что-сделать) а-ля DAG.
from pyspark import pipelines as sdp
@sdp.table
def ingestion_st():
return (
spark.readStream.format("kafka")
.option("kafka.bootstrap.servers", "localhost:9092")
.option("subscribe", "orders")
.load()
)
К объявленной таким способом таблице можно обращаться дальше по пайплайну.
На SQL и того проще
CREATE STREAMING TABLE basic_st
AS SELECT * FROM STREAM samples.nyctaxi.trips;
Или пример с несколькими синками
-- create a streaming table
CREATE STREAMING TABLE customers_us;
-- add the first append flow
CREATE FLOW append1
AS INSERT INTO customers_us
SELECT * FROM STREAM(customers_us_west);
-- add the second append flow
CREATE FLOW append2
AS INSERT INTO customers_us
SELECT * FROM STREAM(customers_us_east);
Осталось разобраться, как в этом всем провязаны семантики доставки (exactly-once, at-least-once), и куда это все полетит при смене схемы источника (Dead Letter). И понять, как устроить мониторинги и алерты работающих или сломавшихся пайплайнов.
Но ясно, что в четвертом Спарке сделать такую операцию как стриминг подхват из топиков Кафки в таблицы Айсберга будет сильно проще, чем сейчас. А то и вовсе - декларативно. Что не может не радовать.
Насладиться примерами можно в офф доке превью версии
Please open Telegram to view this post
VIEW IN TELEGRAM
👍15🔥9
Архитектор Данных
В Spark 4.1 появлся ... Airflow В документации версии Spark 4.1-Preview появились так называемые Spark Declarative Pipelines (SDP) На борту: 1️⃣ Несколько видов датасетов: Материализованные, Стриминговые, Временные 2️⃣ Пайплайн как объект. Описывается через…
Есть любопытный Q&A по фиче Spark пайплайнов.
Подписчики мне справедливо попеняли, что речь идет не про Airflow DAG, а скорее про декларативное описание моделей и потоков данных, что больше похоже на DBT, SQLMesh.
Как раз окрестратор в этом дополнении предельно простой - из одной команды spark-pipeline run my.yaml. Полноценный шедулер (пока) никто не делает. Хотя в будущем, полагаю, появится какой-то аналог dbt run с его селекторами.
На философском уровне, как также верно отметили комментаторы, спарк постепенно из библиотеки, которая запускает Map-Reduce в памяти, превратился в неимоверный комбайн, который разве что кофе не варит. Наверное, это судьба всех успешных фреймворков.
Я честно говоря, жду когда появится альтернатива, которая будет себя позиционировать как SimpleSpark. Или DuckSpark 😁
Если знаете такую, напишите в коментах.
Подписчики мне справедливо попеняли, что речь идет не про Airflow DAG, а скорее про декларативное описание моделей и потоков данных, что больше похоже на DBT, SQLMesh.
Как раз окрестратор в этом дополнении предельно простой - из одной команды spark-pipeline run my.yaml. Полноценный шедулер (пока) никто не делает. Хотя в будущем, полагаю, появится какой-то аналог dbt run с его селекторами.
На философском уровне, как также верно отметили комментаторы, спарк постепенно из библиотеки, которая запускает Map-Reduce в памяти, превратился в неимоверный комбайн, который разве что кофе не варит. Наверное, это судьба всех успешных фреймворков.
Я честно говоря, жду когда появится альтернатива, которая будет себя позиционировать как SimpleSpark. Или DuckSpark 😁
Если знаете такую, напишите в коментах.
Forwarded from StarRocks and modern data stack
Ехал метастор через метастор, видит метастор в метасторе метастор...
Одни очень большие ребята рассказали, что активно смотрят на Apache Gravitino. Плохого же не посоветуют, вот и я решил посмотреть.
А получается у нас на руках каталог каталогов, через который можно управлять метаданными во всем своем зоопарке. Имея на руках HDFS+Spark, StarRocks, Vertica (jdbc) и MySQL, можно из одного места раскатывать миграшки, управлять доступами и даже работать (если есть коннектор). Интересно как реализован линейдж, но мне кажется, что это не совсем тема каталога.
Идея интересная, наверное для больших ребят напрашивается. У нас сейчас 4 сервиса управления доступами (причем довольно разных), только миграции раскатываются через один сервис и однотипно. Аудит - не уверен что в этой штуке реализован корректно.
Подумал, что можно наконец выкинуть из стека Apache Ranger, но нет - это только прослойка для него.
Очень неоднозначная штука, на мой взгляд, и профит от нее для платформы надо внимательно рассматривать под микроскопом.
Видите пльзу для себя, затеялись бы внедрять? :)
Одни очень большие ребята рассказали, что активно смотрят на Apache Gravitino. Плохого же не посоветуют, вот и я решил посмотреть.
А получается у нас на руках каталог каталогов, через который можно управлять метаданными во всем своем зоопарке. Имея на руках HDFS+Spark, StarRocks, Vertica (jdbc) и MySQL, можно из одного места раскатывать миграшки, управлять доступами и даже работать (если есть коннектор). Интересно как реализован линейдж, но мне кажется, что это не совсем тема каталога.
Идея интересная, наверное для больших ребят напрашивается. У нас сейчас 4 сервиса управления доступами (причем довольно разных), только миграции раскатываются через один сервис и однотипно. Аудит - не уверен что в этой штуке реализован корректно.
Подумал, что можно наконец выкинуть из стека Apache Ranger, но нет - это только прослойка для него.
Очень неоднозначная штука, на мой взгляд, и профит от нее для платформы надо внимательно рассматривать под микроскопом.
Видите пльзу для себя, затеялись бы внедрять? :)
🤔11🤯4
StarRocks and modern data stack
Ехал метастор через метастор, видит метастор в метасторе метастор... Одни очень большие ребята рассказали, что активно смотрят на Apache Gravitino. Плохого же не посоветуют, вот и я решил посмотреть. А получается у нас на руках каталог каталогов, через который…
Meta[store] Mesh - ловите новый термин 😁
😁11❤2
DataFusion Comet
Продолжаем разбор интересных докладов.
Сегодня - доклад с Iceberg Summit 2024 про движок Comet от Чао Сана (Chao Sum) Staff Engineer OpenAI
Comet - переписанный на Rust движок вычислений для Spark с векторизацией (SIMD). Включается как Drop-In Replace, если не может по какой-то причине, то сам фолл-бечится на Scala. В итоге получаем скорость Rust, не теряя богатство экосистемы Spark и его API. На бумаге.
В докладе неплохо разобрано, как выглядит с точки зрения Спарка простой запрос. Потом добавляем к нему векторизацию.
Видео c таймкодами ниже в канале или на ВК. Оригинал Youtube - без таймкодов.
Ранее в разборах:
Часть 1 - Разбор нововведений Iceberg v3
Часть 2 - Streaming Data Lake - Redpanda
------------------------------------
------ Архитектор данных -------
------------------------------------
Продолжаем разбор интересных докладов.
Сегодня - доклад с Iceberg Summit 2024 про движок Comet от Чао Сана (Chao Sum) Staff Engineer OpenAI
Comet - переписанный на Rust движок вычислений для Spark с векторизацией (SIMD). Включается как Drop-In Replace, если не может по какой-то причине, то сам фолл-бечится на Scala. В итоге получаем скорость Rust, не теряя богатство экосистемы Spark и его API. На бумаге.
В докладе неплохо разобрано, как выглядит с точки зрения Спарка простой запрос. Потом добавляем к нему векторизацию.
Видео c таймкодами ниже в канале или на ВК. Оригинал Youtube - без таймкодов.
Ранее в разборах:
Часть 1 - Разбор нововведений Iceberg v3
Часть 2 - Streaming Data Lake - Redpanda
------------------------------------
------ Архитектор данных -------
------------------------------------
VK Видео
Iceberg Summut 2024 - DataFusion Comet - Chao Sun, Staff Engineer OpenAI
Comet - переписанный на Rust движок вычислений для Spark с векторизацией (SIMD). Включается как Drop-In Replace, если не может по какой-то причине, то сам фолл-бечится на Scala. В итоге получаем скорость Rust, не теряя богатство экосистемы Spark и его API.…
👍6
Media is too big
VIEW IN TELEGRAM
01:15 - Улучшаем производительность нативного движка Spark
05:10 - Как исполняется код на Spark под капотом и его узкие места
08:45 - Векторизованная модель исполнения кода
10:39 - Comet - движок поверх Dafafusion + Arrow
27:10 - Интеграция Comet - Iceberg
31:36 - Как включить векторизованный движок при чтении Iceberg-Parquet
05:10 - Как исполняется код на Spark под капотом и его узкие места
08:45 - Векторизованная модель исполнения кода
10:39 - Comet - движок поверх Dafafusion + Arrow
27:10 - Интеграция Comet - Iceberg
31:36 - Как включить векторизованный движок при чтении Iceberg-Parquet
Архитектор Данных
DataFusion Comet Продолжаем разбор интересных докладов. Сегодня - доклад с Iceberg Summit 2024 про движок Comet от Чао Сана (Chao Sum) Staff Engineer OpenAI Comet - переписанный на Rust движок вычислений для Spark с векторизацией (SIMD). Включается как…
В коментах вспомнили отличный доклад на Smart Data 2025. Ребята измерили, как на практике работает Comet (Rust), Velox (C++) движки Spark'а.
Слайды тут:
https://smartdataconf.ru/talks/8e248260514840208beaf9cf90cc0778/?referer=%2Fschedule%2Ftable%2F
На картинке спойлер, но посмотрите слайды, там больше деталей. Видео пока что за пефволом
Слайды тут:
https://smartdataconf.ru/talks/8e248260514840208beaf9cf90cc0778/?referer=%2Fschedule%2Ftable%2F
На картинке спойлер, но посмотрите слайды, там больше деталей. Видео пока что за пефволом
❤7
Архитектор Данных
Есть любопытный Q&A по фиче Spark пайплайнов. Подписчики мне справедливо попеняли, что речь идет не про Airflow DAG, а скорее про декларативное описание моделей и потоков данных, что больше похоже на DBT, SQLMesh. Как раз окрестратор в этом дополнении предельно…
На тему альтернативных движков Spark - офигенный доклад со Smart Data 2025 от Евгения Глотова из Navio
Видео пока что за пейволом, но слайды (70 слайдов) можно посмотреть тут.
Спойлер - Евгений фанат Sail
https://github.com/lakehq/sail
Видео пока что за пейволом, но слайды (70 слайдов) можно посмотреть тут.
Спойлер - Евгений фанат Sail
https://github.com/lakehq/sail
Напомню и про свой доклад
https://vkvideo.ru/video-164978780_456239739
Внутри прожарка формата Iceberg - как оно устроено и почему именно так. Как получается (почти) транзакционная система хранения данных при хранении в нетранзакционном S3.
Во второй части короткий воркшоп.
Есть текстовая версия на Хабре. Статья вошла в топ хабрастатей от ВК 2025 года. Даже медальку в интранете дали 🏅
Для тех, кто хочет познакомиться поближе и пощупать технологии Iceberg, Lakehouse, DBT руками - приглашаю на курс. Стартуем 5 февраля
https://vkvideo.ru/video-164978780_456239739
Внутри прожарка формата Iceberg - как оно устроено и почему именно так. Как получается (почти) транзакционная система хранения данных при хранении в нетранзакционном S3.
Во второй части короткий воркшоп.
Есть текстовая версия на Хабре. Статья вошла в топ хабрастатей от ВК 2025 года. Даже медальку в интранете дали 🏅
Для тех, кто хочет познакомиться поближе и пощупать технологии Iceberg, Lakehouse, DBT руками - приглашаю на курс. Стартуем 5 февраля
VK Видео
Больше, чем просто данные в S3: Iceberg как основа архитектуры Next-Gen КХД
Регистрируйтесь на вебинар, на котором мы разберем, как Apache Iceberg превращает Data Lake в полноценный Data Lakehouse — с ACID-транзакциями, эволюцией схем, time-travel, snapshot isolation (через Spark/Trino). Вас ждет теоретическая часть, воркшоп и ответы…
👍12❤4
WB Track - уже видели?
Теперь можно отправить посылку через логистику Wildberries. Адресат заберет ее из своего пункта ПВЗ.
https://track.wildberries.ru/
Вполне логичный шаг, когда есть логистика такого масштаба. Заодно WB окучивает селлеров, которые не работают через маркетплейс, но которым нужна доставка товара до клиентов с развитой сетью и сервисом. Плюс к тому, у маркетплейсов теперь будет большая проблема в содержании сети ПВЗ из-за повышения налоговой нагрузки на малый бизнес. ПВЗ - армия на марше, которую надо кормить, любая дополнительная копеечка сгодится.
Молодцы, что сказать.
Ну а мы можем оценить - какой объем данных генерирует доставка 1 млрд посылок за год
💾 💾 💾 💾 💾
Теперь можно отправить посылку через логистику Wildberries. Адресат заберет ее из своего пункта ПВЗ.
https://track.wildberries.ru/
Вполне логичный шаг, когда есть логистика такого масштаба. Заодно WB окучивает селлеров, которые не работают через маркетплейс, но которым нужна доставка товара до клиентов с развитой сетью и сервисом. Плюс к тому, у маркетплейсов теперь будет большая проблема в содержании сети ПВЗ из-за повышения налоговой нагрузки на малый бизнес. ПВЗ - армия на марше, которую надо кормить, любая дополнительная копеечка сгодится.
Молодцы, что сказать.
Ну а мы можем оценить - какой объем данных генерирует доставка 1 млрд посылок за год
Please open Telegram to view this post
VIEW IN TELEGRAM
track.wildberries.ru
WB Track
WB Track - обменивайтесь посылками через пункты выдачи
Частое обсуждение архитектуры заказчика:
- У вас тут паяльник воду кипятит. Это неудобно, лучше взять чайник.
- Нам еще гвозди надо забивать. Пробовали чайником - ломается, а вот паяльник подошел!
И смотришь потом на самописный BI, который достает данные из ElasticSearch, и не знаешь, как подобрать аргументы.
- У вас тут паяльник воду кипятит. Это неудобно, лучше взять чайник.
- Нам еще гвозди надо забивать. Пробовали чайником - ломается, а вот паяльник подошел!
И смотришь потом на самописный BI, который достает данные из ElasticSearch, и не знаешь, как подобрать аргументы.
😁28
Философское - облако и разделение труда (1)
В одной умной книге по современной экономике натолкнулся на отличную мысль.
Прогресс и рост экономики последние сотни лет идет по линии разделения труда.
В городе три мастера, которые делают телеги сами от начала до конца. Если они договорятся, и один будет делать корпус, второй колеса, третий сбрую, то их суммарная производительность вырастет. Доустим с 3 телег в неделю до 6.
Но это не бесплатно, потому что теперь они зависят друг от друга. Что если мастер колес заболеет? Все останутся без еды! А если мастер сбруи решит делать сбрую не для телег, а для наездников или договорится с другими мастерами? Зависимость растет и растут риски.
Поэтому выгоды кооперации должны перевешивать риски. Например рядом должен быть огромный ненасыщенный рынок телег с тем чтобы рост продаж телег с 3 до 6 давал прибыль такую, что она перевешивает риски. Или рост производительности ведет к увеличению выпуска не х2, а х10.
Начальная точка - натуральное хозяйство, где каждый занимается всем для себя. И зерно вырастил, и дом построил, и лапти связал. Конечная точка - строительство реактивного самолета, адронного коллайдера, космической станции, которые в принципе возможны только в условиях кооперации всех развитых стран Земли.
Продолжение
В одной умной книге по современной экономике натолкнулся на отличную мысль.
Прогресс и рост экономики последние сотни лет идет по линии разделения труда.
В городе три мастера, которые делают телеги сами от начала до конца. Если они договорятся, и один будет делать корпус, второй колеса, третий сбрую, то их суммарная производительность вырастет. Доустим с 3 телег в неделю до 6.
Но это не бесплатно, потому что теперь они зависят друг от друга. Что если мастер колес заболеет? Все останутся без еды! А если мастер сбруи решит делать сбрую не для телег, а для наездников или договорится с другими мастерами? Зависимость растет и растут риски.
Поэтому выгоды кооперации должны перевешивать риски. Например рядом должен быть огромный ненасыщенный рынок телег с тем чтобы рост продаж телег с 3 до 6 давал прибыль такую, что она перевешивает риски. Или рост производительности ведет к увеличению выпуска не х2, а х10.
Начальная точка - натуральное хозяйство, где каждый занимается всем для себя. И зерно вырастил, и дом построил, и лапти связал. Конечная точка - строительство реактивного самолета, адронного коллайдера, космической станции, которые в принципе возможны только в условиях кооперации всех развитых стран Земли.
Продолжение
Telegram
Архитектор Данных
Философское - облако и разделение труда (2)
Переложим эту мысль на наш мир ИТ.
Если мы переложим часть задач разработки на аутсорс, мы успеем больше. Риски от этого повысятся: вдруг заказчик обанкротится, профакапит, сорвет сроки, сделает не так как надо?…
Переложим эту мысль на наш мир ИТ.
Если мы переложим часть задач разработки на аутсорс, мы успеем больше. Риски от этого повысятся: вдруг заказчик обанкротится, профакапит, сорвет сроки, сделает не так как надо?…
✍7❤3🤔2
Философское - облако и разделение труда (2)
Переложим эту мысль на наш мир ИТ.
Если мы переложим часть задач разработки на аутсорс, мы успеем больше. Риски от этого повысятся: вдруг заказчик обанкротится, профакапит, сорвет сроки, сделает не так как надо?
Можем взять на администрирование СУБД или кубернетисов внешнюю команду. Можем часть функционала закрыть SaaS.
Рост кооперации, рост производительности, но и рост рисков.
Чтобы заняться ростом кооперации, нужно чтобы удовлетворялось ряд требований.
1️⃣ Члены кооперации должны уметь считать выгоду и главное, риски. Часто бывает, когда критический функционал аутсорсится, а внутренняя команда занимается всякой ерундой.
2️⃣ Должно быть доверие между участниками. Доверие создается годами и успешными проектами. Часто просто должно пройти время.
3️⃣ Рост производительности должен конвертироваться в рост благосостояния. Телеги должны продаваться и растить маржу, а не оседать на складе.
4️⃣ Риски должны быть разумными и не расти со временем. Не должно быть риска роста рисков - например введения смертельных штрафов в случае если что-то идет не так.
Хотя как известно, нет такого преступления, на которое капитал не пойдет ради 500% прибыли. Люди идут на риск даже при угрозе физического вывоза себя в лес.
Продолжение
Переложим эту мысль на наш мир ИТ.
Если мы переложим часть задач разработки на аутсорс, мы успеем больше. Риски от этого повысятся: вдруг заказчик обанкротится, профакапит, сорвет сроки, сделает не так как надо?
Можем взять на администрирование СУБД или кубернетисов внешнюю команду. Можем часть функционала закрыть SaaS.
Рост кооперации, рост производительности, но и рост рисков.
Чтобы заняться ростом кооперации, нужно чтобы удовлетворялось ряд требований.
Хотя как известно, нет такого преступления, на которое капитал не пойдет ради 500% прибыли. Люди идут на риск даже при угрозе физического вывоза себя в лес.
Продолжение
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Архитектор Данных
Философское - облако и разделение труда (3)
Верх кооперации в ИТ - Платформы и облака.
Сегодня у большой ИТ компании может быть 0 собственных серверов, а продукт базируется на IaaS, PaaS, SaaS сервисах.
В то же время многие либо сидят на своей инфраструктуре…
Верх кооперации в ИТ - Платформы и облака.
Сегодня у большой ИТ компании может быть 0 собственных серверов, а продукт базируется на IaaS, PaaS, SaaS сервисах.
В то же время многие либо сидят на своей инфраструктуре…
❤9
Философское - облако и разделение труда (3)
Верх кооперации в ИТ - Платформы и облака.
Сегодня у большой ИТ компании может быть 0 собственных серверов, а продукт базируется на IaaS, PaaS, SaaS сервисах.
В то же время многие либо сидят на своей инфраструктуре, либо даже мигрируют в другую сторону: с облака на землю.
Если спросить, почему они так делают, то мы по сути получим какой-то недостаток из 4 пунктов выше.
Часто приходится слышать о таких вещах как
🔤 Мы поехали в облако, а оно нас подвело вследствие багов и аварий. Разрушение доверия, реализовавшиеся риски.
🔤 У нас регуляторные ограничения. Прямой запрет на этот тип кооперации от государства. Так как государство считает, что рост рисков конкретно в этой области неприемлем.
🔤 У нас и так все хорошо. Нет рынка для сбыта новой продукции. Нет воли к расширению. Экономика расширения не сходится.
При этом эти глубинные возражения как правило, не озвучиваются. Никто на встрече с представителями подрядчика или вендора не скажет: мы не верим вам достаточно, чтобы поручить вам критичный для нас функционал. Скажут: вот вам таких и таких фичей не хватает, и это срывает головы. Сейлу и продакту кажется, что вот-вот еще доработать то и это, и тогда мы получим крупного клиента.
Не получите. Не потому что фичи плохие, а потому что доверия к вам нет. Sad but true.
Верх кооперации в ИТ - Платформы и облака.
Сегодня у большой ИТ компании может быть 0 собственных серверов, а продукт базируется на IaaS, PaaS, SaaS сервисах.
В то же время многие либо сидят на своей инфраструктуре, либо даже мигрируют в другую сторону: с облака на землю.
Если спросить, почему они так делают, то мы по сути получим какой-то недостаток из 4 пунктов выше.
Часто приходится слышать о таких вещах как
При этом эти глубинные возражения как правило, не озвучиваются. Никто на встрече с представителями подрядчика или вендора не скажет: мы не верим вам достаточно, чтобы поручить вам критичный для нас функционал. Скажут: вот вам таких и таких фичей не хватает, и это срывает головы. Сейлу и продакту кажется, что вот-вот еще доработать то и это, и тогда мы получим крупного клиента.
Не получите. Не потому что фичи плохие, а потому что доверия к вам нет. Sad but true.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🤔6🔥2