Польза, а не маркетинг. Почему стоит потратить время на конференцию Yandex Scale 2021

А план выбрали очень простой. Раз на конференции пять треков (ML & AI, Cloud-native, Security, Data Platform, Infrastructure) — значит, должно быть и пять ключевых докладчиков. Находим этих людей, допрашиваем их с пристрастием: почему были выбраны именно эти темы, насколько можно верить докладчикам и что вообще происходит. И только после этого делаем выводы.

Вот кого нам удалось выхватить.

За трек ML & AI отвечает Игорь Куралёнок. Главный по машинному обучению в Yandex.Cloud. До этого долгое время работал в Поиске, где занимался обучением формулы ранжирования, оценкой качества поиска и мобильным поиском. До работы в Яндексе разрабатывал IntelliJ IDEA. В свободное время занимается наукой и преподаванием.

Всё про трек Infrastructure знает Михаил Костин. Руководитель сервиса Object Storage в Yandex. Cloud и внутренних систем хранения для Яндекса.

Трек Security ведёт Андрей Иванов. Он отвечает за развитие механизмов и сервисов информационной безопасности платформы Yandex.Cloud. В индустрии больше 15 лет. До прихода в Яндекс занимался вопросами облачной безопасности в компании Microsoft, а ещё раньше работал руководителем службы ИБ и руководителем департамента по развитию бизнеса в разных компаниях.

За Cloud-native удар держать будет Глеб Борисов. До перехода в Yandex. Cloud он занимался системой управления кластером внутреннего облака Яндекса, внедрял автоматизацию процессов и DevOps-культуру.

А про Data Platform будем допрашивать Владимира Бородина. В Яндексе он с 2012 года. До 2016-го занимался переездом Яндекс. Почты с Oracle на PostgreSQL, а затем начал разрабатывать database as a service внутри компании. Сейчас руководит разработкой платформы данных в Yandex.Cloud.

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

— У нас есть облачный сервис DataSphere, и за год в нём произошло много изменений. Если раньше мы предоставляли ML-разработчикам инфраструктуру, то сейчас предлагаем уже полноценные инструменты, которые упрощают доступ ко всяким хитрым штукам, непрофильным для рядовых дата-сайентистов. Например, сервис позволяет ML- или дата-сайентистам пользоваться благами прекрасного мира высоконагруженных вычислений без необходимости думать, как организовывать данные для вывода, как обеспечивать эффективную нагрузку, как дебажить это добро и т. д.

— Я бы скорее сравнил это с тем, что сейчас делается на уровне Databricks. У нас, условно, есть библиотека типа Pandas, мы берем команды Pandas и распараллеливаем их на кластер в Spark — и эта связка делает за нас всю работу. Подобный инструментарий только появляется на рынке, и мы верим, что за ним будущее. Ведь часто дата-сайентист вынужден думать не о сути своей работы, а о том, где исполняется его код. И неизбежно попадает в тупик: многопроцессно — это лучше, чем многонитево, или нет? Задаваться этим вопросом — не его дело. Как мне кажется, в облаке мы приходим к hardware-agnostic-схеме, когда нам просто дают задачу, а мы её эффективно вычисляем. По сути, люди платят за решение задачи, а не за утилизацию железа.

— В прошлом году мы выпустили DataSphere как продукт. Сейчас же мы консолидируем собственную разработку в рамках этой платформы и полностью переезжаем на эксплуатацию в ней же. Мы используем DataSphere в своём же продакшене, а это фундаментальное изменение. Можно провести аналогию с кондитером, который делает конфеты, но своим детям их есть не даёт. Мы же занимаемся производством таких конфет, которые нашим детям давать можно.

— У нас всё очень сильно отличается. Если мы говорим про AWS, то там есть SageMaker, и он идёт своей дорогой. Они, по большому счёту, продают виртуальные машины. Да, там есть некоторое развитие в виде автоматизации их dsvm, которую они потихоньку пилят. Но по сути это остаётся набором «Сделай сам» в рамках виртуальной машины.

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

