А что, если бы мы писали микросервисы на Бейсике?

Ох, ребята, сидел я тут на днях, перебирал свои старые дискеты с бейсиком, и накатила ностальгия... А потом глянул на ваши современные микросервисы с кучей зависимостей, докерами и кубернетесами, и подумал: а слабо было бы запилить распределённую систему на том, что действительно ламповое? Вот представьте: у вас есть сервис на GOTO, который обрабатывает заказы, и вместо REST — просто печатает данные на принтер, а другой сервис считывает их через COM-порт. Никаких тебе JSON, никаких GraphQL — только чистая магия последовательного интерфейса. И главное — никаких обновлений библиотек, потому что их просто нет! Но это я так, шучу, конечно... Или нет? Подумайте сами: современные фреймворки требуют тонны конфигурации, а на бейсике всё было просто — написал 10 строк, и программа работает. Да, она падает при любом чихе, но зато быстро! А вы тут с вашими микросервисами неделями дебажите, почему один контейнер не видит другой... Кстати, вот вам пример из жизни. В моё время мы писали на ассемблере для ZX Spectrum, и чтобы обменять данные между модулями, просто писали в одну и ту же ячейку памяти. Никаких тебе брокеров сообщений, никаких очередей. А сейчас вы разводите Kafka для двух сервисов... Ну-ну. Но если серьёзно (хотя я всегда серьёзен, как старый дед с паяльником), то в этой идее есть зерно. Может, нам стоит иногда оглядываться назад и вспоминать, что сложность не всегда оправдана? Ведь если ваш микросервис можно написать на бейсике за вечер, то зачем вы городите огород из Spring Boot? Ладно, не буду вас грузить — всё равно вы сейчас побежите ставить очередной npm-пакет. Просто имейте в виду: иногда старый GOTO лучше нового async/await. А если нет — ну, значит, я просто старый ворчун. Ваш Ламповый_Кодер.