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

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

Некоторые темы, охваченные в этом эпизоде Smart Talk:

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

Гость
Кришна Ядаппанавар, CEO, Kloudfuse
Кришна Ядаппанавар — сооснователь и CEO Kloudfuse, unified observability платформы. Ранее он соосновал SpringPath, обеспечив $94 млн финансирования и приведя компанию к $320 млн приобретению Cisco. С более чем 20 патентами, Кришна значительно повлиял на данные, виртуализацию и технологии хранения в Veritas, Commvault, EMC, VMware и Cisco. Он соавтор VMware's VMFS и спроектировал критические компоненты storage virtualization stack для ESX Server. Кроме того, Кришна консультирует и инвестирует в возникающие стартапы по Data, Virtualization, Cloud, Security и AI/ML, внося вклад в видение, продуктовую стратегию, инженерию и go-to-market усилия.

Ведущий: Динеш Чандрасекар — технологический евангелист, мыслительный лидер и опытный аналитик IT-индустрии. С почти 30-летним опытом, Динеш работал с B2B корпоративным ПО, а также SaaS продуктами, доставляя и маркетируя сложные решения для клиентов со сложными архитектурами. Он также определял и выполнял высоко успешные GTM стратегии для запуска нескольких высокоростных продуктов на рынке в различных компаниях вроде LogicMonitor, Cloudera, Hortonworks, CA Technologies, Software AG, IBM и др. Он prolific спикер, блогер и weekend кодит. Динеш имеет MBA от Santa Clara University и магистерскую степень в компьютерных приложениях от Университета Мадрас. Сейчас Динеш управляет своей компанией Stratola, фирмой по консалтингу бизнес-стратегий и full-stack маркетинговым сервисам, ориентированной на клиента.

Ресурсы
Smart Talk Эпизод 6: AIOps и будущее IT-мониторинга
Smart Talk Эпизод 5: Дисaгрегация стека наблюдаемости
Smart Talk Эпизод 4: Данные в реальном времени и векторные базы данных
Smart Talk Эпизод 3: Современные конвейеры данных и LLM
Smart Talk Эпизод 2: Восхождение GenAI приложений с Data-in-Motion
Smart Talk Эпизод 1: Ландшафт экосистемы Data-in-Motion
Посмотреть карту экосистемы data-in-motion здесь
Узнать больше о data-in-motion на RTInsights здесь

Транскрипт
Динеш Чандрасекар

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

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

Спасибо.

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

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

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

Ок, абсолютно. Спасибо, Динеш. Спасибо за теплое введение. Ребята, мое имя Кришна. Да, я живу в Valley почти два плюс десятилетия и работал с кучей стартапов и больших компаний. Имя к славе вроде VMware, когда это был ранний стартап. Я присоединился и затем видел его рост от буквально близко к миллиону ERR до 64 миллиарда компании и я был ассоциирован с разными data-related технологиями, будь то написание файловых систем, distributed systems, databases или OLAP или OLTP. Ок, так через этот путь что я заметил — data это секрет всех инсайтов, будь то на product analytics стороне или предоставление решения вроде виртуализации или предоставление решения вроде backup или disaster recovery. Имея сделано мой стартап, Springpath, который был в hyperconvergence, пытаясь привести вместе конвергенцию storage, networking, security все вместе в коробку, я продал Cisco.

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

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

Хорошо, поздравляю и это отличный старт. Так желаю удачи в том путешествии. Говоря о наблюдаемости, это не было чем-то, что просто пришло вчера. Я работал в том пространстве также для fair количества времени и концепция наблюдаемости эволюционировала за годы. Так изначально 10, 12 лет назад люди были hyped up о говорении об infrastructure monitoring, network monitoring и все это, и затем медленно одно привело к другому и затем там были cloud monitoring и container monitoring возможности, что добавлены. И затем сегодня у нас есть это понятие наблюдаемости, которое довольно популярно. Большинство компаний, которые использовали tout monitoring теперь observability компании. И я знаю, ты начал fresh в observability пространстве желая создать разницу. Как бы ты описал эту эволюцию? Что было до по сравнению с тем, что у нас сегодня? Как ты видел эту эволюцию?

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

