Smart Talk Эпизод 7:Навигация по мощности, контролю и затратам в наблюдаемости

Мы несколько раз обсуждали наблюдаемость и дополнительное пространство AIOps в этой серии, но на этот раз мы более прагматично погружаемся в эту тему, чтобы понять менталитет покупателя. На что должен обратить внимание ИТ-директор организации, когда ищет решение для наблюдения? Присоединяйтесь к нам в этом выпуске, когда Динеш Чандрасекхар, главный аналитик и основатель Stratola, беседует с Кришной Ядаппанаваром, генеральным директором Kloudfuse. Кришна объясняет наблюдаемость через призму трех факторов – мощности, контроля и затрат.
Эти 3 C являются ключом к пониманию и управлению постоянно растущими данными наблюдения. Эти факторы важны не только для управления данными, но и для использования данных и метаданных для дополнительной аналитики.
Новой разработкой в области наблюдаемости является наблюдаемость моделей, особенно LLM, которые управляют генеративным ИИ. Три C также применимы к этому новому варианту использования.

Некоторые темы, затронутые в этом выпуске Smart Talk:

• Потенциал наблюдаемых данных.
• Распространение инструментов
• Преодоление разрозненных данных наблюдения
• Учитывая метаданные.
• Информация о стоимости

Гость
Кришна Ядаппанавар, генеральный директор Kloudfuse
Кришна Ядаппанавар — соучредитель и генеральный директор Kloudfuse, единой платформы наблюдения. Ранее он стал соучредителем SpringPath, обеспечив финансирование в размере 94 миллионов долларов и приведя компанию к приобретению Cisco за 320 миллионов долларов. Имея более 20 патентов, Кришна существенно повлиял на технологии данных, виртуализации и хранения данных в Veritas, Commvault, EMC, VMware и Cisco. Он был соавтором VMFS VMware и разработал критические компоненты стека виртуализации хранения для ESX Server. Кроме того, Кришна консультирует и инвестирует в новые стартапы в области данных, виртуализации, облачных технологий, безопасности и искусственного интеллекта и машинного обучения, способствуя формированию видения, стратегии продукта, проектированию и выходу на рынок.

Хозяин:  Динеш Чандрасекхар — технологический евангелист, идейный лидер и опытный аналитик ИТ-индустрии. Имея почти 30-летний опыт работы, Динеш работал над корпоративным программным обеспечением B2B, а также над продуктами SaaS, предоставляя и продавая сложные решения для клиентов со сложной архитектурой. Он также разработал и реализовал весьма успешные стратегии GTM для вывода на рынок нескольких быстрорастущих продуктов в различных компаниях, таких как LogicMonitor, Cloudera, Hortonworks, CA Technologies, Software AG, IBM и т. д. Он является плодовитым оратором, блоггером и программистом по выходным. Динеш имеет степень MBA Университета Санта-Клары и степень магистра компьютерных приложений Мадрасского университета. В настоящее время Динеш руководит собственной компанией Stratola, специализирующейся на консультировании по бизнес-стратегии и комплексных маркетинговых услугах.

Ресурсы
Smart Talk, эпизод 6:AIOps и будущее ИТ-мониторинга
Smart Talk, эпизод 5:Дезагрегация стека наблюдаемости
Smart Talk, эпизод 4:Данные реального времени и векторные базы данных
Smart Talk, эпизод 3:Современные конвейеры данных и LLM
Эпизод 2 Smart Talk:Рост приложений GenAI с данными в движении
Smart Talk, эпизод 1:Ландшафт экосистемы данных в движении
Посмотреть карту экосистемы передачи данных здесь
Дополнительную информацию о передаче данных в RTInsights можно найти здесь.

Расшифровка
Динеш Чандрасекхар

Здравствуйте и добро пожаловать на этот выпуск Smart Talk, серии о лидерстве Data in Motion. И в этом выпуске у нас есть специальный гость, Кришна Ядаппанавар. Он генеральный директор Cloud Fuse. Он не новичок в экосистеме стартапов. Он серийный предприниматель. До этого он построил пару компаний, и поэтому мы тепло приветствуем Кришну в разговоре о наблюдаемости, которая, опять же, является любимой темой в этой серии. 

Кришна Ядаппанавар

Спасибо.