Ближе всего к нам как раз Databricks, в который довольно активно вкладывается Microsoft. Суть этого инструмента в том, что у них есть готовая распределённая платформа Spark, на которой учатся решать ML-задачки. Мы делаем очень близкую вещь: накладываем ML на распределённую платформу. Мы не продаем виртуалки, наше предложение — всё облако целиком. А как инструмент работает внутри облака — это уже наши собственные сложности.

Databricks пытаются всё упихнуть в MapReduce-парадигму. И зачастую не очень успешно, потому что у MapReduce-парадигмы есть довольно сильные ограничения. Например, как в ML использовать вычисления на машинке, где хранятся данные, я не очень понимаю. Мы от этого отошли, потому что у нас есть собственный опыт в виде внутреннего инструмента, который, по большому счёту, тот же MapReduce. Видим, какие там возникают сложности, поэтому в рамках DataSphere написали свою собственную распределённую систему, в которую и делегируются задачи. Выглядит всё очень похоже на то, как это сделано у других, но только на уровне UI. Как это работает внутри — мы и будем активно раскрывать на конференции.

— Да. Это наша ключевая фича. Мы работаем в серверлесс-режиме, и какой у нас hardware, становится неважно. Можем бесшовно переносить состояние, переменные, какие-то элементы состояния памяти с одной машины на другую. Сейчас это позиционируется как способ бесплатного масштабирования, т. е. вы какую-то часть вычислений можете делегировать более слабой машинке, но, когда потребуется, — переключить на более сильную. Просто переносим вычисления туда — и она работает только на время обучения. Это понятный, простой сценарий с точки зрения экономики.

Но мы даем возможности, превышающие то, что пользователи обычно получают от ML-платформы. Пример с тем же ноутбуком: в DataSphere можно шарить состояния между ноутбуками, которые будут разделены функционально. В одном, например, мы тренируем, во втором считаем аналитику, в третьем — что-то ещё, а в четвертом — всё это заворачиваем куда-то и несём в прод. При этом все эти ноутбуки делят единое состояние.

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

Я в своих докладах предпочитаю говорить про то, куда мы пойдем дальше, чтобы люди понимали, насколько им с нами по пути. Другие ребята рассказывают о технических вещах, которые отличают Yandex. Cloud от облаков конкурентов.

— Да, у нас именно такое разделение. Один большой визионерский доклад о том, куда мы двигаемся и почему думаем, что в ту сторону стоит двигаться. А остальные — это чисто технические доклады, которые делают наши тимлиды.

— Мы предоставляем полноценное рабочее место дата-сайентиста. Ему не надо париться над тем, чтобы на следующий год выбить бюджет на новые ускорители по $100 тысяч за тушку. Как для технических специалистов, так и для бизнеса — это снятие головной боли и обеспечение самого современного на текущий момент железа. Почему это так важно? Хотя бы потому, что в DataSphere cлишком разнообразный инструментарий. Если программисту на рабочем месте хватит ноутбука и IDE, то у дата-сайентиста очень большой зоопарк по технологиям: чтобы просто настроить окружение, можно потратить много-много дней, пока сойдутся звезды и все пакеты окажутся совместимы между собой. И второе — масштабируемость на команду. Чтобы даже в твоё отсутствие любой мог подхватить задачу, не испытывая болей.

— Во-первых, у нас большой прогресс по этой тематике. Я бы даже сказал, что мы сейчас на передовых позициях, причём не только в России, но и в мире. С той же самой Nvidia мы активно общаемся и примерно понимаем, что делает их команда. Оказывается, что направления близкие: где-то они прокопали глубже, где-то мы.

Во-вторых, в рамках нашей команды мы используем голосовые технологии как того самого котика Шредингера, над которым проводим все мыслимые и немыслимые эксперименты.

— Мы работаем и для облака, и для большого Яндекса. То, о чём мы рассказываем, — Beyond Object Storage.

