ниче подобного - JSON от тебя не потребует перекомпиляции / перегенерации

А перловая реализация поддерживает рекурсивное создание вложенных объектов?

Если так сходу не в курсе, то доку курить не надо, забейте, я сам:)

да, конечно

Но как-то же в моём примере middleName должен появиться. Софт с его поддержкой кто-то должен написать и потом раскатить.
И его же не просто так вводили. Например, он где-то начал фигурировать в ФИО. Софт, поддерживающий потенциальный откат должен учитывать возможность ФИО вместо ФИ в данных, которые в процессе работы нагенерились.

главное, у них (или предка) должны быть определены методы (де)сериализации... впрочем, как и у JSON::XS точно так же

так я в этом примере вижу (выделение моё) "пишете новый раскукоживатель, Раскладываете сначала консумеры с этой версией, Потом делаете кодер с поддержкой middleName, интегрируете его в продюсеров" и только тогда поле добавлено - это долгий и сложный путь.
В котором еще и раскукоживатель сначала написать надо.
Тогда как с JSON/аналогами декодер писать не надо, оно само, и можно добавлять и раскатывать поддержку middleName в любом порядке (если только это не required-поле)

"В любом порядке" - это только в случае, если новые фичи ни на что не влияют.

В общем, разговор непонятно о чём. JSON и Co. - хороший формат. Но сами они не решают ту задачу, которую хочет @mivanych - её надо программировать на уровне приложений. Код, принимающий сериализованные данные из другого микросервиса или готовящий их для другого должен учитывать общую логику обработки, иначе проблемы в эксплуатации гарантированы.

нет, не когда "ни на что не влияют", а когда оно optional

Опциональность - это особенность именно миграции данного конкретного сообщения на новую версию.

т.е. проблема может возникнуть только в одном случае: допустим, мы объявили middleName как required, раскатили всех, и тут вдруг срочно понадобился откат - и продьюсера вдруг откатили раньше потребителя. Но в этом случае у protobuf будет ровно та же самая проблема, он ничем не отличится здесь от JSON.

Опциональность - это костыль, который в protobuf сделали вместо нормальной версионности

Это если раскладывается изменение одного этого сообщения. В принципе, можно такими постепенными миграциями (сначала Юзера, потом, например, Заказы (где фигурируют эти Юзеры) и т.д.) раскладываться. Но тут есть шанс, что на 10 итерации вдруг выясняется, что количество изменений перерасло в качество, и всё надо судорожно откатывать. :)

это уже называется не просто "схема", но и "версия схемы" - т.е. проблему отката required-поля следовало было решить так, что откатнутый продьюсер посылает сообщения предыдущей версии схемы, а более новый консьюмер умеет понимать обе версии (и опять же, protobuf эту проблему не решает)

не найду щас оригинальную статью, но нашел суть той их проблемы - и она проистекает как раз из компилируемости protobuf:

Vadim Goncharov, [27.02.17 13:48]
представь, что у тебя система из микросервисов, обменивающихся сообщениями, настолько сложная, что возникают промежуточные роутеры, которые роутят эти сообщения по полям в них. Представил?

Vadim Goncharov, [27.02.17 13:49]
так вот, это еще хуйня =)

Vadim Goncharov, [27.02.17 13:49]
ну то есть, тебе нужен апгрейд схемы сообщений, это повлечет за собой апгрейд всех таких роутеров, т.к. protobufs - компилируемый

Vadim Goncharov, [27.02.17 13:50]
но это вполне менеджабельно еще

Vadim Goncharov, [27.02.17 13:51]
проблема начинается тогда, когда инфраструктура таких роутеров (пути проходящих сообщений) начинает принадлежать куче разных департаментов, и возникают зависимости от апгрейда РАЗНЫХ сервисов между ними - вот в это (чуть ли не циклические зависимости, не помню точно) они и влетели

Vadim Goncharov, [27.02.17 13:56]
ну, на пальцах, сервисы A и B пользуются старой версией, их пока нельзя трогать, сервисы C и D надо апгрейдить на новую схему - но всё это для всех четверых проходит через роутер X, которыйц, получается, для одного пути апгрейдить НАДО, а для другого НЕЛЬЗЯ :)

Да, такое тоже бывает. Кстати, иногда делают маршрутизацию на входе. К примеру, пришёл запрос в систему - дёргается маршрутизатор, который сразу определяет возможные маршруты (на n_м шаге - обращение к сервису s(n) версии v_n_s ). И дальше, как бы не менялись версии софта, данный запрос (и все связанные) обрабатываются определённой версией.

для не таких больших размеров конторы можно

почему забыть - он как-то особенно медленно принимает соединение?

Да нет. Принимает-то он так-же. Просто у человека задача сделать 10 запросов по принятии коннекта. И если они будет на асинках это делать - время запроса будет ~= времени самого большого подзапроса. А если в синхронном, то надо суммировать. То есть скорость будет ~ в 10 раз медленней.

При этом нагрузки нигде не будет, кроме того что запросы будут медленные... После чего "Перл говно, переходим на питон".

а.. я так понял что процессы  микросервиса синхронные, а  веб-воркеры которые в этот микросервис ходят -  асинхронные