Publicidade
A disseminação da computação em nuvem e da Internet das Coisas (abreviada como IoT, de Internet of Things, em inglês) criou um amplo espaço para aplicações inovadoras. Edição 57 ROBERTO C. MAYER Introdução A disseminação da computação em nuvem e da Internet das Coisas (abreviada como IoT, de Internet of Things, em inglês) criou […]
A disseminação da computação em nuvem e da Internet das Coisas (abreviada como IoT, de Internet of Things, em inglês) criou um amplo espaço para aplicações inovadoras.
Edição 57
ROBERTO C. MAYER
A disseminação da computação em nuvem e da Internet das Coisas (abreviada como IoT, de Internet of Things, em inglês) criou um amplo espaço para aplicações inovadoras. Milhares de startups estão sendo criadas no intuito de desenvolver e usufruir desse potencial de inovações.
Ao longo dos últimos cinquenta anos, o número de CPUs no nosso planeta tem crescido a uma taxa de cerca de dez vezes a cada década. A história pode ser resumida, a partir da era dos mainframes, seguidos sucessivamente pelos minicomputadores, os PCs, os dispositivos móveis e os dispositivos autônomos (que chamamos de ‘coisas’ conectadas porque não precisam de um ser humano operando-os localmente).
Ao mesmo tempo, as redes de telecomunicação tem se tornado tão amplas que já houve quem afirmasse que ‘o computador é a rede’. Porém, a moderna rede global é muito menos confiável que as tradicionais redes locais: não só há links de Internet indisponíveis ou operando com lentidão, mas temos um número cada vez maior de dispositivos cuja energia provém de baterias (que se esgotam no momento menos oportuno, segundo a lei de Murphy).
Em outras palavras, o ambiente de nuvem e IoT apresenta conexões que não são totalmente confiáveis, e contém dispositivos que desaparecem da rede (por falta de energia, como celulares, tablets, máquinas de processamento de cartões de débito/crédito, etc.).
Ao mesmo tempo, desejamos integrar os servidores de missão crítica tradicionais neste novo ambiente, sem abrir mão de características como segurança, escalabilidade e auditabilidade, entre outras.
Assim, verificamos que não apenas o ritmo da inovação em software, que sempre ficou atrás da velocidade da inovação em hardware, mas também as características do novo ambiente se constituem num novo gargalo de desenvolvimento de software, que precisamos solucionar ao menor custo possível.
Para exemplificar as dificuldades geradas pelo novo ambiente, vamos analisar um primeir cenário concreto, retratado na figura: a imagem retrata a entrada de um estacionamento (pode ser de um shopping center, hotel, centro de convenções, aeroporto, etc.), que possui câmeras (objetos) capazes de identificar as placas dos veículos.
Se você e eu agendamos uma reunião nesse lugar, em vez de trocarmos mensagens SMS ou WhatsApp enquanto chegamos, é muito mais prudente informarmos um ao outro a placa do veículo que usaremos nesse dia, e o sistema de controle do estacionamento nos notificar no celular quando o outro chegar.
Certamente não se trata de uma inovação revolucionária; o hardware necessário para sua operação já está todo comprado e instalado. Mas por que o software para viabilizar a idéia não existe?
Observe que o número de usuários que o sistema do estacionamento passaria a atender seria milhares de vezes superior ao originalmente projetado (era para o gerente do estacionamento, os caixas e uma central de segurança). O administrador do estacionamento não pode correr o risco de paralisar o faturamento do estacionamento (que é a sua missão crítica) quando há muitos usuários aguardando a notificação de chegada de seus amigos. Concluo a análise deste exemplo observando que nem nossos celulares, nem o software no servidor do estacionamento são capazes de sanar a dificuldade isoladamente.
Incorporar novos usuários, por meio da nuvem, a sistemas de informação corporativos de missão crítica ainda é um desafio para a grande maioria das empresas.
Esse desafio é ainda maior quando as empresas possuem diversos canais de interação com seus clientes. Por exemplo, bancos e redes de varejo se relacionam com seus clientes nas lojas físicas ou agências, nos caixas automáticos, pela web e celular, no e-commerce (ou online banking), etc. As preferências de atendimento do cliente são prejudicadas pela difidculdade de compartilhar a informação sobre as preferências entre os vários canais.
Por exemplo, se o cliente de um banco configurar seu ‘mobile banking’ para priorizar na tela as transações que ele usa mais frequentemente, é incomum encontrar o uso dessa informação nos caixas automáticos do mesmo banco. Concretizar esse atendimento “omni-canal” exige compartilhar informação que não pertence nem aos sistemas específicos dos canais de atendimento, nem ao sistema de missão crítica do banco.
Dificuldades semelhantes surgem na implantação da internet das coisas. Como exemplo, consideremos uma “cidade inteligente”, coberta a distâncias regulares por sensores de chuva, que repassam (para uma central) informação sobre o volume de chuva que cai.
Essa informação sobre o volume de chuva pode ser exibida no site ou num app da prefeitura para que os cidadãos observem onde chove mais; a mesma informação pode ser repassada ao servidor do Waze para que envie menos motoristas nas vias onde a chuva é mais intensa, e ainda pode ser usada pelo sistema de telemetria dos ônibus urbanos, para que estes reduzam a velocidade drasticamente quando adentrarem áreas de chuva intensa (diminuindo assim a probabilidade de acidentes).
Observamos que a velocidade adequada de atualização das informações sobre a chuva é diferente para cada uso: garantir o encaminhamento adequado destas informações no ritmo correto a cada um de seus usos é o desafio a ser vencido pelo software.
Nós analisamos os exemplos citados na seção anterior, e muitos outros (para os quais o espaço aqui é insuficiente). A mais importante conclusão foi que todas essas novas aplicações possuem novos requisitos que são comuns a maioria delas: dito de outra forma, os requisitos são muito mais consequencia do ambiente de nuvem e IoT do que necessidades específicas da aplicação.
Os principais requisitos que identificamos, incluem os seguintes aspectos:
A partir da consolidação desta lista, passamos a avaliar como seria possível reduzir o custo de desenvolvimento das novas aplicações, por meio de alguma ferramenta de software que fornecesse esses requisitos ‘as a Service’. Porém, diante do fato de que as ferramentas existentes cobriam apenas uma pequena parte da nossa lista, mergulhamos num processo criativo (iniciado em 2014).
Durante o design de uma nova ferramenta, ainda nos vimos diante da oportunidade de inovar também no conceito de ‘transações’, conceito amplamente difundido a partir da adoção dos sistemas de gestão de banco de dados relacionais no começo dos anos 80.
Transações são definidas como um “conjunto de operações que só faz sentido se todas (ou nenhuma) delas forem executadas com sucesso”. O software avisa ao servidor quando inicia uma transação, e posteriormente confirma que o conjunto todo de operações foi bem sucedido (chamado de ‘commit’ na gíria da TI) ou, no caso de erro em alguma das operações do conjunto, solicita ao servidor que ignore as operações anteriores que já foram executadas como parte da transação (fato conhecido como ‘rollback’).
Inicialmente, os programas e o gerenciador de bancos de dados funcionavam dentro do mesmo computador. Posteriormente, na era cliente-servidor, eles passaram a operar em equipamentos separados, porém na mesma rede local.
Como no ‘mundo da nuvem’, porém, a comunicação entre o programa e o servidor não é confiável, e o programa pode ser desligado (quando a bateria do equipamento acaba) no meio de uma transação: nestes casos, as transações iniciadas e que não foram objeto nem de ‘commit’ nem de ‘rollback’ ficam pendentes e ocupando recursos do servidor indefinidamente (por isso, alguns gestores desses servidores optam por reiniciá-los a cada noite).
Entretanto, consideramos que seria muito mais adequado modificar a negociação ao redor das transações de maneira que apenas o ‘Commit’ seja comunicado no caso de uma execução bem-sucedida. Para conseguir isto, basta especificar (quando se marca o início da transação) o tempo máximo de execução da transação.
Assim, se o servidor não receber o ‘Commit’ no tempo máximo previsto, ele pode executar o ‘Rollback’ automaticamente (liberando seus recursos internos). De quebra, ainda viabilizamos a construção de transações envolvendo operações individuais executadas em servidores back-end diferentes.
Todo o desenvolvimento de uma ferramenta com essas características se deu sob sigilo, condição necessária para viabilizar um processo de patente nos Estados Unidos (no Brasil isso não é possível, mas isso é tema para outro artigo).
O primeiro passo formal, consistente no depósito de um pedido provisório de patente, foi protocolado no United States Patent and Trade Office em 5 de abril de 2016, eliminando a partir de então a exigência de sigilo.
A documentação detalhada da ferramenta pode ser consultada em http://www.versacloud.technology.
*Roberto C. Mayer é fundador e CEO da MBI (www.mbi.com.br), diretor de comunicação da Assespro Nacional e vice-presidente da ALETI.
Desenvolvido por: Leonardo Nascimento & Giuliano Saito