Последнее десятилетие проходило под знаком контейнеризации, появлялись десятки и сотни инструментов для управления контейнерами, создания виртуальных сетей для взаимодействия контейнеров на разных узлах кластера, появлялись системы маршрутизации трафика, мониторинга доступности и иные DevOps-инструменты, которые во многом трансформировали деятельность системных администраторов вплоть до того, что начали появляться сомнения в потребности организаций в администраторах Linux (особенно с учетом появления облачных провайдеров, предоставляющих как среды для запуска контейнеров в Kubernetes, так и полностью настроенные и управляемые сервисы баз данных, очередей, систем для накопления и анализа логов и т.п.). Но нередко возникают ситуации, когда нужно осуществить некоторый уровень изоляции или ограничения уже запущенных процессов и для этого можно использовать возможности control groups ядра Linux, которые также лежат в основе технологий контейнеризации Docker и LXC. В этой статье мы последовательно разберем возможности cgroups, обсудим отличия новой cgroups v2 и затронем тему контейнеризации на основе Linux Containers. Да пребудет с вами безопасное окружение выполнения.

Микросервисная архитектура предполагает декомпозицию системы на относительно независимые фрагменты с собственными источниками данных, которые могут переиспользоваться в различных процессах и обмениваться данными. Но в таком решении есть и оборотная сторона, связанная с необходимостью включения логики оркестрации или непосредственно в код сервисов (что затрудняет возможность гибкого изменения процесса), либо использовать внешний оркестратор, который будет обеспечивать запуск микросервисов с входными параметрами, получение и передачу результата, а также управление сценарием при возникновении ошибок или определенных ситуаций при выполнении процесса.

Второй вариант может быть реализован в виде исполняемого кода, либо с использованием специальных движков для исполнения сценария бизнес-процесса, который может включать в себя вызов внешних сервисов. Стандартом в области описания бизнес-процессов является визуальная нотация BPMN 2.0 и наибольший интерес представляет соединение графической диаграммы и исполняемых сценариев, которое также называется Executable BPMN 2.0 и среды для его исполнения, среди которых можно назвать jBPM, Flowable, Camunda BPM и Activiti (она интересна еще и тем, что на ней реализуется управление процессами в Open Source системе управления документами Alfresco). В этой статье мы рассмотрим основы BPMN и создадим простой процесс для управления системой полива в зависимости от измеренной влажности (все компоненты системы реализованы как микросервисы).

В первой части статьи мы последовательно рассмотрели шаги по созданию и преобразования приложения для Android, необходимыми для реализации тестов, начиная от Unit-тестирования и заканчивая E2E-тестами. Сегодня мы рассмотрим архитектурные подходы Model-View-Intent (MVI), создадим собственную реализацию MVI и на ее примере разберем особенности разработки и тестирования приложений на MVI и подготовимся к обсуждению разработки тестируемых реактивных интерфейсов на Jetpack Compose в следующей части статьи.

Начиная с версии 5.3 JUnit Platform предоставило возможность параллельного запуска тестов, что может существенно увеличить скорость прохождения тестовых сценариев. Но в то же время, если сценарии используют какие-либо разделяемые ресурсы, общие для всех тестов, без использования механизмов синхронизации можно обнаружить неустойчивое выполнение тестов из-за возможного переключения потоков выполнения во время исполнения тестируемого кода ("состояние гонки"). В этой статье мы рассмотрим как настроить параллельное тестирование и как обнаружить (и преодолеть) потенциальные проблемы доступа к общим ресурсам.

При всех достоинствах Kafka как распределенного хранилища потока сообщений, боль вызывало раздельное хранение метаданных (топологии разделов, конфигурации кластера и прочего) и необходимость запуска в кластере рядом с Kafka еще и Apache Zookeeper. Побочным эффектом такого соседства (кроме дополнительных забот об администрировании и мониторинге) является долгое время восстановления после сбоя при больших размерах кластера, значительном количестве разделов или сложной топологии групп. Но ситуация улучшается и отличная новость появилась полторы недели назад в KIP-833, что в ближайшей версии Kafka 3.3 новый протокол согласования метаданных (KRaft), работающий внутри Kafka без Zookeeper, будет признан Production-Ready и далее постепенно зависимость от Zookeeper будет помечена как deprecated и удалена. В этой статье мы поговорим об особенностях протокола KRaft и разберемся как настроить новый кластер Kafka без необходимости установки Zookeeper.

Оператором в Kubernetes принято называть развертывание, которое самостоятельно управляет ресурсами кластера, регистрирует новые Custom Resource Definition (CRD) и, в некоторых случаях, добавляется для наблюдения за существующими ресурсами (через механизмы Dynamic Admission Control). В этой статье на примере создания оператора для развертывания и управления кластером Aerospike мы попробуем разобраться с этапами создания оператора, способами взаимодействия с кластером и проблемами, с которыми можно встретиться в реальной практике. Всех практикующих DevOps и желающих поднять автоматизацию развертывания своих сервисов на новый уровень приглашаю под кат.

