Мне много приходилось не только проектировать с нуля и переводить монолиты на микросервисы, но и отговаривать.
Если даже существует бизнес-потребность и бизнес готов потратиться на инфраструктуру, есть еще один важный фактор, без которого просто никуда — я называю его «культура качества», когда каждый в компании вкладывается в качество конечного продукта. И оно неразрывно связано с тестированием, причем автоматизированным.
Только с помощью тестов можно проверить и подтвердить, что постепенно меняющаяся архитектура остается пригодной. Почему еще это так важно на ранних этапах перехода?
Это позволяет переходить на микросервисы микрошагами. Ручной затянутый регрес будет серьезным препятствием к постепенному переходу (что я и видел в нескольких неудачных попытках - деплой даже средних изменений приводил к тому, что то там, то здесь баг, а реализацию бизнес-фич никто не отменял).
Второй момент, — все мы знаем подход shift left (например - выполнять часть тестов производительности и безопасности еще на этапе разработки), когда практики качества серьезно сдвигаются влево. В микросервисах, помимо shift left появляется shift right - тестирование на продакшене (тот же chaos engineering, нагрузка и scalability на проде). Только на проде можно получить самые точные результаты тестов, так это именно то окружение, со своими достоинствами и недостатками, которым пользуется клиент.
Постепенно расскажу о других препятствиях.
Какие виды тестов и в каком количество вы используете?
Если даже существует бизнес-потребность и бизнес готов потратиться на инфраструктуру, есть еще один важный фактор, без которого просто никуда — я называю его «культура качества», когда каждый в компании вкладывается в качество конечного продукта. И оно неразрывно связано с тестированием, причем автоматизированным.
Только с помощью тестов можно проверить и подтвердить, что постепенно меняющаяся архитектура остается пригодной. Почему еще это так важно на ранних этапах перехода?
Это позволяет переходить на микросервисы микрошагами. Ручной затянутый регрес будет серьезным препятствием к постепенному переходу (что я и видел в нескольких неудачных попытках - деплой даже средних изменений приводил к тому, что то там, то здесь баг, а реализацию бизнес-фич никто не отменял).
Второй момент, — все мы знаем подход shift left (например - выполнять часть тестов производительности и безопасности еще на этапе разработки), когда практики качества серьезно сдвигаются влево. В микросервисах, помимо shift left появляется shift right - тестирование на продакшене (тот же chaos engineering, нагрузка и scalability на проде). Только на проде можно получить самые точные результаты тестов, так это именно то окружение, со своими достоинствами и недостатками, которым пользуется клиент.
Постепенно расскажу о других препятствиях.
Какие виды тестов и в каком количество вы используете?