Предыдущим релизом платформы был 0.41. И тут неожиданно будущий релиз 0.42 стал ответом на главный вопрос жизни, вселенной и всего такого: слишком много серьезных изменений накопилось в платформе. Так что 0.42 пришлось переименовать в 1.0.

С выходом версии 1.0 платформа Cozystack перешла на новую архитектурную модель. Мы создали систему пакетов на основе FluxCD и артефактов OCI, похожую на apt в Debian/Ubuntu, но для Kubernetes (см. раздел «Развертывание на основе пакетов» ниже). Это позволило нам реализовать новый подход — Build Your Own Platform (BYOP).

Когда ви-си загнулся окончательно, появилось немало статей с подборкой ресурсов, которые этот самый ви-си могут заменить. Если говорить грубо и прямо, то фактически, контент-маркетологи и разные сомнительные личности, убившие в свое время этот самый ви-си, стали составлять подборки площадок, на которые нога их брата еще особо не ступала. Один из таких ресурсов стал Хабр.

Да, здесь уже не первый год орудуют самые продвинутые из контент-маркетологов. Однако теперь сюда явно доберется и основная их масса. Конечно, есть некий барьер в виде необходимости получить инвайт на Хабр, чтобы писать статьи, но он, насколько я понимаю, достаточно легко обходится за деньги с помощью серых схем с уже набравшими рейтинг дельцами от контент-маркетинга.

Сейчас Kubernetes воспринимается как «готовое» и самодостаточное ПО — грубо говоря, как отдельная программа. Да, чтобы его использовать в проде, придется добавить к нему разных cloud native-инструментов: CNI, service mesh и т.п. штуковины. Однако всё же K8s выглядит именно как приложение (иногда его даже называют ОС для облаков). 

На мой взгляд, такое понимание Kubernetes заводит рынок в тупик. Очевидно, что сложность оркестратора должна расти, очевидно, что будет все больше сфер, в которых он будет использоваться и которые способны извлечь немало пользы из внедрения K8s. Если рынок не начнет смотреть на Kubernetes как на Linux Kernel, это заведет нас в тупик, и вот почему...

Четыре года мы развивали и улучшали werf 1.2, но теперь наконец‑то выпустили стабильную werf 2.0. Причина простая — последовательно накопилось множество улучшений (300+ релизов!), а кроме того, мы доработали новый движок развёртывания Nelm, и в werf 2.0 это единственный движок. Старый движок удалён. Nelm обратно совместим с Helm 3, поэтому никаких особых изменений в чартах не потребуется — они будут развёртываться так же, как и раньше.

В некоторых случаях у Nelm отличается поведение: например, у него более строгая валидация чартов, поэтому, хотя Nelm и доступен в werf 1.2, по умолчанию мы его включили только в werf 2.0.

Рассказываем, зачем мы сделали Nelm, что под капотом werf 2.0, как werf будет развиваться в будущем и как ее попробовать на своем проекте уже сейчас.

3 апреля на сайте InfoWorld вышла статья известного публициста на тему Open Source и юриста Matt Asay под названием «OpenTofu, возможно, демонстрирует нам, как не надо делать форк». Лидер-абзац в статье довольно жёсткий: 

Не согласны с лицензией? Просто сделайте форк проекта, но не выкидывайте его код — говорите, что он всегда был доступен публично. Сравните код и лицензию HashiCorp с версией OpenTofu.

Разберемся в этой истории последовательно — кто прав, кто виноват и чем всё закончилось.

Как и все, я что-то читаю, что-то смотрю, что-то слушаю и т.п. И в результате этого всего возникают всякие мысли — пытаюсь анализировать и думать, что произойдет в ближайшие лет 10 в следствие развития технологий и науки. Хочется думать, что мысли эти практичны и могут позволить подготовиться к будущему с точки зрения карьеры или развития какого-то бизнеса. Хотя из всего вышеописанного я только один пункт пытаюсь реализовать — и то с очень медленно и лениво:) В общем, это просто фантазии, но давно хотелось ими где-то поделиться:)

Вообще, было бы интересно услышать максимально много мнений читателей на эту же тему и вместе попытаться составить какую-то максимально практичную, позволяющую принимать решения прямо сейчас картину будущего. Что-то из этого наверняка уже реализуется, а что-то уже могло и реализоваться — но пока, судя по всему, не в полной мере (поправьте. если ошибаюсь).

Мы во «Фланте» любим Open Source — причем не только пишем свои открытые инструменты (werf, shell-operator, grafana-statusmap, сommunity-версия Deckhouse), но и активно участвуем в разработке различных проектов — участвуем в KEP’ах Kubernetes, в составе небольшой группы разрабатываем Dex, вносим вклад в Istio, передаем патчи и сведения о найденных багах в Cilium.

Поэтому мы решили написать несколько материалов о том, какие возможности для контрибьюторов предлагают известные в мире Open Source- и Free Software-организации. В этом материале мы рассмотрим Linux Foundation, его дочку — CNCF и европейское отделение Free Software Foundation. Сразу отметим, что участвовать в Open Source-проектах можно, даже не будучи программистом, — есть немало задач, связанных с продвижением, контентом, переводами, менеджментом. 

