00:00:07 Событийное хранение и его преимущества по сравнению с традиционными реляционными базами данных.
00:00:31 Событийное хранение и его основная концепция.
00:01:52 Взлет реляционных баз данных и CRUD-приложений в 70‑х годах.
00:04:29 Ограничения и допущения, введенные системами на основе CRUD.
00:06:10 Преимущества событийного хранения при исправлении ошибок и обслуживании системы.
00:08:00 Разочарование от работы с изменяемыми системами и квантовыми ошибками в разработке программного обеспечения.
00:09:02 Событийное хранение как решение проблем цепочек поставок и его связь с дешёвым хранением данных.
00:12:38 Применение событийного хранения в крупных компаниях и его преимущества для прозрачности и эффективности.
00:14:36 Событийное хранение как альтернативная перспектива по сравнению с грубой методологией проектирования ПО для цепочек поставок.
00:15:37 Будущая преобладаемость событийного хранения и потенциальные барьеры для его широкого внедрения.
00:17:18 Сравнение принципов событийного хранения с принципами бухгалтерского учёта и их значение.
00:19:22 Необходимость ориентироваться на данные в управлении цепочками поставок.
00:20:25 Спекуляции о будущем росте Amazon и возможных ограничениях.
00:21:07 Заключение и итоговые замечания.
Резюме
В интервью с Жоанне Верморелем, основателем Lokad, ведущий Киран Чендлер исследует концепцию событийного хранения и его преимущества в управлении цепями поставок. Событийное хранение заключается в представлении состояния компьютерной системы в виде последовательности событий, что обеспечивает более прозрачный и неизменный взгляд на прошлые события, облегчая их воспроизведение и устранение проблем. Верморель отмечает, что популярность модели CRUD, позволяющей пользователям создавать, читать, обновлять и удалять данные, порой затрудняет осознание потенциальных преимуществ событийного хранения. Однако он считает, что по мере удешевления хранения данных событийное хранение станет более распространённым, чему будет способствовать рост технологически ориентированных компаний, таких как Amazon.
Расширенное резюме
В этом интервью ведущий Киран Чендлер и Жоанне Верморель, основатель Lokad, обсуждают концепцию событийного хранения и его растущую популярность по сравнению с традиционными реляционными базами данных. Событийное хранение – это подход, при котором состояние компьютерной системы представляет собой лишь отражение серии событий, исходя из предположения, что данных нет в прямом виде, кроме самих событий. Например, в программном обеспечении для управления запасами нет конкретного уровня запасов, а лишь поток движений товаров, который при консолидации дает синтетическое число, отражающее текущий уровень запасов.
В 1970‑х годах были сделаны выборы относительно того, как электронно представлять данные компании. Реляционная модель стала популярной, и сейчас большинство ПО для цепей поставок относится к категории CRUD‑приложений (создание, чтение, обновление, удаление). Приложения CRUD основаны на таблицах с полями, позволяющими пользователям добавлять, читать, изменять или удалять строки в таблице. Эта простая модель оказалась успешной и получила широкое распространение в различных отраслях.
Однако Верморель отмечает, что существуют альтернативные подходы к представлению данных, такие как событийное хранение. Он предполагает, что популярность CRUD порой затрудняет признание потенциальных преимуществ других методов. Одно из существенных различий между CRUD и событийным хранением заключается в концепции изменяемости: в CRUD прошлое изменяемо, что может быть озадачивающим с философской точки зрения. В отличие от этого, событийное хранение предоставляет более прозрачный взгляд на прошлые события и изменения в системе.
Обсуждение подчеркивает растущий интерес к событийному хранению как альтернативе традиционным реляционным базам данных для управления цепочками поставок и других приложений. Хотя CRUD получил широкое распространение, это не всегда лучший подход, и изучение альтернативных методов представления данных, таких как событийное хранение, может обеспечить лучшую ясность и понимание прошлых событий.
Верморель объясняет, что подавляющее большинство программных систем, используемых для управления цепями поставок, таких как ERP-системы и MRP, построены на основе изменяемого прошлого, что может приводить к сложным и нелогичным ситуациям. Однако он предлагает, что лучшим подходом было бы рассматривать прошлое как неизменное, поскольку это помогает избежать подобных проблем.
Одним из значительных преимуществ использования событийного хранения, по словам Вермореля, является его полезность при устранении ошибок. Он отмечает, что крупные программные системы для цепей поставок часто содержат множество ошибок и нежелательных особенностей, которые могут сохраняться годами и вызывать разочарование. При событийном хранении вся информация в системе представлена в виде последовательности событий. При отладке инженеры могут просто воспроизвести события одно за другим, чтобы точно восстановить ситуацию, приведшую к проблеме, и устранить её.
Верморель противопоставляет это альтернативной ситуации, когда состояние системы является изменяемым, что затрудняет воспроизведение и устранение проблем IT-командами. Это может привести к разочаровывающему циклу сообщений об ошибках и попыток их устранения, при котором ошибки часто вновь появляются спустя короткое время. Событийное хранение, напротив, обеспечивает детерминированный способ регенерации и исправления проблем.
Далее обсуждение переходит к подробному рассмотрению концепции событийного хранения, при которой Верморель объясняет, что рассматриваются все операции, происходящие в цепи поставок. Он предполагает, что можно задаться вопросом, почему событийное хранение не является стандартным подходом, ведь оно соответствует методу, который на протяжении веков использовали бухгалтеры. Бухгалтерские книги, как правило, неизменны, и новые транзакции добавляются для исправления прошлых ошибок, а не для переписывания старых записей.
Верморель объясняет, что событийное хранение не стало стандартным подходом из-за высокой стоимости компьютерного хранилища в конце 1970‑х и начале 1980‑х годов. Чтобы сэкономить на затратах на хранение, программные системы разрабатывались с перезаписью прошлых данных обновлёнными итогами. Однако он отмечает, что с тех пор хранение данных стало намного дешевле, что делает внедрение событийного хранения в качестве стандартной практики более реализуемым.
Когда его спрашивали, должны ли малые компании интересоваться событийным хранением, Верморель отвечает, что это философский взгляд на прошлое, основанный на идее, что прошлое должно оставаться неизменным в компьютерных системах. Хотя большинство ERP-систем не используют событийное хранение, Верморель считает, что внедрение этого подхода может помочь предотвратить проблемы, связанные с изменяемостью прошлого в программном обеспечении для управления цепями поставок.
В итоге Жоанне Верморель выступает за использование событийного хранения в оптимизации цепей поставок, подчеркивая его преимущества в устранении ошибок и соответствие неизменной природе прошлого. Хотя событийное хранение пока не получило широкого распространения, оно обеспечивает более детерминированный способ решения проблем в программных системах для цепей поставок и может быть интересно компаниям любого размера.
Они исследуют преимущества этого подхода, его принятие технологическими лидерами и потенциальное будущее распространение на рынке.
Событийное хранение – это метод проектирования программного обеспечения, при котором состояние системы сохраняется в виде последовательности событий, а не посредством более традиционной методологии Create, Read, Update, Delete (CRUD). Верморель отмечает, что технологические лидеры, такие как Amazon, Zalando и Alibaba, приняли событийное хранение для своих систем цепей поставок, при этом Amazon является основным двигателем его внедрения на рынке.
Верморель утверждает, что событийное хранение предлагает несколько преимуществ для управления цепями поставок. Во-первых, оно обеспечивает большую прозрачность и эффективность, сокращая издержки и повышая оперативность. Во-вторых, оно подчеркивает ограничения модели CRUD, на которую сильно повлияли экономические рамки, актуальные только в 70‑х и 80‑х годах.
Смотря в будущее, Верморель считает, что событийное хранение станет более распространённым по мере удешевления хранения данных и продолжения роста технологически ориентированных компаний. Он подчеркивает, что принятие на рынке определяется процессом «большого фильтра», в ходе которого компании, использующие менее эффективные методы, выходят из бизнеса, а те, кто применяет более успешные подходы, процветают.
Верморель также подчеркивает важность событийного хранения для компаний с собственными программными системами. Даже если они не внедряют событийное хранение напрямую, понимание его принципов может помочь им смягчить проблемы изменяемости в их существующих CRUD‑системах. Он утверждает, что событийное хранение следует рассматривать как краеугольный камень практики управления цепями поставок, подобно концепции незаписываемой книги в бухгалтерском учёте.
Поскольку специалисты по управлению цепями поставок вынуждены опираться на данные, Верморель считает, что им необходимо иметь руководящие принципы для сбора, организации и обработки данных. Он предлагает, что изучение событийного хранения может помочь практикам выявить и устранить многие фундаментальные проблемы в их организациях.
Верморель предвидит будущее, в котором событийное хранение продолжит завоевывать долю рынка, чему будет способствовать рост технологически ориентированных компаний, таких как Amazon. Однако он признает, что эффект масштаба в конечном итоге может ограничить доминирование этих компаний, открывая возможность для более разнообразных подходов к управлению цепями поставок.
Полная расшифровка
Kieran Chandler: Итак, сегодня мы постараемся разобраться, как это работает, и обсудим, как это может обеспечить лучшую ясность в том, что произошло в прошлом. Итак, Жоанне, что же такое событийное хранение?
Joannes Vermorel: Событийное хранение, технически, — это идея о том, что состояние вашей компьютерной системы является лишь отражением серии событий. То, что вы видите в системе, или все, что она делает, основывается на событиях. У вас есть только события, и если на экране отображается какая-либо суммарная информация или другие данные, это является прямым результатом серии событий. Чтобы сделать это более конкретным, представьте, что если в вашем программном обеспечении для управления запасами отображается уровень запасов, то понятие «уровень запасов» в программе отсутствует. Всё, что у вас есть, — это поток движений запасов, где фиксируются поступления и отгрузки, и при объединении всех этих событий вы получаете синтетическое число, представляющее текущий уровень запасов. Но суть событийного хранения состоит в том, что система не содержит ничего, кроме событий, когда речь идет о прошлом.
Kieran Chandler: Где же применяются эти методы событийного хранения? Часто ли мы видим их на рынке?
Joannes Vermorel: В 70‑х годах были сделаны выборы относительно того, каким образом лучше всего представлять данные компании в целом и её прошлое в частности. Это может звучать весьма философски, но на самом деле вопрос довольно широкий. Когда вы хотите цифровизировать свою компанию, вам необходимо электронное представление как компании, так и её прошлого. Даже если это недавнее прошлое, оно всё равно остаётся прошлым. По сути, вы стремитесь получить отражение прошлого, и оказалось, что существует множество способов сделать это. Некоторые из этих способов стали невероятно популярными в конце 70‑х и сохраняли свою популярность на протяжении нескольких десятилетий. Но это не единственный способ взглянуть на вещи. Очень интересно, что когда некий способ выполнения дел становится чрезвычайно популярным, он может вырасти до такой степени, что со временем вы даже не осознаёте, что можно поступать совсем иначе.
Так получилось, что выиграла реляционная модель, и вместе с ней появились приложения, построенные на её основе. По сути, подавляющее большинство программ для цепей поставок сегодня относится к категории так называемых CRUD‑приложений. CRUD — это аббревиатура, означающая Create, Read, Update, Delete (создание, чтение, обновление, удаление). Идея заключается в том, что у вас есть таблицы, каждая с определёнными полями, и ваше программное обеспечение позволяет добавлять строку (то есть создавать), читать существующую строку, изменять (обновлять) её и удалять. Эта модель очень проста, если задуматься, и эти четыре операции, CRUD, захватили мир цепей поставок, позволяя отразить практически всё. Она оказалась очень успешной, очень популярной, но это не тот же подход. И что интересно, существуют и другие альтернативные методы, и событийное хранение является одним из них.
Kieran Chandler: Давайте рассмотрим популярность этого CRUD‑подхода. Привёл ли он какие-либо ограничения или допущения, с которыми мы теперь привыкли работать?
Joannes Vermorel: Да, это действительно привело к тому, что
Kieran Chandler: То, что кажется весьма озадачивающим, если подумать, почти с философской точки зрения, заключается в том, что прошлое изменяемо. То есть, если вы вспомните свой повседневный опыт, то произошедшее в прошлом нельзя изменить, верно? Так оно и есть. И всё же в компьютерных системах, современных корпоративных системах, таких как ERP, MRP и других сложных программных систем, управляющих компаниями и их цепями поставок, подавляющее большинство из них построены на примитивном принципе, согласно которому прошлое полностью изменяемо. Если задуматься, это приводит к самым разнообразным странным ситуациям, являющимся лишь следствием изменяемости прошлого, и может создавать искривлённое представление о системах. Это порождает массу сложности и в целом противоречит тому, что вы интуитивно ожидаете от системы.
Joannes Vermorel: Да, есть одно преимущество событийного источника, которое на самом деле очень значимо и невероятно банально: исправление ошибок. В больших программных системах для управления цепочками поставок присутствуют ошибки, нежелательные функции повсюду, и обычно это продолжается буквально десятилетиями. Тысячи тикетов остаются открытыми и передаются в IT, и большинство из них так и не исправляются. Это чертовски раздражает. Событийное хранение действительно имеет много общего с исправлением ошибок. В Lokad мы используем событийное хранение уже десять лет, и это очень интересно. Когда вы сталкиваетесь с ошибкой в системе, основанной на событиях, вся информация представлена в виде последовательности событий. Поэтому, когда вам нужно что-то отладить, достаточно воспроизвести события одно за другим. Благодаря тому, что единственными данными в вашей системе является этот поток событий, вы можете в точности воспроизвести ту же ситуацию, которая вызвала проблему, и исправить её.
Давайте сравним это с альтернативной ситуацией, когда всё состояние вашей системы изменяемо. Проблема в том, что к тому времени, когда вы сталкиваетесь с проблемой, например, с сбоем в уровне запасов, запасы постоянно меняются. Когда IT-команда пытается разобраться, проблема уже исчезает. Вы не можете её воспроизвести и не можете исправить. Это чрезвычайно раздражает программиста, работающего с системой, которая крайне изменчива. Большинство ошибок оказываются подобны квантовым: ошибка существует, но как только вы на неё смотрите, она исчезает. Затем, когда вы перестаете за ней наблюдать, она возвращается. Это так раздражает.
Событийное хранение в этом отношении очень интересно, потому что оно предоставляет полностью детерминированный способ воссоздания этих проблем и их окончательного исправления. Если рассматривать проблемы цепочки поставок в целом, даже если программное обеспечение не решит все проблемы, оказывается, что на самом деле…
Kieran Chandler: Программное обеспечение зачастую порождает первую долю проблем, с которыми сталкиваются современные цепочки поставок. Ладно, давайте вернемся назад и рассмотрим более подробно событийное хранение — идею записи каждой обыденной операции, произошедшей в цепочке поставок. Это может показаться немного скучным. Насколько же легко вернуться назад, проверить, что произошло, и выявить коренную причину проблемы?
Joannes Vermorel: Почему по умолчанию нельзя просто записывать события по мере их поступления и говорить: «Вот и прошлое»? Если посмотреть на то, что люди делали веками, например, бухгалтеры ведут книги учета. Книги учета обычно обладают неизменностью. Вы только добавляете записи в книгу. Если вы совершаете ошибку в транзакции, вы не удаляете предыдущую запись. Вы просто добавляете новую транзакцию, которая говорит, что предыдущая транзакция была неверной, и предоставляет корректировку — и так всё и происходит. Таким образом, вы не переписываете прошлое, а лишь добавляете новые записи в конец.
Но в конце 70-х годов компьютерное хранилище стоило невероятно дорого, и поэтому идея неизменности прошлого была довольно привлекательной, если ресурсы были крайне ограничены. Если у вашего бухгалтера в книге всего 10 страниц, и когда место заканчивается, всё, что у вас есть — это ластик. Тогда вы пытаетесь подвести итоги по вашим записям, добавить несколько транзакций, и когда место заканчивается, вы просто стираете старую транзакцию, обновляете итоги — и всё. Именно это и происходило в конце 70-х и в начале 80-х годов. Весь мир программного обеспечения пошёл по пути, который имел смысл из-за того, что хранение данных тогда было невероятно дорогим.
Перенесёмся на 40 лет вперёд, и хранение данных стало безумно дешевым. Вы можете купить жесткий диск объемом один терабайт за пятьдесят долларов. Это просто безумно дёшево. Так что, если вы хотите иметь сверхнадежное хранилище данных, вам потребуются множественные копии и система для управления ими, но стоимость ниже 1 доллара за гигабайт, и данные действительно очень, очень дешевые.
Событийное хранение по сути является базовой архитектурой целой ERP-системы. Эти темы действительно представляют интерес для крупных транснациональных корпораций и таких гигантов, как SAP. Должны ли мелкие компании реально интересоваться чем-то подобным?
Kieran Chandler: Это интересный вопрос. Должны ли мелкие компании интересоваться событийным хранением?
Joannes Vermorel: Я считаю, что событийное хранение — это философская перспектива на прошлое, согласно которой прошлое неизменно, и информационные системы должны это отражать, иначе вы получите неоптимальные решения. Подавляющее большинство ERP-систем не используют событийное хранение, вот в чем первая загвоздка. Большинство ERP-систем в основном его не внедряют. Если посмотреть, кто использует событийное хранение, то это технологические лидеры, которые обычно не создают программное обеспечение для управления цепочками поставок, за исключением, возможно, Amazon, Zalando и Alibaba — компаний, которые управляют собственной цепочкой поставок с помощью своего индивидуального софта.
С точки зрения преимуществ, многие компании стремятся к большей прозрачности в цепочке поставок. Они хотят быть более эффективными, менее расточительными, более бережливыми, быстрее реагировать, и они сталкиваются с массой проблем в своих IT-системах.
Kieran Chandler: Хотя это проблемы довольно расплывчатые, и единого решения не существует, я считаю, что событийное хранение очень интересно, потому что оно указывает на определённый недостаток, скажем так, чрезмерно распространенного способа проектирования программного обеспечения для решения задач цепочки поставок. Обычно большинство практиков даже не осознают, что существуют альтернативные подходы. Поэтому я считаю, что событийное хранение интересно не столько потому, что является окончательным решением этих проблем, сколько потому, что само его существование доказывает: на самом деле методология CRUD — Create, Read, Update, Delete — которая используется для построения программных систем для цепочек поставок, не является конечной целью. Это лишь один из способов, и этот шаблон проектирования был сильно обусловлен экономическими ограничениями, актуальными только в 70-х и 80-х годах, и уже к концу 90-х его значимость снизилась. Так что теперь, заглядывая в будущее, когда хранение данных невероятно дешево, мы как бы преодолели эти барьеры. Видите ли вы, что событийное хранение станет более распространенным на рынке в ближайшие пару десятилетий и остаются ли какие-то барьеры, которые нам еще предстоит преодолеть?
Joannes Vermorel: Во-первых, событийное хранение становится более распространенным просто потому, что Amazon становится всё больше. Также, каждый раз, когда Amazon захватывает еще один процент доли рынка, событийное хранение становится на один процент более популярным на рынке. И когда я говорю Amazon, я имею в виду все остальные технологичные компании, которые буквально поглощают рынок. Так что да, оно однозначно становится более распространенным. Рынок — отличный фильтр, он не учитель, поэтому вещи становятся популярными не потому, что их выбирают, а потому что компании, которые ими не пользуются, обанкрочиваются и исчезают, а оставшиеся непременно используют то, что действительно работает. Так что, может ли это стать более популярным? Я бы сказал, безусловно. И когда я смотрю на клиентскую базу Lokad, примерно четверть или пятая часть наших клиентов имеют индивидуальные, внутренние программные системы для управления компанией. Так что если у вас есть собственная система, я настоятельно рекомендую обратить внимание на событийное хранение. Даже если вы не перейдете сразу на событийное хранение, потому что это полное изменение парадигмы в проектировании вашего ПО, все равно есть много чему научиться. А если вы хорошо знакомы с событийным хранением, это позволит вам всё равно применять CRUD — обычный способ управления цепочками поставок.
Kieran Chandler: Современное программное обеспечение может использоваться так, чтобы нивелировать проблемы изменчивости прошлого. Если вы очень внимательно относитесь к его проектированию, вы можете фактически изменить прошлое в своем коде и добиться чего-то, что гораздо ближе к событиям. Вам не обязательно переписывать всё, чтобы приблизиться к этому. Я бы сказал, что это не только проблема IT. Некоторые могут отвергать это как нечто исключительно для гиков, интересное лишь архитекторам баз данных, но я думаю, что это нечто большее.
Joannes Vermorel: Согласен, такие высокоуровневые концепции должны быть краеугольными камнями практики управления цепочками поставок. Так же как тот факт, что книгу учета нельзя переписывать, является основополагающим принципом бухгалтерии. В бухгалтерии известно, что не следует возвращаться к записям прошедших лет и переписывать транзакции. Никто не станет говорить, что эта особенность книг — всего лишь деталь программного обеспечения. Эти принципы были установлены ещё до появления компьютеров.
Если учитывать, что работа специалиста по цепочке поставок связана с обработкой огромного объёма данных, то трудно воспринять реальность цепочек поставок, поскольку они обширны, сложны и распределены по множеству объектов. По замыслу, будучи специалистом по цепочке поставок, вы не можете увидеть все собственными глазами. Вы можете увидеть магазин, склад, но не можете быть повсюду. Таким образом, вы вынуждены полагаться на данные. Всё, что вы знаете о своей цепочке поставок, — это, по сути, цифры, полученные из множества систем.
Я считаю, что, как и бухгалтер, вам нужно иметь определенные руководящие принципы относительно того, как эти данные собираются, организуются и обрабатываются. Возвращаясь к событийному хранению, я думаю, что это стоит того, чтобы специалисты по цепочке поставок всерьез на это взглянули, поскольку это поможет им выявить массу скрытых проблем в их организациях.
Kieran Chandler: Великолепно. Ну, если мы будем ждать Amazon, они рано или поздно захватят еще один процент и приблизятся к 100%. В какой-то момент такие крупные компании, как Amazon, могут рухнуть под собственной тяжестью из-за сложности становления абсолютно гигантами. Это помешает им захватить 100% доли рынка, но проблема в том, что оставшуюся часть рынка захватят другие конкуренты, подобные Amazon.
Joannes Vermorel: Да, следите за новостями.
Kieran Chandler: Это всё на эту неделю. Огромное спасибо, что подключились, и до встречи в следующий раз. Пока.