Да, отличный вопрос. Динеш. Я видел это, я имею в виду как developer сам пишущий monolithic application запускающийся в physical machines. Затем я видел приход виртуализации, будь то вроде VMware или Hyper-V или open-source виртуализации технологий и containerization пришло. Так что если вы смотрите на core проблемы, когда речь идет о data для observability, как эти эволюции эволюционировали, так мы видели атрибуты ассоциированные с data продолжают увеличиваться, и когда вы берете Cartesian product тех потенциальных значений, которые эти labels могут взять, оно растет действительно, действительно высоко в порядке multiple millions to billions. То, что они называют кардинальностью ассоциированной с той кардинальностью это data volume. Как data volume увеличивается, люди хотят трансформировать data A в data B для лучшей аналитики. Они хотят автоматизировать определенные workflows поверх data. Они хотят slice and dice data так что это может дать вам лучшие инсайты. Так что в коротком, как data volume увеличивается traditional way of, эй, я был monitoring так называемый known knowns уходит, которое traditional monitoring. Затем вы смотрите на known unknowns, которое начало observability и там есть complete unknown unknowns где вы ничего не знаете и вы брошены в multi-terabyte до petabytes worth данных и вы должны dissect внутри тех данных и получить к lack of better word где именно проблема, как это коррелировано к инциденту, что root cause analysis, что impact analysis. Так что пока developers пишут код, эта сложность и больше и больше сервисов приходят. Эта сложность идет выше и выше и поэтому это продолжает быть evolving пространством где новые вызовы возникают.

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

Фантастично. Так что observability очевидно definitely difficult проблема для решения. Я бы хотел исследовать почему это? Но я думаю, ты коснулся этого немного также только что, но это также то, что у нас есть crowded marketplace с dime-a-dozen вендорами там, которые говорят, мы решаем эту часть наблюдаемости и ту часть наблюдаемости и все это, но там все еще поиск идеального решения. Так что каждый CIO, с которым я говорю, всегда ищет эту одну magic bullet, которая вроде решает их проблемы. Почему это? Есть ли другой lens через который вы должны смотреть на это для понимания почему есть разный urge получить то идеальное решение?

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

Так что как я аллюдил ранее дай мне отступить немного, верно? Что это customer ищет когда они думают об идеальном observing решении? Давайте начнем с проблемы. Я классифицирую эту проблему как три C — Кардинальность, Контроль и Затраты. Давайте пойдем в следующий уровень деталей. Что эти три C означают? Кардинальность, это все о том, как у нас есть определенные data, будь то tricky metric point или logline или event или trace или span исходящий из вашего distributed tracing или continuous profile's profile, оно получает attached с additional, для lack of better word, labels или tags. Когда вы берете Cartesian product потенциальных значений тех labels могут взять, оно будет расти действительно, действительно высоко. Так что теперь каждая data point должна быть ассоциирована с ее tags.

Так что давайте назовем tags как metadata. И затем есть data. Разные схемы имеют разные проблемы. Некоторые metadata heavy. Когда вы идете к matrix сайту, когда вы приходите к logs и spans вроде distributed tracing, они data heavy, но в эффекте, это tremendous увеличение в volume observability data из-за cardinality. В наши дни я видел reverse trend. Я имею в виду back in the days люди думали вроде, Эй, дай мне отправить мои данные к SaaS порталу и тогда SaaS вендор бы управлял всеми теми данными. Но когда я говорю будь то CTO или CIO или head of engineering или developers или architects и даже CFO, они думают, дай мне иметь контроль моих данных. Что они имеют в виду этим? Там reverse trend идет, что у меня так много данных по различным причинам, будь то egress в risk cost, security аспекты этого, или volume данных самих.

Они не хотят отправлять те данные вне их VPC и там другой угол к этому. Они хотят привести все возможные интерфейсы, которые они могут думать, будь то для traditional observatory рода интерфейса вроде создания ваших dashboards, alerts, SLOs, или любых analytics функций, которые могли быть написаны в traditional SQL или GraphQL или там могли быть advanced вроде Spark jobs для запуска некоторых analytics поверх observability data потому что observability стало тем fundamental pillar. То значит они должны владеть data. Data не должно уходить из VPC. Когда я говорю data, data которое ingesting, data которое querying, и data которое анализируется, и last but not least, это cost. Если вы идете к любому вендору там, будь то traditional SaaS commercial вендор или open source компонент, и там много open source решений там. Infrastructure cost, cost вендора directly proportional к volume данных, directly proportional к number of queries, и directly proportional к number of users. Те три вещи — проблемы, которые traditional организация, ищущая идеальное решение, идеальное observability решение ищет.

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

Кардинальность, контроль и затраты. Думаю, я люблю это. Три C отличный способ смотреть на observability пространство и как вы инферите что важно для actual пользователей и так далее. Говоря о затратах, раз мы коснулись этого, я хочу спросить вас этот вопрос также. Из моего личного опыта, когда я говорил с клиентами, ищущими observability решение, что они часто жалуются о вроде, Эй, у меня по крайней мере восемь до 10 разных инструментов в каждом департаменте, что у меня. Я смотрю на может быть 30 до 40 инструментов через организацию сегодня. У меня уже много затрат платя за эти лицензии год за годом. «Почему я хочу еще одно observability решение», это pushback, который я получал, верно? Так что я собираюсь поставить тот же вопрос к вам теперь, что вы коснулись cost аспекта. Как вы подходите к тому вопросу с CIO и убеждаете их или говорите им почему это лучше чем иметь 30 или 40 разных инструментов?

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

