Ок. Мы проставили теги. Возможно мы много тегов проставили, поскольку оцениваем несколько качеств. Как дальше мы на основе текстовых тегов приоритезируем бэклог?
При всех этих подходах необходимо разделение бэклогов (даже для одно приложения) на пользовательские и, скажем так, системные. Все что связанно с архитектурными изменениями, рефакторингами и т.д. должно оцениваться в разрезе снижения костов или повышения качества, а это уже не ICE/RICE.
Такой подход наиболее эффективен при очень большом бэклоге для компании на b2c рынке. Там фишка в том, что 80% бэклога никогда не будет сделано и надо делать то, что горит прям сейчас ибо конкуренты не дремлют. Отсюда довольно простая логика сводящаяся к сравнению циферок.
Ну и добавлять в мониторинг каждый раз новый сайт неудобно, а так у нас вместо тысячи проверок на тысячу сайтов всего одна проверка с сутью "все LE сертификаты свежи".
Да, certbot renew в теории должен обновлять их, но сайты живые, постоянно разрабатываются, причем разными людьми и с ними иногда происходят разные чудеса. То поменяется DocumentRoot, то появятся правила rewrite/redirect, которые блокируют проверку, то доменное имя куда-то уедет... В общем, обновления иногда фейлятся и сертификаты протухают. А когда сайтов много, что-то проблемное случается регулярно.
Ааа. Вот в чем проблема. Ну pip install в вашей жизни ничего не решит толком. Надо исправлять саму возможность возникновения подобных проблем, а не отказываться от certbot renew.
Просто добавить в bashrc. Если уж написали эту строчку, то сделать ее переиспользуемой не сложно.
Атеперь, представьте, что мы хотим не просто увидеть дату, а еще и как-то что-то сделать, если до истечения останется меньше 20 дней... как будет выглядеть команда?
Зачем это делать через какие-либо скрипты? Если вы используете LE, то у вас должна в кроне стоять задача на замену сертификата, как это рекомендуется создателями этой системы. И там все за вас уже сделано.
Ну и должен быть мониторинг, а любой мониторинг умеет в проверку сертификатов.
Т.е. showcert без сомнения хорошая, удобная вещица для ad-hoc проверок. Но при чем здесь shell, флот и триггер скриптов мне не понятно.
У нас компания в джунах и стажерах обычно заинтересована. Я лично нанял или собеседовал с успехом 4 стажеров, два по-прежнему с нами, два в хороших компаниях заграницей. Найм же джунов и около джунов с прицелом на рост для меня обычная история. Плюс служба саппорта, которая студентов коллекционирует (удобный, хотя иногда тупиковый вариант для начала карьеры).
Обычно обращаю внимание на системное мышление, интерес к IT и интерес к вакансии. А вопросы задаю по резюме, не ожидая, что человек знает сходу то, что мне нужно, но подразумевая, что он готов отвечать за знания, которые заявил.
Но вот еще не разу я не взял "вайтишника". Выдел у людей курсы в резюме, но все они отзывались о них плохо, говоря, что просто делая что-то на коленке для себя или универа или в open source они получали больше знаний.
Монолит также может быть горизонтально отмасштабирован с load balancer-ом и high availability.
Обычно это сложнее. Когда говорят, что микросервисы могут легко масштабироваться, разумеется имеют ввиду, что хорошо масштабируются сервисы без состояния. Все, что имеет состояние вызывает проблемы. Ну и монолит этой проблеме подвержен также.
Вторая проблема это неравномерное масштабирование. В больших комплексах часто надо масштабировать конкретную функцию, а не весь объем кода. Размножать весь монолит, ради одной функции нелепо. И тут мы приходим к давней идее аппликейшен серверов, RPC, DI, resource pooling и прочего. Называется по-другому, но в общем-то это тоже микросервисы и контейнеры, только без k8s и https everywhere.
ИМХО, Java хорошо переживает тысячи разрабов в одной репе благодаря всей этой сложившейся культуре с иерархией архитектор-->team lead --> senior --> middle --> junior.
Плюс там паттерны заточены под переиспользование кода с минимальными последствиями.
У кого сотня микросервисов, как вы живете, страдаете?
Микросервисы это не столько архитектурная, сколько организационная проблема.
Нужна команда SRE. Программистам хода на продакшен нет. Никогда.
Нужен хороший CI/CD
Нужна строгость в сборке и деплойменте: -snapshot.jar недопустим (он так-то никогда недопустим, но кого это останавливает)
Как можно больше статических проверок контрактов. Как раз в Java c этим прекрасно (хотя я не Java прогер, могу ошибаться)
Как можно больше асинхрона для уменьшения связности.
SDET и QA Automation.
При выполнении этих и еще ряда условий (в том числе архитектурных) масштабируемость резко возрастает и увеличивается независимость команд. Хотя и не ясно нужно ли это конкретно вам.
Есть мифы, частично упомянутые в статье:
Сервис дискавери это сложнА! - Нет, не сложно, поскольку там очень шаблонированный код, особенно в наше время. Да и в большинстве случаев все ограничивается k8s и terraform и не доходит до Consul и Zookeeper
Мониторинг сложнее чем в монолите - Нет, не сложнее. Если не делать архитектурных глупостей, то мониторинг можно шаблонировать и выйдет примерно как с монолитом. А еще раскурить ELK и OpenTelementry. Ну и главная проблема мониторинга едина для всех подходов: необходимо каждый параметр описать и определить диапазоны, а на это уходит дикое количество времени.
Деплоймент это сложнА! - Для программистов да, хотя не то чтобы сложно, а непривычно и ненужно. Но для этого есть отдельные специалисты: SRE, DevOPS, QA
Имхо, с микросервисами есть одна ловушка: когда компания готова к микросервисам, разработка монолита для нее бессмысленна, но вы можете ошибаться, думая, что вы к этому готовы.
Все дело в том как конкретно применяют Swagger. В библиотеках на Python принята идеология "code first", когда схема генерируется по уже готовому API (например Django DRF) и тогда возникает куча проблем с несовместимой схемой, на это забивают и в конечном счете от сваггера не остается ничего.
Если же использовать логику "schema first", то выясняется, что прям хороших генераторов сервера для Python нет. А то что есть не дотягивает до уровня Fast API, например.
В других языках schema first может лучше работать, а может и хуже.
Что меня радует в MS, так это традиции: каждая вторая версия должна быть неудачной. Тут похоже та же история. И дело не в том, что чего-то там еще не сделано, а просто в дикой популярности предыдущей версии (10ой), которая не позволит взлететь сырым инновациям 11ой.
Да, про эту штуку я уже читал, но меня она немного подбешивает. Мне не нравится, что в python втащили синтаксис bash, перегрузив привычные операторы (если я правильно понял как оно устроено).
Т.е. синтаксис как бы разваливается на две части: обычный питон, и питон с магией.
Я бы предпочел более привычную для python историю. Что-то типа
Ну тогда это выходит эквивалентно выставлению одного числа. Например priority. Т.е. я не вижу какой-либо принципиально разницы с тем что в статье.
Ок. Мы проставили теги. Возможно мы много тегов проставили, поскольку оцениваем несколько качеств. Как дальше мы на основе текстовых тегов приоритезируем бэклог?
Не очень понятно что вы понимаете под "качественной" моделью. Так-то I в ICE/RICE это тоже вполне себе качество.
При всех этих подходах необходимо разделение бэклогов (даже для одно приложения) на пользовательские и, скажем так, системные. Все что связанно с архитектурными изменениями, рефакторингами и т.д. должно оцениваться в разрезе снижения костов или повышения качества, а это уже не ICE/RICE.
Такой подход наиболее эффективен при очень большом бэклоге для компании на b2c рынке. Там фишка в том, что 80% бэклога никогда не будет сделано и надо делать то, что горит прям сейчас ибо конкуренты не дремлют. Отсюда довольно простая логика сводящаяся к сравнению циферок.
А это действительно интересно.
Любая система мониторинга умеет в шаблоны.
Ааа. Вот в чем проблема. Ну pip install в вашей жизни ничего не решит толком. Надо исправлять саму возможность возникновения подобных проблем, а не отказываться от certbot renew.
Просто добавить в bashrc. Если уж написали эту строчку, то сделать ее переиспользуемой не сложно.
Зачем это делать через какие-либо скрипты? Если вы используете LE, то у вас должна в кроне стоять задача на замену сертификата, как это рекомендуется создателями этой системы. И там все за вас уже сделано.
Ну и должен быть мониторинг, а любой мониторинг умеет в проверку сертификатов.
Т.е. showcert без сомнения хорошая, удобная вещица для ad-hoc проверок. Но при чем здесь shell, флот и триггер скриптов мне не понятно.
У нас компания в джунах и стажерах обычно заинтересована. Я лично нанял или собеседовал с успехом 4 стажеров, два по-прежнему с нами, два в хороших компаниях заграницей. Найм же джунов и около джунов с прицелом на рост для меня обычная история. Плюс служба саппорта, которая студентов коллекционирует (удобный, хотя иногда тупиковый вариант для начала карьеры).
Обычно обращаю внимание на системное мышление, интерес к IT и интерес к вакансии. А вопросы задаю по резюме, не ожидая, что человек знает сходу то, что мне нужно, но подразумевая, что он готов отвечать за знания, которые заявил.
Но вот еще не разу я не взял "вайтишника". Выдел у людей курсы в резюме, но все они отзывались о них плохо, говоря, что просто делая что-то на коленке для себя или универа или в open source они получали больше знаний.
Обычно это сложнее. Когда говорят, что микросервисы могут легко масштабироваться, разумеется имеют ввиду, что хорошо масштабируются сервисы без состояния. Все, что имеет состояние вызывает проблемы. Ну и монолит этой проблеме подвержен также.
Вторая проблема это неравномерное масштабирование. В больших комплексах часто надо масштабировать конкретную функцию, а не весь объем кода. Размножать весь монолит, ради одной функции нелепо. И тут мы приходим к давней идее аппликейшен серверов, RPC, DI, resource pooling и прочего. Называется по-другому, но в общем-то это тоже микросервисы и контейнеры, только без k8s и https everywhere.
Можно эти свойства переложить на отдельные сервисы, например добавив MQ, или сделав связку MQ+ServerLess.
ИМХО, Java хорошо переживает тысячи разрабов в одной репе благодаря всей этой сложившейся культуре с иерархией архитектор-->team lead --> senior --> middle --> junior.
Плюс там паттерны заточены под переиспользование кода с минимальными последствиями.
Хотя усилий требуется не мало, конечно.
Микросервисы это не столько архитектурная, сколько организационная проблема.
Нужна команда SRE. Программистам хода на продакшен нет. Никогда.
Нужен хороший CI/CD
Нужна строгость в сборке и деплойменте: -snapshot.jar недопустим (он так-то никогда недопустим, но кого это останавливает)
Как можно больше статических проверок контрактов. Как раз в Java c этим прекрасно (хотя я не Java прогер, могу ошибаться)
Как можно больше асинхрона для уменьшения связности.
SDET и QA Automation.
При выполнении этих и еще ряда условий (в том числе архитектурных) масштабируемость резко возрастает и увеличивается независимость команд. Хотя и не ясно нужно ли это конкретно вам.
Есть мифы, частично упомянутые в статье:
Сервис дискавери это сложнА! - Нет, не сложно, поскольку там очень шаблонированный код, особенно в наше время. Да и в большинстве случаев все ограничивается k8s и terraform и не доходит до Consul и Zookeeper
Мониторинг сложнее чем в монолите - Нет, не сложнее. Если не делать архитектурных глупостей, то мониторинг можно шаблонировать и выйдет примерно как с монолитом. А еще раскурить ELK и OpenTelementry. Ну и главная проблема мониторинга едина для всех подходов: необходимо каждый параметр описать и определить диапазоны, а на это уходит дикое количество времени.
Деплоймент это сложнА! - Для программистов да, хотя не то чтобы сложно, а непривычно и ненужно. Но для этого есть отдельные специалисты: SRE, DevOPS, QA
Имхо, с микросервисами есть одна ловушка: когда компания готова к микросервисам, разработка монолита для нее бессмысленна, но вы можете ошибаться, думая, что вы к этому готовы.
Все дело в том как конкретно применяют Swagger. В библиотеках на Python принята идеология "code first", когда схема генерируется по уже готовому API (например Django DRF) и тогда возникает куча проблем с несовместимой схемой, на это забивают и в конечном счете от сваггера не остается ничего.
Если же использовать логику "schema first", то выясняется, что прям хороших генераторов сервера для Python нет. А то что есть не дотягивает до уровня Fast API, например.
В других языках schema first может лучше работать, а может и хуже.
А что это за "профильный" чат. Он тайный, или туда можно попасть?
По моим ощущениям этой истории уже много лет (10-15) и это банальная калька с английского, где слово expertise может использоваться в этом значении.
https://dictionary.cambridge.org/dictionary/english/expertise
Что меня радует в MS, так это традиции: каждая вторая версия должна быть неудачной. Тут похоже та же история. И дело не в том, что чего-то там еще не сделано, а просто в дикой популярности предыдущей версии (10ой), которая не позволит взлететь сырым инновациям 11ой.
Ждем 12ю?
Как бы потом, смотря на скрипт в 10к строк не пришлось за стаканы браться.
Да, про эту штуку я уже читал, но меня она немного подбешивает. Мне не нравится, что в python втащили синтаксис bash, перегрузив привычные операторы (если я правильно понял как оно устроено).
Т.е. синтаксис как бы разваливается на две части: обычный питон, и питон с магией.
Я бы предпочел более привычную для python историю. Что-то типа
И да, такое можно сделать и даже вроде как не сложно, но сила привычки велика.