Да, CDN придумали не вчера. S3 тоже придумали не вчера, но у нас своя реализация, и сделали мы её хорошо. Поэтому минимум половина доклада будет посвящена нашим преимуществам.

— Инфраструктурные сервисы — это те кирпичики, без которых ничего не построить. Без серверов сервисам будет негде работать. Без Object Storage сервисы не смогут ничего хранить. И так далее. Поэтому эти базовые кубики мы и называем инфраструктурой.

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

Мы и темы докладов так выбирали:

— Да, будем.

— Так всё просто: о тех крутых штуках, которые сделали за год. Максимально ёмко, интересно, чтобы все об этом узнали.

— У нас сервисы появляются постоянно. Выделять один и говорить, что он выше остальных, я не хочу. Точно хочется отметить всевозможные сертификации, которые мы прошли. Мы открыли все сегменты, показали, что мы надёжны, что с нами можно работать, что это всё проверено и можно приносить нам данные — хоть банковские, хоть государственные, хоть персональные данные любого уровня.

Запуски сервисов, которые хочется отметить — Cloud CDN, Cloud DNS, Network Load Balancer, Application Load Balancer. Ещё мы добавили managed-сервисы — например, для СУБД Greenplum, Kafka, Elastic. Отмечу, что по итогам прошлого года наше облако выросло в 5 раз по количеству клиентов. Так что есть чем поделиться.

— Когда несколько лет назад создавался наш Yandex. Cloud, мы отставали от Amazon лет на 15. Несколько лет спустя можно было сказать, что раза в три мы точно сократили это отставание. А сейчас местами стали опережать.

В первый момент повторять за лидером полезно для совместимости. Мы поддерживаем совместимость с S3, чтобы клиентам было удобно работать с нами. Все инструменты для работы с S3 уже придуманы: ты берёшь готовый инструментарий, будь то просто SDK или готовое решение, переключаешь его с AWS на наш Object Storage, и у тебя всё работает. Возможность переключиться в один клик — это громадное преимущество.

Для нас очень важно мнение пользователей. Их запросы мы учитываем и при запуске новых сервисов, и в развитии уже существующих. Смотреть на AWS — это полезная практика, но ни в коем случае не ориентир. Тот же стандарт S3: да, мы его поддерживаем, мы совместимы, но стандарт, прямо скажем, старый. Ему лет 15, и в нём становится тесно, поэтому мы делаем вещи, которых нет в стандарте S3, но они нужны пользователям.

— Сервис CDN мы сделали вместе с отличной компанией G-Core Labs, у которой на каждом континенте по нескольку точек присутствия.

Главное, всегда помнить, что данные ты раздаёшь в паблик и надо следить за их приватностью. Залил что-то в Object Storage, открыл bucket, веб-сайтик настроил, выложил в интернет и назвал mypersonaldomain.com. И всё — кто скачал, тот скачал. Поэтому ответственность только на раздающем. Мы просто даём возможность раскидать данные по всему миру. А дальше всё сам: сам принял решение, сам закачал, сам сказал «возьми, покешируй мне это отсюда сюда».

— Стандартные вещи туда приносит команда Yandex. Cloud: мы собираем, поддерживаем, патчим, когда надо. Есть решения Microsoft, Cisco, Checkpoint, Лаборатории Касперского и т. д.

Но если ты зайдёшь на сайт маркетплейса, там самая большая кнопка «принеси нам своё». Приносишь продукт, и если другие пользователи его используют, ты на этом ещё и зарабатываешь. Поэтому приносить нам свои образы не просто можно, а нужно.

— Тему действительно обсудили уже миллион раз, но не помогает! На первый взгляд всё просто: есть инфраструктура провайдера, дата-центр, физические хосты, виртуализация. Провайдер всё это контролирует и отвечает за безопасность. Но есть сервисы, где определённые настройки контролирует клиент. И в рамках этих настроек он сам отвечает за безопасность.

