Было бы с PMI все было хорошо, то не было бы и ITIL/ITSM, и Agile/Scrum. Просто везде свое. И, конечно, тут панацеи нет, нужно смотреть что за задача и окружение, а уж после под это подбирать решение.
Для определенности, буду писать только об ИТ-проектах.
В этом случае вся разработка инкрементальна, а вот ценность может быть бинарна (когда подписали акт, например).
Скрам, прежде всего, это организационный фреймворк. Просто невозможно говорить о Скраме, когда у вас нет скрам-мастера, команды и владельца продукта как отдельных людей. Это уже просто не Скрам (повторение любых артефактов или собраний ничего от Скрама не даст -- все они были и до Скрама, может быть под другими названиями).
Да, Скрам делался для продуктов. Вполне возможно использовать его и для достаточно длинных контрактов (особенно если команда уже была сформирована и до конкретного контракта).
Немного о проектном треугольнике: время, стоимость, функционал и качество. В классических проектах небольшая группа экспертов это все оценивает, затем контрактом фиксирует. При этом возникают проблемы при реализации, на то он и проект, а не процесс. Тогда чем-то нужно жертвовать. В классических проектах начинают смотреть в контракт и жертвуют недоописанными вещами (качество и функционал), при адекватных заказчиках увеличивают стоимость (change request), иногда еще жертвуют своей прибыльностью (увеличивают время). Agile (не только скрам) же говорит, что мы фиксируем стоимость и время, о качестве тоже договариваемся (но можем поменять по желанию заказчика), а функционал делаем с самого критичного до самого некритичного (и предполагаем, что на горизонте в полгода-год к нам еще придет бизнес и скажет, что приоритеты теперь другие).
Понятно, что у заказчика всегда есть подозрение, что люди не будут работать, поэтому это проще достигается с внутренними командами.
А роль Скрама здесь -- это как раз мотивировать команду и прозрачно показать весь процесс заказчику.
Теперь немного комментариев по тексту:
Scrum - это не метод управления проектами
Метод управления, но не всеми вариантами проектов, есть ограничения (минимальные размеры проекта прежде всего).
Скрам не умеет контролировать попадание в "проектный" треугольник Time - Budget - Scope, фактически он фокусируется только на удовлетворенности заказчика.
Умеет. Точнее никто не умеет, всегда чем-то жертвуют.
Вывод - Скрам хорошо подходит для разработки новых продуктов в области программного обеспечения. И очень ограниченно подходит для аутсорсинговых проектов, тем более не софтверных.
Если проект достаточно длинный (от полугода со стабильной командой), то, по моему опыту, Скрам вполне применим. При этом о том, что он практикуется заказчику вообще нет особой нужды знать -- это внутренний способ работы аутсорсера.
Scrum ничего не знает о дедлайнах или фиксированном бюджете
Как раз наоборот: у Скрама всегда фиксированный дедлайн и бюджет. При этом в самом Скраме совсем не описано как оценивать сложность/длительность задач, это можно делать как и без Скрама делаете. Скрам лишь позволяет выстроить процесс постепенного приблежения к цели с максимальной отдачей за единицу затрат в любой момент времени.
Поэтому даже если внешне это может выглядеть как Скрам, по сути таковым оно часто не является, если нет ценного, полезного инкремента в каждом спринте.
Похоже на передергивание. Понятно, что в самом начале, когда мы добавили, например, только авторизацию, продукт еще нельзя использовать конечными пользователями, но так же и нельзя сказать, что в спринте ничего ценного не добавили. Ценное -- добавили, заказчику -- показали, а выпускать текущий артефакт на пользователей заказик решает сам -- когда, на какую группу и тп. Другими словами под ценным мы понимаем видимое продвижение к цели продукта, а не возможность продукта сразу же быть использованным, тк да, бывают ситуации, когда это невозможно.
Вывод - перед началом проекта нужно проверять, возможно ли поставлять инкрементами что-то полезное заказчику и получать с этого обратную связь для коррекции работ.
Обратную связь всегда возможно получать. Если даже нет, то это особо ничего не меняет -- лишь добавляет дополнительный этап опытно-промышленной эксплуатации, когда заказчик бужет уже смотреть. При этом Скрам команда с самого начала все так же итеративно поставляет сборки, которые могут быть продемонстрированы заказчику, чтобы показать, что прогресс идет, или отданы отдельной команде тестирования (если уж заказчик не хочет смотреть промежуточные этапы).
Scrum - командный подход
Вывод - Скрам требует наличия сплоченной самоорганизованной команды. Нужно заранее продумать, есть ли она, или как её планируется создать.
Тут полностью согласен. Только сформулирую по-другому: нужно заранее понимать необходимость формирования команды (и это и есть основная задача скрам-мастера) и должно быть достаточное количество времени и стабильность команды, чтобы это имело смысл. Иначе нужно использовать не Скрам, а что-то другое.
Scrum опирается на кросс-функциональную команду
Вывод - Перед началом проекта проверить действительно ли кросс-функциональна команда, либо найти способ обойти это (напр. замена QA автотестами, вовлеченность команды в планирование с PO – аналитик не нужен).
Немного не так. Не обязательно, чтобы все отделы работали по Скраму (или все команды по контракту работали по Скраму). Например, IT обычно по Скраму не работают. Не обязательно, чтобы каждый член команды все мог (хотя это и мечта и традиционных руководителей проектов). Важно, чтобы задачи, который попадают в команду, могли бы быть решены этой командой. Например, дизайнеров можно вывести из Скрам-команды в команду владельца продукта, если они, в основном, будут нужны эпизодами. Аналитики и QA могут быть как внутри, так и снаружи -- опять же зависит скорее от кол-ва часов, которые они тратят на этот проект.
В Scrum достаточно высокие накладные расходы на "церемонии"
Вывод - Скрам поощряет работу короткими спринтами для быстрой адаптации к меняющимся требованиям, но слишком короткие спринты (одна - две недели) влекут за собой достаточно высокие накладные расходы на церемонии Скрам.
Есть такая проблема, но она разделяется на:
- дейли так или иначе обычно есть всегда, вполне понятно как их контролировать по времени
- демо позволяют получить обратную связь от заказчика и далее правильнее принимать тысячи мелких решений, которые программист делает чуть ли ни ежедневно, так что вполне себе окупаются
- ретро призваны повысить эффективность уже со следующего спринта -- т.е. окупаются моментально или проводятся как-то не так
- бэклог груминг -- тут сложнее всего контролировать время. Например, иногда на груминг берут не всех людей из команды, если это скорее совещание с аналитиками и дизайнерами по первоначальным уточнениям от разработчиков. Опять же на уровне ТЗ (когда еще нет кода) проще всего исправить проблемы (например, найти нестыковку с другим функционалом) и тут нужна вся команда (и тогда это окупается), но сами задачи уже должны быть достаточно хорошо проработаны.
Scrum не масштабируется на большие команды, и не умеет управлять паралельными потоками связанных работ
Вывод - при работе нескольких команд над одним продуктом Скрам как таковой уже не подходит, применяются другие подходы - SAFe, LeSS.
В целом -- да, но нельзя прям сказать, что другие. Скрам обычно остается на нижнем уровне и появляются надстройки для управления многими скрам-командами. Тут еще часто появляются микросервисы, чтобы отделить команду от команды.
Сторонники Scrum скупы на критику
Вывод - придется во всем разбираться самому, на помощь со стороны сильно не надейтесь.
Ну, и у нас есть подобные профессионалы. Есть книги, конференции, тот же Хабр, но да, если в вашей компании нет опыта, то нужно его нарабатывать. И сначала на не самом критичном проекте. А лучше найти человека в штат с опытом.
Scrum побуждает к привлечению внешних специалистов - Скрам-мастеров и Agile коучей
Вывод - у Agile коуча всегда много вопросов и нет ответов.
Мое искреннее мнение -- скрам-мастер не может быть внешним, это основа Скрама.
Нужен коуч или нет и в каком формате -- все решают сами, тут ничего нового.
Высокие требования в Scrum к Владельцу Продукта (Product Owner)
Скрам не предусматривает достаточный по времени этап сбора и анализа требований. Откуда они возьмутся, как правильно оценить их взаимосвязь, влияние на бизнес, выставить приоритет - ответов Скрам не даёт.
Вывод - без толкового Владельца продукта процесс не полетит. А найти такового очень непросто.
Не согласен. Как раз в традиционном подходе заказчик изначально все подписывает и получает, что подписал. Или платить кучу денег за дополнительные соглашения. Agile (даже не Скрам) позволяет заказчику уточнять задачу по мере увеличения понимания. Не обязательно запускать Скрам с момента подписания контракта или запуска нового продукта -- какое-то время до начала разработки может проводиться первоначальный анализ, прототипы дизайна и UI, это никак не противоречит Скраму, тк скрывается за абстракцией владельца продукта, а скрам-команда либо еще не начала работать, либо занимается какими-то заранее известными задачами (пишет интеграции с другими системами, например).
Резюмируем сказанное
Понятно, что резюме тоже другое. Для длительных проектов или продуктов Скрам вполне себе подходит, но нужно четко понимать роль скрам-мастера, иначе это просто не Скрам.
PS: Большое спасибо автору за статью, тему поднимать надо и рассуждать об этом тоже полезно всем.
В целом, можно представить себе схему когда у нас есть "монолит", который состоит из кучи библиотек (вместо отдельных сервисов).
Все-таки наличие таких библиотек необходимо (с какого-то размера), чтобы команды могли независимо делать эксперименты (если нет множества разных команд с разными целями и сроками, то и микросервисы, и библиотеки не нужны особо).
Таким образом, мы уходим от сетевых задержек. Какие при этом могут быть минусы?
- необходимость возможности старта всей системы на одном сервере: если используются локальные кеши, то такое не всегда возможно - увеличенное время сборки, но при этом вся система стартует локально (что удобно для разработчиков) - необходимо для одного запроса для снижения задержек использовать больше cpu/памяти/сети, чем есть на одном сервере - вроде бы в таком случаем масштабирование проще, но когда есть совсем разные разпросы, то оно не эффективно (например, один запрос требует кучу данных в памяти, а другой запрос cpu, а третий по сути аркестрирует вызовы к базам) - при большом количестве серверов и экспериментов придется довольно часто передеплоивать все, что, как ни крути, приводит к какому-то простою серверов и потенциальным ошибкам при обновлении
Т.е. да, в каких-то областях возможно не переходить на обычные микросервисы, а еще какое-то время оставаться на библиотечных микросервисах, но это каждый раз надо смотреть по месту. И, конечно, если у вас все и так хорошо без микросервисов, то не нужно их внедрять просто чтобы были.
Какая-то непонятная пропаганда. Почему, например, Россия не попала в сравнение? Я знаю довольно много обычных российских программистов, которые уже обеспечили себе старость и счастливых детей. Думаю, и во многих других странах у них все более чем хорошо.
Не согласен, что это ничего не стоит. Представим, что это один хобби-разработчик. Если тикет создан, то его так или иначе прочитаешь. Потом начинаешь думать о тикете. Сразу хочется какие-то уточнения спросить или посоветовать как это обойти. Т.е. на практике минут 15 на один новый тикет -- это как минимум.
Если только сделать систему, что автору проекта тикеты в принципе не видны, пока туда не поступит денег хотя бы на час работы, чтобы произвести первоначальный разбор тикета. А иначе на практике все равно заметное количество времени будет на это уходить, как ни крути.
Понятно, что статья старая, но добавлю свои 5 копеек, а то может сложиться превратное впечатление о Jooq.
Прежде всего, все примеры из статьи имеют место быть, но я бы по другому делал.
Например, получение строки таблицы по id (мне больше нравится название переменной db, а не dsl):
val user = db.fetchOne(USERS, USERS.ID.eq(userId), USERS.DELETED_AT.isNull)
Или создание записи:
val user = db.newRecord(USERS.class)
user.setName("Name")
user.store()
Это уже выглядит получше, чем примеры из статьи.
При этом логику дозагрузки списков нужно писать. И в том же хибернейте довольно много проблем с ней (делать ее LAZY or EAGER и как в разных местах это чередовать). Здесь же явно задаешь что нужно. Jooq-мэперы не использую, просто прохожу циклом в нужном методе, так как так все компактно видно в одном месте. Вместе с Jooq применяю Dao (Data Access Object) классы, которые включают всю сколько-нибудь нетривиальную логику получения данных. При этом классы с отчетами обычно не используют DAO, т.к. это один или несколько сложных sql-запросов сами по себе.
В целом, Jooq как раз для любителей чистого SQL. Просто языки программирования не могут типизировать SQL внутри строк, поэтому типизация достигается через такой DSL.
Генератор запускаю вручную и комичу сгененированный код в систему контроля версий. Так пока что проще и никаких проблем с таким подходом.
Новость сумбурная и повторяют про масленное мало. Kubernetes -- основа построения Private Cloud. KNative -- реализация Serverless (как у больших облаков) для Private Cloud.
Часто под Serverless имеют в виду Lambda: есть какая-то функция, написанная на каком-то популярном языке программирования. Ее нужно скомпилировать и подключить к входящим запросам по http, очередям или еще как-то. Ну и от кол-ва запросов масштабировать от 0 до нужного количества. Ну и куча обвязки типа как логировать и мониторить эти функции.
Мастеров может быть 1, 3+. Мастер может быть и воркером (т.е. запускать обычную нагрузку). OpenShift 4 поддерживает только 2 сценария: 1 (при этом нельзя добавить воркеров) или 3 мастера.
Воркеров может быть 0+.
Важно дать памяти достаточно, т.к. swap в K8s отключен. Для стабильной работы должен быть запас по свободной памяти.
Если совсем по минимальному, то я бы не использовал K8s, т.к. будут все связанные сложности, а развернуть кучу удобных сервисов ресурсов не будет.
Непонятно как вы собираетесь переподнимать 1 мастер. Если 1 мастер и он упал, то нужно переставлять весь кластер (при этом да, приложения продолжают работать, если не используют k8s api -- cron, скейлинг и тп). Переставить кластер вполне может быть приемлемым, не каждый год оно падает, а простой может быть дешевым.
При этом, если есть хотя бы 3 ноды, то нет особых причин не запустить 3 мастера. На мастерах можно запускать обычные поды (настройка). Оверхед 2х дополнительных etcd не такой уж большой, зато кластер не нужно будет переставлять.
Был опыт работы с K8s на мелких виртуалках в Digital Ocean. И сам с нуля поднимал, и подключал воркер в их сервис. В итоге, оно нестабильно работает -- через пару месяцев само ломается. А вот с docker из systemd проблем нет. Для ультрамелких деплоев пока что так делаю.
Лучше отдельный systemd-сервис на каждое приложение. Podman (из RH операционок) умеет командой такие делать. Для Docker нужно будет самому написать. Пример из Podman:
Kubernetes -- это основа Private Cloud. Из этого 2 следствия:
Cloud, хоть и Private, сложно масштабировать вниз.
Cloud, хоть и Private, состоит из десятков (а то и сотен) сервисов. И да, их нужно ставить, настраивать и обслуживать. И далеко не все из них есть в готовых дистрибьютивах типа OpenShift. Тут Kubernetes можно рассматривать как Linux (ядро), по отношению к дистрибьютивам.
Есть варианты малых кластеров, но они для удаленных офисов (Edge) или разработки/тестирования.
Исходя из этого, все претензии изначальной статьи выглядят странно. Кроме разве проблем масштабирования вниз. Об этом нужно знать и использовать другие решения: K8s в публичном облаке или более классические решения (Anisble).
Есть знакомый сварщик -- при найме они делают тестовое задание по сварке, а для того, чтобы приступить к работе еще и теорию сдают по каким-то нормам.
Про машинистов и хирургов не знаю, но лучше бы делали какие-то тестовые задания, чем просто наличие обучения/опыта, но все зависит от кол-ва кандидатов: когда их меньше, чем вакансий, то часто берут всех подряд.
Было бы с PMI все было хорошо, то не было бы и ITIL/ITSM, и Agile/Scrum. Просто везде свое. И, конечно, тут панацеи нет, нужно смотреть что за задача и окружение, а уж после под это подбирать решение.
Для определенности, буду писать только об ИТ-проектах.
В этом случае вся разработка инкрементальна, а вот ценность может быть бинарна (когда подписали акт, например).
Скрам, прежде всего, это организационный фреймворк. Просто невозможно говорить о Скраме, когда у вас нет скрам-мастера, команды и владельца продукта как отдельных людей. Это уже просто не Скрам (повторение любых артефактов или собраний ничего от Скрама не даст -- все они были и до Скрама, может быть под другими названиями).
Да, Скрам делался для продуктов. Вполне возможно использовать его и для достаточно длинных контрактов (особенно если команда уже была сформирована и до конкретного контракта).
Немного о проектном треугольнике: время, стоимость, функционал и качество. В классических проектах небольшая группа экспертов это все оценивает, затем контрактом фиксирует. При этом возникают проблемы при реализации, на то он и проект, а не процесс. Тогда чем-то нужно жертвовать. В классических проектах начинают смотреть в контракт и жертвуют недоописанными вещами (качество и функционал), при адекватных заказчиках увеличивают стоимость (change request), иногда еще жертвуют своей прибыльностью (увеличивают время). Agile (не только скрам) же говорит, что мы фиксируем стоимость и время, о качестве тоже договариваемся (но можем поменять по желанию заказчика), а функционал делаем с самого критичного до самого некритичного (и предполагаем, что на горизонте в полгода-год к нам еще придет бизнес и скажет, что приоритеты теперь другие).
Понятно, что у заказчика всегда есть подозрение, что люди не будут работать, поэтому это проще достигается с внутренними командами.
А роль Скрама здесь -- это как раз мотивировать команду и прозрачно показать весь процесс заказчику.
Теперь немного комментариев по тексту:
Метод управления, но не всеми вариантами проектов, есть ограничения (минимальные размеры проекта прежде всего).
Умеет. Точнее никто не умеет, всегда чем-то жертвуют.
Если проект достаточно длинный (от полугода со стабильной командой), то, по моему опыту, Скрам вполне применим. При этом о том, что он практикуется заказчику вообще нет особой нужды знать -- это внутренний способ работы аутсорсера.
Как раз наоборот: у Скрама всегда фиксированный дедлайн и бюджет. При этом в самом Скраме совсем не описано как оценивать сложность/длительность задач, это можно делать как и без Скрама делаете. Скрам лишь позволяет выстроить процесс постепенного приблежения к цели с максимальной отдачей за единицу затрат в любой момент времени.
Похоже на передергивание. Понятно, что в самом начале, когда мы добавили, например, только авторизацию, продукт еще нельзя использовать конечными пользователями, но так же и нельзя сказать, что в спринте ничего ценного не добавили. Ценное -- добавили, заказчику -- показали, а выпускать текущий артефакт на пользователей заказик решает сам -- когда, на какую группу и тп. Другими словами под ценным мы понимаем видимое продвижение к цели продукта, а не возможность продукта сразу же быть использованным, тк да, бывают ситуации, когда это невозможно.
Обратную связь всегда возможно получать. Если даже нет, то это особо ничего не меняет -- лишь добавляет дополнительный этап опытно-промышленной эксплуатации, когда заказчик бужет уже смотреть. При этом Скрам команда с самого начала все так же итеративно поставляет сборки, которые могут быть продемонстрированы заказчику, чтобы показать, что прогресс идет, или отданы отдельной команде тестирования (если уж заказчик не хочет смотреть промежуточные этапы).
Тут полностью согласен. Только сформулирую по-другому: нужно заранее понимать необходимость формирования команды (и это и есть основная задача скрам-мастера) и должно быть достаточное количество времени и стабильность команды, чтобы это имело смысл. Иначе нужно использовать не Скрам, а что-то другое.
Немного не так. Не обязательно, чтобы все отделы работали по Скраму (или все команды по контракту работали по Скраму). Например, IT обычно по Скраму не работают. Не обязательно, чтобы каждый член команды все мог (хотя это и мечта и традиционных руководителей проектов). Важно, чтобы задачи, который попадают в команду, могли бы быть решены этой командой. Например, дизайнеров можно вывести из Скрам-команды в команду владельца продукта, если они, в основном, будут нужны эпизодами. Аналитики и QA могут быть как внутри, так и снаружи -- опять же зависит скорее от кол-ва часов, которые они тратят на этот проект.
Есть такая проблема, но она разделяется на:
- дейли так или иначе обычно есть всегда, вполне понятно как их контролировать по времени
- демо позволяют получить обратную связь от заказчика и далее правильнее принимать тысячи мелких решений, которые программист делает чуть ли ни ежедневно, так что вполне себе окупаются
- ретро призваны повысить эффективность уже со следующего спринта -- т.е. окупаются моментально или проводятся как-то не так
- бэклог груминг -- тут сложнее всего контролировать время. Например, иногда на груминг берут не всех людей из команды, если это скорее совещание с аналитиками и дизайнерами по первоначальным уточнениям от разработчиков. Опять же на уровне ТЗ (когда еще нет кода) проще всего исправить проблемы (например, найти нестыковку с другим функционалом) и тут нужна вся команда (и тогда это окупается), но сами задачи уже должны быть достаточно хорошо проработаны.
В целом -- да, но нельзя прям сказать, что другие. Скрам обычно остается на нижнем уровне и появляются надстройки для управления многими скрам-командами. Тут еще часто появляются микросервисы, чтобы отделить команду от команды.
Ну, и у нас есть подобные профессионалы. Есть книги, конференции, тот же Хабр, но да, если в вашей компании нет опыта, то нужно его нарабатывать. И сначала на не самом критичном проекте. А лучше найти человека в штат с опытом.
Мое искреннее мнение -- скрам-мастер не может быть внешним, это основа Скрама.
Нужен коуч или нет и в каком формате -- все решают сами, тут ничего нового.
Не согласен. Как раз в традиционном подходе заказчик изначально все подписывает и получает, что подписал. Или платить кучу денег за дополнительные соглашения. Agile (даже не Скрам) позволяет заказчику уточнять задачу по мере увеличения понимания. Не обязательно запускать Скрам с момента подписания контракта или запуска нового продукта -- какое-то время до начала разработки может проводиться первоначальный анализ, прототипы дизайна и UI, это никак не противоречит Скраму, тк скрывается за абстракцией владельца продукта, а скрам-команда либо еще не начала работать, либо занимается какими-то заранее известными задачами (пишет интеграции с другими системами, например).
Понятно, что резюме тоже другое. Для длительных проектов или продуктов Скрам вполне себе подходит, но нужно четко понимать роль скрам-мастера, иначе это просто не Скрам.
PS: Большое спасибо автору за статью, тему поднимать надо и рассуждать об этом тоже полезно всем.
В целом, можно представить себе схему когда у нас есть "монолит", который состоит из кучи библиотек (вместо отдельных сервисов).
Все-таки наличие таких библиотек необходимо (с какого-то размера), чтобы команды могли независимо делать эксперименты (если нет множества разных команд с разными целями и сроками, то и микросервисы, и библиотеки не нужны особо).
Таким образом, мы уходим от сетевых задержек. Какие при этом могут быть минусы?
- необходимость возможности старта всей системы на одном сервере: если используются локальные кеши, то такое не всегда возможно
- увеличенное время сборки, но при этом вся система стартует локально (что удобно для разработчиков)
- необходимо для одного запроса для снижения задержек использовать больше cpu/памяти/сети, чем есть на одном сервере
- вроде бы в таком случаем масштабирование проще, но когда есть совсем разные разпросы, то оно не эффективно (например, один запрос требует кучу данных в памяти, а другой запрос cpu, а третий по сути аркестрирует вызовы к базам)
- при большом количестве серверов и экспериментов придется довольно часто передеплоивать все, что, как ни крути, приводит к какому-то простою серверов и потенциальным ошибкам при обновлении
Т.е. да, в каких-то областях возможно не переходить на обычные микросервисы, а еще какое-то время оставаться на библиотечных микросервисах, но это каждый раз надо смотреть по месту. И, конечно, если у вас все и так хорошо без микросервисов, то не нужно их внедрять просто чтобы были.
Плохо, как ни крути, это монополия (Яндекс.Еда + Delivery Club).
Какая-то непонятная пропаганда. Почему, например, Россия не попала в сравнение? Я знаю довольно много обычных российских программистов, которые уже обеспечили себе старость и счастливых детей. Думаю, и во многих других странах у них все более чем хорошо.
Не согласен, что это ничего не стоит. Представим, что это один хобби-разработчик. Если тикет создан, то его так или иначе прочитаешь. Потом начинаешь думать о тикете. Сразу хочется какие-то уточнения спросить или посоветовать как это обойти. Т.е. на практике минут 15 на один новый тикет -- это как минимум.
Если только сделать систему, что автору проекта тикеты в принципе не видны, пока туда не поступит денег хотя бы на час работы, чтобы произвести первоначальный разбор тикета. А иначе на практике все равно заметное количество времени будет на это уходить, как ни крути.
В Америке цены пишут без НДС, у нас цена уже с НДС. Т.е. курс ближе к 83р. Понятно, что это все равно выше, но кто знает что они еще туда закладывают.
Понятно, что статья старая, но добавлю свои 5 копеек, а то может сложиться превратное впечатление о Jooq.
Прежде всего, все примеры из статьи имеют место быть, но я бы по другому делал.
Например, получение строки таблицы по id (мне больше нравится название переменной db, а не dsl):
Или создание записи:
Это уже выглядит получше, чем примеры из статьи.
При этом логику дозагрузки списков нужно писать. И в том же хибернейте довольно много проблем с ней (делать ее LAZY or EAGER и как в разных местах это чередовать). Здесь же явно задаешь что нужно. Jooq-мэперы не использую, просто прохожу циклом в нужном методе, так как так все компактно видно в одном месте. Вместе с Jooq применяю Dao (Data Access Object) классы, которые включают всю сколько-нибудь нетривиальную логику получения данных. При этом классы с отчетами обычно не используют DAO, т.к. это один или несколько сложных sql-запросов сами по себе.
В целом, Jooq как раз для любителей чистого SQL. Просто языки программирования не могут типизировать SQL внутри строк, поэтому типизация достигается через такой DSL.
Генератор запускаю вручную и комичу сгененированный код в систему контроля версий. Так пока что проще и никаких проблем с таким подходом.
У нас в школе висела примерно такая цитата:
Разум Грэма как раз попадает в талант, а остальные качества в труд (с американским оттенком в виде глубокой специализации и независимости).
Но я согласен с тем, что для околофилософской статьи в ней очень мало воды.
Новость сумбурная и повторяют про масленное мало. Kubernetes -- основа построения Private Cloud. KNative -- реализация Serverless (как у больших облаков) для Private Cloud.
Часто под Serverless имеют в виду Lambda: есть какая-то функция, написанная на каком-то популярном языке программирования. Ее нужно скомпилировать и подключить к входящим запросам по http, очередям или еще как-то. Ну и от кол-ва запросов масштабировать от 0 до нужного количества. Ну и куча обвязки типа как логировать и мониторить эти функции.
Мастеров может быть 1, 3+. Мастер может быть и воркером (т.е. запускать обычную нагрузку). OpenShift 4 поддерживает только 2 сценария: 1 (при этом нельзя добавить воркеров) или 3 мастера.
Воркеров может быть 0+.
Важно дать памяти достаточно, т.к. swap в K8s отключен. Для стабильной работы должен быть запас по свободной памяти.
Если совсем по минимальному, то я бы не использовал K8s, т.к. будут все связанные сложности, а развернуть кучу удобных сервисов ресурсов не будет.
Непонятно как вы собираетесь переподнимать 1 мастер. Если 1 мастер и он упал, то нужно переставлять весь кластер (при этом да, приложения продолжают работать, если не используют k8s api -- cron, скейлинг и тп). Переставить кластер вполне может быть приемлемым, не каждый год оно падает, а простой может быть дешевым.
При этом, если есть хотя бы 3 ноды, то нет особых причин не запустить 3 мастера. На мастерах можно запускать обычные поды (настройка). Оверхед 2х дополнительных etcd не такой уж большой, зато кластер не нужно будет переставлять.
Был опыт работы с K8s на мелких виртуалках в Digital Ocean. И сам с нуля поднимал, и подключал воркер в их сервис. В итоге, оно нестабильно работает -- через пару месяцев само ломается. А вот с docker из systemd проблем нет. Для ультрамелких деплоев пока что так делаю.
Непонятно откуда требования, выделенные жирным. Вот документация (там 4/16/100 для мастера и 2/8/100 для worker): https://docs.openshift.com/container-platform/4.9/installing/installing_bare_metal/installing-bare-metal.html#minimum-resource-requirements_installing-bare-metal . При этом на практике я бы не делал ноды меньше 8/32. И, понятно, число нод должно быть таким, чтобы ресурсы на 3 мастера на их фоне выглядели как ничто.
Про dev (CodeReady Containers) -- это именно OpenShift (с ui и прочим). Если достаточно чистого Kubernetes, то его в Docker можно включить.
Да, возвращаться к Kubernetes ;).
Если планируются потенциально дети, то это тоже нужно учитывать. Например, в США это весьма дорого.
Странные цены на аренду в США и UK (про другие заграницы не скажу). Уж больно дешево. Например, первая же ссылка: https://usa-info.com.ua/novosti/news/rent-house
Да, публичные облака тоже называют новым видом операционной системы.
Лучше отдельный systemd-сервис на каждое приложение. Podman (из RH операционок) умеет командой такие делать. Для Docker нужно будет самому написать. Пример из Podman:
Kubernetes -- это основа Private Cloud. Из этого 2 следствия:
Cloud, хоть и Private, сложно масштабировать вниз.
Cloud, хоть и Private, состоит из десятков (а то и сотен) сервисов. И да, их нужно ставить, настраивать и обслуживать. И далеко не все из них есть в готовых дистрибьютивах типа OpenShift. Тут Kubernetes можно рассматривать как Linux (ядро), по отношению к дистрибьютивам.
Есть варианты малых кластеров, но они для удаленных офисов (Edge) или разработки/тестирования.
Исходя из этого, все претензии изначальной статьи выглядят странно. Кроме разве проблем масштабирования вниз. Об этом нужно знать и использовать другие решения: K8s в публичном облаке или более классические решения (Anisble).
OpenShift без поддержки называется OKD (и он бесплатен).
Tanzu не стоит дополнительных денег, если уже оплачивается VMWare. Такие компании ее и используют.
Есть знакомый сварщик -- при найме они делают тестовое задание по сварке, а для того, чтобы приступить к работе еще и теорию сдают по каким-то нормам.
Про машинистов и хирургов не знаю, но лучше бы делали какие-то тестовые задания, чем просто наличие обучения/опыта, но все зависит от кол-ва кандидатов: когда их меньше, чем вакансий, то часто берут всех подряд.