Хорошее мобильное приложение должно быть не только создано с использованием современных архитектурных шаблонов, но и быть подготовленным к реализации автоматических тестов. Мы рассмотрим с вами на практическом примере как создается приложение с учетом возможностей тестирования, чем отличаются архитектуры и соответствующие подходы к созданию тестов и как создать полный спектр тестов от unit-тестирования бизнес-логики до End-to-End тестов приложения как единого целого. В первой части статьи мы поговорим про разработку интерфейсов без использования реактивной модели, последовательно создадим (и доработаем) приложение на архитектурах MVP и MVVM и разработаем тесты (с использованием виртуального времени на тестовом диспетчере, моков и Hilt для подстановки тестовых объектов). Во второй части статьи речь пойдет о MVI и о тестировании приложений для Jetpack Compose (включая анимацию и передачу данных через LocalComposition-объекты). Всех, кому интересна мобильная разработка, приглашаю под кат.

Тема задержки доступа и скорости извлечения сетевых ресурсов никогда не перестанет быть актуальной. Максимально близкое расположение источника влияет не только на скорость загрузки и пользовательский опыт, но и на эффективность работы глобальной сети в целом, поскольку позволяет локализовать трафик и сократить загрузку магистральных каналов, предпочитая использовать кэшированные или расположенные локально реплики сетевых ресурсов. Не случайно Google реализует модель сохранения локальных кэшей на оборудовании крупных региональных провайдеров (Google Global Cache) и интеллектуальные алгоритмы в маршрутизации на ближайшую реплики. В этой статье мы обсудим различные подходы к реализации распределенной сети доставки контента (Content Delivery Network, он же CDN), а также акцентируем возможные решения для создания CDN в масштабах отдельно взятой страны или города.

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

Сердцем любого backend являются данные. Существует два сценария использования данных. В одном из них данные изменяются редко, но при этом активно используются в сыром или агрегированном виде и применяются для целей аналитики в реальном времени (такие системы принято называть OLAP). В других системах важно обеспечить сохранение с высокой скоростью большого количество неструктурированных или полуструктурированных объектов, поступающих от устройств Интернета вещей, из источников произвольных событий, наблюдений за активностью пользователя (такие системы называются OLTP - Online Transaction Processing, ориентированные на большое количество транзакций с минимальной задержкой обработки). Для таких систем важно обеспечить надежность хранения данных, поддержку распределенного хранения на нескольких серверах и/или дата-центрах и сохранение консистентности распределенного хранилища.

При этом сами объекты могут отличаться от привычной реляционной модели данных и представляться, например, в виде json-документов с произвольной схемой, объектов с полями со множественными значениями или графов. Разумеется это приводит к необходимости изучения новых подходов к поиску и добавлению данных, использованию специальных драйверов. Но что если соединить распределенное надежное хранилище и синтаксис запросов, близкий к SQL? В этой статье мы познакомимся с проектом Apache Cassandra и обсудим на примере разработки API на Kotlin для сбора телеметрии с датчиков, расположенных по всему миру (с поддержкой отказоустойчивости и управляемой репликации между дата-центрами).

Любая асинхронность повышает уровень тревожности при разработке автоматических тестов. Особенно в ситуации, когда нужно выполнить проверку корректности работы системы, основанной на графе состояний со взаимодействием с внешним API через Flow. Примером такой системы может быть Telegram-бот, построенный на диалоге с внешним пользователем. В этой статье мы с вами создадим простой бот на Kotlin (с поддержкой многоязычности) и последовательно разберем возможные способы использования асинхронных моков и тестов для Flow с использованием библиотеки mockk и типобезопасной библиотеки для взаимодействия с API Telegram на Kotlin.

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

Как известно, системные администраторы делятся на 3 категории - кто еще не делает резервные копии, кто уже делает и кто уверен, что из них можно восстановиться. В нашу эпоху DevOps вопрос автоматизации управления резервным копирования стал еще более актуальным, поскольку каждая система предлагает свой уникальный способ создания (и восстановления) дампа и даже в пределах одной системы может быть множество разных способов хранения данных. В этой статье мы обсудим возможные стратегии и доступные технологические решения для создания резервных копий данных для развертываний в Kubernetes и поговорим о возможностях автоматизации и мониторинга процесса резервного копирования.

В предыдущей статье мы рассмотрели использование Go для создания веб-приложений (с выполнением через Web Assembly). Но прежде всего Go интересен как язык для реализации высокопроизводительных и неблокирующих решений на стороне сервера и в этой статье мы изучим использование Go для backend на примере разработки API для мобильного приложения для совместного редактирования списка покупок. Приложение будет включать в себя механизмы авторизации, запроса и модификации объектов, а также мгновенные уведомления (через веб-сокеты и Push) и мониторинг доступность API. В качестве примера мы создадим минимальный API, для которого обеспечивается уведомление всех зарегистрированных пользователей об изменении списка, а также будут предусмотрена отправка пуш-уведомлений всем адресатам по запросу.