Динеш Чандрасекхар

Итак, Кришна, почему бы тебе не рассказать нам о Kloudfuse и твоем стремлении основать компанию, чтобы представиться?

Кришна Ядаппанавар (01:01):

Хорошо, абсолютно. Спасибо, Динеш. Спасибо за теплое знакомство. Привет, ребята, меня зовут Кришна. Да, я живу в Долине почти два с лишним десятилетия и работаю с множеством стартапов и крупных компаний. Имя к славе похоже на VMware, когда она только начинала свою деятельность. Я присоединился к компании, а затем увидел, как она выросла с буквально почти миллиона ERR до компании с оборотом в 64 миллиарда, и я был связан с различными технологиями, связанными с данными, будь то написание файловых систем, распределенных систем, баз данных, OLAP или OLTP. Итак, на протяжении всего этого пути я заметил, что данные — это секрет всей информации, будь то со стороны аналитики продукта или предоставления таких решений, как виртуализация, или предоставления таких решений, как резервное копирование или аварийное восстановление. После запуска моего стартапа Springpath, который занимался гиперконвергенцией и пытался объединить конвергенцию систем хранения данных, сетей и безопасности в коробке, которую я продал Cisco.

И, проведя некоторое время в Cisco, я задумался, какие следующие большие тенденции появятся? Это было еще в начале 2020 года. Я столкнулся с несколькими тенденциями, например, с некоторыми тенденциями, связанными с тем, как данные о DevOps или SecOps разработчика растут в геометрической прогрессии. Как новые тенденции в области машинного обучения, искусственного интеллекта и моделей LLM, которые тогда были на ранних стадиях, изменят рынок? А затем, когда человеческий мозг начинает думать и реагировать на определенные происшествия, вы хотите, чтобы машины действовали аналогичным образом. Это были некоторые из проблем, с которыми мы столкнулись, и на пересечении всех трех я обнаружил, что решение проблемы не только наблюдаемости, но и наблюдаемости плюс аналитики и автоматизации, помимо данных, которые ориентированы на разработчиков и DevOps, очень важно. Это привело к созданию Kloudfuse:одно повлекло за собой другое, и теперь в нашей команде около 40 с лишним человек.

Динеш Чандрасекхар (03:16):

Что ж, поздравляю и это отличное начало. Так что желаю вам удачи на этом пути. Говоря о наблюдаемости, это произошло не вчера. Я тоже работал в этой сфере довольно долгое время, и концепция наблюдаемости развивалась с годами. Итак, первоначально 10-12 лет назад люди были в восторге от разговоров о мониторинге инфраструктуры, мониторинге сети и всем таком, а затем постепенно одно привело к другому, а затем были добавлены возможности облачного мониторинга и мониторинга контейнеров. И сегодня у нас есть довольно популярное понятие наблюдаемости. Большинство компаний, которые раньше рекламировали мониторинг, теперь являются компаниями, занимающимися наблюдением. И я знаю, что вы начали заново в области наблюдения, желая изменить ситуацию. Как бы вы описали эту эволюцию? Что было раньше по сравнению с тем, что мы имеем сегодня? Как вы оцениваете эту эволюцию?

Кришна Ядаппанавар (04:09):

Да, отличный вопрос. Динеш. Я видел это, я имею в виду себя как разработчик, пишущий монолитное приложение, работающее на физических машинах. Затем я увидел появление виртуализации, будь то VMware или Hyper-V, или технологии виртуализации с открытым исходным кодом, и появилась контейнеризация. Итак, если вы посмотрите на основные проблемы, когда дело доходит до данных для наблюдения, по мере развития этих оценок мы видим, что атрибуты, связанные с данными, продолжают увеличиваться, и когда вы берете декартово произведение этих атрибутов, то оно становится действительно большим, порядка нескольких миллионов или миллиардов. То, что они называют мощностью, связанной с этой мощностью, — это объем данных. По мере увеличения объема данных люди хотят преобразовать данные A в данные B для лучшей аналитики. Они хотят автоматизировать определенные рабочие процессы на основе данных.

