A ciência da computação e AWS como abstração

Por Francisco Javier Baños Lemoine, Arquiteto de Soluções, AWS México

Sempre me perguntei como sites como amazon.com, linkedin.com ou google.com fazem para implementar a funcionalidade de preenchimento automático na busca de produtos, empresas ou o assunto de interesse em questão. Aplicar uma dose de ciência da computação para implementar o autocomplete nos coloca em contato com a estrutura de dados Trie (árvores de prefixos). Por exemplo, para procurar o nome de um país com preenchimento automático, um primeiro nível do Trie é o seguinte:

Abaixo de cada nó virá todas as letras de país começando com a letra correspondente: “A” para “Alemanha”, “Áustria”, “Austrália”, etc. “B” para ‘Bolívia’, ‘Bósnia’, ‘Burundi’, etc. Ao desenvolver os nós seguintes a letra ‘A’ terá uma estrutura semelhante a figura abaixo:

No nó ‘l’ abaixo ‘A’ você pode desenvolver nomes de países como ‘Alemanha’ e ‘Albânia’ e sob o nó’ z ‘viria o nome ‘Azerbaijão’. Os nomes de país “Áustria” e “Austrália” mostram as vantagens de uma estrutura de dados como Trie: à medida que as letras da palavra que procura chegam, você percorre a rota marcada pelos nós. Por exemplo, com os caracteres A ‘,’ u ‘,’ s’, ‘t’ e ‘r’ você executa o mesmo caminho para o nó ‘r’. Se o próximo caractere for um ‘i’, será direcionado para o nó esquerdo e se for um caractere ‘a’ é feito em direção ao nó direito. Para fins ilustrativos, uma implementação simples de um Trie foi feita em Java que pode ser visualizada neste repositório do GitHub. Um exemplo de sua execução é mostrado abaixo:

Prefixo (insira um ponto para terminar): Aust

Sugestões de preenchimento automático

        (Aust) ralia

        (Aust) ria

Prefixo (insira um ponto para terminar): Ale

Sugestões de preenchimento automático

        (Ale) mania

Fragmento (para terminar, insira um ponto): Ru

Sugestões de preenchimento automático

        (Ru) sia

        (Ru) mania

Fragmento (para terminar, insira um ponto): Z

Sugestões de preenchimento automático

        (Z) ar

        (Z) imbabwe

Fragmento (para terminar, insira um ponto):.

A complexidade do tempo de procurar uma palavra em um Trie é O.(k) onde k representa o comprimento da palavra. É linear! E claro que processamos todo o texto disponível na internet então estruturar e manter um Trie exige muito mais do que um processo e memória que temos disponível. O objetivo do exemplo é destacar a importância de escolher a estrutura de dados correta ou algoritmo para o problema em questão.

AWS como uma abstração

Na maioria das vezes, se não sempre, eu me vejo usando abstrações. Por exemplo, se eu tiver que escrever um programa que lê um arquivo em disco, vou usar uma função como open() em Python ou fopen() em C que são abstrações que reduzem o esforço de interagir diretamente com o Sistema de Arquivos. Outra abstração, read(), que me permite ler o arquivo sem ter que lidar com tarefas de baixo nível como ‘ler’ os setores do disco onde os dados são distribuídos; a abstração read(), me dá a ilusão de que eles são adjacentes, então tudo que eu preciso é aprender a usá-lo.

Do meu ponto de vista, a AWS fornece um conjunto de abstrações. Por exemplo, se um aplicativo precisar de funcionalidade de autocomplete, considere a quantidade de memória que um Trie exige. Um cluster de memória geralmente está presente nesses casos. Além disso, a programação deve ser adaptada para trabalhar com memória de cluster em vez do processo associado. As tarefas acima são as tarefas que uma equipe de TI, se decidir implementá-lo por conta própria, teria que executar. No entanto, é aqui que vem a proposta de valor da AWS: uma oferta como o Amazon CloudSearch torna a implantação mais conveniente, pelo menos eu, faria.

Por trás dos serviços da AWS, há ciência da computação aplicada. O Amazon CloudSearch é uma abstração do Trie. Devido à melhor experiência do usuário que ele oferece, a funcionalidade de preenchimento automático é uma demanda constante em soluções que são desenvolvidas hoje em dia. Um serviço como o Amazon CloudSearch permite prover tal funcionalidade a uma fração dos recursos que seriam necessários para uma empresa implantar em seu data center.

Este é o caso das diversas necessidades de processamento de informações em que os CXOs e a equipe de arquitetura em cada empresa tem que resolver, o dilema Buy vs. Build. Como a ideia de implementar um cluster de memória, a instalação e o gerenciamento de tecnologias de base de Big Data (Hadoop, HBase, Spark, etc.) encontram uma resolução melhor para comprar ( Buy ), literalmente e metaforicamente, uma abstração como Amazon Elastic Map Reduce (EMR).

A decisão é mais importante do que “o quê”, à primeira vista, parece. A tecnologia da informação é um meio para alcançar um fim: as soluções de negócios que os usuários internos ou externos exigem de uma empresa. Por exemplo, para decidir sobre um investimento, um tesoureiro precisa consultar determinados PKIs em um painel, e pouco importa se para isso é necessário um cluster de Hadoop, ainda menos se ele reside no data center corporativo ou na AWS. É responsabilidade do CIO, do CTO e TI fornecer a melhor solução possível, mantendo baixos custos e alta segurança e disponibilidade.

Visão geral

Neste artigo lembrei que a ciência da computação consiste em algoritmos e estruturas de dados. Um exemplo é o Trie para a funcionalidade de autocomplete e outro é MapReduce para processamento de Big Data. Implementá-los em escala corporativa tem o potencial de exigir um investimento considerável de recursos (ao longo do tempo, com o que é mais valioso). A tecnologia é um meio para alcançar um fim, que são as soluções de negócios que os clientes e usuários exigem. Portanto, a decisão de implantá-lo por conta própria (Build) ou contratá-lo como um serviço na AWS (Buy) será a marca registrada entre uma empresa lenta e uma empresa ágil.

Este artigo foi traduzido do Blog da AWS em Espanhol

Sobre o autor

Francisco Javier Baños Lemoine é Arquiteto de Soluções de AWS México.