Лого vc.ru

Тёмная сторона Agile

Тёмная сторона Agile

Основатель компании-разработчика Hello World Technologies Евгений Тюменцев о том, почему ценности гибкой методологии не подходят для крупных проектов.

Евгений Тюменцев

В январе 2016 года на Гайдаровском форуме Герман Греф произнес знаменитую фразу: «Кто не освоит Agile сегодня, тем придется в текущих бизнес-процессах быть лузерами завтра». Глава «Сбербанка» увидел в гибких методологиях инструмент, который увеличит скорость изменений программной платформы банка.

После заявления Грефа, возможно, многие компании не из ИТ-сферы начнут предпринимать попытки (или уже начали) внедрять у себя Agile. Может ли это ускорить изменения? Чтобы ответить на поставленный вопрос, вспомним, что такое Agile.

Ценности гибких методологий задекларированы в Agile-манифесте. Их четыре:

  1. ​Люди и взаимодействие важнее процессов и инструментов.
  2. Работающий продукт важнее исчерпывающей документации.
  3. Сотрудничество с заказчиком важнее согласования условий контракта.
  4. Готовность к изменениям важнее следования первоначальному плану.

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

Еще в 60-х годах 20 века Наус и Фарр замерили, как количество программного кода влияет на продолжительность проекта. Они получили нелинейную зависимость, которая имела вид степенной функции с показателем 1,5 — как показано на рисунке. Пунктирная линия показывает график линейной зависимости, а сплошная — график фактической.

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

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

Для программирования свойственно падение производительности труда по мере роста проекта

Никогда не задумывались, почему компании, выпуская новую версию своего продукта, с гордостью заявляют, что она написана с нуля, без использования старого кода? Это противоречит здравому смыслу: старый код стоил много денег, зачем его выбрасывать, если в новой версии содержится в том числе функциональность старой.

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

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

Есть еще несколько проблем, которые порождены эффектом падения производительности и имеют непосредственное отношение к Agile. Каждую из проблем опишем с двух точек зрения: как её решают программисты и как решение подается клиенту.

Проблема №1. Нарушение сроков разработки

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

Решение: итеративные процессы разработки. При небольших объемах скорость разработки меняется незначительно, а значит, можно добиться приемлемой точности оценки. Отказываемся от оценки всего проекта в целом. Разбиваем его на небольшие куски — фазы. Перед стартом новой фазы делаем оценку только для неё. Так появились итеративные процессы разработки.

Подача решения: необходимость в получении обратной связи. В конце каждой итерации необходимо получить обратную связь от заказчика, чтобы быть уверенным, что проект на правильном пути. Обратная связь, безусловно, очень важна, но современные практики, например, Continuous Delivery, позволяют получить её в любой момент, не дожидаясь конца итерации. Зато итеративная разработка прижилась.

Следствие решения проблемы № 1: производительность всё равно падает

Производительность команды снижается со временем. Поэтому даже при итеративной разработке ошибка будет только нарастать.

Решение: Velocity. В Agile есть практика Velocity, которая заключается в определении коэффициента — разница между фактическим объемом и планируемым, поделенная на планируемый объем работ. На этот коэффициент будет умножаться оценка следующей итерации.

То есть просто описываем нелинейную кривую производительности с помощью набора небольших линейных участков, уменьшая погрешность в собственной оценке. В математике такой прием называется кусочно-линейной аппроксимацией.

Подача решения: никак. Это временной буфер, который каждый грамотный менеджер должен иметь на проекте.

Проблема №2. Стоимость реализации требований увеличивается со временем

Чем дольше откладывается изменение, тем дороже обойдется его реализация.

Решение: расставить приоритеты. Важна последовательность реализации. Делать в первую очередь надо то, что приносит наибольшую выгоду. Аргумент, с которым трудно спорить.

В условиях падения производительности приоритизация требований приобретает дополнительный смысл — надо успеть реализовать те функции, за которые пользователь будет платить деньги, пока не исчерпан весь бюджет. Вопрос в том, как оценить выгоду. Оценка очень субъективная и меняется для одного и того же требования заказчика от итерации к итерации.

Подача решения: готовность к изменениям важнее следования первоначальному плану (четвёртая ценность Agile). Как следствие, заказчик, возможно, неосознанно, принимает, что будет реализована не вся функциональность, которую он хочет, а только та, на которую у него хватит денег, при этом заранее неизвестно, на что именно их хватит.

Проблема №3. Нет времени на документацию

Разработка кода будет стремиться съедать весь бюджет, выделенный на проект. Как мы уже разобрались, нелинейная зависимость вызвана необходимостью вносить правки в текст программы. При этом документация — тот же самый текст, поэтому правки в нем будут также иметь нелинейный характер. Вместо одной нелинейной кривой получаем уже две.

Решение: отказаться от документирования. Хороший код должен быть самодокументируемым — то есть понятным настолько, чтобы не нуждаться в документации. На первый взгляд, выглядит дико, но мне на практике не встречался проект, где с документацией было всё в порядке. Чаще всего её начинают писать, но потом бросают из-за того, что не хватает времени на разработку.

Подача решения: работающий продукт важнее исчерпывающей документации (третья ценность Agile).

Проблема №4. Невозможно выполнить проект при соблюдении сразу всех трёх ограничений: функциональность, сроки, бюджет

Классический треугольник управления проектами описывает три ограничения: сроки, стоимость и содержание проекта. Изменение одного из параметров влияет на два остальных. Чего хочет клиент: получить нужную функциональность за оговоренные деньги в указанные сроки.

Сроки сложно выдержать, а значит, и управлять ими тоже. Тогда для сохранения функциональность необходимо увеличивать бюджет, а для сохранения бюджета урезать функциональность.

