Integração de Borda de Aplicação: Um Estudo em Evolução
Voo: Evolução convergente na prática
A maioria de nós já sonhou em poder voar; e, como se vê, a evolução também sonhou. A capacidade de voar — seja para fugir de predadores, procurar comida com mais eficiência ou migrar longas distâncias — tem sido repetidamente demonstrada como sendo de grande utilidade para uma grande variedade de animais. Tanto e tão frequentemente, de fato, que a evolução continua tentando encontrar algum caminho para atingir o objetivo de voar. Hoje, vemos três grupos distintos de animais que desenvolveram independentemente a capacidade de voar: insetos, pássaros e mamíferos (morcegos). Cada um desses três grupos seguiu diferentes caminhos evolutivos que levaram ao voo, com a forma atual de voo refletindo suas formas ancestrais pré-voo. Considere os insetos: os insetos ancestrais tinham exoesqueletos externos, que têm a propriedade de serem de baixa densidade e laminados, resultando em diferentes resistências à tração em diferentes dimensões. Como consequência, a evolução dos insetos em direção ao voo alavancou o uso de asas deformáveis — uma abordagem que aproveitou a baixa densidade e a resistência à tração variável disponíveis. As aves, por outro lado, tiveram o desenvolvimento das penas como a "tecnologia" crucial em sua jornada rumo ao voo; neste caso, as penas foram uma feliz coincidência, motivada pelas necessidades de um conjunto de dinossauros de sangue quente que necessitavam de um material semelhante a pelos para reter calor. Foi só mais tarde que as penas se revelaram uma "tecnologia" fortuita para permitir o voo. Por fim, os morcegos, sendo o grupo mais recente a desenvolver o voo, usam uma abordagem baseada na evolução incremental de mamíferos planadores, mas ainda não têm o benefício de eras de adaptação evolutiva.
Um complemento interessante e digno de nota para essa história é a observação de que, quando os humanos finalmente alcançaram o voo prático, usando máquinas, eles aplicaram um conjunto de abordagens completamente diferentes — mais leves que o transporte aéreo ou aerofólios de movimento rápido impulsionados por motores movidos a gasolina.
Isso foi interessante, mas o que isso tem a ver com a vantagem?
De uma perspectiva de pensamento evolucionário, os caminhos que a entrega de aplicativos tomou nos últimos 20 anos também são uma história de evolução convergente. Mais especificamente, esses anos testemunharam o desenvolvimento de múltiplas tecnologias de entrega que, quando vistas em retrospectiva, foram todas aquelas etapas evolutivas iniciais e nascentes em direção ao que está se tornando a ponta do aplicativo.
O precursor de muitas dessas tecnologias ancestrais foram as Redes de Distribuição de Conteúdo (CDNs). Essa tecnologia foi motivada — seu "nicho evolutivo", por assim dizer — pela necessidade de fornecer uma grande quantidade de dados relativamente estáticos, geralmente imagens grandes e streaming de áudio/vídeo, para uma comunidade considerável de clientes consumidores. A solução foi colocar cópias em cache dos grandes arquivos de dados em vários locais geograficamente dispersos, mais próximos dos dispositivos clientes. Essa abordagem permitiu que a carga de trabalho de entrega fosse distribuída para longe de um único data center central, em termos de computação e largura de banda, ao mesmo tempo em que fornecia latência menor e mais previsível.
Hoje, à medida que os aplicativos avançam e se tornam fortemente integrados às nossas rotinas diárias, a necessidade de melhorar a experiência do cliente com os aplicativos continua a gerar a necessidade de reduzir a latência e fornecer largura de banda adicional. No entanto, as regras básicas mudaram e evoluíram. Assim como o clima e a geografia impulsionam continuamente a adaptação na natureza, as mudanças nos requisitos de entrega de aplicativos impulsionam mudanças nas soluções necessárias. As necessidades de entrega de aplicativos mais modernos vão muito além do cenário básico de CDN. Os casos de uso mais sofisticados de hoje exigem mais do que entregar apenas conteúdo estático simples; eles também têm requisitos nas áreas de computação e interatividade. Exemplos de aplicações com necessidades mais avançadas são videoconferência e negociação eletrônica. De forma mais ampla, a tendência geral em direção ao paradigma de Aplicativo de Página Única (SPA), no qual um aplicativo é composto pela agregação de vários serviços web distintos, requer um conjunto mais robusto de recursos distribuídos do que mero armazenamento estático para manter uma experiência rica para o usuário. À medida que o ambiente "evoluiu" em direção a esses novos casos de uso, vemos a convergência correspondente de diversas soluções de mercado existentes se adaptando para melhor se adequar a esse novo e lucrativo "nicho evolutivo" — o análogo tecnológico do conceito de "evolução convergente".
A primeira dessas soluções pré-existentes são as CDNs mencionadas anteriormente. A "força" de sua incumbência evolutiva é sua infraestrutura substancial existente de um grande número de nós CDNs existentes; seu caminho "evolutivo" é aprimorar os nós existentes, deixando de se concentrar apenas no armazenamento do tipo cache para fornecer uma combinação mais equilibrada de múltiplas tecnologias de armazenamento — arquivos, bancos de dados, armazenamentos de objetos — juntamente com recursos de computação que podem operar nesse armazenamento.
A segunda solução de mercado estabelecida são os provedores de nuvem pública. Sua área de "força" é o ecossistema robusto de recursos de computação, armazenamento e largura de banda, bem como os modelos de consumo flexíveis correspondentes para esses recursos. Por exemplo, a AWS oferece diversas formas de tecnologia de banco de dados, disponibiliza computação usando um modelo baseado em servidor ou sem servidor, tem um rico conjunto de tecnologias para lidar com identidades e autenticação e fornece um conjunto diversificado de serviços auxiliares, como registro/relatórios, visualização, modelagem de dados e assim por diante. No entanto, sua "lacuna evolutiva" é que eles não têm tantos pontos de presença quanto os fornecedores de CDN existentes, então eles não desfrutam da mesma amplitude de distribuição.
No outro extremo da escala de pontos de presença estão os Provedores de Serviços Móveis (MSPs), especialmente à medida que eles implementam suas infraestruturas 5G. Os grandes MSPs planejam ter dezenas de milhares de pontos de acesso móveis, cada um dos quais é um ponto de entrada na rede principal. Além da “força” de distribuição e escala, eles têm capacidade computacional e alguma capacidade de armazenamento limitada nesses pontos de acesso; no entanto, a computação e o armazenamento, até recentemente, eram limitados em escopo para focar nas próprias necessidades de infraestrutura dos MSPs. Portanto, a "lacuna" que eles precisam abordar é migrar para um paradigma de computação que exponha a infraestrutura de computação a aplicativos externos e ampliá-la com recursos de armazenamento adicionais.
Retornando ao voo — e por que os humanos usaram uma abordagem diferente
A jornada apenas delineou mapas como um processo evolutivo incremental natural. No entanto, por vezes, ocorrem “fatores de mudança [1]” evolucionários — algo que perturba a evolução e provoca uma reavaliação da progressão linear. Para os humanos que estão desenvolvendo o voo, o desenvolvimento de sistemas que podem fornecer rapidamente uma grande quantidade de energia (por exemplo, motores movidos a gasolina), juntamente com materiais e tecnologias de engenharia que podem fabricar ligas leves e fortes, permitiu que nós, humanos, reimaginássemos como o desafio do voo poderia ser enfrentado, "mudando o jogo" em relação à forma como a natureza desenvolveu o voo.
Relacionando essa história de volta ao conceito de ponta, a narrativa de entrega de aplicativos até agora se concentrou em descarregar o trabalho do lado do "servidor", ou seja, a parte da cadeia de entrega que começa com o servidor recebendo uma solicitação. Especificamente, devido à "predisposição evolutiva" das soluções preexistentes (uma em que o valor era aliviar a carga do servidor de aplicativos), o foco tem sido implicitamente no descarregamento e distribuição da computação e entrega de conteúdo que é em resposta à solicitação de um cliente.
No entanto, considere agora o que acontece quando pensamos nesses pontos de presença geograficamente dispersos não apenas como nós de computação e caches para aliviar o servidor — "proxies de aplicativo" — mas também como pontos de controle que prestam igual atenção às solicitações de clientes recebidas, mapeando essas solicitações em nós de infraestrutura e computação/cache apropriados para os requisitos do aplicativo. Por exemplo, um aplicativo tolerante à latência, mas com alta largura de banda, como backup de arquivos na nuvem, pode ser roteado de forma diferente de um aplicativo sensível à latência e com baixa largura de banda, como jogos online. Os aplicativos bancários que precisam de uma central de compensação de dados podem ser direcionados para um data center central. Esse conceito, que considero um "orquestrador de aplicativos", surge naturalmente quando você pensa na borda não como algo que apenas descarrega o servidor, mas como um elemento cuja função é ser a rampa de acesso ao ambiente generalizado de servidor/nó de acesso.
Vamos construir um avião, não um ornitóptero
Assim como os humanos finalmente alcançaram o voo prático não pelo uso de uma abordagem mecanizada semelhante à dos pássaros (o famoso "Ornithopter" de da Vinci), mas pensando em como aproveitar melhor as tecnologias mais apropriadas disponíveis — aerofólios acoplados a motores movidos a gasolina —, deveríamos pensar em como a infraestrutura de aplicativos pode ser reinventada com o advento de uma vantagem generalizada, distribuída e rica em serviços. À medida que o poder dessa capacidade emergente se torna mais aparente e mais consumível, os proprietários e operadores de aplicativos começarão a próxima etapa na jornada de evolução dos aplicativos. O evento resultante de "mudança de jogo" — a evolução disruptiva da borda de ser apenas um proxy para o servidor de aplicativos ou um cache de aplicativos com esteroides, para ser um orquestrador de aplicativos completo — abrirá o ecossistema de aplicativos para uma explosão de novas possibilidades, que serão o assunto de artigos futuros.
Prevendo esse caminho à frente, pretendo compartilhar uma visão de como abraçar o papel de orquestrador de aplicativos da borda permitirá uma especificação mais declarativa e orientada por intenção do comportamento pretendido de cada aplicativo, impulsionando otimizações tanto da infraestrutura do aplicativo quanto da experiência do cliente com o aplicativo. Por exemplo, um aplicativo, talvez um que enfatize a tecnologia de realidade aumentada, pode especificar uma política que priorize latência e largura de banda, enquanto um aplicativo financeiro pode priorizar confiabilidade ou centralização, e ainda algum outro aplicativo de IoT para o consumidor pode se concentrar no gerenciamento de OpEx. De forma mais ampla, adotar uma mentalidade que expanda o papel da borda e a aproveite como orquestradora de aplicativos também posiciona a borda como o local lógico para implementar políticas de segurança e visibilidade, realizando outro sonho de muitos proprietários de aplicativos: a meta de controles de aplicativos independentes de infraestrutura.
[1] O desenvolvimento do metabolismo baseado em oxigênio é um bom exemplo, mas terei que guardar essa história para outra ocasião.