O contexto é rei

Coisas de consumo. Coisas de negócios. Fabricando Coisas.

Telefones. Comprimidos. Tablets. Laptops. Desktops.

Computação intensa. Intenso em rede. Armazenamento intenso.

Lar. Trabalhar. Restaurante. Carro. Parque. Hotel.

O cenário está mudando em ambos os lados do negócio: aplicativos e clientes. O termo “usuário” não significa mais apenas um ser humano. Inclui também sistemas e coisas que são acionadas automaticamente para conectar, compartilhar e interagir com aplicativos no data center.

Considere, por exemplo, a tendência arquitetônica emergente de microsserviços, que divide aplicativos monolíticos em suas partes compostas. Cada parte é seu próprio serviço e apresenta uma API (interface) por meio da qual outras partes (serviços) e ‘usuários’ podem se comunicar.

Não é um dos 36% que se interessa por microsserviços? ( Typesafe, 2015 ) Manter arquiteturas de aplicativos bem compreendidas não o protegerá do impacto da crescente diversidade de "usuários", especialmente se você estiver mergulhando na Internet das Coisas. Nossos dados mostram que alguns de vocês estão, com 22% de todos os entrevistados acreditando que isso será de importância estratégica pelos próximos 2 a 5 anos e 15% começando a planejar a compra de tecnologia para dar suporte à IoT nos próximos 12 meses.

Isso significa que as “coisas” terão que ser vistas como “usuários”, tendo seu próprio conjunto único de necessidades e requisitos com relação à segurança e desempenho, sem mencionar a disponibilidade. 

Isso significa que os serviços de rede e aplicativos encarregados de fornecer um conjunto cada vez mais diversificado de aplicativos para um conjunto crescente de clientes em ainda mais locais precisam ser capazes de diferenciar entre um usuário humano e um usuário de coisa. Para otimizar o desempenho e garantir a segurança, é fundamental que os serviços responsáveis pelo desempenho e pela segurança sejam capazes de aplicar a política certa na hora certa, considerando o conjunto certo de variáveis.

Isso significa que eles precisam gerenciar o tráfego (dados e comunicações, em termos de aplicativo) dentro do contexto de toda a transação: o usuário, o aplicativo e a finalidade para a qual tal comunicação está sendo tentada.

Você pode pensar no contexto da mesma forma que lhe foi ensinado (se você tiver idade suficiente, e não, você não precisa admitir se preferir) sobre os cinco "Ws" que você precisa perguntar quando estiver coletando informações básicas: quem, o quê, onde, quando e por quê. Ao questionar o tráfego e extrair uma resposta para cada uma dessas perguntas, você pode reunir contexto suficiente para poder tomar uma decisão apropriada sobre como tratar a troca. Negue isso. Permita. Escaneie-o. Esfregue. Otimize-o. Roteie-o. Esses são os tipos de coisas que os serviços de aplicativos fazem “na rede” e eles fazem isso melhor e com maior efeito se o fizerem dentro do contexto da troca.

• Quem
  Identifica o usuário. É um ser humano? Se sim, corporativo ou consumidor? É uma coisa ou outro aplicativo? Se sim, qual coisa e qual aplicativo? Embora minha lâmpada inteligente possa ter acesso a um aplicativo de relatórios de dados, ela não tem acesso aos sistemas de contabilidade.
• O que
  O que eles estão fazendo? Enviando dados? Solicitando dados? Procurando? O HTTP contém uma grande quantidade de dados que podem ajudar a determinar isso sem precisar investigar muito profundamente. É um HTTP POST ou um GET? Uma ATUALIZAÇÃO ou EXCLUSÃO? Só o status pode nos dar pistas sobre o propósito dessa troca.
• Onde
  De onde eles estão fazendo isso? Eles estão em casa? Na sede? Do outro lado da rua, no Starbucks, ou do outro lado do mundo? Em uma rede local ou pela Internet? A geolocalização é um meio popular de restringir o acesso a aplicativos, recursos e dados. Ao entregar aplicativos aos usuários, independentemente do tipo, a localização é importante, principalmente se houver políticas corporativas contra o acesso a certos tipos de dados ou aplicativos de locais públicos, como o aeroporto ou o Starbucks local.
• Quando
  Que horas são? E o mais importante, que horas são aqui e onde o usuário está localizado? Eles estão tentando acessar um sistema às 3 da manhã de um local onde são 8 da manhã? Por exemplo, sabemos por pesquisas que o tráfego de bots aumenta significativamente após o expediente, entre 18h e 21h. E poderíamos juntar esses dados com “quem” e ser capazes de determinar instantaneamente que Alice deveria estar trabalhando às 3 da manhã quando ela trabalha na sede corporativa.
• Por que
  Por que é como se a camada 8 não existisse. Ele só pode ser inferido a partir de quê, e requer que você consiga juntar pistas a partir de dados que, de outra forma, seriam bastante básicos, como o URI (assumindo que seja baseado em HTTP, o que, atualmente, é uma suposição razoável). Depois que sabemos o que eles estão fazendo, como enviar dados, podemos querer saber por que eles estão enviando. É uma atualização de perfil ou eles estão enviando dados do sensor? Eles estão fazendo uma pesquisa ou enviando um pedido?

É isso que compõe o contexto. Não é necessariamente o caso de você precisar coletar todos os cinco (afinal, isso não é Pokémon) para poder tomar uma decisão sobre qual ação tomar. Mas você precisa ter visibilidade (acesso) a todos os cinco, caso precise. É por isso que a visibilidade de toda a pilha de rede – das camadas 2 a 7 – é tão importante para os serviços de aplicativos. Porque cada um pode precisar avaliar uma solicitação ou resposta dentro do contexto em que foi feita, e somente tendo visibilidade de toda a pilha é que você pode acessar e obter essas informações quando necessário.

Essa é uma das coisas que um proxy inteligente traz para a mesa; a visibilidade necessária para garantir que arquitetos (e engenheiros) de rede, segurança e infraestrutura possam implementar políticas que exijam contexto para garantir a segurança, velocidade e confiabilidade que cada usuário — não importa se humano, sensor ou software — precisa.