Все наши клиенты или уже в облаке или мигрируют туда. On-premis уходит в прошлое. И еще раз пример был приведент, чтобы показать, как правильно доносить свою идею. Сам по себе пример абстракный и без привязки к конкретному случаю тут даже нечего обсуждать.
Этот топик больше относится к архитекторам, а это уже посредник между бизнесом и тех частью. Бизнес узнает, что нужен рефакторинг когда будет слишком поздно.
У каждой системы есть пиковые нагрузки и время простоя, если рассматривать монолит, то он будет всегда потреблять одно и тоже количество оперативной памяти, но при недогрузке ресурсы будут протаивать, а при перегрузке будут проблемы с производительностью. С сервис-ориентированной архитектурой есть возможность масштабировать вверх и вниз, тем самым эффективно утилизирую ресурсы и не теряя деньги и клиентов в момент пиковых нагрузок, когда это так важно. А вообще пример с сервис-ориентированной архитектурой это лишь пример, чтобы показать концепт самого рефакторинга и основные ошибки при коммуникации с бизнесом. Как раз основная идея проверить принесет ли это пользу, а потом предлагать бизнесу. У меня есть много примеров, когда рефакторенг был ненужен.
В наших проектах применялся пятый и шестой, так же. Четвертый, тоже имеет право на жизнь. Третий немного надуманный и в практике, на реальных проектах его не встречал. Но как я уже написал в конце, это лишь стартовая точка, чтобы натолкнуть читателей на собственные решения или выбрать из существующих.
Суть состоит в том что любой может обратится к рест сервису и получить беспорядочный набор символов, а точнее шифрованный ответ от сервера и только владелец приватного ключа сможет его расшифровать.
Любой клиент может совершать операцию, но расшифровать может только один
Любой клиент может совершать операцию, но расшифровать может только один
— гуглятся только те, что есть в базе.
Я не утверждаю что этот метод самый надежный, скорее наоборот, но он есть и возможно кому-то пригодится.