В последние годы рынок облачной безопасности переживает стремительное развитие, становясь ареной жесткой конкуренции между ведущими игроками индустрии. Одной из самых заметных историй последних лет стало приобретение Google компании Wiz за 32 миллиарда долларов — событие, которое однозначно свидетельствует о том, кто в современном облачном пространстве задает тон. При этом успех Wiz вызвал множество вопросов: почему компания, вышедшая на рынок позже, смогла значительно превзойти Lacework, которая стартовала на пять лет раньше, обладая мощной командой и солидной венчурной поддержкой? Анализ причин этого феномена раскрывает важные уроки не только для компаний, специализирующихся на безопасности, но и для всех, кто работает с большими данными и построением архитектур сложных продуктов. Если внимательно следить за обсуждениями на популярных технических площадках таких, как Reddit, X (бывший Twitter) и Hacker News, можно увидеть множество обсуждений, в которых инженеры и руководители делятся опытом сравнения Lacework и Wiz. В этих дискуссиях много внимания уделяется не просто продуктовой стратегии или маркетинговым ходам, а техническим аспектам инфраструктуры данных — той самой части, которая часто остается за кадром, но в итоге определяет успех.
Lacework стартовала в 2015 году с амбициозным проектом, основанным на концепции графов – Polygraph® Data Platform. Идея заключалась в том, чтобы выявлять угрозы, анализируя взаимосвязи и поведение между облачными активами, что теоретически идеально подходит для графового представления данных. Однако, вопреки предположениям, Lacework не использовала настоящую графовую базу данных, а построила свою систему поверх Snowflake, популярной облачной платформы для хранения и обработки данных в табличном формате. Выбор Snowflake имел под собой очевидные основания — эта платформа предлагала высокую масштабируемость при относительно низких затратах и отлично подходила для хранения огромных объемов телеметрии из облачных источников. Для компании, ориентированной на экономическую эффективность и масштабируемость, такой подход казался естественным.
Однако скрытой проблемой стала несовместимость Snowflake с задачами глубокого анализа графовых взаимосвязей. Самые простые запросы, основанные на многократных соединениях таблиц, превращались в сложные и запутанные SQL-конструкции, что серьезно затрудняло отладку, сопровождение и быструю разработку новых функций. Пример запроса с несколькими соединениями в SQL наглядно демонстрирует эти сложности. При увеличении степени связности, количества переходов и усложнении условий становится практически невозможно эффективно управлять кодом и быстро реагировать на изменения требований со стороны безопасности. В противоположность этому, Wiz, основанная в 2020 году командой с опытом из Adallom, сделала решительный выбор в пользу использования нативной графовой базы данных — Amazon Neptune.
Благодаря этому они смогли моделировать всех пользователей, облачные ресурсы, роли и потоки как узлы и ребра, что идеально соответствовало естественной структуре данных в контексте безопасности. Используя язык запросов Gremlin, разработчики Wiz могли формулировать сложные графовые обходы и проверки всего в нескольких строках кода. Такая компактность и выразительность способствовали высокой скорости прототипирования и быстрому выпуску новых функций, что в условиях постоянно изменяющихся угроз кибербезопасности является критическим преимуществом. Выбор архитектуры на базе нативных графовых технологий обеспечил Wiz значительное превосходство по показателям разработческой эффективности и инновационной скорости. Это позволило компании не просто догонять конкурентов, а опережать их в вопросах внедрения новых возможностей и отклика на запросы клиентов.
Тогда как Lacework делал упор на экономию и масштабируемость через Snowflake, Wiz оптимизировал инфраструктуру для достижения максимальной итеративной скорости и глубины аналитики, жертвуя при этом большей стоимостью инфраструктуры. Для рынка кибербезопасности, где важна оперативность обнаружения и реагирования на угрозы, такой компромисс оказался выигрышным. На самом деле этот раскол в архитектурных решениях отражает более широкую дилемму: можно ли совместить преимущества быстрого и гибкого графового анализа с бюджетными и масштабируемыми решениями на базе современных озер данных? Некоторые компании уже пробуют гибридные подходы — например, хранить топологическую информацию в специализированных графах, а атрибуты ресурсов — в хранилищах типа Snowflake или Databricks. Другие ограничивают объем графовой информации, чтобы не перегружать базу. На горизонте появляется новая технология — PuppyGraph, которая предлагает проверенное инновационное решение: запускать полноценный графовый движок напрямую на озерах данных без необходимости выделять отдельные базы и делать сложный ETL.
Такой подход позволяет выполнять запросы Gremlin или Cypher по Parquet и другим форматам с низкой задержкой и значительно меньшими затратами. Успех Wiz — это не просто сценарий выбора между двумя компаниями, а урок о важности архитектуры данных и зрелости технологического выбора. Приняв вызов и сделав ставку на технологии, ориентированные на развитие продукта и скорость инноваций, можно одержать верх над конкурентами, даже если старт был позже и бюджет ниже. Для специалистов и компаний, строящих решения на основе графовых структур, это история вдохновения, демонстрирующая, насколько критично правильно выбрать основу для своей инфраструктуры. Разработка эффективной и удобной в сопровождении системы с высокой скоростью итераций зачастую ценнее, чем минимизация издержек хранения или единовременная оптимизация продуктов.
