Architecture

Существует момент, который переживает каждый основатель. Вы только что закрыли первый раунд финансирования, ваш продукт набирает обороты, и кто-то в канале Slack упоминает, что вам «вероятно, стоит задуматься о Kubernetes». Ваш CTO задумчиво кивает. Все начинают искать учебники по Kubernetes в полночь. К следующему утру вы убеждаете себя, что Kubernetes — неизбежная часть вашего пути к статусу единорога с миллиардной оценкой. Вот неудобная правда: вы, вероятно, совершаете ужасную ошибку. Я здесь не для того, чтобы критиковать Kubernetes....

Нам десятилетиями внушали: пишите портативный код, избегайте привязки к поставщику, держите свои возможности открытыми. Это как если бы вам говорили никогда не сжигать мосты или всегда оставлять себе путь к отступлению. Разумный совет, безусловно. Но что, если я скажу вам, что иногда лучший мост, который нужно сжечь, — это тот, который вам вообще не нужно было строить? Вот неудобная правда, которую никто в докладе на конференции не хочет признать: стремление к абсолютной портабельности часто является формой преждевременной оптимизации, которая маскируется под архитектурную мудрость....

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

Представьте: вы находитесь в кофейне, потягиваете переплатить за латте, и вдруг слышите, как два разработчика спорят о том, стоит ли создавать своё новое блестящее приложение с помощью React Native или же выбрать нативное развитие. Один разработчик драматично размахивает руками, крича: «Переиспользование кода!», а другой возражает: «Производительность и пользовательский опыт!». Знакомо? Что ж, возьмите ещё кофе, потому что мы собираемся глубоко погрузиться в вопрос о том, когда вам следует безоговорочно выбрать нативное развитие вместо кроссплатформенных решений....

Представьте: вы находитесь на технологической конференции, и каждый третий спикер восхваляет бессерверные вычисления, как будто это святой грааль современной разработки. «Нет необходимости управлять серверами!» — кричат они. «Бесконечное масштабирование!» — обещают они. «Платите только за то, что используете!» — скандируют они в унисон. Но вот в чём дело — и я говорю это как человек, который развернул множество функций Lambda и Azure Functions в продакшене — бессерверные вычисления не всегда являются решением, и рассматривать их как универсальную панацею — это путь к архитектурным проблемам....