Пошёл искать, что за зверь такой - Python-Terrascript, а он не развивается уже несколько лет. Так себе инструмент для сравнения. Да и в целом проблема не такая большая, как описывается в статье. Да, в некоторых случаях приходится писать некрасивый код и костылять для Terraform, но в целом описание инфраструктуры достаточно наглядное и понятное.
Поясните тем, кто не в теме, в чём цель создания данного двигателя? Эволюционное улучшение существующего или замена в связи с ограничениями поставок компонентов?
Хотелось бы почитать больше аргументов за и против, иначе всё действительно скатывается в простой посыл - с чем команда умеет работать, такие инструменты и надо выбирать. И дело не только в Кубере, команда может банально не уметь в контейнеры. Накатили jBoss application server, залили через ГУЙ артефакты и готово. Другое дело, что надо думать и о среднесрочной перспективе с автоматизациями. Тут-то Кубер и может быть одним из инструментов. Особенно, если взять облако и не тратить силы на поддержку.
То же самое и с кубом. Сейчас подавляющее большинство Go, Java и еще что там разработчиков приходит на собеседования со знанием контейнеров, докера, кубера, пониманием CI/CD и прочего. Это тот уровень абстракции, на котором работает сегодняшний программист (ну скажем, 80% программистов). Завтрашний работает на уровне примитивов Istio и Knative, послезавтрашний - на основе примитивов девелопера в рамках ролевой модели Dapr.
Смею не согласиться со знаниями сегодняшних программистов. Очень многие до сих пор пилят не контейнеризованные приложения. А из тех, кто пилят под контейнеры, мало понимают в них. Люди хорошо секут в конкретном языке программирования + выучили несколько команд как собрать контейнер и залить в репозиторий. А в худшем случае и их не знают, так как сборкой занимается CI/CD.
Я тут хочу подчеркнуть, что говорю не про senior developer'ов, а про обычных разрабов, которые занимаются разработкой как ремеслом, а после рабочего дня занимаются не программированием.
Докер и кубер создали общую абстракцию, за которую убрано очень много инфраструктурных нюансов - ОС, диск, сеть, логирование и скейлинг, перезапуск умерших сервисов и так далее. Это приводит к тому, что отдельному разработчику не нужно париться над этими задачами и выдумывать велосипеды/использовать зоопарк библиотек для их решения. То есть область, в которой работает разработчик, сужается до фактически написания бизнес-логики, остальное улетает за абстракции.
Нечто схожее можно сказать и про JVM. Да, перезапуска умерших сервисов в ней нет, но это далеко не всегда задача разработчика. Есть опсы, которые оборачивают сервис и виртуалку мониторингом и скриптами по обслуживанию. Так что тут в целом для разработчика меняется шило на мыло.
Такие решения как раз позволяют иметь меньше "свистелок" в проекте. Условный Dapr абстрагирует pub/sub и key-value за единый интерфейс. Нужно асинхронно слать эвент - берешь dapr pub/sub api, нужно закешировать данные - берешь dapr kv api. Решение требует минут вместо часов и дней, как было раньше, и въехать в код приложения быстрее и проще. А что там за имплементация pub/sub и key-value уже будет самый опытный инженер в команде думать, исходя из требований проекта.
Здесь не стану спорить, я пока не разбирался с этими решениями. Правда, говоря про докрутки над Кубером, скажем тот же Istio, то всерьёз приходится задумываться над усложнением общей инфраструктуры. Ведь должны быть спецы, которые смогут обновить уже не только Кубер, который выходит раз в квартал, но ещё и Istio. В этих проектах периодически меняется синтаксис, поэтому необходимо следить за всем этим делом. Да, мы опять говорим по 2-3 спецов, которые будут помогать команде, но нагрузка на них всё растёт и растёт.
Знаний, которые нужно держать в голове архитектору/техлиду, всегда было много, просто одни устаревают, а другие появляются. От этого никуда не уйти.
Не спорю, этим ребятам надо идти в ногу со временем, ковырятся в новомодных технологиях и уметь донести их до руководства и исполнителей. Жаль, 24-х часов в сутках не всегда хватает для всех этих хотелок, а также всего того, что происходит вне ИТ мира.
Знаний же в головах начинающих инженеров нужно даже меньше, чем раньше - уметь писать на своем ЯП, понимать особенности работы в контейнере (стейтлесс, грейсфул шатдаун, параллельная работа нескольких реплик), ну и неизменные вещи вроде ACID транзакций и лучших практик программирования.
Возможно мне попадались неправильные начинающие разработчики и даже консультанты, поскольку не все знали, что существует telnet, которым можно проверить доступность удалённого сервиса. Да что там telnet, просто сам факт такой проверки. В итоге всё, что выходит за рамки написания кода афишируется как блокер, флажок в джире и лапки к верху. Обучение этих людей идёт туго, ведь ИТ с высокими зарплатами так разрекламировано, что учиться эти люди не особо стремятся, им интересные проекты подавай и чтобы всё с нуля, чтобы распоследние технологии.
Так-то оно так, вот только те самые дорогущие программисты всё меньше понимают, как эта балалайка работает. В итоге на вхождение человека в проект тратятся месяцы. Точнее не так, никто месяцы не тратит, новичок долбит вопросами лида, ведь самому в этом не разобраться. И я не про бизнес логику конкретного приложения/сервиса, а про архитектуру и как всё накручено. У каждого проекта свой набор свистелок, которые обеспечивают mesh и прочит хотелки.
Я понимаю, что все эти хотелки не из пальца высосаны, но то количество знаний, что необходимо держать в голове с трудом туда помещается.
Судя по предложенной архитектуре будущих приложений, дополнительные затраты на то, чтобы приложение крутилось в Кубере, увеличится ещё больше и скоро достигнет 50%. Облачные провайдеры будут рады такому раскладу. Да и обычные продавцы железа тоже.
Про javadoc глупость какая-то написана. Я хоть и не разработчик, но не так давно надо было править старый монолит и именно благодаря javadoc удалось легко найти необходимый метод и исправить.
Также допущение о доступности исходного кода звучит странно. А если исходники не доступны, то как смотреть на javadoc? Его достаточно легко экспортировать и отдать вместе с продуктом. Опять же, когда над кодом может работать множество людей, javadoc хоть как-то организует разработчиков одинакого документировать код.
С тех пор, как Adrian Cantrill ушёл из Linux Academy и их купили ACG, не могу порекоммендовать их курс. По курсу Адриана получил Solutions Architect Professional, по курсу ACG получил SysOps Associate, девелопера не получилось сдать, так как Pearson Vue заглючил в день сдачи.
По тестам могу порекоммендовать Job Bonso, его тесты есть как на Udemy, так и на его сайте: tutorialsdojo.com. На Udemy сайт получше, тесты не сбиваются, если решаешь один тест в течении двух дней. Но автор получает меньше гонорар за свои труды.
Что касается подготовки в целом, то конечно надо учить материалы, работать руками, читать whitepaper'ы, если такие есть. И гонять тесты, без них никак.
Согласен. В целом статья очень здравая, по-крайней мере мне, человеку далёкому от медицины показалась правдоподобной. Но последние строки про «гонку вооружений» дискредетируют статью.
Не думаю, что кто-то будет разрывать контракты. Это попадос на деньги, а также репутационные издержки. Опять же, сделка будет закрыта лишь летом следующего года.
У меня 14 получилось от того, что я принял перемножение тех же квадратиков на себя за умножение на 3. Следовательно квадратик получился равен 9. Такой вот позор.
Пока писал пост, продавец уже изменил цену до 95 долларов. Правда в итоге 5 добавили (за купон). Жду заказ и благодарю ещё раз за ссылку, будет теперь с чем играться.
Спасибо за информацию, заказал. Правда с почтой пока не совсем понятно, есть только EMS и DHL, надеюсь смогу договориться с продовцом о более другом варианте доставки.
Даже в организации из пяти человек ITIL может помочь. Правда в такой небольшой организации почти любая книга по организации процесса может помочь, надо лишь найти, что именно можно применить.
Я согласен, что книгу читать очень сложно. Впервые я открыл книгу в августе предыдущего года, причитал страницу, понял, что абсолютно ничего не понял, а количество сложных английских плилагательных было настолько высоко, что моего технического английского нехватало для понимая сути. Лишь спустя полгода я нашёл в себе силы открыть книгу снова и после 30-ой муками прочтённой страницы, остальные пошли как по маслу. Да, там нет конкретных решений, по-крайней мере в foundations, зато там есть те самые базовые понятия, которые открывают мир в совершенно новые области.
Простой пример — пока организация маленькая, настройки и подобная информация не структурируется, всё разбросано там да сям. ITIL говорит, что за настройки отвечает configuration management. Очевидно, что нанимать человека рано при штате в 5 человек, но поставить на сервер веб-приложение, которое будет хранить все настройки, нетрудно. Вы скажете, что это можно сделать и без прочтения ITIL. Конечно, можно, но многие очевидные вещи просто не вспоминаются, пока ворона не клюнет. А так прошёлся по заголовкам при становлении организации, учёл базовые принципы и вперёд.
Согласен, даже мелкие организации работают в рамках ITIL, при этом, возможно с ошибками, которые можно было бы запросто решить, внедрив ITIL. По-моему каждый лидер и менеджер ИТ организаций или же ИТ отдела должны пройти курс ITIL foundations, так как это даёт возможность посмотреть на эталонную организацию и, возможно, увидеть, что команда / организация в данный момент имеет неправильные процессы или вообще не отлаженные процессы.
П.С.: на этой неделе дочитал книгу по ITIL foundations, как-раз готовлюсь к экзамену.
Я только начал увлекаться управлением проектов и опыта достаточно мало, особенно в финансовой части. В результате из статьи почти ничего не понял и, судя по комментариям, отписались пока лишь те люди, кто хорошо понимают данную тематику и знают вышеизложенное.
Если это возможно, хотелось бы статью с реальными примерами, дабы формулы не были сухими и присутствовали реальные цифры, вроде: «Имеем столько-то поступлений, расходы на то и то такие-то». Небольшой пример настоящего проекта идеально сформировал бы образ того, как надо считать и какие данные необходимы.
В любом случае, спасибо за статью, из комментариев подчерпнул несколько книг / авторов, которых стоит почитать, чтобы получить фундаментальные знания.
Интересная практика, спасибо! Я сейчас только начинаю изучать управление проектами и не работал ещё со специализированными приложениями, отсюда вопрос — база данных рисками и их добавление к проектам реализованы в каком-либо готовом ПО для управления проектами или у вас собственная разработка?
И ещё, если есть мнение по этому поводу: чьи наработки Вы считаете более применимым в современных ИТ проектах? International Project Management Association или Project Management Institute? В данный момент как-раз выбираю, по какому пути развиваться.
Пошёл искать, что за зверь такой - Python-Terrascript, а он не развивается уже несколько лет. Так себе инструмент для сравнения.
Да и в целом проблема не такая большая, как описывается в статье. Да, в некоторых случаях приходится писать некрасивый код и костылять для Terraform, но в целом описание инфраструктуры достаточно наглядное и понятное.
Спасибо, теперь всё понятно!
Поясните тем, кто не в теме, в чём цель создания данного двигателя? Эволюционное улучшение существующего или замена в связи с ограничениями поставок компонентов?
Хотелось бы почитать больше аргументов за и против, иначе всё действительно скатывается в простой посыл - с чем команда умеет работать, такие инструменты и надо выбирать. И дело не только в Кубере, команда может банально не уметь в контейнеры. Накатили jBoss application server, залили через ГУЙ артефакты и готово. Другое дело, что надо думать и о среднесрочной перспективе с автоматизациями. Тут-то Кубер и может быть одним из инструментов. Особенно, если взять облако и не тратить силы на поддержку.
SnowBall'ы позволяют обрабатывать данные в процессе перекачки в/из хранилища. Именно для этого такие мощности.
Смею не согласиться со знаниями сегодняшних программистов. Очень многие до сих пор пилят не контейнеризованные приложения. А из тех, кто пилят под контейнеры, мало понимают в них. Люди хорошо секут в конкретном языке программирования + выучили несколько команд как собрать контейнер и залить в репозиторий. А в худшем случае и их не знают, так как сборкой занимается CI/CD.
Я тут хочу подчеркнуть, что говорю не про senior developer'ов, а про обычных разрабов, которые занимаются разработкой как ремеслом, а после рабочего дня занимаются не программированием.
Нечто схожее можно сказать и про JVM. Да, перезапуска умерших сервисов в ней нет, но это далеко не всегда задача разработчика. Есть опсы, которые оборачивают сервис и виртуалку мониторингом и скриптами по обслуживанию. Так что тут в целом для разработчика меняется шило на мыло.
Здесь не стану спорить, я пока не разбирался с этими решениями. Правда, говоря про докрутки над Кубером, скажем тот же Istio, то всерьёз приходится задумываться над усложнением общей инфраструктуры. Ведь должны быть спецы, которые смогут обновить уже не только Кубер, который выходит раз в квартал, но ещё и Istio. В этих проектах периодически меняется синтаксис, поэтому необходимо следить за всем этим делом. Да, мы опять говорим по 2-3 спецов, которые будут помогать команде, но нагрузка на них всё растёт и растёт.
Не спорю, этим ребятам надо идти в ногу со временем, ковырятся в новомодных технологиях и уметь донести их до руководства и исполнителей. Жаль, 24-х часов в сутках не всегда хватает для всех этих хотелок, а также всего того, что происходит вне ИТ мира.
Возможно мне попадались неправильные начинающие разработчики и даже консультанты, поскольку не все знали, что существует telnet, которым можно проверить доступность удалённого сервиса. Да что там telnet, просто сам факт такой проверки. В итоге всё, что выходит за рамки написания кода афишируется как блокер, флажок в джире и лапки к верху. Обучение этих людей идёт туго, ведь ИТ с высокими зарплатами так разрекламировано, что учиться эти люди не особо стремятся, им интересные проекты подавай и чтобы всё с нуля, чтобы распоследние технологии.
Так-то оно так, вот только те самые дорогущие программисты всё меньше понимают, как эта балалайка работает. В итоге на вхождение человека в проект тратятся месяцы. Точнее не так, никто месяцы не тратит, новичок долбит вопросами лида, ведь самому в этом не разобраться. И я не про бизнес логику конкретного приложения/сервиса, а про архитектуру и как всё накручено. У каждого проекта свой набор свистелок, которые обеспечивают mesh и прочит хотелки.
Я понимаю, что все эти хотелки не из пальца высосаны, но то количество знаний, что необходимо держать в голове с трудом туда помещается.
Судя по предложенной архитектуре будущих приложений, дополнительные затраты на то, чтобы приложение крутилось в Кубере, увеличится ещё больше и скоро достигнет 50%. Облачные провайдеры будут рады такому раскладу. Да и обычные продавцы железа тоже.
Также допущение о доступности исходного кода звучит странно. А если исходники не доступны, то как смотреть на javadoc? Его достаточно легко экспортировать и отдать вместе с продуктом. Опять же, когда над кодом может работать множество людей, javadoc хоть как-то организует разработчиков одинакого документировать код.
По тестам могу порекоммендовать Job Bonso, его тесты есть как на Udemy, так и на его сайте: tutorialsdojo.com. На Udemy сайт получше, тесты не сбиваются, если решаешь один тест в течении двух дней. Но автор получает меньше гонорар за свои труды.
Что касается подготовки в целом, то конечно надо учить материалы, работать руками, читать whitepaper'ы, если такие есть. И гонять тесты, без них никак.
Я согласен, что книгу читать очень сложно. Впервые я открыл книгу в августе предыдущего года, причитал страницу, понял, что абсолютно ничего не понял, а количество сложных английских плилагательных было настолько высоко, что моего технического английского нехватало для понимая сути. Лишь спустя полгода я нашёл в себе силы открыть книгу снова и после 30-ой муками прочтённой страницы, остальные пошли как по маслу. Да, там нет конкретных решений, по-крайней мере в foundations, зато там есть те самые базовые понятия, которые открывают мир в совершенно новые области.
Простой пример — пока организация маленькая, настройки и подобная информация не структурируется, всё разбросано там да сям. ITIL говорит, что за настройки отвечает configuration management. Очевидно, что нанимать человека рано при штате в 5 человек, но поставить на сервер веб-приложение, которое будет хранить все настройки, нетрудно. Вы скажете, что это можно сделать и без прочтения ITIL. Конечно, можно, но многие очевидные вещи просто не вспоминаются, пока ворона не клюнет. А так прошёлся по заголовкам при становлении организации, учёл базовые принципы и вперёд.
П.С.: на этой неделе дочитал книгу по ITIL foundations, как-раз готовлюсь к экзамену.
Если это возможно, хотелось бы статью с реальными примерами, дабы формулы не были сухими и присутствовали реальные цифры, вроде: «Имеем столько-то поступлений, расходы на то и то такие-то». Небольшой пример настоящего проекта идеально сформировал бы образ того, как надо считать и какие данные необходимы.
В любом случае, спасибо за статью, из комментариев подчерпнул несколько книг / авторов, которых стоит почитать, чтобы получить фундаментальные знания.
И ещё, если есть мнение по этому поводу: чьи наработки Вы считаете более применимым в современных ИТ проектах? International Project Management Association или Project Management Institute? В данный момент как-раз выбираю, по какому пути развиваться.
Заранее спасибо!