Они хотят разбить данные на кусочки, чтобы они могли дать вам лучшее понимание. Короче говоря, по мере увеличения объема данных традиционным способом, эй, я отслеживал так называемый «по мере того, как известное известное уходит», то есть традиционный мониторинг. Затем вы смотрите на известные неизвестные, что является началом наблюдаемости, и есть полные неизвестные неизвестные, о которых вы ничего не знаете, и вас бросают на многотерабайтные или петабайтные данные, и вам приходится анализировать эти данные и добираться до отсутствия лучшего слова, где именно заключается проблема, как она коррелирует с инцидентом, каков анализ первопричины, каков анализ воздействия. Так что пока разработчики пишут код, появляется эта сложность и все больше и больше сервисов. Эта сложность будет становиться все выше и выше, и, следовательно, это продолжает оставаться развивающимся пространством, где возникают новые проблемы.

Динеш Чандрасекхар (06:14):

Фантастика. Таким образом, наблюдаемость, очевидно, является трудной для решения проблемой. Я хотел бы выяснить, почему это так? Но я думаю, что вы только что немного затронули эту тему, но дело также в том, что у нас есть переполненный рынок с десятком поставщиков, которые говорят:мы решаем эту часть наблюдаемости, такую ​​​​наблюдаемость и все такое, но поиск идеального решения все еще продолжается. Поэтому каждый ИТ-директор, с которым я разговариваю, всегда ищет волшебное средство, которое как бы решит его проблемы. Почему это? Есть ли другая точка зрения, через которую вам нужно взглянуть на это, чтобы понять, почему существует другое стремление получить это идеальное решение?

Кришна Ядаппанавар (07:04):

Итак, как я уже говорил ранее, позвольте мне немного отступить, не так ли? На что смотрит этот клиент, когда думает об идеальном решении для наблюдения? Начнем с проблемы. Я классифицирую эту проблему как три «С»:мощность, контроль и стоимость. Позвольте мне перейти на следующий уровень детализации. Что означают эти три С? Кардинальность, все дело в том, как у нас есть определенные данные, будь то сложная метрическая точка, логлайн, событие, трассировка или интервал, полученный из трассировки вашего дистрибьютора, или профиль непрерывного профиля, к ним прикрепляются дополнительные, за неимением лучшего слова, метки или теги. Если вы возьмете декартово произведение потенциальных значений, которые могут принять эти ярлыки, оно вырастет очень, очень высоко. Итак, теперь каждая точка данных должна быть связана со своими тегами.

Итак, давайте называть теги метаданными. И тогда есть данные. В разных схемах разные проблемы. Некоторые из них содержат много метаданных. Когда вы заходите на сайт матрицы, когда вы приходите к журналам и интервалам, таким как распределенная трассировка, они похожи на тяжелые данные, но по сути это колоссальное увеличение объема наблюдаемых данных из-за кардинальности. Сейчас я наблюдаю обратную тенденцию. Я имею в виду, что в те времена люди думали:«Эй, позвольте мне отправить мои данные на портал SaaS, а затем поставщик SaaS будет управлять всеми этими данными». Но когда я разговариваю с техническим директором, ИТ-директором, руководителем инженерного отдела, разработчиками, архитекторами или даже финансовым директором, они думают:позвольте мне контролировать свои данные. Что они под этим подразумевают? Происходит обратная тенденция:у меня так много данных по разным причинам, будь то потеря стоимости риска, аспекты безопасности или объем самих данных.

Они не хотят отправлять эти данные за пределы своего VPC, и на это есть другая сторона. Они хотят внедрить все возможные интерфейсы, о которых только могут подумать, будь то традиционный интерфейс обсерватории, такой как создание информационных панелей, оповещений, SLO или любых аналитических функций, которые могут быть написаны на традиционном SQL или GraphQL, или могут быть расширены, например, задания Spark, для запуска некоторой аналитики поверх данных наблюдения, поскольку наблюдаемость стала этой фундаментальной опорой. Это означает, что они должны владеть данными. Данные не должны покидать VPC. Когда я говорю о данных, данные, которые принимаются, данные, которые запрашиваются, и данные, которые анализируются, и, наконец, что не менее важно, это стоимость. Если вы обратитесь к любому поставщику, будь то традиционный коммерческий поставщик SaaS или компонент с открытым исходным кодом, вы увидите множество решений с открытым исходным кодом. Стоимость инфраструктуры, затраты вендора прямо пропорциональны объёму данных, прямо пропорциональны количеству запросов и прямо пропорциональны количеству пользователей. Эти три вещи — проблемы, которые ищет традиционная организация, которая ищет идеальное решение, идеальное решение для наблюдения

