cloud-native cassandraforward

Можно ли игнорировать отказоустойчивость при создании облачных приложений?

7 марта 2023 г.

Самар Аббас из Temporal считает, что разработчикам не следует даже думать о потере состояния. Есть только такие долговечные казни, которые никогда не подведут.

Если вы долгое время использовали текстовые редакторы, вы помните рефлекторное действие нажатия клавиши «Сохранить» — страх потерять свою работу, ругаться вслух и оплакивать потрясающую работу, которую вы только что потеряли.

С современными инструментами (вспомните Google Docs) эта проблема даже не возникает. В середине слова отключается питание? Без проблем. Все сохраняется в том состоянии, в котором вы его оставили, и вы можете двигаться дальше.

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

Temporal была основана в 2019 году Аббасом и его коллегой Максимом Фатеевым, когда они работали в Uber. Они создали платформу разработки для компании по заказу автомобилей под названием «Cadence». Это эволюция платформы AWS Simple Workflow Service, которую этот дуэт помог разработать, когда они были коллегами в Amazon в середине 2000-х. Десятки сервисов и приложений Uber используют Cadence.

Аббас и Фатеев ушли, чтобы стать соучредителями Temporal и построить отказоустойчивый движок рабочего процесса, преемник Cadence. За прошедшие три года компания добилась солидного успеха: такие компании, как Netflix, Instacart и другие, использовали программный код Temporal с открытым исходным кодом. Ранее в этом году компания провела раунд раунда B на сумму 103 млн долларов, в результате чего ее оценка составила 1,5 млрд долларов.

Недавно у меня был разговор с Аббасом (вы можете посмотреть все здесь) о том, как он и Фатеев построили свое невероятно успешное предприятие. (Его слова ниже отредактированы для ясности и длины).

От Uber к Temporal

В 2015 году компания Uber открыла офис в Сиэтле, и я присоединился к их инженерной команде. Мы с Максом [сооснователь Temporal Максим Фатеев] оказались в Uber с разницей в месяц. Ключевым проектом, над которым мы работали вместе, был Cadence.

В Uber инженеры потратили много времени на объединение низкоуровневых очередей, баз данных и надежные таймеры для обеспечения отказоустойчивости своих приложений.

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

Это было успешно в Uber, и, поскольку это был открытый исходный код, мы начали наблюдать широкое распространение этой технологии за рубежом. Итак, в 2019 году мы с Максом решили сделать рывок и запустили Temporal, потому что действительно хотели сосредоточиться на внедрении технологии за рубежом.

Временный опыт разработчиков

Люди иногда описывают Temporal как механизм рабочего процесса или описывают его функции, но для нас главное ценное предложение — продуктивность разработчиков: насколько быстро разработчики могут создавать приложения и запускать их в рабочей среде, не тратя недели или месяцы на тестирование всевозможных сбоев. ситуации, которые могут возникнуть в облачной среде.

То, как мы думаем об опыте разработчиков, — это не только основные аспекты того, что может предложить технология; мы охватываем весь жизненный цикл разработки программного обеспечения с самого начала, как разработчики создают свое приложение. Например, многие механизмы рабочих процессов обычно используют маршрут предметно-ориентированного языка (DSL). Мы все основаны на коде. Мы знаем, что разработчики любят писать код, и мы хотим, чтобы они писали код, но просто уберите определенный класс проблем, например, как сделать этот код устойчивым, если какая-то базовая инфраструктура выходит из строя, или как сделать код устойчивым, когда происходит сбой сети. .

Когда и как временное значение имеет значение?

Денежные переводы – один из ключевых вариантов использования Temporal. Если вы переводите деньги с одного счета на другой, как правило, с точки зрения пользователя, да, я дебетую со счета А, а затем зачисляю на счет Б. Но большая часть времени разработки программного обеспечения тратится на системные сбои между этими двумя вызовами. Именно на это в основном инженеры тратят все свое время.

Это пример того, когда такая система, как Temporal, может очень помочь — она даже кажется волшебной. Мы часто слышим этот вопрос: что произойдет, если мое приложение перестанет работать на этом этапе?

Наш ответ на этот вопрос таков: рабочие процессы никогда не дают сбоев (в Temporal мы называем примитив, который мы создаем, «рабочим процессом»). Это один из тех моментов, когда загорается выключатель. Мы начали называть это «долговечным исполнением», где на высоком уровне мы обеспечиваем следующее: ваши исполнения полностью долговечны. Они никогда не подведут.

Влияние на бизнес рабочего процесса с отслеживанием состояния «Fault Oblivious»

В 90-х годах, когда я учился в школе, мы печатали все наши задания в Microsoft Word. Вы привыкли сохранять свой документ каждый раз, когда вносили несколько правок. Тем не менее, был определенный класс сбоев, например отказ жесткого диска, из-за которого вы потеряли всю свою работу.

Теперь, с Google Docs, дети даже не могут понять это. Даже кнопки «сохранить» больше нет. Мы считаем, что существует класс приложений с отслеживанием состояния, которые все еще существуют в эпоху 1990-х годов, где более 80% кода посвящено обработке сбоев инфраструктуры для обеспечения отказоустойчивости приложений с отслеживанием состояния. Каждый раз, когда происходит событие, вы загружаете это состояние, применяете это событие, выполняете ряд действий, а затем сохраняете это состояние обратно. Это то, к чему стремится большинство инженеров: как сделать это надежным, быстрым и производительным и защитить его от всех видов сбоев и повреждений.

Разработчики не должны даже думать, что они могут потерять свое состояние. Есть только эти долговечные казни, которые никогда не подведут. И я думаю, что это полностью изменит отношение инженеров к облачным системам.

Зачем использовать управляемый Apache Cassandra?

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

У нас есть подключаемая модель постоянства; мы поддерживаем Apache Cassandra, MySQL и Postgres в качестве подключаемых адаптеров. Cassandra — один из адаптеров с очень хорошими характеристиками масштабируемости. Ключевым преимуществом для наших пользователей является тот факт, что они используют критически важные приложения< /a>, и главное, что они ищут, это надежность. Поэтому мы не относимся к этому легкомысленно, когда вносим новую зависимость во временную складку. Мы потратили месяц на оценку всех вариантов сохранения. Это была DataStax Astra DB безоговорочно.

Одни базы данных выигрывают по одним характеристикам, другие — по другим. Но в данном случае дело было даже не в технологии; это про людей. Мы считаем, что ошибки и неудачи являются частью жизни. Все дело в том, как вы реагируете, когда происходит сбой. И здесь мы считаем, что Astra DB побеждает. Существует так много общего с тем, как DataStax обращается со своими клиентами, и с теми отношениями, которые они строят, когда дело доходит до операционализации их баз данных. И это вселило в нас уверенность в том, что мы хотим инвестировать в эту зависимость как в основную часть системы.

Я не думаю, что мы были бы в том положении, в котором находимся сегодня, если бы у нас не было такой технологии, как Astra, которую мы могли бы использовать и развивать. Такие вещи, как просто ввод в действие Cassandra и «доведение до конца» вещей в одиночку, будут как минимум годичным проектом, и это даже не является частью нашей основной силы. Для такой компании, как мы, где ключевым преимуществом является надежность, если мы не можем найти способ надежно управлять и эксплуатировать ваше хранилище, у нас нет бизнеса.

Зарегистрируйтесь сейчас для Cassandra Forward: бесплатное двухчасовое виртуальное мероприятие, которое состоится 14 марта, посвящено всем аспектам Apache Cassandra.

Патрик Макфадин, DataStax