Требования, конечно, меняются. Иногда. Но гораздо чаще случается, что мы не до конца выяснили у заказчика и стейкхолдеров все требования, оставив множество умолчаний.

В этой статье я опишу примеры подобных ситуаций и расскажу о техниках, позволяющих задать нужные вопросы, выявить максимальное количество требований на ранних этапах анализа, обсудить со стейкхолдерами нужность этих требований и их приоритеты. Как правило, после применения всех техник в 1,5−2 раза возрастает объём требований и юзкейсов для обсуждения — и это одна из основных задач аналитика: задать все вопросы и выяснить все детали до начала проектирования и разработки системы.

Возможно, многие подходы вы уже применяете, а о некоторых даже не слышали; я попробую свести их в единую систему.

Эта статья носит практический характер, составлена в виде пошагового чек-листа. Если вы сочтёте полезными описанные в статье техники и начнёте применять что-то из изложенного в этом материале, буду рад получить обратную связь.

Kubernetes, как система оркестрации, позволяет автоматизировать процесс развертывания сложных приложений и восстанавливать ожидаемое состояние кластера после сбоев. В общем случае приложение представляет собой резидентно запущенные контейнеры, которые обрабатывают запросы клиентов в цикле обработки событий, при этом при росте нагрузки могут создаваться дополнительные реплики (с использованием механизма Horizontal Pod Autoscaling). Однако, нередко бывают случаи, когда сервис используется не очень часто, но при этом в запущенном состоянии он забирает большое количество оперативной памяти или процессорного времени, и желательно обеспечить механизм запуска сервиса по запросу (или по внешнему событию). Для реализации такого варианта использования сейчас доступен инструмент knative, который был принят в марте 2022 года в качестве incubating-проекта в CNCF (Cloud Native Computing Foundation). В этой статье мы разберемся с основными понятиями knative и попробуем создать архитектуру приложения, основанную на событиях, с использованием eventing-возможностей knative.

Всем известный закон Мёрфи гласит: «Если что-то плохое может случиться, то оно обязательно произойдет». Согласитесь, не самая позитивная установка, особенно когда это касается работы. И тут мне стало любопытно, а есть ли такие законы, которые мне, как ИТ-специалисту, максимально помогут избежать «чего-то плохого». К своему удивлению, я их нашел, и даже не один. Потому делюсь с вами сегодня своими сакральными знаниями в блоге ЛАНИТ. 

В процессе изучения разных алгоритмов и структур данных приходит понимание, что не все они применимы в прикладных задачах (в отличие от задач про Васю и Петю/Алису и Боба). Но тот факт, что алгоритм/структура данных не является полезной на практике не означает, что идеи в них содержащиеся не привлекают пытливые умы даже из чистого любопытства. Потому речь пойдёт о красивых (субъективно) и, что важно, простых с точки зрения концепции структурах данных. 

Помните: если что-то не компилируется, это псевдокод. 

При использовании языка Go чувствуется нехватка хорошей библиотеки для работы с потоками данных. Имеющиеся библиотеки в основном написаны во времена до дженериков и имеют не очень удобный интерфейс.

С выходом Go 1.18 появилась возможность реализовать библиотеку потоковой обработки данных goio, вдохновлённую превосходными Scala-библиотеками cats-effect и fs2.

Привет, Хабр! Меня зовут Вова, я разрабатываю observability-платформу в Ozon. Как-то раз в наш уголок на 42 этаже заглянули коллеги — и поделились наблюдением. Если открыть рядом графики времён запросов и ответов двух живущих в Kubernetes и общающихся между собой микросервисов, то иногда можно наблюдать большую разницу в высоких квантилях: клиент считает, что один ответ из сотни ему приходит за сто миллисекунд, сервер же говорит, что успевает ответить за десять.

Куда ушло время? Можно ли его вернуть? Под катом расскажу о том, с какими граблями может столкнуться микросервис, живущий в типичной инсталляции Kubernetes.

Эта статья берет за основу Go 1.12.