Динеш Чандрасекхар (10:24):

Мощность, контроль и затраты. Я думаю, мне это нравится. Три C — отличный способ взглянуть на пространство наблюдаемости и сделать вывод о том, что важно для реальных пользователей и так далее. Говоря о затратах, раз уж мы затронули эту тему, хочу задать вам и этот вопрос. По моему личному опыту, когда я разговаривал с клиентами, которые ищут решение для наблюдения, они часто жаловались:«Эй, у меня в каждом отделе есть как минимум восемь-десять различных инструментов». Сегодня я рассматриваю от 30 до 40 инструментов в организации. У меня уже есть много затрат на оплату этих лицензий из года в год. «Почему мне нужно еще одно решение для наблюдения?» — это ответ, который я обычно получал, верно? Итак, я собираюсь задать вам тот же вопрос теперь, когда вы затронули аспект стоимости. Как подойти к этому вопросу ИТ-директору и убедить его или объяснить, почему это лучше, чем иметь 30 или 40 различных инструментов?

Кришна Ядаппанавар (11:23):

Хорошо, отличный вопрос. Итак, чтобы ответить на этот вопрос, давайте начнем с вопроса о том, почему происходит распространение инструментов. Итак, если вы посмотрите на всю экосистему, традиционно некоторые поставщики, если я возьму коммерческих поставщиков, они были довольно хороши в определенных направлениях. Если вы зайдете в журналы, вы можете подумать о Splunk. Если вы думаете о метриках, вы думаете о Datadog. Затем внутри Google и всех Клыков мира. Все это движение открытого исходного кода началось, особенно с появлением Kubernetes, затем появились такие вещи, как Prometheus, OpenTelemetry и многое другое.

И происходит целый сдвиг в сторону решений на основе открытого исходного кода. Что это значит? Это означает, что разработчики, архитекторы и ребята из DevOps хотят получать свои данные наблюдения в открытом формате. Это означает, что даже если я выберу какой-либо инструментарий для инструментирования своего кода или назначу какой-либо агент для сбора моих данных, он должен быть на сто процентов совместим с открытым исходным кодом. Вот почему, когда коммерческие поставщики также начали размещать свои агенты с открытым исходным кодом, то на стороне запросов они хотели, чтобы вся визуализация, информационные панели, оповещения — все эти возможности управлялись языками запросов с открытым исходным кодом. Вот почему с появлением PromQL, LockQL, TraceQL, OpenTelemetry теперь пробуют еще один язык запросов с открытым исходным кодом.

 Итак, теперь вы находитесь в этом мире, где у вас есть много вариантов. Клиенты уже выбрали определенных для определенного направления, определенных поставщиков.

Затем появляется движение за открытый исходный код, и разные команды используют разные инфраструктуры. Некоторые из них основаны на Kubernetes, некоторые — на бессерверных, некоторые — на ECS, Fargate и так далее. Таким образом, это добавляет еще одно измерение, и чтобы добиться скорости и гибкости доставки всего продукта, CI/CD развилась на этом перекрестке, чтобы очень быстро решать проблемы. Они пытаются найти конкретное решение и, следовательно, в конечном итоге выбирают именно это решение. Вот когда мы, как идеальное решение для наблюдения, если бы я начал свой стек наблюдения для своей компании, я бы сделал шаг назад и увидел:эй, если я хочу уменьшить MTTR и MTTD, мне нужно собрать все конечные потоки данных наблюдения. Мне пойти в n разных поставщиков и выберите n разные потоки, или мне следует обратиться к озеру данных наблюдения, где я могу объединить все потоки, чтобы корреляция и расширенные функции, такие как обнаружение выбросов, аномалии и причинно-следственные связи, стали относительно проще? Это было бы идеальное решение, позволяющее консолидировать все в озере данных и хранить данные внутри своих помещений.

Динеш Чандрасекхар (14:18):