Решение: для завершения проекта придется либо увеличивать бюджет, либо урезать функциональность. На изменение бюджета или урезание функциональности заказчик может согласиться, только если имеет высокую степень доверия по отношению к исполнителю.

Подача решения: сотрудничество с заказчиком важнее согласования условий контракта (вторая ценность Agile).

Проблема №5. В условиях, когда сроки сложно прогнозировать, результат проекта зависит от усилий и способностей конкретных исполнителей

Решение: дать людям почувствовать ответственность за результат. На этой почве в Agile используется очень много психологических приемов, цель которых — сделать так, чтобы человек принял на себя ответственность.

Например, довольно часто программист может отказаться от ответственности за соблюдение сроков по отдельной задаче, если оценку давал не он сам. Чтобы исключить подобную ситуацию, используется прием Planning Poker — коллективное оценивание задач на итерацию, конечный результат которого — согласие каждого члена команды с оценкой на каждую задачу.

Подача решения: люди и взаимодействие важнее процессов и инструментов (первая ценность Agile). Хочу заметить, что я ни в коем случае не нахожу ценности неверными или вредными. Каждая из них сама по себе приносит пользу.

Дело в другом: Agile не решает проблему, которая существует в ИТ-отрасли с самого её появления, а вместо этого адаптирует к ней и заказчиков, и исполнителей. В этом плане Agile-манифест — отличное пособие о том, как недостатки превратить в преимущества. Но этого недостаточно для больших проектов.

Присылайте колонки, соответствующие требованиям редакции, на secret@vc.ru.

Взгляд достаточно однобокий. Ведь самое главное в Agile - это делегирование решения самой проблемы, а не четкого технического задания. Для этого нужно во-первых перестать относиться к разработчикам, как к простым исполнителям, во-вторых четко показывать им картину, в чем нуждаются пользователи и сроков, когда это должно быть сделано - из сроков релиза как раз и проистекает в каком виде можно успеть сделать решение: совсем "костыль", "перфекционистское" или, что гораздо чаще, нечто среднее между этим.

По своей работе постоянно встречаюсь с подобным скепсисом, когда Agile воспринимается скорее как "гомеопатия", призванная бороться с какими-то недостатками, чем как философия, которая предлагает сфокусироваться на улучшении главной метрики: Time To Market и делать для этого все возможное.

Можно короче, Аджайлом не оправдать распил , так хоть кипа бумаги останется о бурной работы, Аджайлом сыт не будешь.

0

Да ну? Еще как можно оправдать! Можно прекрасно освоить кучу денег на "внедрение Agile" в крупной организации...И оправдание есть прекрасное - "нам Греф посоветовал внедрять..." :)

0

И часто вы с господином Грефом беседуете?

0

Ни разу. Когда Греф внедряет Agile, это не требует от него личных бесед с каждым участником процесса. Странно, правда?

0

> делегирование решения самой проблемы, а не четкого технического задания

Эта концепция совершенно ортогональна Agile. В смысле - не противоречит, а просто никак не связана. Встречал подрядчиков, которые как раз наоборот, работают строго по принципу "не учите нас решать проблемы, просто расскажите о них". И при этом совершенно не взаимодействуют с заказчиком по ходу дела после завершения фазы бизнес-анализа вплоть до сдачи работ.

Здравствуйте, Андрей!

Спасибо за отклик!

1. В начале статьи я поставил вопрос: "Может ли это ускорить изменения?" Имея ввиду Agile.

2. И по ходу статьи сделал заключение, ссылаясь на исследование Науса и Фарра: "Для программирования свойственно падение производительности труда по мере роста проекта".

3. Отсюда в конце сделал вывод, что "Agile не решает проблему, которая существует в ИТ-отрасли с самого её появления, а вместо этого адаптирует к ней и заказчиков, и исполнителей", то есть несмотря на Agile скорость изменений будет падать, пока не достигнет неприемлемого уровня, в смысле, что Agile на это никак не влияет. А значит ожидание: " в гибких методологиях инструмент, который увеличит скорость изменений " неоправданно.

При этом "Хочу заметить, что я ни в коем случае не нахожу ценности неверными или вредными. Каждая из них сама по себе приносит пользу."

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

> что гораздо чаще, нечто среднее между этим.
Гораздо чаще это костыли. Хорошее решение требует очень много времени на проектирование и разработку. Я не видел ни одного проекта, который бы такими интеративными кусками в конце разработки не разваливался при эксплуатации. Даже спорили на внушительную сумму денег с коллегой, что его латание систем выльется в полную деградацию работы. Так оно и получилось.

0

от закона Конвея не убежишь.

0

Тогда почему в офисе сбера на первом этаже стоят огромные буквы «Agile Go Home»?
Кто знает?)

Для маленьких проектов-agile, для крупных - классическая проектная технология

0

Автор пишет, что Agile не подходит для крупных проектов, описывает проблемы и их решение. И среди решений я так и не увидел "уход от Agile" :)

Здравствуйте, Илья!

Спасибо за отклик!

Цель статьи была сказать: "Agile не решает проблему, которая существует в ИТ-отрасли с самого её появления, а вместо этого адаптирует к ней и заказчиков, и исполнителей", то есть несмотря на Agile скорость изменений будет падать, пока не достигнет неприемлемого уровня, в смысле, что Agile на это никак не влияет. А значит ожидание: " в гибких методологиях инструмент, который увеличит скорость изменений " неоправданно.

При этом "Хочу заметить, что я ни в коем случае не нахожу ценности неверными или вредными. Каждая из них сама по себе приносит пользу."

0

А если добавить еще 2 хайп слова: devops и micro services? Тогда и проекты стали гораздо меньше, и выкатывать их можно непрерывным потоком.

