Комментарии 8
спасибо за перевод, еще не читал но видно что глобальная статья и думаю она будет популярна в закладках.
И хочу предложить поменять в тексте «меха»-компоненты и меха-архитекура на мех-компоненты и мех-архитектуру, мне кажется это более правильное сокращение, но возможно мой словарный запас банально испорчен чтением книг BattleTech в юные годы.
Судя по предложенной архитектуре будущих приложений, дополнительные затраты на то, чтобы приложение крутилось в Кубере, увеличится ещё больше и скоро достигнет 50%. Облачные провайдеры будут рады такому раскладу. Да и обычные продавцы железа тоже.
Ничего необычного, железо дешевеет, разработка дорожает. Все идет по пути упрощения написания программ с момента возникновения программирования. Kubernetes был просто очередным шагом, Service Mesh - следующий шаг, а Knative и Dapr - уже следующий шаг.
Что-то следующее будет уже внутри них реализовано, например какой-нибудь хитрый акторный распределенный фреймворк, общающийся через брокера и работающий с KV. Возможно, описывать программу на этом шаге станет можно на декларативном ЯП, к чему все давно идет.
Так-то оно так, вот только те самые дорогущие программисты всё меньше понимают, как эта балалайка работает. В итоге на вхождение человека в проект тратятся месяцы. Точнее не так, никто месяцы не тратит, новичок долбит вопросами лида, ведь самому в этом не разобраться. И я не про бизнес логику конкретного приложения/сервиса, а про архитектуру и как всё накручено. У каждого проекта свой набор свистелок, которые обеспечивают mesh и прочит хотелки.
Я понимаю, что все эти хотелки не из пальца высосаны, но то количество знаний, что необходимо держать в голове с трудом туда помещается.
Отвечу по пунктам.
те самые дорогущие программисты всё меньше понимают, как эта балалайка работает
И не должны понимать, в этом и смысл изменений. Когда-то программист должен был понимать, как программировать под конкретное железо, пока не появился POSIX с набором сисколов. Потом появились более высокоуровневые ЯП, которые и работу с сисколами заменили абстракциями. Все это делается ради того, чтобы программист мог больше своего времени тратить на реализацию бизнес-логики и меньше - на интеграцию в конкретную инфраструктуру.
Понимает ли программист, как работает сискол под капотом? Если да, то не каджый. Надо ли ему это? Если не пишет дрова или микроконтроллеры - нет.
То же самое и с кубом. Сейчас подавляющее большинство Go, Java и еще что там разработчиков приходит на собеседования со знанием контейнеров, докера, кубера, пониманием CI/CD и прочего. Это тот уровень абстракции, на котором работает сегодняшний программист (ну скажем, 80% программистов). Завтрашний работает на уровне примитивов Istio и Knative, послезавтрашний - на основе примитивов девелопера в рамках ролевой модели Dapr.
Плохо ли это? Да в общем нет - компании не нужно, чтобы все знали обо всем. Достаточно нанять пару "экспертов в технологии X (например DevOps для технологии Kubernetes), которые и будут решать задачи, где нужно знание "как эта балалайка работает". Остальные же будут работать с абстракциями, позволяющими деливерить продукты быстрее и лучше. И масштабировать обычно нужно команду разработчиков, а не "экспертов в X", а проще масштабировать команду людей, умеющих работать поверх абстракции, нежели экспертов в узкой области.
В итоге на вхождение человека в проект тратятся месяцы
Докер и кубер создали общую абстракцию, за которую убрано очень много инфраструктурных нюансов - ОС, диск, сеть, логирование и скейлинг, перезапуск умерших сервисов и так далее. Это приводит к тому, что отдельному разработчику не нужно париться над этими задачами и выдумывать велосипеды/использовать зоопарк библиотек для их решения. То есть область, в которой работает разработчик, сужается до фактически написания бизнес-логики, остальное улетает за абстракции.
Это приводит к тому, что люди приходят с хорошим знанием одной общей абстракции (докер, куб, деплоймент, сервис, блю/грин, стейтфулсет), и эта абстракция примерно одна и та же от компании к компании. Нюансы конечно есть, но например поработав в одной компании с Nginx в качестве ingress, а в другой с Istio в том же качестве, разницы в коде приложения я никакого не увидел.
У каждого проекта свой набор свистелок
Такие решения как раз позволяют иметь меньше "свистелок" в проекте. Условный Dapr абстрагирует pub/sub и key-value за единый интерфейс. Нужно асинхронно слать эвент - берешь dapr pub/sub api, нужно закешировать данные - берешь dapr kv api. Решение требует минут вместо часов и дней, как было раньше, и въехать в код приложения быстрее и проще. А что там за имплементация pub/sub и key-value уже будет самый опытный инженер в команде думать, исходя из требований проекта.
но то количество знаний, что необходимо держать в голове с трудом туда помещается
Знаний, которые нужно держать в голове архитектору/техлиду, всегда было много, просто одни устаревают, а другие появляются. От этого никуда не уйти.
Знаний же в головах начинающих инженеров нужно даже меньше, чем раньше - уметь писать на своем ЯП, понимать особенности работы в контейнере (стейтлесс, грейсфул шатдаун, параллельная работа нескольких реплик), ну и неизменные вещи вроде ACID транзакций и лучших практик программирования.
Прошу простить за простыню текста, хотелось ответить подробно и с примерами.
То же самое и с кубом. Сейчас подавляющее большинство 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, просто сам факт такой проверки. В итоге всё, что выходит за рамки написания кода афишируется как блокер, флажок в джире и лапки к верху. Обучение этих людей идёт туго, ведь ИТ с высокими зарплатами так разрекламировано, что учиться эти люди не особо стремятся, им интересные проекты подавай и чтобы всё с нуля, чтобы распоследние технологии.
Обучение этих людей идёт туго, ведь ИТ с высокими зарплатами так разрекламировано, что учиться эти люди не особо стремятся, им интересные проекты подавай и чтобы всё с нуля, чтобы распоследние технологии.
Ну такое всегда было и всегда будет. Есть просто разные люди: кто-то самостоятелен и замотивирован, кто-то нет. В итоге и карьера у них складывается по-разному.
В остальном не увидел принципиальных разногласий с моими аргументами. Начинающие разработчики знают недостаточно и поверхностно, вне зависимости от инфраструктуры. Опытные инженеры знают глубоко и широко, опять же, вне зависимости от инфраструктуры.
Отличие одно - уровень работы с инфраструктуры становится все выше и выше (от голого железа до условных "функций" или вообще какого-то декларативного кода). Уровень поднимается за счет появления новых абстракций - ОС, контейнеры, оркестратоты, сервисмеши и т.п.
Сначала они неустойчивые и сложные, потом обрастают сообществом, становятся лучше и надежнее, и со временем переходят в разряд стандартов. И уже поверх них начинают пилиться новые ненадежные абстракции. Кубер уже перешел в категорию стандартов, сервисмеши пока в пути, прочие навороты пока только на горизонте.
---
Кстати, это очень хорошо можно увидеть, посмотрев InfoQ Trends Report, в котором очень четко видно, как с годами технологии переходят из разряда новых идей в разряд корпоративных стандартов.
Эволюция распределённых систем в Kubernetes