В этой статье мы рассмотрим, почему API-шлюзы стали ключевым элементом экосистемы современных облачных вычислений и как появление Kubernetes API Gateway упростило и стандартизировало работу с ними. 

Статья составлена на основе сразу двух англоязычных материалов. В первом (его мы поместили в самое начало) авторы на примере профессий объясняют роль различных компонентов облачных приложений, а во втором — проводят глубокий анализ все возрастающей значимости API-шлюзов для экосистемы облачных приложений, их места в рамках концепции «Kubernetes — облачная операционная система» и того, как повлияет на дальнейшее развитие API-шлюзов появление Kubernetes API Gateway. 

На днях мы работали над переводом глоссария CNCF и начали спорить о том, как писать словосочетание cloud-native. Раньше мы использовали название с дефисом — такое правило применяется к составным прилагательным в английском языке (пример — well-known actor). «Википедия» в статье «Cloud-native computing» тоже следует этому правилу, с другой стороны, название CNCF расшифровывается уже без дефиса: Cloud Native Computing Foundation. Так что нам пришлось провести небольшое расследование.

Месяц назад компания «Экспресс 42» вместе с партнерами (одним из которых как раз был «Флант») выпустила подробный отчет на 75 страницах о состоянии DevOps в России. В этой статье мы бы хотели более подробно рассказать, какие инструменты и операционные системы компании используют для работы с инфраструктурой, как меняется их проникновение от года к году, как продвигается импортозамещение и что именно российские компании понимают под этим термином.

В мае 2023 года «Фланту» исполнилось 15 лет. За это время из небольшого предприятия двух друзей-студентов, которые мечтали поставить GNU/Linux на каждый рабочий стол, мы выросли в команду опытных и уважаемых в индустрии DevOps-инженеров и постепенно трансформируемся в продуктовую компанию с собственной экосистемой продуктов.

В этой статье мы хотели порефлексировать о переходе от сервисной компании к созданию собственных продуктам, рассказать, как эти продукты развивались и что с нами произошло за последние 5 лет.

Сразу обозначим свой «символ веры». Услуга DevOps as a Service (DaaS) была, есть и будет основой нашей продуктовой линейки. Именно благодаря инженерам, которые 24/7 обслуживают сотни клиентских кластеров, мы можем получать максимально быстрый фидбэк по своим продуктам, тестировать новые релизы и собирать кучу новых идей для дорожной карты. То есть в нашем случае услуга, как бы странно для классических продуктовых компаний это ни звучало, является одним из ключевых компонентов продуктовой разработки.

Без правильной обратной связи в команде даже успешные компании могут недополучать до 22% выручки. К такому выводу пришли исследователи из Gallup и Workplace Medicine. Культура продуктивного фидбэка внедряется по двум направлениям: постоянное обучение сотрудников правилам обратной связи и организация системы обратной связи.

в последние годы компании начинают внедрять системы непрерывной обратной связи. Среди крупных компаний пионерами были Deloitte и Adobe. В результате в Adobe снизилось количество увольнений по собственному желанию, руководители и сотрудники стали чувствовать себя комфортнее, а благодаря увеличению вовлеченности в работу выросла и эффективность. Еще одно интересное следствие — люди, которые регулярно дают обратную связь, чаще становятся успешными лидерами.

Правильная организация процесса обратной связи помогает компании работать продуктивнее и серьезно экономить на найме. Вот каких результатов достигают компании, выстраивая правильную систему обратной связи:

— Личная производительность может повыситься на 39%.

— Количество прогулов может снизиться на 41%, а текучка — на 59%.

— Эффективность руководителей может вырасти на 71%.

— Удовлетворенность клиентов — на 10%.

Язык программирования — это тоже продукт. Он помогает разработчикам выражать свои идеи так, чтобы их мог интерпретировать компьютер. Может показаться, что развивать язык — это брать последние достижения теории языков программирования, реализовывать их и из года в год выкатывать разработчикам. Это не так. Егор Толстой, Kotlin Product Manager, и Андрей Бреслав, руководитель проекта Kotlin, рассказали, зачем JetBrains бесплатный язык программирования, как он устроен и откуда приходят новые пользователи. Статья вдохновлена выпуском подкаста make sense о Kotlin.

Язык — это в первую очередь рабочий инструмент, который миллионы людей используют ежедневно по много часов. Все эти люди решают разные задачи и сталкиваются с разными проблемами. Для команды разработки Kotlin знание этих сценариев и болей — основной источник идей, как улучшить пользовательский опыт и дать новые возможности программистам.

Мы начали делать Kotlin десять лет назад, а первый релиз вышел зимой 2016 года. Изначально он задумывался как язык, который улучшит жизнь Java-программистов. Сейчас на Kotlin пишут даже приложения для браузеров и iOS. Современный Kotlin — универсальный язык программирования с большим количеством приятных для разработчиков фич, статически типизированный, заточенный под большие проекты и поддержку крупных кодовых баз.

Это вторая часть материала о «синдроме самозванца». В ней мы вместе с Еленой Станковской, кандидатом психологических наук и практикующим консультантом разберем, почему возникает этот синдром, как с ним справиться и какие типы «самозванцев» выделяют ученые. Основа статьи — международные исследования и многолетний практический опыт Елены.

Синдром самозванца. Часть 1: что это, как его распознать и надо ли идти к психологу