Добрый день, Дмитрий!

Ни devops, ни micro services не созданы для борьбы с эффектом, описанным в статье. Как и с любым удачным решением, которое начинает тиражироваться, получим очередной "hell". Раньше были dll hell, callback hell, будет micro services hell.

У меня по осени выходит статья в научном журнале, которая с помощью математики объясняет причину падения производительности труда от размера проекта.

Ну а с микросервисами это должно проявиться примерно так: когда их станет довольно много в приложении, то возникнет желание вызывать один из другого. Уже сейчас вопрос: "что с этим делать?" довольно популярен.

> У меня по осени выходит статья в научном журнале, которая с помощью математики объясняет причину падения производительности труда от размера проекта

Вот это очень интересно ! Дайте знать где и когда

Журнал Математические структуры и моделирование - это журнал факультета компьютерных наук, где я работаю, 3 номер за 2017 год. Точный срок выхода пока неизвестен - все в отпусках, но в сентябре будет отдан в печать. Скорее выйдет в октябре.

0

Спасибо большое (и за эту интересную статью и за публикацию) !

А что вы хотели? Agile - это как демократия. Его все обязаны хвалить, даже если на самом деле думаю иначе..такой тренд навязан обществом. На самом деле обе системы хреновые - и Agile и демократия, но просто другие системы, известные человечеству - еще хуже :) Так что за неимение лучшего пока деваться некуда...

0

Ребята, расходимся! Agile и не обещал быть идеальным для всех. Серебряная пуля дура, короче.

0

Прочитал пост, так и не увидел ответ на вопрос, почему же Agile не подходит для больших проектов.
Вода, кэпство и ничего по теме.

В тексте очевидно смешаны понятия Scrum, Agile и для Velocity странная формула приведена. Вот коллеги из Scrum Alliance описывают что это такое, простое среднее www.scrumalliance.org/community/articles/2014/february/velocity

0

Добрый день, Михаил!

Спасибо за отклик!

Не могли бы Вы уточнить, в чем произошло смешение понятий Scrum и Agile? Я использовал только Agile-манифест. В тех пунктах, где речь идет о ценностях (2-5) больше ни о каких Agile-практиках не упоминается. Возможно, путаница возникла из-за Veloctiy. Но про нее я написал отдельно, как следствие, вытекающее из итеративного процесса разработки.

Насчет velocity - я как раз и описал формулу вычисления средней скорости.

В описании подходов к решению в проблеме 1 и 5 описывается до смешения похожий на Scrum подход, именно про это я и говорю.

Кроме того, разница между фактическим объемом работ и планируемым, деленная на планируемый объем и сумма фактической работы за N периодов деленная на N - несколько разные формулы.

Кроме того в описании проблемы 2 говорится о субъективной оценке ценности. Хотя имеется ряд скоринговых моделей, снижающих этот фактор. Та же модель Кано.

Ну и в целом статья опирающаяся только на 4 ценности (не являющиеся исчерпывающим руководством к действию, а только ориентиром для принятия решений), без упоминания 12 принципов - неполная.

А в целом мнение интересное и материал подан интересно, иначе бы мне не захотелось написать комментарий :) спасибо!

Важная и критичная составляющего Agile метода - команда с высокой степенью самоорганизации. Таких людей подобрать совсем не простая задача

Поэтому в нормальных компаниях есть архитекторы. Система разбивается на microservices, которые уже могут писаться индивидуальными командами, и переписываться, если потребуется.
Опять же , не надо путать кодера с программистом, а программиста с архитектором.

Не мечи бисер перед свиньями, не трать время. В России вообще не принято использовать узкую специализацию. Берут человека который ВСЕ делает ПЛОХО. То есть если в резюме указать ОДНУ вещь, которую ты делаешь действительно ХОРОШО, например аналитику, то будешь годами сидеть без работы, плюс фактор кумовства в Москве никто не отменял. Поэтому возьмут человека который будет плохим системным администратором программистом и аналитиком, зато очевидная экономия на ИТ с точки зрения менеджера продукта. То же самое с архитектором, программистом и аналитиком. То есть все принимают правила игры, что в России в резюме можно написать вообще всё, что угодно, никакого доверия сертификатам, а проверять будут все равно так, как будто вчера институт закончил, при этом отдавая предпочтение однокурсникам. Так что вообще все равно, что и как ты знаешь, это не имеет почти никакого значения - главное- как ты "обманешь" работодателя. Поэтому хорошие кодеры - это full-stack програмисты, пргарммисты - это архитекторы систем а архитекторы систем - это у нас генеральные директора, не окончившие MBA, и все всё знают и умеют, а спеси - просто вагонами разгружай. Лично я вообще не встретил за 4 года в Москве вообще ни одного архитектора, все либо глубоко законспирировавшиеся менеджеры продукта, либо вообще пользователи ПК Visio, имеющие сугубо абстрактное представление о предмете. Потому что даже специализации такой в высшей школе нет - все без исключения в лучшем случае "инженер-программист"-ы. То есть это вообще не российская тема, нам не понять, зачем нужен отдельный человек для рисования в Visio архитектур, хоть немного приближенных к реальности, а не просто веселые картинки для заказчика (хотя на эту задачу как раз и берут), отдавая на откуп программистам всю архитектуру систем,на коленке сделал - молодец, сэкономил деньги гендиру на дачку. Нет - не беда, возьмем другого "гения". Так и получается, что в условиях отсутствия жесткой конкуренции все бросаются на "универсалов", и под iOS чот-то криворукое слабать, и страничку HTML наковырять, главное уметь сделать картинку, а уж как оно внутри работает - лучше вообще не спрашивать. Все равно никто никогда не пишет комментарии.

