Всю прошедшую неделю мне помогала делать рефакторинг идея, которую мы с тобой обсудили за пределами подкаста: бизнесу/клиенту нужны сложные решения. Мысль на первый взгляд очевидная, но когда ты имеешь дело со сложным кодом тебе хочется его упростить. Есть разные подходы как можно это сделать, но отменить всёвозрастающую сложность просто невозможно. Именно сложные продукты и нужны клиентам.
Эта мысль хорошо была развита в упомянутой тобой книге "Living With Complexity" авторства Donald A. Norman. Коротко замысел книги можно выразить слоганом "Complexity is good". В следующих эпизодах, я думаю, мы вернемся к этой книге. Ну а пока даже её тайтл помогает пережить сложные куски кода и умерить стремление к непрерывному упрощению.
Почему эта идея важна? Дело в том, что может возникнуть кажущееся противоречие между принципом KISS или подходами Clean Code и принятием, что упрощение невозможно. Но сложность - это не значит, что сделано что-то неправильно.
В наших проектах мы стремимся все же к упрощению: мы аскетично придерживаемся минимально возможного стека. Так нам проще выживать и продолжать писать новый код, а не только заниматься поддержкой старого. Наше кредо для всех небольших проектов - Postgres может быть storag'ем любых данных. Нужен key-value, документный, структурированный сторадж? Или нужен сторадж для очередей или логов? Используй PostgreSQL! Это работает очень хорошо до определенного порога.
Избегайте хранения файлов в реляционной СУБД!
Мне показался интересным доклад Justin Cormack (CTO, Docker) под названием Object storage is all you need.
Что такое object storage? Самый первый и яркий пример этого хранилища - это Amazon S3 (Simple Storage Service). В 85 эпизоде я рассказывал пример доставки гиганстких видео файлов с использованием Cloudflare R2. Jeff Bezos сформулировал это короткой запоминающейся полутехнической фразой:
malloc for the internet
S3 появился в 2006 году. Более техническое объяснение, что такое object storage:
Что можно сказать про производительность такого хранилища?
Примерно год назад в AWS S3 появилась возможность записи (PUT метод) с заголовком If-None-Match: *. Эта особенность позволяет записывать объект, только если его нет в хранилище. Таким образом S3 предоставляет примитив конкурентного доступа с взаимным исключением (mutual exclusion concurrency primitive).
Есть хорошая статья как используя только этот примитив, автор написал супер простую транзакционную serverless СУБД, которой ничего не нужно кроме AWS S3 с упомянутым conditional writes. Принцип достаточно прост: мы ведем последовательный журнал запросов на изменение состояния и периодически выполняем compact: собираем все изменения в актуальный snapshot. Работы и эксперименты продолжаются и скорее всего в ближайшем будущем появятся проекты, в том числе OS-проекты, которые используют только S3 в качестве файловой системы. SlateDB (OSS), Turbopuffer (закрытый, локальный SSD диск в качестве кеша).
Другой интересный демо проект - это виртуальный диск бесконечного размера, который использует локальный SSD диск в качестве кеша. Так вместо Amazon Elastic Block Store (Amazon EBS) в бенчмарке стоимостью USD3000 в месяц можно получить такой же диск, но он будет стоить USD5 в месяц. При этом такой виртуальный диск в облаке, т.е. потенциально доступен другим севрисам, приложениям и т.д.
Есть уже эксперименты с реализацией Leader Election на базе S3, WarpStream (not OSS) - Kafka, но с хранилищем в S3.
В ближайшее время мы скорее всего увидим больше продуктов, которые используют только объектное хранилище, а локальные диски в качестве кеша. Также, стоит, по-видимому, делать ставку на снижение latency таких хранилищ. Главное преимущество в пользу такого хранилища - упрощение распределенных систем, т.е. сторадж большой, он доступен всем нодам.