Если копать глубже, возникает масса вопросов, ответы на которые обычно пытаются изобразить в виде некой таблички. Нельзя сказать, что она получается какая-то неправильная. Но как только чуть копнёшь вглубь — сталкиваешься с нюансами, которые эта табличка не отражает. Например, процессы: что делать, если произошёл инцидент в рамках ИБ? Или: как строить отказоустойчивую инфраструктуру и кто на каком уровне должен это делать? В нашей презентации на Scale 2021 мы хотим пробежаться по различным срезам и раскрыть их более глубоко. Например, с точки зрения контроля показать, что конкретно контролирует провайдер в каждом из сервисов. Или взять обычную базу данных, которую предоставляют как сервис клиенту: за безопасность виртуальной машины несёт ответственность провайдер, но за базу данных и доступ к данным отвечает сам клиент. На таких примерах мы попытаемся более чётко эту ответственность показать и разделить.

Другой пример: резервное копирование — что и в каком случае бэкапит провайдер, а что — клиент. Мы предоставляем этот сервис, но клиенту надо сделать минимальные усилия — отметить нужный чекбокс. А есть сервисы, где клиенту ничего делать не надо, потому что мы гарантируем сохранность данных за счёт наших систем репликации.

И тут есть нюансы. Если данные потеряются — это одно, другое — если клиент их сам испортит. Для этого у нас есть версионирование, но его надо включить. Вот по таким аспектам и инцидентам мы собираемся пробежаться.

— Да, наша задача: на реальных примерах объяснить эту конструкцию. Всех деталей не раскроем, но, надеюсь, наш доклад позволит пользователям понять нюансы разделения ответственности. Чтобы, когда люди приходят в облако, смотрят на эту табличку и начинают задавать вопросы, нам не приходилось начинать этот диалог каждый раз заново.

— Я, как человек за него отвечающий, предложил коллегам темы. Мы согласовали названия, обсудили внутреннюю фактуру и выбрали добровольцев, готовых сделать доклады. Рассказывать о каждом из сервисов будут коллеги, создающие эти сервисы и понимающие все детали их архитектуры. Они лучше всех знают про гарантии безопасности данных, которые обрабатываются в этих сервисах. Наш доклад о разделении ответственности — по сути вводный, а дальше коллеги будут рассказывать про инструменты для клиентов, в том числе про новые сервисы и новые возможности.

— Но ведь так сложно начать доверять свои данные какому-то дяде из облака!

— Вопрос комплексный и непростой. Если отвечать на него объективно, то тут нет единственно верного ответа, который сразу убедит не бояться облаков, чужих глаз, рук и т. д. Если бы такое решение было, его бы знали все. В этом и суть. Честно говоря, риски, которые видит в облаке клиент, в определённой степени действительно существуют. Но тут важно понимать, что если потенциальные клиенты скажут: «Ой, облако небезопасно, потому что мы его не контролируем, и давайте не будем его использовать», — то будут ли они правы? Частично да, потому что чёрт, как обычно, кроется в деталях. Да, они не полностью контролируют облако, но разве можно говорить о полном контроле над любой средой? Это же большая профанация. Можем ли мы контролировать ядро операционной системы вплоть до байта? Или исходный ход, который не лично мы писали? А что мы знаем про внутреннюю работу файрвола? Есть только документация и понимание общих правил игры, но кто сказал, что там нет каких-то закладок?

Контроль — немного эфемерное понятие. Собственную среду, которая стоит за кучей файрволов, в определённой степени можно назвать контролируемой, но точно не на 100%. Как я часто говорю коллегам: коль уж мы согласны даже в своей среде работать без 100%-го контроля каждого байта, наверное, и с облаком так же можно работать. Просто в своём режиме.