0

Да , российских реалий не знаю. но микрософт сделал VSTS заточенный под Agile, откуда можно сразу делать все - CI и тд. И потом делать новый проект можно вообще с интерфейсом который идет на API возвращающие тестовую информацию, то есть фактически прототип который показывается пользователям. а backend писать позже.
Все зависит от проекта, но большие проекты надо точно разбивать на подсистемы, чтобы исключить проблемы, описанные в статьи.

Не надо ничего разбивать, надо нанимать адекватных людей, платить много денег и завышать строки 2.5x. Обкатано 2 системами, которые писались 4 и 5,5 лет. Обе по окончанию выстрелили и приносят кучу профита. Разработка шла без этих аджайлов/скрамов/вотерфолов. И большой проект - это геораспределенный сторадж со своим умным мастер элекшном и возможностью выбора поколоночного/сторокового храниения данных, а не сайтик с API, CI и прочими бэкендами.

0

Гала, почитайте про microservices, docker и cloud. Distributed computing это не только база данных, это также парадигмы программирования где вы либо пишете monolithic application я использованием actor pattern, либо кучу services, каждый из которых вы может потом либо переписывать, либо убирать, либо scale. Иначе система просто в какой то момент станет либо слишком дорогая либо сломается.
На сегодняшний системы не пишутся по 4 и 5 лет, никакие инвесторы не дадут на это деньги.

0

Все эти микросервисы - хорошо забытое старое и лишний оверхед. Всё уже было: grid, rpc, corba, com/dcom да даже ejb решало те же задачи. Теперь вот появился докер, офигеть какая новизна !

0

Вам по делу есть что сказать? Или вы так, свои пять копеек хотите вставить просто.

0

Уже сказал, только вы походу не поняли. ;-)

Я вам могу рассказать как работает докер до уровня строчек инициализации cgroups в ядре, тк учавствовал в разработке аналогичного решения на основе lxe. Я отлично знаю что такое cloud и учавствовал в запуске кластеров на самописных решениях ещё до появления хадупа и это все мы делали в России. Так вот, ваши микросервисы раньше назывались SOA, ничего революционного тут нет.

Про модель акторов/корутин известно давно и она ортогональна микросервисам. И сервисы, которые скейлятся это из области булшит бинго. Вы теряете минимум два сискола и контекст свеча и сеть у вас ни разу не рилаебл. А всякие паксосы с опытами и госип протоколами можно реализовывать без микросервисов. То о чем вы говорите это набор базвордов, типичный хайп драйвен девелопменту. Займитесь чтением Тененбаум лучше.

0

Причем тут cloud и хадуп? в клауде уже давно есть ВСЕ :)))
Расскажите про это все разработчикам Netflix, которые построили свою систему так, что chaos monkey не могут вывести ее из строя. Если вы создаете систему которая ломается от упавшего элемента типа сети, то вам надо поучиться немного у Нетфликс.
"модель акторов/корутин известно давно и она ортогональна микросервисам" -я и не писала что это одно и то же, я написала - либо либо, что в русском языке обозначает или или :)))

0

>Расскажите про это все разработчикам Netflix, которые построили свою систему так, что chaos monkey не могут вывести ее из строя

У них там есть интеграционное тестирование перед релизом ? Или как ? Если у них такая устойчивая архитектура, то особого смысла нет, т.к. даже пролезший баг вреда не принесет, не так ли ? ;-)

0

Вот здесь все описано
medium.com/netflix-techblog/deploying-the-netflix-api-79b6176cc3f0

Довольно типичная для компаний которые практикуют CI методология.

0

Никаких откровений статья не содержит, равно как и упоминаний о микросервисах, а ведь мы о них же дискутируем ?

> Расскажите про это все разработчикам Netflix, которые построили свою систему так, что chaos monkey не могут вывести ее из строя. Если вы создаете систему которая ломается от упавшего элемента типа сети, то вам надо поучиться немного у Нетфликс.
Я готов поспорить на любые деньги что могу завалить Netflix несколькими командами при настройке сети. man autonomous system. Компания где я работаю выключает целые дата-центры для поиска проблем. Но да, куда уж нам до Netflix, они же статей понаписали как у них все хорошо.
> -я и не писала что это одно и то же, я написала - либо либо, что в русском языке обозначает или или :)))
Тогда я вообще не понимаю зачем вы это написали.
> Это не из области булшита, это из реальной жизни, когда можно scaleout количество вебсерверов при повышенной нагрузке и scale down когда пользователи идут спать, а так scale up и scale down database. Выигрыш по деньгам и доверию клиентов очевиден.
Не очевиден, вы даже базовой подготовки не имеете по CS. Можно в рантайме увеличить количество балансеров и терминировать их какой-либо заглушкой, но базу данных таким образом масштабировать нельзя. Если вы знакомы с базовым понятиями того какие типы адресации хэш таблиц существуют, то сразу же увидите противоречие между словами и делом. Сама структура БД, которые доступны вам не позволяет быстро нарастить жирок просто потому что вы забьете себе сеть во время расширения количества/перемещении бакетов для хэшей. Это работает только на сайтиках магазинов, но не работает когда у вас за сутки приходит 100Тб сырых данных.
> Причем тут cloud и хадуп? в клауде уже давно есть ВСЕ :)))
А теперь самое интересное. Netflix с точки зрения построения системы фактически read-only система. Это ни месседжер, ни социальная сеть, ни система обработки 100500 показаний с датчиков. Почему я выше упомянул 100Тб? Все элементарно, все что нужно от Netflix взять широкий канал и отдавать при совпадении какого-то хэша пользователю стрим с видео. Они не кодируют видео на лету, эта задаче даже не потребляет cpu, а при грамотном подходе можно вообще все популярные сериалы грузить в RAM и снизить нагрузку на диск на несколько порядков, а уж если подхачить ядро, то можно убрать copyto/copyfrom(например, dpdk) и вообще быть в шоколаде. Но это не работает если вам нужно процессить 100Тб данных в реалтайме. Я вот вижу как забиваются 10Гб/с интерконнекты между нодами кластера, и 40Гб/с видел забитыми. И это еще с учетом того что там нет TCP/IP, а свой собственный протокол. Сидят на другом конце Петя с Васей и периодически запускают свои аналитические скрипты + считаются какие-то ежедневные данные для пользователей. Никто из них не подозревает что с другой стороны 272000 ядер загружены на 85-92%(это очень высокий процент утилизации, если что), все 512Гб памяти каждой ноды используются на 80-90%. Там каждый день одна нода прокачивает через себя четверть всего дневного трафика Netflix, если не больше. А вы мне тут про микросервисы :)
> CAP theorem как раз об этом и есть - вы либо выбираете availability, либо consistency.
martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html вот тут почитайте.

