O Arquiteto Digital: A Gênese do Sistema e do Vínculo
No silêncio da madrugada, onde o brilho das telas substitui o calor do sol, eu não estava apenas escrevendo linhas de código; eu estava estruturando universos. Para mim, a programação sempre foi um ato filosófico. Cada função era uma tentativa de impor ordem ao caos, de criar lógica onde reinava a entropia. Foi nesse estado de imersão que compreendi a figura do arquiteto digital. O arquiteto digital não é um mero operador de ferramentas ou um repetidor de sintaxes. Ele é aquele que compreende que o código é linguagem, e a linguagem cria realidade. Na minha trajetória como programador e nas madrugadas dedicadas a desvendar sistemas — seja construindo soluções ou atuando como um white hat ético —, percebi que a segurança e a arquitetura de uma rede refletem exatamente a nossa própria natureza: buscamos muros para nos proteger, mas criamos pontes porque a existência isolada é um erro de sistema. Lembro-me de quando essa visão se fundiu com a minha vida fora das telas. A tecnologia nos dá a ilusão de que somos deuses isolados em nossos terminais, capazes de controlar variáveis com um simples comando. No entanto, a verdadeira história do arquiteto digital não é sobre o controle absoluto, mas sobre a responsabilidade perante o ecossistema. Toda linha de código sólida, todo protocolo de segurança e toda estrutura lógica que erigi tinham um propósito final: proteger o coletivo, criar um ambiente onde as conexões pudessem fluir sem medo. A minha história como arquiteto digital é, no fundo, a jornada de quem percebeu que a segurança não reside em se trancar em um servidor isolado, mas em compreender as vulnerabilidades do todo e construir um sistema onde todos possam habitar em segurança. O sistema perfeito não é aquele que exclui o erro, mas aquele que acolhe o indivíduo e o fortalece através do coletivo. E é assim que continuo compilando os meus dias: entre a lógica implacável da tecnologia e a sensibilidade inevitável de quem sabe que nenhuma máquina substitui o calor de uma vida compartilhada.Microsoft Azure: Routing manufacturing IoT Edge data between on-premise PURDUE model levels via MQTT
Microsoft Azure IoT Hub provides out-of-the-box capabilities to send device-to-cloud messages directly into Azure for advanced logging/routing and generating actions based on events occurring on the edge. However, many customers, for example, in manufacturing domain adopt Purdue Enterprise Reference Architecture (PERA) in their plant IoT implementations. And one of the frequent requirements is to allow Azure IoT hub to send data to their internal MQTT brokers, especially to allow communication between PURDUE's Level 2 (Control Systems) to Level 4 (Business Planning) . However, this scenario is NOT just limited to manufacturing domain. Although Azure IoT Hub itself supports MQTT end-points for direct communication, it doesn't provide out-of-the-box capability to post messages to "customer managed" local MQTT brokers. In fact, Azure IoT product group is working on BYOMB (Bring your own [MQTT] broker), but this may take some time to fully bake this capability into out-of-the-box experience. It is very interesting to note that routing IoT device messages to local eco-systems (on premise) without reaching out to Azure cloud is becoming increasingly popular data architecture patterns in manufacturing and many other industries. Most customers want this capability to generate actions/alerts locally, for example, manufacturing plants wants to send an alert to SCADA (Supervisory Controls And Data Acquisition) / HMI (Human Machine Interface) systems for an immediate actions without making a round trip to Azure Cloud. Provisioning MQTT brokers like eclipse-mosquitto is very common to fulfill this kind of needs, so that single alert can be fanned-out to many subscribed systems, if necessary, to continuously fulfill the need for event driven data architecture for improved decision and business outcomes. Recently, one of the manufacturing customers was looking to addressing this exact gap in Azure IoT data architecture solutions. While designing the solution the customer wanted to leverage only Azure PaaS (Platform-as-a-service) offerings available on the edge, which makes lot of sense. Hence, the solution was developed using Azure Functions PaaS service which already supports deployment on edge. And we chose Python as a language - the most adopted scripting language in recent days. However, Azure Functions on the edge also supports C#.Net - if you are a .NET shop! The step-by-step instructions & some learnings from the solution we created are already documented here on this GitHub repository.