Go радует нас легким и умным управлением горутинами. Легким, поскольку стек горутин изначально весит всего 2 КБ, а умным, потому что горутины могут автоматически увеличиваться/уменьшаться в соответствии с нашими потребностями.

(Disclaimer!) Данная точка зрения не претендует на роль абсолютной истины и является лишь результатом моего опыта, чтения, наблюдений и размышлений.

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

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

Эта статья оперирует версией Go 1.14.

Релокация — это этап процесса линковки, в рамках которого каждому внешнему символу присваиваются соответствующие адреса. Поскольку пакеты компилируются отдельно, они не имеют понятия, где функции или переменные из других пакетов находятся фактически. Начнем с тривиального примера, когда нам потребуется релокация.

Первая ассоциация, которая приходит при упоминании serverless-решений это облачные решения вроде AWS Lambda, Azure Functions или Google Functions, а на российском рынке Yandex Cloud Functions. У них имеются определенные бесплатные лимиты и это подкупает. В случаях когда вы уже используете в работе K8s, смысла выносить отдельные части вашего приложения за кластер нет. Если вам интересно познакомиться с возможностями использования функций, с вариантами serverless решений на Bare-metal Kubernetes, а также узнать, как и где можно развернуть свое PoC решение бесплатно на облачной виртуальной машине, то приглашаю под кат.

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

Распределённая трассировка (Distributed Tracing) - это метод, используемый для мониторинга приложений. Для микросервисов он просто незаменим.

В качестве примера мы будем использовать приложение Meow-Micro , специально созданное для этой статьи. Но вы можете развернуть собственные приложения, если захотите.

Довольно долгое время я воевал с красно-черным деревом. Вся информация, которую я находил, была в духе "листья и корень дерева всегда черные, ПОТОМУ ЧТО", "топ 5 свойств красно-черного дерева" или "3 случая при балансировке и 12 случаев при удалении ноды". Такой расклад меня не устраивал.

Мне не хотелось заучивать свойства дерева, псевдокод и варианты балансировки, я хотел знать: почему. Каким образом цвета помогают при балансировке? Почему у красной ноды не может быть красного потомка? Почему глубину дерева измеряют "черной высотой"?

Ответы на эти вопросы я получил только тогда, когда мне дали ссылку на лекцию про два-три дерево, с которого мы и начнем.

Эта статья разделена на 3 логические части. Я рекомендую прочитать их в указанном порядке. Первая часть (данная) будет направлена на введение в кчд и знакомство с ним. Во второй части мы поговорим о балансировке и вставке в кчд. В третьей, завершающей, части мы разберем процесс удаления ноды. Наберитесь терпения и приятного чтения.

Часть 5. В масштабе Вселенной

Эта статья написана главным образом для родителей детей, страдающих различными формами аутизма. Родители проводят со своими «особенными» детьми гораздо больше времени, чем дефектологи, психологи и учителя. И поэтому, я считаю, что они должны понимать, что происходит с их детьми и как это исправить.

В этом руководстве мы кратко обсудим, как Helm может помочь упростить управление приложениями Kubernetes, и узнаем, как использовать Helm для создания базового чарта.

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

В этом руководстве мы позволим Helm создать для нас базовый чарт. В этом руководстве предполагается, что у вас есть хотя бы базовое понимание того, что такое Helm. Если вы не знакомы с ним, я предлагаю вам ознакомиться с этим руководством, прежде чем приступить к статье: https://www.alibabacloud.com/help/doc-detail/86511.htm

Эта статья не о том, как проходить собеседования, чтобы вас взяли. Она о том, как смотреть на работодателей, чтобы сделать выбор в условиях, когда тексты вакансий, рекрутеры, да и весь процесс найма копируют друг друга. Все работают итерациями, используют Jira, технический стек тоже часто идентичен. С первого взгляда кажется, что это одна и та же кухня. Стоит ли сменить поднадоевшее, но привычное место работы на новое и неизведанное? Как выбрать между двумя офферами с похожими условиями? Как понять, где работать будет комфортно, а где придется терять нервы и интерес к делу?

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