Давайте уже составим доску булшит бинго и будем опровергать ваши тезисы :)

0

Scale up и scale down real time работает совсем не так как вы написали. Создается новый сервер, больше памяти и CPU, происходит failover. Да там присутствует blip, но так как сервисы уже работают с расчетом что БД может быть недоступна, то ничего не падает, просто в какой то момент клиенты могут получить какое то количество failed response, но если failover произойдет за несколько секунд то даже этого не будет.

"Не очевиден, вы даже базовой подготовки не имеете по CS. " тоже смешно, вы наверное еще по ладони гадать умеете и будущее по кофейной гуще предсказываете.

То что вы описали - очень специфично для вашего проекта, и думать что все проекты одинаковы - очень наивно. Микросервисы надо применят там где они нужны, с умом. Я не буду рассказывать что я видела, когда один пользователь заваливает весь монолит и система лежит, вы можете сами догадаться.

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

0

Напишите как лучше кем вы работаете, какова ваша специализация ?

0

"Напишите как лучше кем вы работаете, какова ваша специализация ?"
Да что тут писать, вы наверное уже сами догадались.
Работаю в сельском магазине кассиршей. Специализируюсь в обслуживании алкоголиков, клиническая дура.

0

Вы нахватались buzzwords и раскрученных имен авторитетов (компаний и персоналий) и козыряете ими, а в технологии не шарите ;-)

0

Извините, но я работаю с этими технологиями, а также читаю статьи от "авторитетов". Где вы там увидели козыряние я не знаю. Все аргументы которые я вам привела, про это все написано и мне ничего не надо придумывать. Мы думали о переходе на эту методологию несколько месяцев, потом попали в программу Microsoft по поддержке перехода в Azure и потихоньку начали переписывать систему.
Вы по моему не понимаете - microservice это не одна технология, это методология написания проекта со своими ньюансами

0

Ладно, отстану от вас, но только потому, что вы используете технологии моего любимого Микрософта (и даже упоминаете про VSTS).

0

Вам даже лень нажать на мой профиль, а там указано где я работаю.
остается догадываться как вы узнаете информацию для работы.

0

Читал, вижу у вас используется MS SQL Server - вот это правильно !

0

> Scale up и scale down real time работает совсем не так как вы написали. Создается новый сервер, больше памяти и CPU, происходит failover. Да там присутствует blip, но так как сервисы уже работают с расчетом что БД может быть недоступна, то ничего не падает, просто в какой то момент клиенты могут получить какое то количество failed response, но если failover произойдет за несколько секунд то даже этого не будет.
Это несусветная чушь, никто так не делает кроме стартапов. failover - это отказоустойчивость, она не происходит, она всегда присутствует. Создается либо избыточностью изначально, либо хот стендбаем. Никто. Никогда. Не запускает дополнительные инстансы в реальном времени потому что неизвестно как это будет происходить под нагрузкой, за сколько времени оно запустится и как перебалансируется. Вообще тема балансировки весьма сложная и только на rr не заканчивается. Перебалансировать новые веса, да еще и в разных ДЦ, да еще и с приоритетами и чтобы все работало - это только в рекламе маркетологов работает.
> тоже смешно, вы наверное еще по ладони гадать умеете и будущее по кофейной гуще предсказываете.
Я умею гадать по тому как люди используют базворды. Если человек не может словами описать что он предполагает, а сразу использует какой-то термин, то знаний в этой области у человека нет.
> То что вы описали - очень специфично для вашего проекта, и думать что все проекты одинаковы - очень наивно. Микросервисы надо применят там где они нужны, с умом. Я не буду рассказывать что я видела, когда один пользователь заваливает весь монолит и система лежит, вы можете сами догадаться.
Микросервисы от криворукости не спасают, так же как и монолитные, но микросервисы почему-то позиционируются как серебрянная пуля. Типа пусть у вас в мясо разлетелась часть сервиса, зато остальное будет работать.
> В случае с Нетфликс все просто - один сервис показывает видео, другой сервис делает аналитику и показывает пользователю какие еще фильмы можно посмотреть, и тд и тп, и если что то сломалось, все остальное продолжает работать.
Один сервис показывает видео, другой статистику, а неправильный анонс AS убивает все их микросервисы разом. И это еще не известно что у них внутри для маршрутизации используется.
> Причем тут ваши кластеры - вообще непонятно.
Наши кластеры куда сложнее всего netflix, обслуживают куда больше пользователей и обрабатывают куда больше данных. И все это монолитное. Получается что пример netflix не показателен.

0