Фантастика. И я также хотел бы добавить, что стоимость распространения инструментов, я согласен, во многом потому, что разработчики хотят создавать свои собственные вещи, и они также добавили в эту смесь множество инструментов с открытым исходным кодом, но это также покупки на уровне отдела. Итак, ИТ-отдел чувствует, что я могу решить эту проблему, потому что позвольте мне получить пластырь, позволить мне купить этот инструмент с полки и использовать его. А потом со временем поняли, что добавили в арсенал еще один инструмент и сами того не осознавая, что ищут не за деревьями лес. Таким образом, разговоры ИТ-директоров всегда интересны и о том, как можно сжать или сократить количество инструментов, имеющихся у вас на предприятии, и иметь одну платформу наблюдения, которая будет охватывать все отделы, просматривать приложения, инфраструктурные контейнеры и многое другое. 

Кришна Ядаппанавар (15:08):

Абсолютно. Я хочу добавить к этому, что теперь разные люди в компании также просматривают одни и те же данные. Как и разработчики DevOps, все архитекторы смотрят на данные наблюдения в отношении инфраструктуры, приложений контейнеризации и многого другого. Используя те же логи. Ребята из SecOps пытаются проанализировать данные, чтобы выявить безопасность и угрозы. Глядя на аналогичные данные, поступающие из журналов или трассировок. Даже ребята из DataOps думают:«Эй, насколько хороши мои операции с данными?» А теперь, с появлением LLM, даже ребята из LLM Ops просматривают аналогичные данные для проведения своего рода аналитики. Поэтому необходимо провести еще одну консолидацию. Это то, что я хотел бы найти в идеальном решении для наблюдения. Как мне объединить всех сотрудников организации, чтобы они могли использовать данные из одного и того же так называемого озера данных?

Динеш Чандрасекхар (16:05):

Воистину пресловутое единое оконное стекло, к которому мы все стремились. Так что это хорошо. Итак, я хочу коснуться еще одной вещи, о которой вы кратко упомянули, объясняя предыдущий ответ, а именно о сокращении MTTR, верно? Таким образом, основная задача наблюдения заключается не только в устранении неполадок, но и в сокращении MTTR, уменьшении шума предупреждений и подобных показателей. Таким образом, это определенно избавляет SRE и ИТ-операторов от необходимости ломать голову и выяснять, в чем проблема, и все это в качестве ключевого фундаментального требования для решения этой проблемы. Вам нужен доступ к происходящим в реальном времени событиям. Если в конкретное приложение или на конкретный сервер введен журнал о вредоносной активности или чем-то в этом роде, вам нужен доступ к этому событию прямо сейчас, чтобы вы могли понять, где находится эта аномалия, что происходит в вашей инфраструктуре, почему этот конкретный всплеск в определенном потоке памяти или что-то еще.

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

Кришна Ядаппанавар (18:03):

Хорошо, еще один замечательный аспект команды наблюдателей, ты абсолютно прав, Данеш. Таким образом, ключевым параметром, в котором используются наблюдательные данные, является то, как быстро я могу получить данные, в тот момент, когда данные уходят из источника данных, будь то ваше приложение, компоненты вашей инфраструктуры или ваша платформа, например компоненты с открытым исходным кодом и тому подобное. Итак, если вы посмотрите на то, как развивалась индустрия за последние пять-десять лет или около того, появились потоковые сервисы в реальном времени и базы данных в реальном времени. Если вы посмотрите на традиционные решения для наблюдения, я имею в виду, что они не могли использовать эти функции, потому что технология была относительно старой. Таким образом, с появлением потоковой передачи в реальном времени и баз данных в реальном времени вы можете получить доступ к данным как можно быстрее. Так что это мера так называемой свежести данных с момента их выхода из приложения до тех пор, пока они не станут доступны для запроса, вот и все.

Еще есть такой аспект:«эй, у меня есть все данные». Как мне разделить эти данные? Как мне найти соответствующие закономерности, которые мне нужны, чтобы добраться до основной причины, — это следующий набор проблем. Это означает, что я должен иметь возможность преобразовывать данные из одних данных в другие данные. Эй, я получаю серию журналов. Могу ли я быстро просмотреть метрику из журналов? Я получаю серию промежутков. Могу ли я просмотреть какой-либо атрибут в этом диапазоне или трассировку для анализа этих данных? Потому что эти атрибуты обычно коррелируют, и именно так происходит отладка. Итак, это следующее измерение. И третье измерение — это расширенная аналитика. Могу ли я помимо этих данных использовать какие-нибудь интересные статистические или большие языковые модели для анализа данных и поиска так называемых выбросов в моей системе?

