Как стать автором
Обновить
149
-2
Александр Бындю @AlexanderByndyu

Автор книг «Антихрупкость в IT» и «Карта гипотез»

Отправить сообщение
В большинстве случаев срабатывает microservices.io/patterns/decomposition/service-per-team.html, но надо примерять к своей реальности и делать корректировки. Плюс, рекомендую использовать InnerSource, потому что этот подход хорошо сочетается с микросервисами.
Как обычно надо оценить какие бонусы получит бизнес (в конце статьи пару ссылок на эту тему) и посчитать расходы. Если первое больше, чем второе, то стоит переходить :)
Архитектура же от бизнеса строится, т.е. архитектура это производное от бизнеса. В зависимости от стратегии и устройства всей компании будет делаться нарезка.
Из практики обычно получается так, что в монолите многое сложилось «исторически» и почему так уже никто не помнит. То есть много функций работает и на них не обращают внимания, а они со временем обрастают разными зависимостями. Например, сервис, который должен заниматься расшифровкой, заодно работает с архивами и в базу данных кладет файлы и в папочки на FTP скидывает какие-то вещи. Такой сервис получает много причин сломаться и при создании микросервисов надо понять, что у него внутри, чтобы не тащить AS IS, а подойти к «распилке» с толком.
Тем, что бизнес-процесс нужно осознать самому, передать знание другому и поддерживать и изменять. Сложные процессы осознать через код очень сложно, поэтому их всё равно рисуют, но без привязки к коду, поэтому такие схемы не точные и устаревают.
Да, и к срочности добавляется еще и ограничению бюджета, что является значительным фактором.

Что значит срочный вариант?

По FFF оценку нужно давать аналогично Fixed price. Разница только в том, что из этой оценки объем работы считается плавающей величиной.
Используем или www.envoyproxy.io или сами пишем прослойки. istio.io пока не заводится в полный рост. В целом, концепция очень нравится.

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


P.s. Рад, что как-то вам помог :)

Статьи по запросу «scale up scale out comparison» говорят об обратном. Если коротко, то супер-машина с 100ГБ оперативки стоит дороже, чем 10 машин с 10ГБ оперативки

Я согласен, что делать микросервисы ради моды нет смысла, потому что такая архитектура дороже в реализации и развитии
Иллюзия дешевизны и простоты

Это ошибочная иллюзия. Если у бизнеса есть цель уйти от проблем монолита, то за это придется платить. Тут дело в том, что если ваши конкуренты смогли перейти на микросервисы и получить ускорение, то вам тоже придется это сделать, потому что захочется не отставать в скорости.
Если приложение решает одну бизнес-задачу (соответствует SRP), то оно и есть микросервис
Микросервис можно раскатать на 150 машин и он будет работать быстрее, а в монолите рано или поздно будет достигнут предел вертикального масштабирования
С точки зрения сервиса А действительно ничего не поменяется. Но представьте, что вам нужно понять, кто вызывает сервис А. Или нужно понять, где у сервиса А лежит API. API Gateway хорошо структурирует связи.

Пример, который работает и с которым я работал https://lm-tech.ru/platformeco/

1) К сожалению, люди из бизнеса не могут заглянуть в код и порадоваться, что «классическом программировании уже давно этот вопрос решен». Использовать квадратики, когда их много тоже не очень удобно, но это всё равно удобней, чем вглядываться в кодовую базу сотни сервисов.
2) Вопрос производительности имеет место быть, но он решаем при грамотном проектировании.
3) Да, в монолите в этом плане намного проще :) Микросервисы добавляют сложности, как я написал, в обнаружении проблем и понимании как проходит запрос и какие события при этом создаются.
При работе через API Gateway видно кто и как кого вызывает. Управляемость и наглядность повышаются в сравнении с беспорядочными запросами между микросервисами напрямую.

По поводу внедрения все этого. Это очень сложно и довольно дорого. Переписывание монолита на микросервисы обходится примерно как стоимость самого монолита. При этом есть риск сделать еще хуже, потому что компетенции нужны довольно высокие. Компании идут на этот шаг, если проблемы монолита становятся критичны для их бизнеса.
Я описал проблемы, которые возникают при монолитной архитектуре. Если для бизнеса они критичны, значит «монолит это плохо». Если для бизнеса эти проблемы не критичны, значит монолит это не плохо

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность

Специализация

Project Director, Chief Executive Officer (CEO)
Lead
C#
Agile
Microservices
Designing application architecture
Design patterns
SOLID
High-loaded systems
Kanban
Project management
People management