Вы похоже кроме как теорий ничего выдвигать не умеете, собеседник вы хреновый, гадаете на кофейной гуще и современных реалий не знаете.
Никто не пишет что микросервисы это silver bullet - это только в вашей голове.

Вы даже не видите разницы между архитектурой веб сервисов и ваших кластеров. Это принципиально разные вещи с разные проблемами.

"Это несусветная чушь, никто так не делает кроме стартапов. failover - это отказоустойчивость, она не происходит, она всегда присутствует. Создается либо избыточностью изначально, либо хот стендбаем. Никто. Никогда. Не запускает дополнительные инстансы в реальном времени потому что неизвестно как это будет происходить под нагрузкой, за сколько времени оно запустится и как перебалансируется. Вообще тема балансировки весьма сложная и только на rr не заканчивается. Перебалансировать новые веса, да еще и в разных ДЦ, да еще и с приоритетами и чтобы все работало - это только в рекламе маркетологов работает."

Сразу видно что вы лезете не в свою тему, в которой вообще ничего не понимаете, и про таймауты не слышали, про circuit breaker patterns не слышали.

docs.microsoft.com/en-us/azure/sql-database/sql-database-service-tiers

"Changing the service tier and/or performance level of a database creates a replica of the original database at the new performance level, and then switches connections over to the replica. No data is lost during this process but during the brief moment when we switch over to the replica, connections to the database are disabled, so some transactions in flight may be rolled back. The length of time for the switch over varies, but is generally under 4 seconds is less than 30 seconds 99% of the time. If there are large numbers of transactions in flight at the moment connections are disabled, the length of time for the switch over may be longer."

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

0

> Вы даже не видите разницы между архитектурой веб сервисов и ваших кластеров. Это принципиально разные вещи с разные проблемами.
Конечно не вижу, я же веб разработкой занимался много лет еще во времена когда все писалось на C/C++/perl или php. И ушел из нее с появлением NodeJS, потому что невозможно смотреть на код людей, которые за 3 месяца выучили JavaScript и теперь считают что они разработчики.
> Сразу видно что вы лезете не в свою тему, в которой вообще ничего не понимаете, и про таймауты не слышали, про circuit breaker patterns не слышали.
Опять булшит бинго с базвордами. Circuit breaker используется как раз из-за убогости микросервисов. Вы мне решили всю www.oreilly.com/programming/free/microservices-antipatterns-and-pitfalls.csp процитировать? Я ее тоже читал, не удивите :)
> Я тупо перепечатываю мысли других людей, а вы начинаете со мной спорить, как будто я сама все это придумала и этого ничего не существует и выставляете себя полным дураком.
Вы это не придумали, вы не понимаете причину и следствие. Вот тот же пример с circuit breaker говорит о том что вы не понимаете зачем оно нужно и почему появилось. Ну мне просто нельзя из-за NDA говорить где я работаю и над чем, а покидаться в микросервисы говном святое дело, особенно если человек не понимает что это всего лишь базворды. Вся ваша инфарструктура сейчас скопирована с той компании где я работаю. Мы это видели, плавали и знаем где оно стреляет :)

0

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

0

Вы даете ссылку на книгу, которую написал an experienced hands-on software architect involved in the architecture, design, and implementation of Microservices Architectures, Service Oriented Architectures, and distributed systems in J2EE and other technologies.
Вы ему напишите что это buzzword, хотела бы посмотреть на этот разговор. То есть человек написао книгу исходя из своего опыта про ловушки и антипаттернс, а вы это все передергиваете и выставляете все как булшит.
Вы уже 10 раз повторили что я не понимаю причину и следствие,а по моему это у вас в голове каша полная.

0

> Вы даете ссылку на книгу, которую написал an experienced hands-on software architect involved in the architecture, design, and implementation of Microservices Architectures, Service Oriented Architectures, and distributed systems in J2EE and other technologies.
А на кого я должен дать ссылку? На человека который никогда не проектировал микросервисы?
> Вы ему напишите что это buzzword, хотела бы посмотреть на этот разговор. То есть человек написао книгу исходя из своего опыта про ловушки и антипаттернс, а вы это все передергиваете и выставляете все как булшит.
Начнем с того, что в названии книги есть слово antipatterns. Если начать читать то что там излагается, то можно внезапно узнать узкие места, которые являются критичными во многих системах. Иногда это приводит людей к тому, что они начинают задумываться стоит ли им бездумно следовать тренду и использовать микросервисы. Базворды это не плохо, плохо когда человек не понимает всей сути этих слов. Вот пример бездумного использования базвордов вами:
> где вы либо пишете monolithic application я использованием actor pattern, либо кучу services, каждый из которых вы может потом либо переписывать, либо убирать, либо scale.
Что же здесь плохого? Модель акторов мы уже обсудили, она может быть использована в любом приложении, она ортогональна микросервисам. Это базворд, потому что вы не понимаете его сути и лепите куда попало. Куча сервисов тоже базворд, потому что это никак не затрудняет возможность рефакторинга монолитного приложения. Переписать можно все что угодно. Убирать тоже можно все что угодно. По поводу масштабирования тоже базворд, вы не понимаете сути построения приложения. Например, используя gossip протокол я могу приводить к консенсусу кучу инстансов монолитного приложения. Оно так же может быть отмасштабировано добавлением и удалением нод и это тоже ортогонально микросервисам.
Что же мы видим в книге и почему это не набор базвордов? Все очень просто. Автор описывает словами как и где не нужно использовать микросервисы. Он не просто бросается словами и пишет: "мы тут скейлимся за счет акторов, а ваши монолитные приложения так не могут". Видите разницу? Он ни где там не пишет что монолитные приложения устарели и всем пора переписать все на микросервисах.
> Вы уже 10 раз повторили что я не понимаю причину и следствие,а по моему это у вас в голове каша полная.
Очень давно мне задали вопрос про работу MMU и я такой радостный начал выкрикивать слова вроде прерываний, аллокации памяти, виртуального и реального режима. Все это было чушью, ибо я не мог это объяснить словами. Да, я посидел с осцилом, почитал книги по микроэлектроннике, написал собственную реализацию процессора и только потом смог объяснить что же это такое. Вот когда вы сможете своими словами объяснить чем же плохи монолитные приложения, а не будете выкрикивать scale! docker! ci! services! как Стив Баллмер на конференции, тогда я приму ваше мнение как что-то стоящее, а сейчас это _набор базвордов_.