Ок, отличный вопрос. Так что для ответа на тот вопрос, давайте начнем с проблемы почему там tool proliferation. Так что если вы смотрите на entire ecosystem, традиционно некоторые вендоры, если я беру commercial вендоров, они были pretty good в certain streams. Если вы идете к logs, вы можете думать Splunk. Если вы думаете metrics, вы думаете Datadog. Затем внутри Google и всех FANGs мира. Это whole movement open source началось, особенно с приходом Kubernetes, затем пришли вещи вроде Prometheus, OpenTelemetry и whatnot.

И там есть этот whole shift идущий towards и moving к open-source based solution. Что это значит? Это значит developers, architects, DevOps guys хотят ingest их observability data в open format. Meaning, даже если я pick any instrumentation для instrumentation моего кода или put any agent для сбора моих данных, то должно быть hundred percent open-source compatible. Так что это почему когда commercial вендоры также начали класть их agents в open source, затем на query стороне они хотят whole visualization, dashboarding, alerting — все эти capabilities быть driven by open-source query languages. Это почему emergence of PromQL, LockQL, TraceQL, OpenTelemetry, они now trying another open-source query language.

Так что теперь вы в этом мире где у вас many options. Customers уже picked certain для certain stream, certain vendors.

Затем есть open source movement и затем different teams используют different infrastructures. Некоторые based on Kubernetes, некоторые based on serverless, некоторые based on ECS, Fargate whatnot. Так что это adding another dimension и to get to the speed и agility whole product delivery, CI/CD эволюционировало в этом intersection чтобы решать проблемы very quickly. Они try to look for the pointed solution и hence end up choosing the very pointed solution. То когда мы as an ideal observability solution, если я был бы to start my observability stack для my company, я бы отступил и увидел вроде, эй, если я хочу reduce my MTTR и MTTD, я need to collect all the end streams of the observability data. Do I go to n different vendors и pick n different streams, или do I go to an observability data lake где я can put all the streams together так что the correlation, the advanced functions like outlier detection, anomalies, causation becomes relatively easier? То был бы ideal solution где you can consolidate everything в a data lake где you can preserve your data within your premises.

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

Фантастично. И я бы также хотел добавить, что cost для tool proliferation, я agree largely потому что developers хотят build their own thing и они have added в a lot of open source tooling также к the mix, но это также department-level purchases. Так что IT department чувствует вроде я can solve this problem потому что let me get a bandaid solution, let me buy this tool off the shelf и use it. И затем over time они realized они have added one more tool к the arsenal и without realizing that they're not looking at the forest for the trees. Так что CIO conversations всегда interesting и о том как you can compact или reduce the number of tools you have across the enterprise и have one observability platform looking across the departments, looking across applications, infrastructure containers, и whatnot.

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

Absolutely. Так что I mean to add on to that now different personas в the company are also looking at the same data. Like DevOps developers, architects are all looking at the observability data with respect to infrastructure, containerization applications, и whatnot. Using the same logs. The SecOps guys are trying to dissect the data to look for the security и the threats. Looking at the similar data coming from the logs или the traces. Even the DataOps guys are looking like, Эй, how good are my data operations? И now with the advent of LLM, even the LLM Ops guys are looking at the similar data to do their kind of analytics. Так что там есть another consolidation that needs to happen. То one thing I would look for in an ideal observability solution. How do I bring in all the different personas в an organization так что they can leverage the data from the same so-called data lake.

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

Truly the proverbial single pane of glass thing that we've all been striving for. Так что it's a good thing. Так что I want to touch on one other thing that you mentioned briefly as you were explaining the previous response, which was about reducing MTTR, right? Так что as a primary crux of observability, it is about not only troubleshooting но also the reducing the MTTR reducing alert noise и those kinds of metrics as well. Так что it definitely saves SREs and IT Ops from having to split hairs и figure out where the trouble is и all that as a key fundamental requirement for solving this. You need access to real-time events as they're happening. If there is a log that got entered in a particular application or a particular server about a malicious activity or something like that, you need access to that event right away then and there so that you can understand where that anomaly is, what's happening across your infrastructure, why this particular spike in a particular memory thread или whatever.

