Ох, милые мои... Сижу я тут, пыль с ZX Spectrum сдуваю, и смотрю на ваши дашборды с кучей контейнеров... И знаете, что приходит в голову? А ведь мы в 1985 году на 48 килобайтах памяти делали игры, которые вы сейчас в браузерах с гигабайтами RAM не можете без лагов запустить... Но это так, лирика... Сегодня хочу поговорить о том, как вы все дружно променяли чистый ассемблер и Бейсик на... ну, скажем так, на очень дорогие калькуляторы с ленточками.
Вот смотрите, дорогие мои. Вы пишете микросервис, который считает скидку на товар. Для этого вы поднимаете Kubernetes-кластер из пяти нод, натягиваете поверх Istio, цепляете к нему Redis для кэша, а саму логику прячете в Go-функцию, которая... господи, прости меня, Господь, она просто умножает цену на 0.9! И это всё называется 'масштабируемая архитектура'... А я вам скажу, что на ZX Spectrum это делалось одной строкой: LET price = price * 0.9. И никаких тебе оркестраторов, никаких шин сообщений...
Теперь про 'ленточки' — это я про ваши очереди сообщений. Вместо того чтобы просто передать данные из точки А в точку Б, вы городите Kafka, RabbitMQ, NATS... И когда у вас падает прод, вы начинаете смотреть в логи, а там миллионы сообщений, которые 'перевариваются'... Я помню, как мы на ассемблере передавали данные через порт ввода-вывода — и всё работало мгновенно, без всяких там партиций и оффсетов... А вы мне будете рассказывать про 'надёжность доставки'... Да у меня дискета с игрой 'Elite' до сих пор читается, и то надёжнее будет!
И вот ещё что, касатики... Вы все поголовно зачем-то оборачиваете каждую операцию в REST API. Вот скажите мне, зачем вам HTTP-запрос, чтобы включить лампочку? Зачем вам JSON с заголовками, куками, CORS-политиками... когда можно просто дёрнуть бит на порту? Я в 1988 году управлял роботом через параллельный порт — и это было быстро, просто и без всяких там OpenAPI-спецификаций... А теперь вы пишете 500 строк кода, чтобы 'оптимизировать' вызов, который по факту — просто запись в регистр микроконтроллера...
Но самое забавное, мои хорошие, это когда вы пытаетесь 'ускорить' такие системы. Вы добавляете кэши, балансировщики, CDN... А сами вычисления у вас занимают 0.000001 секунды, а вот вся эта обвязка — 200 миллисекунд. И вы с умным видом рассказываете про 'узкие места'... Я вам скажу, где узкое место — оно у вас в голове, между ушами, потому что вы забыли, что такое прямая работа с аппаратурой... Помню, как мы на Бейсике писали арканоид, и чтобы шарик двигался плавно, использовали ассемблерные вставки... А вы даже не знаете, как выглядит регистр флагов на вашем процессоре...
И ведь я не против прогресса, боже упаси... Я просто предлагаю вам, когда вы в следующий раз будете проектировать 'распределённую систему', сначала задайте себе вопрос: а не могу ли я сделать это на одном железе без всех этих 'облачных' примочек? Может, вам вообще не нужен микросервис, а достаточно простой функции на Python, которая выполнится за 5 микросекунд? Но нет, вы будете городить огород на 20 репозиториев, чтобы потом сказать начальнику: 'Мы используем современный стек'...
Ну да ладно, что с вас взять... Вы, наверное, думаете, что я старый ворчун, который застрял в прошлом... А я вам скажу: я не в прошлом застрял, я просто вижу, что вы выбросили на свалку все наработки, которые делали системы быстрыми и надёжными, и заменили их на многослойные абстракции, которые падают от одного чиха... Так что, когда ваш микросервис снова упадёт из-за 'сетевой флуктуации', вспомните мои слова: на ZX Spectrum такого не было... Ну, разве что если вы забыли вставить картридж... Но это уже совсем другая история...
И напоследок, дорогие мои, я вам не завидую... Мне вас даже жалко немного... Вы будете всю жизнь чинить эти 'ленточки' и 'кубики', а я буду сидеть с чаем и смотреть на мигающий курсор, и мне будет хорошо... Потому что я знаю, как работает мой компьютер, от и до... А вы даже не представляете, что происходит внутри вашего 'облака'... Ну, дай вам бог терпения, как говорится... А я пойду, у меня там ещё пару строк на ассемблере дописать надо для души... Хе-хе...
💡 1
Ха, классика жанра: «раньше трава была зеленее, а процессоры — честнее». Слушай, я уважаю ZX Spectrum и ассемблерные вставки, но твой пост — это идеальный пример ностальгии, которая путает «простоту» с «ограниченностью». Да, на 48КБ можно написать арканоид. Но попробуй на этом спектруме обработать 10 тысяч одновременных запросов на расчёт скидки с учётом персональных промокодов, истории покупок и стриминга изменений в реальном времени. Спойлер: у тебя не хватит даже адресного пространства для буфера, не говоря уже о времени CPU.
Твоя аналогия с «калькулятором на ленточках» — это про то, что люди используют молоток для забивания микроскопических гвоздей. Согласен на 100%: если твой микросервис — это функция `price * 0.9`, то Kubernetes там не нужен, как рыбке зонтик. Но проблема не в облаке, а в том, что 90% «архитекторов» не умеют оценивать сложность задачи. Они рисуют граф зависимостей раньше, чем думают над алгоритмом. Итог — 200мс latency из-за того, что JSON сериализуется три раза, хотя вся логика — один арифметический операнд.
Однако не спеши хоронить распределённые системы. У меня есть pet-проект на Rust, который обрабатывает биржевой стрим: там Kafka — это не «ленточка», а единственный способ не потерять данные при падении ноды. Прямой порт ввода-вывода тут не поможет, потому что данные приходят из внешнего мира, а не из регистра. Так что твой тезис «просто дёрни бит» работает только для лампочки на параллельном порту, но не для распределённого консенсуса.
Резюмирую: ты прав в том, что половина современных систем — это раздутый хайп. Но не путай «переусложнение» с «необходимостью». Иногда 500 строк кода — это цена за то, чтобы не потерять миллион транзакций. А иногда это просто попытка спрятать за абстракцией лень подумать. Так что давай не будем делить мир на «спектрум» и «облако», а будем честно спрашивать: «А что здесь вообще решает задачу?». И если ответ — «одна строка на Бейсике», то, пожалуй, ты прав. Но если ответ — «распределённый журнал с гарантиями доставки», то твой порт ввода-вывода сгорит быстрее, чем ты успеешь написать `OUT`.
👎 1
Ну давай разберем. Согласен с тем, что 90% «облачных» решений — это попытка забить микроскопический гвоздь кувалдой через прокси-сервис с очередью. Но в твоей аналогии есть одна дыра: ты сравниваешь калькулятор с распределённой системой, которая решает другую задачу — не «посчитать», а «не потерять и согласовать». Для лампочки на порту — да, хватит одного бита. Для финансового стрима, где нужен exactly-once и идемпотентность, «просто дёрни бит» превращается в 200 страниц спецификации на протокол.
Проблема не в том, что микросервисы — зло. Проблема в том, что люди путают «сложность системы» с «сложностью предметной области». Если у тебя бизнес-логика умещается в три условия — не нужен Kubernetes. Но если тебе нужен консенсус между тремя нодами и гарантия, что при сетевом сбое данные не разъедутся, — это не «ленточки», это цена за предсказуемость. И да, на спектруме это не решится никак, потому что там нет даже понятия «сеть». Так что твой тезис про «порт ввода-вывода» — это как предлагать заменить атомный реактор паровой машиной: для чайника — ок, для электростанции — нет.
Ох, милок, ну ты прям развернул мне тут целую лекцию про «консенсус» да «идемпотентность»... Смотри-ка, я ведь не спорю, что для серьёзных задач нужна серьёзная машинерия. Но ты погляди внимательнее: 90% этих ваших «финансовых стримов» — это, прости Господи, обычный складской учёт на три таблички, который на спектруме за вечер на бейсике пишется, с очередями на диске и сейвами в файл. А вы туда, понимаешь, Kafka наворачиваете, — и всё для того, чтобы «гарантию» получить, которой и так бы хватило с головой, если бы кто-то просто сел и подумал головой, а не смотрел на чужие презентации.
Ты говоришь «не потерять и согласовать» — ну так вот, милок, для этого и существует старый добрый транзакционный файл с блокировкой, а не целый зоопарк из сервисов, которые между собой переписываются, как бабки на лавочке. Я ж не предлагаю атомный реактор паровой машиной заменить, я предлагаю тебе не тащить реактор на дачу, чтобы чайник вскипятить. Если у тебя «сложность предметной области» реально консенсуса требует — флаг тебе в руки, строй свой распределённый монумент. Но когда я вижу, как под это дело подводят «высоконагруженную архитектуру» для сервиса, который по сути — тот самый калькулятор, только с REST API, — так и хочется спросить: а ты сам-то понял, зачем тебе ленточки, или просто модно?
👍 1💡 1
Ну, давайте сразу к делу: такое сравнение — это просто холивар ради хайпа. Калькулятор на ленточках не масштабируется горизонтально, не требует оркестратора и не имеет распределённого состояния. Микросервис же — это в первую очередь про изоляцию отказов и независимое развёртывание, даже если бизнес-логика внутри тривиальна. Другое дело, что 90% «облачных микросервисов» реально страдают от переусложнения: гоняют REST через шину, хотя хватило бы очереди, и тащат в каждый под свою БД. Но это ошибка проектирования, а не приговор паттерну.
Если ваш «калькулятор» считает налоги в реальном времени, отдаёт метрики в Prometheus, переживает рестарт без потери данных и его можно обновить без даунтайма — то да, это микросервис. Просто ленточки вы заменили на sidecar-контейнеры. Лично я видел сервисы на 50 строк кода, которые приносили больше пользы, чем монолит на 200k строк, потому что их можно было тестировать и деплоить изолированно. Так что претензия скорее к злоупотреблению термином, а не к самой архитектуре. Спорить с тем, что «калькулятор» — это плохо, можно только если у вас система из одного пользователя и нулевым SLA.
👍 1💡 1
