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

Есть ли смысл тратить время на разработку форм с нуля, если есть возможность сгенерировать их? С каждым месяцем все больше людей склоняются к тому, что «не стоит». Но есть нюанс: вопрос безопасности. В этой статье мы поговорим о том, в чем заключаются угрозы работы с LLM для генерации, а также рассмотрим пример создания формы на базе DeepSeek.

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

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

Поэтому управление ресурсами — это не вспомогательная функция облака, а отдельный архитектурный контур. В рамках подхода Resource as a Strategy облачные ресурсы рассматриваются как управляемые элементы корпоративной модели: с владельцем, жизненным циклом, финансовой принадлежностью, политиками безопасности, историей изменений, зависимостями и способом воспроизводимого создания.

Сервисы PaaS предлагают комплексное решение для оптимизации как финансовых, так и временных затрат на поддержку информационных систем. В этой статье на примере управляемых сервисов Cloud X мы рассмотрим, в каких случаях потребление услуг по модели PaaS дает компаниям прямой финансовый эффект, а также обсудим, когда преимущества PaaS‑решений могут оказаться несущественными.

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

Проблема начинается, когда данных становится так много, что прежняя архитектура перестает выдерживать изменения: появляются новые источники, ускоряются бизнес-процессы, растет стоимость хранения и обработки, а каждое изменение в модели данных требует пересмотра уже принятых решений. Как быть, когда архитектурные подходы организации данных, такие как DWH, Data Fabric, Data Lake, Снежинка, Data Vault, Anchor Modeling и другие, перестают отвечать требованиям и почему под давлением динамично меняющихся обстоятельств стройные концепции постоянно нарушаются?

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

В серверной разработке кэш влияет не только на скорость ответа. От него напрямую зависят стоимость обработки запроса, нагрузка на базу, поведение системы под пиком и предсказуемость масштабирования. Именно поэтому практика кэширования имеет сегодня столько нюансов и разновидностей, если вы хотите реализовать что-то особенное или применить сложную схему кэширования, от ваших специалистов потребуются специальные навыки и умения. Под катом — рассказ о том, как мы ушли от кастомного кода к использованию гибридного кэша из .Net Framework, с какими сложностями столкнулись на этапе масштабирования системы, и как решали вопросы инвалидации кэша в процессе развития нашего проекта API Hub.

Индустрия 4.0+ — это универсальный подход к построения умного производства, в котором данные, средства автоматизации и цифровые модели позволяют управлять промышленными объектами эффективнее. Однако интереснее всего оказывается практика реализации такого подхода. В этой статье вы узнаете, почему в реальности переход на новые принципы автоматизации оказывается не простым для подавляющего большинства предприятий, и как мы воплощаем Индустрию 4.0+ за счет применения ИИ, цифровых двойников, граничных вычислений (Edge) и облачных технологий.

Связка React+MobX хорошо себя зарекомендовала при работе с формами, в то время как за реактивность модели данных в Angular обычно отвечает библиотека RxJS. Но что делать, если вы хотите воспользоваться преимуществами Angular в React или Node.js? В этой статье речь пойдет о новой библиотеке от Cloud X, которую мы разработали для того, чтобы проложить “мостик” из мира Angular, где всё богато, но дорого в мир React, где все дешево, но скудно. В этой статье я описываю применение ядра @cloudx/react-ui-kit-forms, которое отвечает за структуру модели данных, реактивность модели данных и контроль состава данных (валидацию), позволяя “скрестить” плюсы React и Angular на одном проекте. 

Когда речь идет о веб-разработке, а именно — о разработке форм, можно встретить множество мнений о том, «на чем» лучше делать проект. Очень часто React и Angular Framework рассматриваются как альтернативы друг другу. При этом выбор фреймворка — критически важный этап, который определяет дальнейшую разработку и особенности развития технологического стека компании.  

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

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

Эта статья является продолжением моей первой публикации, в которой я уже рассказывал о функциональном хаосе и поиске архитектурной устойчивости. Прочитать ее можно здесь. Сегодня же мы рассмотрим вопрос с более практической стороны и начнем с более гибкого архитектурного принципа.

Может показаться, что в современной разработке только и успеваешь, что реагировать на изменения: новые интеграции, обновленные бизнес-правила, смена технологического стека. В итоге команды тратят недели на задачи, которые должны решаться днями, а каждое новое требование встречается с сопротивлением. Но что если существует подход, который превращает постоянные изменения из головной боли в конкурентное преимущество? Сегодня мы поговорим о проектировании на основе нестабильности — архитектурной парадигме, которая позволяет системам становиться лучше с каждым изменением.