Могу ли я найти аномалии в моей системе? Хорошо, могу ли я изучить сезонный аспект моих данных? Могу ли я спрогнозировать свои данные на основе того, что я видел в прошлом? Сезонный аспект данных? Все это я называю пакетом расширенной аналитики. Поэтому, когда вы думаете об общем решении после обновления данных, вам нужно думать о данных как о единице кирпича, а затем о том, как можно настроить каждый кирпичик, а затем о наборе аналитических функций. И тогда естественно, что нам нужно будет подумать:эй, я уже проанализировал это один раз, могу ли я это автоматизировать? Это становится естественным продолжением всего этого. Вот почему наряду с проблемой трех C мы видим, как клиенты спрашивают, как я могу наблюдать, анализировать и автоматизировать свои данные наблюдений.

Динеш Чандрасекхар (20:57):

Очень круто. Очень круто. А затем в своем ответе вы также упомянули волшебное слово LLM — большие языковые модели. Я имею в виду, что в наши дни невозможно вести разговор, не говоря о программах магистратуры GenAI. Я рад, что вы упомянули об этом, потому что я определенно мог бы спросить вас об этом, а именно о наблюдаемости LLM. Похоже, что это внезапно возникшая сфера, учитывая, что у нас повсюду распространено количество программ LLM, и люди изо всех сил пытаются понять, как они работают, и так далее. Так расскажите нам об этом. Похоже, что Kloufuse тоже что-то строит в этом направлении, верно? Расскажите нам об этом подробнее.

Кришна Ядаппанавар (21:32):

Я имею в виду, да. Я имею в виду, что в целом модели LLM используются в различных случаях использования, верно? Что касается отсутствия лучшего слова. Динамика данных меняется, особенно в мире наблюдаемости, данные очень динамичны. Построить правильную модель LLM для выполнения определенных операций всегда сложно. Итак, мы рассмотрели проблему с двух сторон. Как я могу использовать определенные модели LLM поверх существующих данных наблюдения, которые потребляются всеми разными людьми, о которых я говорил, будь то DevOps, SecOps, DataOps или ребята из LLMOps. Это один из аспектов этого. И есть еще один аспект:эй, я разрабатываю приложение, в котором LLM является очень, очень важным компонентом. Как мне посмотреть на полную наблюдаемость приложения, которое производит данные, которые передаются в LLM, а затем есть множество потребителей, которые потребляют эти данные из этих моделей LLM.

Итак, мы думаем, по сути, я могу сказать, что мы первые, кто комплексно задумался о том, какова истинная наблюдаемость для всех приложений, которые разрабатываются с использованием моделей LLM. Потому что я нашел множество решений, просто глядя на наблюдаемость модели, например дрейф и тому подобное. Но мы ищем от начала до конца. Это очень интересный аспект, потому что большая часть наблюдаемости инфраструктурных приложений сочетается с наблюдаемостью модели и всем остальным. И наконец, последнее, но не менее важное:если вы спросите любого ИТ-директора или финансового директора, стоимость LLM, как и текущих решений, является еще одним ключевым аспектом. Еще одним аспектом является то, как вы сохраняете эти затраты или даже предоставляете какую-либо аналитику по показателям затрат самих моделей LLM. Таким образом, вам нужно учитывать все: производительность, отсутствие, назовем это APM для приложений LLM, а затем стоимость. Вот типичные размеры, на которые вы могли бы обратить внимание.

Динеш Чандрасекхар

Очень крутое, захватывающее пространство, и я определенно с нетерпением жду возможности узнать, что будет в этом пространстве в ближайшие несколько месяцев. Так что спасибо тебе огромное, Кришна. Это был очень, очень замечательный разговор. Мне очень понравилось видеть тебя на нашем шоу. Люблю говорить о наблюдаемости. Я запомню ваши три пункта:кардинальность, контроль и затраты. Я думаю, что это отличный способ, отличная мантра взглянуть на наблюдаемость. Так что спасибо за все идеи. Ценю, что вы здесь. Спасибо.

Кришна Ядаппанавар

Большое спасибо, Динеш. Спасибо, что пригласили меня в свой веб-чат.