Есть несколько подзабытое понятие SOHO (small office, home office – малый офис, домашний офис – МОДО, если изволите по-русски).

Его развитие подстегнуло еще 2 явления:

  • развитие удаленки после ковида
  • развитие self hosting – кода люди отказываются от публичных облаков и переходят на приложения, запущенные дома (тут же моя серия заметок “Домашнее облако”)

Отмечу, что стартапы на ранних стадиях (понятно, тут мы не говорим о сотнях людей) так же походят под определение SOHO.

Для простоты технического обсуждения SOHO-решение – это решение над которым работают до 20 человек и базы данных которого помещаются на один физический сервер (пусть и большой). Не принципиально на сколько человек рассчитано само решение.

Давно известен “закон” Мелвина Конвея:

Организации, проектирующие системы, ограничены дизайном, который копирует структуру коммуникации в этой организации.

Можно переформулировать как-то так: структура организации существенно влияет на архитектуру приложения.

И добавить про размер: размер организации существенно влияет на архитектуру приложения.

И тогда у нас есть очевидное, но иногда невероятное следствие: используемые технологии должны зависеть от размера организации.

Другими словами, то, что хорошо Гуглу вовсе не факт, что будет хорошо вам.

Давайте рассмотрим на примере Kubernetes. Технология позволяет автоматизировать развертывание приложений, переложить больше обслуживания с команды конкретного приложения на отдел админов (например, если раньше у каждой достаточно большой системы был свой мониторинг и базы, то теперь это предоставляет отдел девопсов через K8s). Но подходит ли Kubernetes для дома? Нет:

  • для дома достаточно 2-х машин, минимальная 3-я лишняя
  • слишком большие накладные расходы – даже чистый Kubernetes постоянно всякое спрашивает у всех своих абстракций – а дома при отсутствии активности приложение по идее ничего не должно делать

Поэтому для SOHO (и стартапов) я обычно предлагаю “развертывание через Podman”.

Аналогично и с базами данных: Cassandra и Mongo обычно не нужны в SOHO. Тут лучше подходят Postgres и SQLite (как бы на первый взгляд это не звучало).

Мысли этой заметки перекликаются с Вы – не Гугл, то там автор большую часть текста хочет вывести на эмоции.

У меня сформировались такие основные требования для SOHO-систем:

  • простота эксплуатации
    • никакого постоянного анализа логов и метрик отдельной командой
    • автоматическое восстановление после сбоев
    • и легкая переустановка с восстановлением данных из бекапа, если все пошло не так
    • удаленное управление (мобильное приложение и/или веб, без Linux-консолей)
  • низкое энергопотребление
  • тишина, а может вообще выключение, если сейчас приложения на машине не нужны
  • быстрая загрузка системы, чтобы долго не ждать, когда понадобится
  • адекватные требования по железу aka хорошее масштабирование вниз (например, Kafka требует слишком много для маленькой HA-инсталяции на 2 ноды)