Por Roberto C. Mayer*
A disseminação da computação em nuvem e da Internet das Coisas (IoT) 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 têm 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, a computação na 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ãos de características como segurança, escalabilidade e audibilidade 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.
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 dificuldade 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 de internet das coisas. Como exemplo, consideramos 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 aplicativo 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).
Sobre os exemplos citados, a mais importante conclusão foi que todas essas novas aplicações possuem novos requisitos que são comuns à maioria delas: dito de outra forma, os requisitos são muito mais consequência da computação na nuvem e IoT do que necessidades específicas da aplicação.
Transações Limitadas no Tempo
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.
*Roberto C. Mayer é membro do Conselho de Ética da Assespro – SP; diretor de Comunicação da Assespro Nacional; fundador e CEO da MBI e vice-presidente da ALETI.