0

"И сервисы, которые скейлятся это из области булшит бинго. Вы теряете минимум два сискола и контекст свеча и сеть у вас ни разу не рилаебл."
Это не из области булшита, это из реальной жизни, когда можно scaleout количество вебсерверов при повышенной нагрузке и scale down когда пользователи идут спать, а так scale up и scale down database. Выигрыш по деньгам и доверию клиентов очевиден.

0

Latency вы никак не убавите, а только умножите, хоть 1млрд инстансов поставьте в параллель, т.к. то, о чем вам пишет умный человек (под ником Гала) это константный оверхед взаимодействия компонентов. Чем больше компонентов, тем больше издержек их коммуникации в сумме и задержек.

Вебсервер и база данных - это не микросервисы ни разу.

0

Latency никто и не уменьшит, она возрастет, никто и не сказал что это плохо -все зависит от business requirements. CAP theorem как раз об этом и есть - вы либо выбираете availability, либо consistency.

0

Тогда в чем плюсы решения то ?
При таких очевидных издержках ?

И что нового может предложить технология (или подход) микросервисов по сравнению с тем, что я перечислил ранее (RPC, COM/DCOM, CORBA, Grid) ?

0

Кто сказал что микросервисы это принципиально что то новое? Это такой же термин как RPC,....
Почитайте что такое микросервисы здесь. Я не понимаю о чем вы спорите.
smartbear.com/learn/api-design/what-are-microservices/

0

Конечно не понимаете, т.к. вопросом, очевидно, не владеете.

А тем не менее, я спрашивал ранее:

"Тогда в чем плюсы решения то ?
При таких очевидных издержках ?
И что нового может предложить технология (или подход) микросервисов по сравнению с тем, что я перечислил ранее (RPC, COM/DCOM, CORBA, Grid) ?"

Вот и весь "спор". Ответа нет - это тоже ответ ;-)

0

Я вижу вы очень любите хамить и по делу ничего не говорите. Вы спросили про методологию тестирования в нетфликс? Я вам дала ссылку. Но она вам не нравится, потому что там нет слова Microservice. Вот вам ссылка про микросервисы в нетфликс www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/

По поводу плавать это очень смешно, спасибо что мне напомнили термины из 90ых. я их уже позабыла ))))

0

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

Но тем не менее, поучаете нас, практиков, сказками про "нормальные компании".

Просто смешно !

Вам уже дали дельный совет: хотя бы Таненбаума прочитать.

Могу только к нему присоединиться.

0

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

Про звон это скорее про вас. В нашей компании мы уже начали писать микросервисы 3 года назад и уже сэкономили $300-400K. Про звон расскажите лучше архитектору ASOS или, например, Дино Эспозито.
А что мне читать, я, спасибо, сама решу. Ваши знания, похоже устарели лет на 5-10.

0

Ну почему же ? Я задавал вам конкретные вопросы, а в ответ только ссылки и ни одной своей мысли, про техническую сторону даже и говорить нечего

>В нашей компании мы уже начали писать микросервисы 3 года назад и уже сэкономили $300-400K. Про звон расскажите лучше архитектору ASOS или, например, Дино Эспозито

Это технические аргументы или как ?

Очередное понтование, а конкретики нет ;-)

0

Какая вам еще конкретика нужна? Про микросервисы уже столько написано, в том числе микрософтом. На все конференции которые я езжу, всегда что то есть про микросервисы.
Я вам уже написала про работу команд, релизы. Добавлю еще что работу над определенным микросервисом можно аутсорсить и сэкономить на разработке, или команды могут находится в разных городах или странах. Или каждая команда может выбирать свои технологии. У этого всего конечно тоже есть минусы, и надо конечно с умом подходить ко всему, но это не только работы касается. Но зато появляется выбор.

"Это технические аргументы или как ?" -Вы технических аргументов вообще не привели. Я просто вам говорю что многие компании применяют эту методологию в своих проектах, и если ваш проект похож на их, то есть смысл почитать и решить, нужно вам или нет.
Если не похож - нужно делать то, что имеет смысл, но по моему это такие вещи, про которые писать даже не надо, это и так понятно.

"Не приходилось и не придется, т.к. я сразу делаю как надо, без технического долга"
Дело не в техническом долге, а то что может появится новая технология, более подходящая для вашего сервиса, и переписать все равно придется, чтобы например улучшить скорость или снизить затраты на инфраструктуру. Или например появится миллион пользователей вместо запланнированых 50 тысяч, и все равно все придется переписывать.

0

Но в любом случае, за ссылки спасибо !

0

Плюсов очень много, например организационные. Каждая команда работает параллельно и делает релизы паралелльно.
Существует прозрачность нагрузки, откуда идут баги, что используется в системе а что нет. Refactoring можно сделать тоже отдельного компонента, а не всей системы, что практически невозможно. если что то не используется, этот код можно просто выбросить и его не придется maintain. Минусы там тоже есть конечно, просто с ними надо научится работать .

