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, 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ã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 do ambiente de
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.
0 comentários: