ИМХО, анализ политической информации имеет такое же право на попадание на главную на хабре, как и анализ обезличенной медицинской, демографической или полётов самолётов. То, что в комментариях пустились во все тяжкие, это скорее не про статью, а про людей.
Да, в нашем случае табличка весит пару сотен гигабайт и изменений схемы занимает 2 дня. Вы верно отметили, что тут про процессы, а не про микросервисы. Я даже скорее про релиз говорю, и про скорость изменений.
Мы действительно о несколько разных вещах говорим.
Комментарий GreedyIvan примерно описывает что я понимаю под монолитом и его проблемами, с которыми в концепции DevOps разработчики борятся. ИМХО, адекватный уровень автоматизации доставки гораздо ближе к сферическим микросервисам в вакууме — при большой базе (кода и данных) приходится грамотно разделять компоненты и деплоить их по-одному или несколько (но не обязательно все сразу).
Если тестировать нужно меньше, значит вы как-то изолировали влияние компонента на другие части системы. То есть у нас низкая связанность. Что вам мешает делать монолиты с низкой связанностью?
Верно, я не озвучил очевидное для меня допущение — релиз монолитного приложения по процессу занимает от часа до недели. В случае, если релиз приложения можно выкатить за минуту (и откатить за секунду), то, конечно, делить его смысла нет.
В Longhorn им пришлось выкинуть в мусорку несколько человеко-лет работы потому, что они хотели зарелизить всё и сразу и некоторые компоненты (WinFS в частности) оказались ненужны на момент релиза.
Потому, что вместо релиза, скажем, Windows, происходит релиз только отдельного компонента и соответственно тестировать нужно меньше. И это можно сделать умнее, чем просто «тестим всё» при релизе монолита. Кроме того, если над каждым микросервисом работает отдельная команда, то одни могут релизиться каждую среду, другие — каждый четверг и т.д. В случае зависимости микросервисов релиз также будет завязан друг на друга, но в монолите по факту такое происходит каждый раз.
Опять же, зависит от количества команд. Чем больше, тем сложнее релизить монолит часто.
Верно, разбиение не даст возможность релизиться чаще. Даже наоборот, каждый отдельный микросервис будет релизиться реже (вплоть до N раз в идеальном случае), что как раз снижает накладные расходы.
Проблема не в монолите, в скорости изменений. Можно ли монолит релизить несколько раз в день? Гипотетически да, но зачем так жить?
Второй момент — стоимость железа. Гектар оперативы стоит копейки и довольно часто баланс между скоростью разработки и стоимостью поддержки в деньгах чаще выражается в большей эффективности быстрой разработки.
Конечно, в отдельных отраслях это неразумно, но, я надеюсь, в них люди на хайп не байтятся.
Да, неплохо бы посмотреть как общественное мнение коррелирует с победителем. Взять, например, архив прессы за 20-й век и посмотреть на аналогичные показатели, с какого-то года подмешать Twitter, Facebook, YouTube.
А так — можно просто пойти на IMDB или Кинопоиск и посмотреть оценку и отзывы, думаю, будет даже релевантнее.
Slack себя позиционирует больше, чем IM. Они говорили, что в слак каналы можно постить всё подряд — тикеты из zendesk, сообщения из электронной почты, видео, фотки и, естественно, обсуждения. К тому же сами чаты делаются только для определённого круга лиц, в отличие от чатов, где все видят всех. То есть многие компоненты были и раньше, но по отдельности. Slack их удачно скомбинировал и скормил малому-среднему бизнесу. Причём настолько хорошо зашло, что имхо слаком начинают заменять то, к чему он изначально не приспособлен. Собственно так я понимаю посыл автора статьи.
> Лично мне кажется, что это очень хорошее решение проблемы рекламы в интернете.
Реклама в интернете — это проблема? Точно также будут резать скрипты, которые майнят.
ИМХО, майнинг вместо показа рекламы порождает гораздо больше глобальных проблем. Не считая того, что огромные вычислительные ресурсы тратятся впустую, сжигая массу энергии вникуда, сами монеты — слишком волатильны, по сути спекулятивны. И редкие сайты захотят переключиться на такой источник дохода, который сегодня приносит миллионы, а завтра — только делает, что нагружает девайсы юзеров, снижая отзывчивость интерфейса и создавая шум от систем охлаждения, тем самым заставляя их уйти с назойливого сайта.
Если следовать подходу, вынесенному в заголовок, кандидату следует прямо сообщать "Вы берётесь на позицию заткнуть провал в ресурсе, Ваша зарплата в долгосрочной перспективе неадекватна, но мы со всей этой фигнёй попробуем взлететь как-нибудь это решим". Правда тогда я не понимаю, как эта ситуация проходит "псевдопубличный" тест.
То есть принципы по отдельности я понимаю, но несостыковки между ними одним "это жизнь" не закроешь.
Прочитал статью и вперёд, и взад, и по диагонали. Долго не мог понять что меня в ней смущает. Потом дошло. Субъективный опыт и повелительные наклонения не очень сочетаются. Подобный опыт (помноженный на Ваши убеждения), имхо, можно получить за пару лет тимлидства при адекватной ретроспективе.
Очень интересно было бы почитать про то, как HR'ы помогают техдирам в продуктах Яндекса. Без этого, к сожалению и сугубо имхо, статью можно свести к двум предложениям. Ведь как бы ни была налажена коммуникация с непосредственным начальником (даже если это CTO), есть вещи, которые ему/ей не говорят. Кроме того вы ведь не изобретаете велосипед каждый раз и есть какие-то фреймворки по развитию карьеры сотрудников во всех подразделениях?
Зачем городить такой огород, если можно просто сделать docker run? Который по капотом, конечно, делает примерно то же самое, но не заставляет об этом думать (по крайней мере так часто).
github.com/awslabs/aws-sam-local
Мы действительно о несколько разных вещах говорим.
Верно, я не озвучил очевидное для меня допущение — релиз монолитного приложения по процессу занимает от часа до недели. В случае, если релиз приложения можно выкатить за минуту (и откатить за секунду), то, конечно, делить его смысла нет.
Опять же, зависит от количества команд. Чем больше, тем сложнее релизить монолит часто.
Второй момент — стоимость железа. Гектар оперативы стоит копейки и довольно часто баланс между скоростью разработки и стоимостью поддержки в деньгах чаще выражается в большей эффективности быстрой разработки.
Конечно, в отдельных отраслях это неразумно, но, я надеюсь, в них люди на хайп не байтятся.
А так — можно просто пойти на IMDB или Кинопоиск и посмотреть оценку и отзывы, думаю, будет даже релевантнее.
Реклама в интернете — это проблема? Точно также будут резать скрипты, которые майнят.
ИМХО, майнинг вместо показа рекламы порождает гораздо больше глобальных проблем. Не считая того, что огромные вычислительные ресурсы тратятся впустую, сжигая массу энергии вникуда, сами монеты — слишком волатильны, по сути спекулятивны. И редкие сайты захотят переключиться на такой источник дохода, который сегодня приносит миллионы, а завтра — только делает, что нагружает девайсы юзеров, снижая отзывчивость интерфейса и создавая шум от систем охлаждения, тем самым заставляя их уйти с назойливого сайта.
Если следовать подходу, вынесенному в заголовок, кандидату следует прямо сообщать "Вы берётесь на позицию заткнуть провал в ресурсе, Ваша зарплата в долгосрочной перспективе неадекватна, но мы
со всей этой фигнёй попробуем взлететькак-нибудь это решим". Правда тогда я не понимаю, как эта ситуация проходит "псевдопубличный" тест.То есть принципы по отдельности я понимаю, но несостыковки между ними одним "это жизнь" не закроешь.
Очень интересно было бы почитать про то, как HR'ы помогают техдирам в продуктах Яндекса. Без этого, к сожалению и сугубо имхо, статью можно свести к двум предложениям. Ведь как бы ни была налажена коммуникация с непосредственным начальником (даже если это CTO), есть вещи, которые ему/ей не говорят. Кроме того вы ведь не изобретаете велосипед каждый раз и есть какие-то фреймворки по развитию карьеры сотрудников во всех подразделениях?