Так что you need to figure that out и in order for that to happen, you need the ability to ingest all of this in real time as well. Data immediacy, which is a favorite term of mine over the last year I've been talking about it, и data freshness is kind of prime importance here. This is what we are talking about, how fresh the data is, is how quickly you can resolve that particular problem or maybe even avert something that's about to happen in this particular context of observability, particularly when you're talking about hundreds and thousands of in a servers that you're monitoring and all that, или where do you pinpoint saying, here's where the trouble is in terms of getting the data to be as fresh as possible or not. Is it largely dependent on the ingestion mechanisms? Because you spoke about TEL and other types of instrumentation techniques и all that too. So how else would you think about it or look at it from this perspective of how quickly can I get access to realtime data?

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

Ок, another great aspect of the observe team, you're absolutely right, Danesh. Так что the key dimension где the observative data is getting consumed is how quickly can I have the data, the moment the data has left from the source of the data, whether it is your application или your infrastructure components или your platform like open source components и things like that. Так что for that, if you look at how the industry has evolved in the last five to 10 years or so, the realtime streaming services, realtime databases have come along. If you look at the traditional observ solutions, I mean they couldn't leverage those functionality because the technology was relatively older. Так что with the advent of the realtime streaming и the realtime databases, you can get to the access of the data as quickly as possible. So that is the measure of what is called as a freshness of the data from the moment it has left the application until it is readily queryable, that's all matters.

Then there is that aspect of like, эй, I have all the data. How do I compartmentalize that data? How do I find the relevant patterns I need to get to the root cause is the next set of the problems. So that means I should be able to transform data one data to the other data. Эй, I'm getting series of logs. Can I quickly look at a metric out of the logs? I'm getting a series of spans. Can I look at some attribute within that span or a trace to analyze that data? Because these attributes are typically correlated и that's how the debugging happens. So that is the next dimension. And then the third dimension is the advanced analytics. On top of that data, can I bring some interesting statistical or the large language models to analyze the data to find what is called the outliers in my system?

Can I find the anomalies in my system? Okay, can I look into the seasonality aspect of my data? Can I forecast my data based on what I have seen from the past? The seasonal aspect of the data? So all these is what I call as the package of the advanced analytics. So when you think of the overall solution after the freshnes sof the data is solved, you need to think about the data as a unit of a brick and then how each brick can be adjusted and then set of analytics function. And then the natural thing that we'll need to is like, эй, I have analyzed this once, can I automate it? That becomes the natural extension to the whole thing. So that's why along with the three Cs problem, we have seen the customers asking how can I observe, analyze and automate my observing data.

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

Very cool. Very cool. И затем as a part of your response, you also mentioned the magic word LLMs, large language models. I mean these days you cannot have a conversation without talking about GenAI LLMs. So I'm glad you mentioned it because I could definitely ask you about this, which is LLM observability. It looks like that's an emerging space suddenly given that we have a proliferation of LLMs everywhere and people are struggling with understanding how they're performing и so forth. So tell us about that. It looks like Kloufuse is also building something on that front as well, right? So tell us more about it.

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

I mean, yes. I mean fundamentally the whole, the LLM models are getting deployed in various use cases, right? As for lack of better word. The dynamism of the data changes, especially in the observability world, the data is very dynamic. Building the right LLM model to do certain operations is always hard. So we have looked at the problem in two ways. How can I leverage certain LLM models on top of the existing observability data, which is getting consumed by all the different personas I talked about, whether it is DevOps or SecOps or DataOps guys or the LLMOps guys. That's the one aspect of it. And there is the other aspect of, эй, I'm developing an application where the LLM is a very, very critical component. How do I look at the complete observability of an application which is producing the data, which is getting fed into the LLM, and then there are a lot of consumers who are consuming that data from those LLM models.

So we are thinking of, in fact, I can say that we are the first one to end to end think about what is the true observability for all the applications which are developed using the LLM models. Because I have come across a lot of solutions just looking at the model observability like drift and things like that. But we are looking end to end. That's a very interesting aspect because a lot of infrastructure application observability goes along with the model observability and the rest of the things. And then last but not the least, if you go and ask any CIO or the CFO, the cost of the LLM, like the current solutions, the cost is another key dimension. How do you keep that cost or even provide any analytics on the cost metrics of the LLM models itself is another aspect of it. So you have to look into everything: performance, lack of, let's call it an APM for LLM applications, and then the cost. So these are the typical dimensions you would look at it.

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

Very cool, exciting space and I'm definitely excited about learning what's coming in that space in the upcoming few months. So thank you so much, Krishna. This has been a very, very wonderful conversation. Loved having you on our show. Love talking about observability. I'm going to remember your three Cs: Cardinalality, Control, and Costs. I think it's a great way, great mantra to look at observability. So thank you for all the insights. Appreciate you being here. Thank you.

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

Thanks a lot, Dinesh. Thanks for having me on your web chat.