— Надо плясать от архитектуры конкретной системы. Вот есть наше решение в облаке, в рамках которого обрабатываются определённые данные. Исходя из того, где и какие компоненты обрабатывают эти данные и насколько они критичны, мы определяем конкретные риски. Например, есть система, которая собирает финансовые данные клиентов для последующего анализа. Но сделать это на земле, по определенным причинам, невозможно. Это ведь абсолютно реальный кейс для многих компаний.

А у нас есть сервисы, позволяющие эту аналитику легко настроить. Значит, эти данные надо каким-то образом передать в облако — например, через наше объектное хранилище Object Storage. Получается, что первая точка риска — это именно Object Storage. Теоретически, наши сотрудники могут получить к ним доступ. Для этого мы с клиентом проговариваем: это невозможно, так как у нас используется шифрование на уровне физики. Даже если кто-то в нарушении всех регламентов, выключив камеры, аки ниндзя, сможет выдернуть диск из сервера, то данные там в живом виде он не увидит, потому что они на более высоких уровнях архитектуры шифруются. И так по каждому пункту.

— Мы анонсировали серверлесс-контейнеры. Это история о том, что можно просто запустить контейнер как сервер. Пользователь платит за время выполнения, количество запросов и не думает, сколько их понадобится, не надо ли всё это скейлить, не настраивает мониторинг, логирование и т. д. Контейнеры — здорово, они с нами надолго, потому что позволяют сделать повторяемые билды. Контейнеры стали новым стандартом упаковки: запустить с их помощью приложения можно в почти любой операционной системе. Невероятная гибкость.

Но появление контейнеров не избавило пользователя от необходимости что-то настроить, установить, сконфигурировать, подумать о безопасности. И ладно если у пользователя один сервер и, чтобы логи почитать, надо просто сходить в /var/logs/. А если 10 серверов и на каждом по 5 контейнеров — это сразу 50 сущностей. Куда теперь идти за логами, чтобы понять, как ведёт себя приложение? Так что на деле всё сильно усложнилось.

Следующий эволюционный шаг — это оркестраторы вроде Kubernetes. Ты (прим. — пользователь) в облаке, у тебя есть Kubernetes, вроде как всё должно быть просто. Но нет. Потому что проблемы с Kubernetes — всё ещё твои: если ты что-то навертел и сломал в ноде, то облако за это не отвечает. Облако может пересоздать эту виртуалку, но только лишь пересоздать, т. е. никто не будет её чинить и искать причину краша. Так что сложность никуда не делась. Мы просто её поделили и спрятали куски.

А серверлесс-подход — ещё более высокая ступень эволюции, где пользователю не надо думать о серверах, т. к. у него их реально нет. С серверлесс он даже не знает, что там, под капотом. Может, кубер, а может быть, нет. Это уже наше дело.

Мы обещаем пользователю запустить контейнер — мы его запускаем. Но серверлесс-подход подразумевает, что пользователь переписал свой код под облако. AWS Lambda, Google Cloud Function — это всё одного поля ягодки: везде надо написать приложение с нуля, используя технологии облака. Причём конкретного облака, потому что функции из Google, например, в AWS не переносятся. В этом плане Яндекс более-менее совместим. То есть пользователь может функцию из AWS перенести к нам и от нас к AWS.

— Да, это не волшебная таблетка. Тебе дают ванильное окружение, где всё сконфигурировано и работает, но неизбежно возникает вопрос: а как обеспечить безопасность? Ты пытаешься разобраться, как всё устроено на этих нодах, ведь нужно понять, как оно устроено изнутри, что можно сделать, а что нет. И тут если ты сделал что-то не так, это твои проблемы.

С серверлесс ты говоришь нам: хочу, чтобы вот этот контейнер отвечал на http-запросы. Мы тебе говорим: отлично, вот тебе URL, ты можешь вызывать свой контейнер — всё остальное делаем мы: мы его запускаем, масштабируем, берём с него логи, метрики. Тебе остаётся только свой код писать, а не разбираться во всей этой кухне.

