The post has been translated automatically. Original language: Russian
If you listen to the pitches of tech startups, you might think that the whole world migrated to the cloud a long time ago. """"We are building Cloud-Native SaaS", ""Serverless architecture", "Global scaling out of the box".
It sounds right. For B2C, fintech, or e-commerce, this is indeed the standard. But when you come to heavy industry, an agricultural holding company, or a remote quarry with this architecture, you very quickly face harsh reality.
A reality in which physics and infrastructure dictate their own rules, and the cloud turns from an advantage into a bottleneck.
Let 's figure out why we deliberately abandoned the classic cloud architecture in favor of On-Premise and Edge solutions, and how this changes the approach to Industrial AI development.
Three Walls that Cloud AI is crashing against
When we started designing the system, we were tempted to make a classic SaaS: data flies to the cloud, models spin there, and insights return from there. And we have not completely abandoned the design of such an option, because in some situations it turns out to be convenient. But diving into the context of industrial clients has revealed three fundamental problems with this approach.
1. Local perimeter and data sovereignty
The problem of collecting raw telemetry from equipment or sensors has long been solved by the market (trackers, LoRa, local gateways). This data is already stored in the customer's local systems: Wialon Local, 1C, SCADA, or MES.
For a large company to open these local circuits to the outside for constant streaming of data arrays to a third—party vendor's cloud is a direct security risk and compliance violation. The data must remain inside the perimeter.
2. The architectural fragility of two-way synchronization
Even if there is Internet at the facility, the constant unloading of the historical context from the local system to the cloud creates an excessive load on the customer's infrastructure. For example, to analyze a single event, our system requires a telemetry window 24 hours before and 3 hours after. To pull these historical arrays over the Internet in real time means to make the decision dependent on the quality of the "last mile" channel and artificially complicate integration.
3. We are not replacing data collection, we are adding intelligence.
Our goal is not to become another "vacuum cleaner" of raw data competing with current monitoring systems. Our goal is to become an intelligent add—on. And the add -on should integrate seamlessly into the existing landscape as much as possible, rather than requiring the customer to rebuild the entire architecture for the sake of one new module.
Our architectural choice: separation of learning and inference
To solve these problems, we have divided the life cycle of AI into two independent parts: learning (Training) and Inference.
Training can be centralized. We collect impersonal patterns, train an ensemble of algorithms on aggregated data, and validate new versions of models in a controlled environment. Here, a cloud or powerful local servers are appropriate.
The inference must be local (On-Premise/Edge). Decision-making itself (analyzing the event and making a verdict) should take place inside the client's contour. The models are packaged in lightweight containers, which are deployed on a local enterprise server or even on an edge device.
How it works in practice
The architecture of our system looks like an intelligent add-on that does not require a "big bang" and infrastructure replacement.
1. Local context collection. The container connects to existing monitoring systems or SCADA/MES inside the enterprise LAN. It collects the necessary data via API or directly from databases. No internet connection is required at this stage.
2. Inference on the periphery. When an event occurs, the local model analyzes it in context ( telemetry window, operating modes, historical data). The entire calculation takes place in milliseconds, without delays for network requests.
3. Generating insight. The system outputs a verdict and a text explanation directly to the operator's local interface.
4. Asynchronous synchronization. Only confirmed insights, quality metrics, and impersonal feature vectors (not raw data), agreed with the client, are packaged in a lightweight package and sent to the center when a communication channel appears. This channel is also used to get updated model weights.
Engineering compromise: updating models without the Internet
The most common question in On-Premise architecture is: "How will you update the model if the object is offline?"
We solve this through the "lightweight updates" mechanism. Instead of transferring gigabytes of new data or retraining the model from scratch on the spot, the system downloads only the delta — updated weights and rules of the ensemble. This requires a minimum of traffic and allows you to keep the algorithms up-to-date even at facilities with an intermittent communication channel (store-and-forward). In very severe cases, no one canceled the "walking Internet".
Why is this important for the industry
The choice between Cloud and On-Premise are not a hype issue. It's a matter of matching the architecture to the physical and business constraints of the environment.
The cloud scales the business logic perfectly. But when it comes to industrial AI, where latency, privacy, and operating in an uncertain infrastructure environment are important, the cloud will have to move away.
We came to the conclusion that in Industrial AI, the best architecture is the one that brings intelligence to data, rather than trying to forcibly drag all data to intelligence.
──────────────────────────────────────────────────
Colleagues, how do you solve the Cloud vs On-Premise dilemma in your projects? Have you encountered resistance from customers when trying to move their data to the cloud? Share your experience in the comments.
#IndustrialAI #EdgeComputing #OnPremise #SystemDesign #MachineLearning #AstanaHub
Если вы послушаете питчи технологических стартапов, можно подумать, что весь мир давно мигрировал в облако. «Мы строим Cloud-Native SaaS», «Serverless архитектура», «Глобальный скейлинг из коробки».
Звучит правильно. Для B2C, финтеха или e-commerce это действительно стандарт. Но когда вы приходите с этой архитектурой в тяжелую промышленность, агрохолдинг или на удаленный карьер, вы очень быстро сталкиваетесь с суровой реальностью.
Реальность, в которой физика и инфраструктура диктуют свои правила, и облако превращается из преимущества в узкое место.
Давайте разбираться, почему мы сознательно отказались от классической облачной архитектуры в пользу On-Premise и Edge-решений, и как это меняет подход к разработке Industrial AI.
Три стены, о которые разбивается облачный ИИ
Когда мы начинали проектировать систему, у нас был соблазн сделать классический SaaS: данные летят в облако, там крутятся модели, оттуда возвращаются инсайты. И мы не отказались полностью от проектирования такого варианта, т.к. в некоторых ситуациях он оказывается удобным. Но погружение в контекст промышленных клиентов показало три фундаментальные проблемы этого подхода.
1. Локальный периметр и суверенитет данных
Проблема сбора сырой телеметрии с техники или датчиков уже давно решена рынком (трекеры, LoRa, локальные шлюзы). Эти данные уже лежат в локальных системах заказчика: Wialon Local, 1С, SCADA или MES.
Для крупной компании открыть эти локальные контуры наружу для постоянного стриминга массивов данных в облако стороннего вендора — это прямой риск безопасности и нарушение комплаенса. Данные должны оставаться внутри периметра.
2. Архитектурная хрупкость двусторонней синхронизации
Даже если интернет на объекте есть, постоянная выгрузка исторического контекста из локальной системы в облако создает избыточную нагрузку на инфраструктуру заказчика. Например, для анализа одного события нашей системе требуется окно телеметрии за 24 часа до и 3 часа после. Тянуть эти исторические массивы через интернет в реальном времени — значит делать решение зависимым от качества канала «последней мили» и искусственно усложнять интеграцию.
3. Мы не заменяем сбор данных, мы добавляем интеллект
Наша цель — не стать еще одним «пылесосом» сырых данных, конкурирующим с текущими системами мониторинга. Наша цель — стать интеллектуальной надстройкой. А надстройка должна максимально бесшовно встраиваться в существующий ландшафт, а не требовать от заказчика перестройки всей архитектуры ради одного нового модуля.
Наш архитектурный выбор: разделение обучения и инференса
Чтобы решить эти проблемы, мы разделили жизненный цикл ИИ на две независимые части: обучение (Training) и инференс (Inference).
Обучение может быть централизованным. Мы собираем обезличенные паттерны, дообучаем ансамбль алгоритмов на агрегированных данных и валидируем новые версии моделей в контролируемой среде. Здесь облако или мощные локальные серверы уместны.
Инференс должен быть локальным (On-Premise / Edge). Само принятие решений (анализ события и вынесение вердикта) должно происходить внутри контура клиента. Модели упаковываются в легкие контейнеры, который разворачивается на локальном сервере предприятия или даже на edge-устройстве.
Как это работает на практике
Архитектура нашей системы выглядит как интеллектуальная надстройка, которая не требует «большого взрыва» и замены инфраструктуры.
1. Локальный сбор контекста. Контейнер подключается к существующим системам мониторинга или SCADA/MES внутри локальной сети предприятия. Он забирает необходимые данные по API или напрямую из баз данных. Никакого выхода в интернет на этом этапе не требуется.
2. Инференс на периферии. Когда происходит событие, локальная модель анализирует его в контексте (окно телеметрии, режимы работы, исторические данные). Всё вычисление происходит за миллисекунды, без задержек на сетевые запросы.
3. Генерация инсайта. Система выдает вердикт и текстовое объяснение прямо в локальный интерфейс оператора.
4. Асинхронная синхронизация. Только подтвержденные инсайты, метрики качества и обезличенные векторы признаков (а не сырые данные), согласованные с клиентом, упаковываются в легкий пакет и отправляются в центр при появлении канала связи. Этот канал используется также для получения обновленных весов модели.
Инженерный компромисс: обновление моделей без интернета
Самый частый вопрос при On-Premise архитектуре: «Как вы будете обновлять модель, если объект не в сети?»
Мы решаем это через механизм «легковесных обновлений». Вместо того чтобы передавать гигабайты новых данных или переучивать модель с нуля на месте, система скачивает только дельту — обновленные веса и правила ансамбля. Это требует минимум трафика и позволяет поддерживать актуальность алгоритмов даже на объектах с прерывистым каналом связи (store-and-forward). В совсем уже тяжелых случаях никто не отменял «пеший интернет».
Почему это важно для индустрии
Выбор между Cloud и On-Premise — это не вопрос хайпа. Это вопрос соответствия архитектуры физическим и бизнес-ограничениям среды.
Облако отлично масштабирует бизнес-логику. Но когда речь заходит о промышленном ИИ, где важны задержка, конфиденциальность и работа в условиях неопределенной инфраструктуры, облаку придется отойти.
Мы пришли к выводу, что в Industrial AI лучшая архитектура — это та, которая приносит интеллект к данным, а не пытается насильно перетащить все данные к интеллекту.
──────────────────────────────────────────────────
Коллеги, как вы решаете дилемму Cloud vs On-Premise в своих проектах? Сталкивались ли вы с сопротивлением заказчиков при попытке увести их данные в облако? Делитесь опытом в комментариях.
#IndustrialAI #EdgeComputing #OnPremise #SystemDesign #MachineLearning #AstanaHub
Share