Как нередко бывает - новое, это хорошо забытое старое. Эволюция инструментов разработки напоминает колебания маятника от универсального мощного инструмента для написания кода и навигации по проекту до визуального конструирования описания процессов из алгоритмических блоков (начиная от блок-схем и заканчивая executable BPMN). Были и остаются популярными среды разработки, включающие элементы визуального проектирования интерфейсов и быстрого прототипирования с использованием готовых компонентов (например RAD-среды от Embarcadero) и конструкторы и среды выполнения BPMN-процессов (например Activiti Engine, Camunda, jBPM и др.) и это в значительной степени стало основой для создания инструментов для разработки low-code приложений.

В то же время наблюдалось движение и в облачных архитектурах, где hosted-решения последовательно заменялись на внешние облачные решения для типовых задач (аутентификация, логирование, хранилища данных и файлов и др.) с постепенной интеграцией возможностей запуска кода непосредственно внутри инфраструктуры облака (Amazon Lambda, Google Cloud Functions и др.).

В этой статье мы рассмотрим один из возможных вариантов организации архитектуры приложения, сконструированного с использованием подходов low-code и запуска приложения и его компонентов в управляемой инфраструктуре.

Технология WebAssembly появилась относительно недавно (в 2015 году) и позиционировалась как альтернатива JavaScript для выполнения в среде браузера с максимально достижимой производительностью. Приложение на WebAssembly может использовать все возможности, доступные в "песочнице" браузера для JS (доступ к Document Object Model, дополнительным классам HTML5), но при этом может быть изначально написано на других технологиях разработки и скомпилировано в формат байт-кода WASM, предоставляя свои интерфейсы сценариям на JavaScript.

Наиболее известным набором инструментов для компиляции в wasm32 является emscripten, с его помощью можно скомпилировать приложение, написанное на C/C++ или на любом языке, имеющим frontend-компилятор для LLVM. При этом компилятор подменяет вызовы OpenGL и POSIX на соответствующие аналоги в браузере, что например используется при компиляции библиотеки skia для браузера (canvaskit) из исходного кода на C++, а также портирование существующих библиотек (например, ffmpeg или opencv). Но некоторые языки программирования поддерживают wasm32 как одну из целевых платформ, среди которых можно выделить Kotlin (Native) и Go. В этой статье мы обсудим общие вопросы о запуске приложений Go в среде браузера и использование библиотеки Vecty для создания веб-приложений на основе переиспользуемых компонентов.

Язык Go благодаря своей простоте, возможности компиляции в выполняемый образ и встроенной поддержке многозадачности стал, в некотором смысле, "серебряной пулей" для создания высокопроизводительных инструментов и, совместно с Rust, сформировал современный технологический ландшафт для DevOps. Но в действительности, благодаря поддержке набора инструментов LLVM, стало возможным использовать Go и для встраиваемых систем, например при создании мобильных приложений для Android/iOS (например, проекты android-go или gomobile) или микроконтроллеров. В этой статье мы поговорим о возможностях проекта TinyGo, его преимуществах по сравнению с C++ для Arduino и других микроконтроллеров, рассмотрим несколько примеров по работе с оборудованием (на примере реализации драйвера шины SPI для светодиодной ленты WS2812).

Каждому из вас наверняка знакома ситуация, когда через полгода работы над проектом команды из нескольких человек, вы внезапно обнаруживаете, что в разных частях проекта используется разные правила оформления кода, тесты написаны, но отчеты по ним не собираются и не анализируются, в виджетах встречается бизнес-логика и вычислительно сложные задачи вызываются непосредственно в методе build. Кроме этого появились гигантские классы и методы, в коде избыточно много использования типа dynamic или в функциях отсутствует тип возвращаемого результата. И у вас возникает желание открутить маховик времени в начало проекта и сделать все необходимое, чтобы вероятность возникновения такого хаоса была минимальной. В этой статье мы рассмотрим некоторые удобные механизмы анализа кода и результатов тестов для Flutter.

Язык программирования Dart был изначально разработан как перспективная замена JavaScript в веб-приложениях (с поддержкой асинхронности, потоков, классической поддержки ООП и возможностью использования строгой типизации), но, к сожалению, в этом качестве он так и не достиг значительных успехов. Однако в дальнейшем компилятор Dart был доработан для других целевых платформ и наибольшего успеха достиг в сочетании с фреймворком Flutter как инструмент разработки высокопроизводительных мобильных приложений, создаваемых на основе реактивной модели. Но нужно отметить, что наряду с возможностями компиляции в целевые платформы Android и iOS (а также, разумеется, Web), Dart также может использоваться для создания приложений для операционных систем Windows, Linux и MacOS, что в сочетании с возможностями фреймворка Flutter и оптимизированных платформенных реализаций Flutter Engine и Embedder, представило новый путь к созданию нативных приложений с графическим интерфейсом. В этой статье мы рассмотрим возможности и особенности реализации desktop-приложений на Flutter и разберемся с механизмами интеграции внешних библиотек.

Для создания микросервисной архитектуры на Go может использоваться фреймворк Flogo, основанный на идеях потока сообщений/данных между микросервисами и реакции на события. В этой статье мы рассмотрим его возможности на примере простой задачи обработки данных телеметрии.