— Когда ты просто запустил приложение, встаёт вопрос: что случится, когда к тебе придут пользователи? Вот пришло 100 человек — наверное, одна виртуальная машина выдержит. А если придёт миллион человек сразу? Kubernetes не выдержит, тебе надо его поскейлить. Поскейлить как? Или разобраться с автоскейлером, который встроен в Kubernetes — а это опять своя кухня, — или залить это всё деньгами: создать кластер такого размера, который выдержит любую нагрузку. А серверлесс решает эту проблему за тебя сам, он видит: много запросов — запустим больше контейнеров.

Пользователю всё равно, сколько запущено контейнеров, потому что модель ценообразования подразумевает, что он платит за результат. Мы хорошую аналогию с ребятами придумали. Представь, что ты приходишь в ресторан. Тебе предлагают арендовать на час столик, повара и официанта, а ещё купить продукты для блюда. Звучит тупо: ведь когда ты приходишь в ресторан, то просто платишь деньги, и тебе приносят еду. Серверлесс ровно про это: ты не должен разбираться, как работает вся эта кухня, кто вовлечён, откуда взялись продукты. Ты приходишь, платишь — и получаешь результат. Серверлесс уравновешивает наш реальный IT-мир.

— За серверлесс мы отвечаем полностью. Ты нам принёс контейнер, он должен запуститься. Есть чёткий водораздел: всё, что внутри контейнера, нас не касается, мы туда даже смотреть не можем. Пока ты явно в тикете в поддержке не написал: «Да, я разрешаю вам посмотреть код моего приложения», — до этого момента у нас руки связаны. Мы логи твои даже почитать не можем, потому что это ФЗ 152 и прочий комплаенс. Если ты дал разрешение, мы посмотрим, что происходит, и тогда или решим проблему на своей стороне, или посоветуем, что надо сделать, чтобы приложение заработало. Если проблема — не ошибка пользователя, это всё дойдёт до команды разработки, они всё это исследуют, поймут, в чём проблема и будут исправлять.

— Это не чёрный ящик, а хорошая тема для беседы. Всё — собственная разработка, которая тянется десятилетиями. Яндекс — очень большая штука: многие технологии внутри существуют довольно давно. То есть это не так, что мы сели и такие: «Давайте очередь сообщений напишем», — нет. Очередь сообщений есть в Яндексе, она обрабатывает петабайты данных в сутки. Такие данные в России мало у кого есть, поэтому нашим разработчикам пришлось написать её самим, и получилась надёжная штука. Дальше мы адаптировали её, сделали понятную модель, красивый UI, написали документацию и теперь предлагаем это пользователям.

То же самое с базой данных. Yandex Database — полностью собственная разработка Яндекса. Мы её писали лет десять, и на ней построено много сервисов Яндекса. Большая часть Yandex. Cloud работает поверх Yandex Database. То есть вся метаинформация о виртуальных машинах, функциях, о дисках и т. д. — всё построено поверх Yandex Database. Это огромная платформа, на которой базируются очень много сервисов.

— Это просто. Первый доклад называется «Новости и планы платформы данных»: он позволит пользователям за полчаса понять, что Yandex. Cloud сделало за год. Большими мазками: какие новые сервисы запустили, где что улучшили в старых, какие планы на следующий год. Расскажем о самих сервисах, различных СУБД, очередях и т. д. Руководитель сервиса DataLens отдельно расскажет про визуализацию данных. Далее будет превью сервиса Yandex Managed Service for Greenplum®. Это специальная массивная параллельная база данных, на которой строят корпоративные хранилища. Можно сказать, что аналог Vertica, Teradata и прочих Redshift. Представит доклад Дима Павлов — наш менеджер по развитию бизнеса платформы данных, главный человек по Greenplum в стране, можно даже так дерзко сказать. В смысле не главный начальник, но управляющий комьюнити и чата Greenplum на 1000 человек.

