Архитектурный шаблон, базирующийся на трех факторах:
1. Realtime GraphQL («Use GraphQL for a very simple and flexible frontend developer workflow.»)
2. Reliable eventing («Remove in-memory state manipulation in your backend APIs and persist them as atomic events instead»)
3. Async serverless («Write business logic as event handlers»)
Основная идея проста и не нова: в коде не должно храниться состояние, в идеале — вообще.
https://3factor.app
#pattern
1. Realtime GraphQL («Use GraphQL for a very simple and flexible frontend developer workflow.»)
2. Reliable eventing («Remove in-memory state manipulation in your backend APIs and persist them as atomic events instead»)
3. Async serverless («Write business logic as event handlers»)
Основная идея проста и не нова: в коде не должно храниться состояние, в идеале — вообще.
https://3factor.app
#pattern
Концептуальная схема self-healing (самовосстанавливающейся) системы, то есть такой системы, в которой автоматически выявляются аномалии и предпринимаются корректирующие действия.
Например: при отказе железа под кластером перевод на другой кластер, перезапуск хостов, изменение таблиц маршрутизации, расширение канала, остановка или запуск экземпляров сервисов.
Нередко в таких системах корректирующие действия появлятся как результат Chaos Testing на производственной среде.
#pattern
Например: при отказе железа под кластером перевод на другой кластер, перезапуск хостов, изменение таблиц маршрутизации, расширение канала, остановка или запуск экземпляров сервисов.
Нередко в таких системах корректирующие действия появлятся как результат Chaos Testing на производственной среде.
#pattern
❤1
Техника... монолитизации — объединения сервисов в монолит.
Статья про Oat++, web-фрейморк для C++, так что и речь идет о нем, но в целом техника не зависит от языка.
Когда рекомендуют применять:
• Низкая нагрузка
• Отсутствие потребности в масштабировании
Заявленные выгоды:
• Снижение уровня потребления памяти
• Снижение затрат на инфраструктуру за счет сокращения нагрузки на сеть
Идея интересная, но я вижу такие риски:
• Когда потребуется масштабирование, команда и инфраструктура могут оказаться не готовы за счет отсутствия опыта развития и управления распределенной системой
• Усложняется тестирование, — есть автономные сервисы и к ним в довесок виртуальный монолит
• По описанию выглядит так, что для выделения сервиса из виртуального монолита требуется полная пересборка с измененным Monolith Config — не самый повторяемый и надежный процесс
При этом выгоды сомнительны, разве что если сервисы очень «говорливы», а сообщения достаточно объемны.
Поделитесь идеями, где можно применить (без привязки к фреймворку). Как минимум — подход не обычный.
https://oatpp.io/docs/monolithization/
#pattern
Статья про Oat++, web-фрейморк для C++, так что и речь идет о нем, но в целом техника не зависит от языка.
Когда рекомендуют применять:
• Низкая нагрузка
• Отсутствие потребности в масштабировании
Заявленные выгоды:
• Снижение уровня потребления памяти
• Снижение затрат на инфраструктуру за счет сокращения нагрузки на сеть
Идея интересная, но я вижу такие риски:
• Когда потребуется масштабирование, команда и инфраструктура могут оказаться не готовы за счет отсутствия опыта развития и управления распределенной системой
• Усложняется тестирование, — есть автономные сервисы и к ним в довесок виртуальный монолит
• По описанию выглядит так, что для выделения сервиса из виртуального монолита требуется полная пересборка с измененным Monolith Config — не самый повторяемый и надежный процесс
При этом выгоды сомнительны, разве что если сервисы очень «говорливы», а сообщения достаточно объемны.
Поделитесь идеями, где можно применить (без привязки к фреймворку). Как минимум — подход не обычный.
https://oatpp.io/docs/monolithization/
#pattern
oatpp.io
Monolithization | Oat++
Monolithization of microservices in Oat++ Web Framework.