Доброго дня. Цікава стаття, дякую. Повністю погоджуюсь, неформальна нотація дуже корисна особливо з нетехнічними стейкхолдерами.

Доброго дня. Так, структурні діаграми та діаграми поведінки більш точний переклад. Дякую.

Доброго дня. Цей підхід мені найбільше подобається. Внутрішній стандарт ЕПАМ також вокористовує цей підхід.

Доброго дня, Lucidсhart (www.lucidchart.com) для роботи з клієнтом, бо це його внутрішній стандарт. Особисто для себе використовую Draw.IO (app.diagrams.net). EPAM наlає MS Visio.

Я не ставив за мету написатти статтю, за якою можна вчитися. В ЕПАМ є ціла школа для архітекторів на 6 місяців, де дуже багато матеріалу. Меня цієї статті — розповісти, що і як роблять архітектори з деякими прикладами та зробити статтю цікавою, а не академічною. Ще я маю надію, що цю статтю читають менеджери, які тепер зможуть більш впевненно розуміти, що роблять архітектори. Бо дуже часто я бачу, як менеджери просять архітекторів займатися роботою лідів, тому що не розуміють за що відповідає архітектор.

Неистово плюсую :-)

Спасибо за конструктивный комментарий.

en.wikipedia.org/...​entational_state_transfer
restfulapi.net/...​rchitectural-constraints

Точно, спасибо

Ну как минимум две машинки в разных зонах, к ним лоад балансер, потом там и база была, что постоянна работала, про все просто не напишь :-) бумага мокрая от слез становиться :-)

Нет, скорее это недостаточная проработка механизма скейлинга для базы или сервисов, неверная оценка загруженности того или иного шага бизнес процесса. На пример, база скейлилась под нагрузкой, но сервис не видел новые реплики. Проблему отловили, добавили новый сценарий тестирования скейлинга, но сервисы разные, их много, потому время от времени что-то похожее выскакивает.

Для такого масштаба кажется Enterprise подошел

Молодежь достаточно охотно соглашается, одних привлекает возможность попробовать схему, по которой работают инженеры в Netflix, AWS, Google, других привлекает дополнительная компенсация, третьим нравиться чувство, что от них зависит многомиллионный бизнес, у четвертых еще что-то :-)

Действительно серьезных сбоев не было. У нас много разных тестов и мы отлавливаем большинство проблем до продакшена. И да, сейчас в основном это проблемы с ресурсами, производительностью и т.д.

В системе порядка 10 кластеров и в кажом порядка 100 сервисов. Команда отвечает только за свои сервисы. Т.е. это не совсем чужой код. Если проблема действительно в сервисе, за который отвечает другая команда, то дежурный может заескалировать проблему выше и лид или архитектор имеет право перевести решение проблемы на другую команду.