Комментарии 23
HDD это не только hard disk drive, но и hype driven development.
Ну так это были ожидаемые проблемы. Даже если не переписывать, а писать с нуля ситуация лучше не становиться, за всё надо платить. Стало легче делать одно, сложность перешла на другой уровень, теперь до написания кода надо подумать как оно впишется в кучу микросервисов, ну и стоимость железа возрасла, но программистов можно брать дешевле и больше, ведь мелкие куски делать много уметь не надо, делай по готовому примеру и паблиши.
>Зная обо всех этих ужасах, вы все еще любите распределенные системы?
Только в том случае, когда распределенная система имеет преимущества. К примеру, 100% требуется масштабирование, но в момент разработки еще не совсем понятно где именно. Тогда используются всякие кубернетесы или серверлесс код в облаках.
Перед тем как играться в кубернетесы и всякое горизонтальное масштабирование в облаках, бывает полезно разобраться, а где, собственно, мешающее масштабированию бутылочное горлышко. Если сервис в основном занят ожиданием ввода-вывода, какой смысл закупать для этого высокомудрого занятия ещё дюжину виртуалок? Может быть лучше проверить, что мешает параллелизму?
Интересно, как люди раньше масштабировали системы и процессы разработки, до того как стали модными кубернетесы и прочие микросервисы.
Те же соцсети пишутся огромными коллективами и испытывают огромные нагрузки. Но как-то обходились 10 лет без микросервисов.
Почему сейчас все считают что им нужны микросервисы?
Стало много языков и фреймворков. Раньше в команды набирали по знанию технологии/языка к примеру. Сейчас это практически не реально, кто то гуру Java, кто то попивает смузи и пишет бэк на JS или Go, каждый второй знает питон (но он же медленный), кто то влюблён в ruby, а кому то подуше больше php, из какого то интерпрайза сбежала группа C#’перов на вольные берега стартапов, эпплбой сказал что корзина будет на swift, всех этих ребят собеседует бородатый Cишник. Можно нанять всех и заставить писать на чем то одном, но сколько денег на это потребуется? Сильно дороже чем Кластер с кубером и пара девопсов.
Зачастую вместо горизонтального масштабирования лешевле вертикальное. Просто тупо докупить проца или памяти и соблюсти святой принцип - не трожь пока работает.
А вообще микросервисы это такая же крайность как и монолит.
Приложение дллжно быть просто модульным. С одной стороны можно отдельно разрабытывать и тестировать модули с другой стороны в целом это все же одно приложение а не десятки
О, про крайности и модули у нас как раз недавно был другой перевод.
Не "зачастую", а просто "всегда". Вертикальное масштабирование ВСЕГДА дешевле горизонтального, пока оно вообще возможно.
С микросервисами как с шардингом - в большинстве случаев нужно избегать любой ценой и внедрять только в местах, где других вариантов нет. А еще перестать читать Фаулера, Мартина и Бека, ибо они только портят программистов)
Так "настоящим архитекторам" вообще зашкварно разбираться в деталях, это ведь любая обезьяна программист может сделать, а "архитектор" должен должен быть выше этого - мыслить абстракциями и творить с помощью диаграмм, кружочков и стрелочек.
Хоть кто-то вообще видел эти стереотипы в живую?
А вообще практически в любой области, когда ты начинаешь руководить или планировать над группой людей или процессов - ты уже перестаешь непосредственно работать. Условно: главный врач больницы может не быть врачом
Я лично видел как даже изначально неплохие программисты, которые после повышения отстранялись от конкретных деталей работы системы и начинали мыслить и проектировать в шаблонах/диаграмках, через некоторое время доходили до абсурда. Намного печальнее ситуация с начинающими архитекторами начитавшимися Фаулера. После этого оказывается, что проект должен быть platform agnostic, который при необходимости можно легко перевести с Azure на AWS и поменять Mysql на MongoDb настройкой в конфиге. Чем меньше человек начинает разбираться в деталях, тем больше сложные вещи ему начинают казаться простыми, а невозможное возможным.
Если не контролировать дизайн кода и отпустит в свободное плавание то девелоперы нагавнакодят лижбыработало даже в самой изящной архитектуре. Видал я когда и в микросервисах устраивали филиал ада, и из монолита - свалку поддержанных велосипедов делали.
На волне всеобщего хайпа микросервисы стали уже своего рода карго-культом в IT.
Автор вскользь упомянул проблему с непротиворечивости данных. В монолитной архитектуре у нас есть контекст выполнения, который "из коробки" привязывается к acid транзакциям. При возникновении любой ошибки откат производится автоматически. В микросервисной архитектуре приходится городить самопальные велосипеды, ввиде шаблона "сага", которые легко заметить, не решают проблему от слова совсем. В большинстве же случаев acid и консистентность данных ни кого по сути уже не заботит.
Как раньше бездумно хвалили микросервисы, так теперь бездумно ругают.
"All problems in computer science can be solved by another level of indirection" (the "fundamental theorem of software engineering"). "...except for the problem of too many layers of indirection."
была тут статья пару лет назад с названием типа "вы не гугл", так вот, если вы не гугл, то вам не нужны все эти микросервисы, супер пупер базы и т.д. :) конечно, наверно каждый думает, что лучше всё делать по крутому сразу, когда-нибудь клиентов будет невпроворот, и что тогда - переписывать всё? но как показывает практика и железо будет другое и оптимизация будет за счёт иных вещей, зато не будет всех этих инородных и искусственных проблем
Пришла такая мысль - кто не умеет делать монолит тому нельзя разрешать делать микросервисы.
Катастрофы, с которыми я столкнулся в мире микросервисов