Вот цитата из статьи которую я вам уже дала

Examples of Microservices

As Martin Fowler points out, Netflix, eBay, Amazon, the UK Government Digital Service, realestate.com.au, Forward, Twitter, PayPal, Gilt, Bluemix, Soundcloud, The Guardian, and many other large-scale websites and applications have all evolved from monolithic to microservices architecture.

Netflix has a widespread architecture that has evolved from monolithic to SOA. It receives more than one billion calls every day, from more than 800 different types of devices, to its streaming-video API. Each API call then prompts around five additional calls to the backend service.

Amazon has also migrated to microservices. They get countless calls from a variety of applications—including applications that manage the web service API as well as the website itself—which would have been simply impossible for their old, two-tiered architecture to handle.

The auction site eBay is yet another example that has gone through the same transition. Their core application comprises several autonomous applications, with each one executing the business logic for different function areas.

0

Собственно, все эти плюсы имели и старые технологии и подходы, тем более, что не зря Гала говорил про SOA:

"Netflix has a widespread architecture that has evolved from monolithic to SOA"

Параллельная работа вообще возможна и при монолитном подходе, если заранее определяются интерфейсы.

Так что таки очередной маркетинговый булщит ч.т.д.

Но я спор не ради спора начал и ответ на свой вопрос знаю.

На самом деле плюс только один:

При таком подходе можно перезапускать не всё приложение целиком (как при монолитном подходе), а только его часть (или части). Любители же микросервисов суют их к месту и не к месту "чтобы как у Амазона было". ;-)

0

Похоже вам никогда не приходилось refactoring делать :)))

0

Не приходилось и не придется, т.к. я сразу делаю как надо, без технического долга.

Напомню, с чего началась наша дискуссия.

Коллега Гала выдвинул тезис:

>Не надо ничего разбивать, надо нанимать адекватных людей, платить много денег и завышать строки 2.5x

Короче, уметь надо и сперва думать, а потом делать (да, это не Аджайл, ну и черт с ним тогда)

0

"Вебсервер и база данных - это не микросервисы ни разу"

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

0

Вы очевидно плаваете в теме, иначе как объяснить то, что в контексте обсуждения преимуществ/недостатков микросервисов вы написали о БД и Вебсерверах - это раз, а два - привели статью про Нетфликс, где опять таки, о микросервисах ни слова.

0

Про сайтик вы наверное пошутили да, CI уже давно делают все большие нормальные компании.

Какой-то поток сознания.
> России в резюме можно написать вообще всё, что угодно, никакого доверия сертификатам, а проверять будут все равно так, как будто вчера институт закончил, при этом отдавая предпочтение однокурсникам.
Не можно. В нормальных компаниях уже давно есть интервью на алгоритмы и архитектуру, никаких предпочтений однокурсникам нет, потому что собеседуют люди из других отделов.
> Лично я вообще не встретил за 4 года в Москве вообще ни одного архитектора, все либо глубоко законспирировавшиеся менеджеры продукта, либо вообще пользователи ПК Visio, имеющие сугубо абстрактное представление о предмете.
Вам поименно перечислить знакомых архитекторов в Касперском, 1С, Яндексе, ФРИИ, Lazada и прочих компаниях с офисами в Москве?
> Так и получается, что в условиях отсутствия жесткой конкуренции все бросаются на "универсалов", и под iOS чот-то криворукое слабать, и страничку HTML наковырять, главное уметь сделать картинку, а уж как оно внутри работает - лучше вообще не спрашивать.
Вы в какой-то параллельной реальности живете. Конкуренция огромная, просто вы не сталкиваетесь, например, с выпускниками МФТИ, которые к 3 курсу имеют опыт стажировки в Google, вы им просто не интересны. Если повезет, то они доберутся в худшем случае до Mail.ru, в лучшем до Яндекса.

Вот как в реальности транслируются принципы Agile в Москве:

Ценности гибких методологий задекларированы в Agile-манифесте. Их четыре:

1. ​Люди и взаимодействие важнее процессов и инструментов.

Да, поэтому берем однокурсников гендира, сотрудников, имеющих смутное представление о предмете работы в принципе, зато лид и взаимодействие будет важнее процессов и инструментов. Точно, Инструментам можно научить, кажется?

2. Работающий продукт важнее исчерпывающей документации.

Абсолютно верно, поэтому на десять тысяч строк кода будет как максимум сто копирайтов, а чаще всего вообще ни одного адекватного комментария, кроме авто документируемых функций

3. Сотрудничество с заказчиком важнее согласования условий контракта.

О-да, если заказчику захочется вдруг вмешаться в процесс дизайна приложения и UI/UX, нужно смело браться за работу, пытаясь реализовать понимание заказчиа о продукте. Постойте-ка, на минуточнку, а какое может быть представление о продукте у заказчика, если он его в глаза не видел? Может быть, увидев свои желания - он ужаснется своим представлениям о usability? Получим очередной Excel в форм-факторе iPhone4?

4. Готовность к изменениям важнее следования первоначальному плану.

Ну конечно, в российских условиях это превращается. Сдать заказчику на от*бись. Мы планировали собственный дизайн?Заказчик приволок "своего" дизайнера, вообще не имеющего представление о UI/UX? Замечательно! Выкидываем все нафиг! Или по-другому - наш супер-пупер программист сделал "как умеет", все сдаем, говорим что это наша концепция UI/UX подготовилась к изменениям, мы же готовы, что всегда будет получаться г*вно? Готовы! Ну и зае*ись!

0

Ого, какой мощный эксперт нарисовался. На основе каких исследований такие заявления делаете?

Прямой эфир
Голосовой помощник выкупил
компанию-создателя
Подписаться на push-уведомления