После доклада о Managed Greenplum идёт доклад про сервис под названием DataTransfer и анонс нового сервиса Yandex Data Streams. Это аналог Amazon Kinesis. Data Streams и Kinesis — с точки зрения API одно и то же. Что такое DataTransfer и что такое Data Streams? Это способы поставлять данные в облако. Например, из каких-то баз данных можно инкремент выгружать и класть его в облако. Или просто однократно скопировать базу откуда-то из он-према. Или из Amazon получить её полную актуальную копию с доливкой изменений в Yandex.Cloud. Можно и наоборот. Обо всех этих сценариях расскажем. И про PostgreSQL, и про MySQL, и про MongoDB, и про ClickHouse. Почему это всё вместе? Потому что Data Streams сможет быть источником данных для Data Transfer, что открывает много интересных сценариев доставки данных. Это самый интересный доклад, и на текущем этапе развития облака мы считаем, что это очень важный сценарий, который позволяет пользователям проще и легче въезжать и выезжать из облака.

Идём дальше. У нас есть один из крупнейших клиентов, это компания «Метр квадратный», m2.ru, они же «ВТБ Жилищная экосистема». У них подробный доклад о том, с чем они сталкивались при заезде в облако и конкретные сервисы. Там разные истории — про Mongo, про Kafka, даже про S3 будет. Получается вполне честный рассказ от клиента, что они получили, зачем и как делали.

Следующие два доклада — про транспорт и про путешествия. Я решил, что будет прикольно из разных индустрий взять людей. Когда обзавелся недвижимостью, хочется путешествовать и машину купить, ну или не машину, а самокат. 62 тысячи самокатов, они — один из крупнейших пользователей MongoDB. Клиент будет рассказывать о своём опыте с Mongo, в том числе и про DataTransfer, про то, как они из одной очень большой базы в Mongo, используя только серверлесс, сделали несколько маленьких.

И последний доклад стоит особняком. Он на английском, это наш эксперимент. Надеюсь, он будет удачным. Мы — один из трёх мировых партнёров компании Elastic NV по предоставлению Elasticsearch на базе того, что делает Elastic, а не Open Distro или Open Search. Они сейчас форкнулись, есть энтерпрайз-версия Elastic, есть опенсорсная. Мы пошли в сторону того, что предоставляем более дорогую, но и более функциональную версию от компании Elastic, т. е. от самого вендора. Они недавно запустили версию 7.14, и Майк Николс, руководитель продактов по направлению секьюрити, расскажет о Elastic 7.14. Какие новые фичи появились в последней версии Elastic, куда они идут, что изменилось. И в конце заявим, что 7.14 у нас в облаке уже доступно.

— Скорее всего, всё заработает из коробки. Бывает, конечно, что у пользователя есть какие-то экзотические расширения или команды, которые требуют суперпользователя, но такое придётся переделать на другой способ выполнения того же самого. Это минимальные переделки, обычно можно обойтись тем, чтобы сделать ту же задачу по-другому.

— Его правильно представлять как BI-инструмент для аналитиков. Я бы сказал, что два главные свойства сервиса таковы: функционально оно близко к промышленным BI-инструментам (90% фичей условного Power BI закрывает), при этом сервис бесплатный. С ним можно работать не только с базами данных в облаке, а с любыми, до которых у него будет сетевой доступ. Мы сами этим пользуемся.

Ну что же, вот мы и поговорили с властителями всех пяти треков. Разговоры получились достойные, властители — профессионалы своего дела. Абсолютно всем я задавал один и тот же вопрос: как вы выбирали темы и почему спикерами выступают именно эти люди? Ответ всегда поступал один: темы выбирает команда, занимающаяся разработкой продукта, и никто другой. Никаких указаний сверху или из других отделов. Ребята сами решают, о чём хотят рассказать, и сами выдвигают свои кандидатуры для выступления. Поэтому за каждую презентацию можно ручаться, что выступать будет человек, который каждый день взаимодействует с тем, о чём он рассказывает. И как никто другой знает, как работает его продукт, в чём его сильные и слабые стороны.

Не знаю, как вы, а я бы пошёл их послушать.