A definição de edge sempre esteve interligada à evolução da arquitetura do data center. A última década testemunhou uma rápida transformação na arquitetura de infraestrutura empresarial, expandindo de data centers locais para as arquiteturas de nuvem distribuídas de hoje. Reconhecemos o Edge 2.0 como uma mudança tecnológica que permitirá que os aplicativos aproveitem uma arquitetura de nuvem distribuída.
Cada pessoa, organização ou entidade tem uma interpretação diferente da vantagem. Alguns podem considerar a borda como uma torre de celular, outros podem dizer que seu dispositivo móvel é a borda. Para provedores de serviços de nuvem (CSPs), a borda é uma infraestrutura gerenciada que se integra perfeitamente ao seu back-end. Para aplicações militares, a borda é o teatro de batalha, seja em terra, no mar ou no ar. Toda vez que lemos sobre a borda, a interpretação geralmente é resumida como capacidades de computação, rede e armazenamento da infraestrutura e/ou sua localização.
Mas também vemos o Edge 2.0 como a experiência que ele entrega a todas as partes interessadas no ecossistema, e não apenas o ativo da infraestrutura ou seu local.
Este documento descreve qual deve ser a funcionalidade do Edge 2.0, independentemente de sua infraestrutura física ou virtual, ou de onde ele está localizado ou instanciado. A intenção não é explicar como criar um aplicativo distribuído melhor, mas sim esclarecer os recursos que devem estar no Edge 2.0 para dar suporte à criação dos aplicativos distribuídos mais adequados a um requisito específico.
Do ponto de vista de uma entidade que reside nessa nuvem distribuída, a borda é onde quer que a entidade esteja localizada atualmente. Assim, propomos uma definição de Edge 2.0 centrada na experiência, não vinculada apenas à localização da infraestrutura, ao tipo de infraestrutura ou à entidade controladora.
O foco do Edge 2.0 é aprimorar as experiências centradas em aplicativos, operações e desenvolvedores. O Edge 2.0 deve abordar as metapropriedades (como SLAs e SLOs) do aplicativo, adaptando-se às necessidades variáveis do aplicativo. O Edge 2.0 deve ser simples de operar e aliviar as equipes de operações da necessidade de criar novas automações para cada aplicativo distribuído. O Edge 2.0 deve reduzir o atrito enfrentado pelos desenvolvedores ao desenvolver e implantar aplicativos distribuídos em escala, oferecendo suporte contínuo aos objetivos de segurança, governança e nível de serviço.
Como exemplo, vamos pegar um aplicativo bancário. O objetivo do Edge 2.0 não é melhorar a lógica comercial da transação. O objetivo é torná-lo mais seguro, rápido, privado, utilizável em todas as regiões (conforme necessário) e escalável para cima ou para baixo, conforme necessário, para dar suporte aos objetivos comerciais.
A seguir, estão os principais conceitos e declarações desse white paper:
Há diversos tópicos que ainda não foram abordados nesse white paper:
A Figura 1 descreve melhor a coevolução das arquiteturas Edge e de datacenter. O Edge 1.0 e 1.5 foram baseados na noção de um site de origem e na movimentação de dados e serviços da origem para o consumidor. O Edge 1.0 foi uma implantação de infraestrutura de internet focada principalmente na otimização do uso de largura de banda com cache de conteúdo distribuído, também conhecido como redes de distribuição de conteúdo. CDNs são um padrão de design fundamental, pois o conteúdo agregado a ser transferido sempre será maior que a largura de banda disponível.
À medida que os custos de CPU e memória diminuíam, as fazendas de computação surgiram junto com os nós CDN. Os aplicativos eram consumidos como serviços por meio de arquiteturas orientadas a serviços (SOA). Daí a referência ao Edge 1.5 como Rede de Distribuição de Serviços.
Uma característica comum do Edge 1.0 e do Edge 1.5 é a ideia de um site de origem. Antes do crescimento dos dispositivos móveis, pessoas, dispositivos e coisas estavam basicamente baixando conteúdo ou agindo como consumidores do serviço. O site que originou o serviço ainda era diferente daquele do consumidor.
No Edge 2.0, no entanto, qualquer entidade pode atuar como um site de origem ou como um consumidor. O fluxo do tráfego mudou. Humanos, telefones e dispositivos estão produzindo dados ativamente à medida que carregam conteúdo ou geram dados periódicos. Os aplicativos estão se tornando consumidores à medida que dependem de outros aplicativos. Todas as entidades podem atuar como produtoras ou consumidoras de um serviço: APIs, humanos, dispositivos IoT ou aplicativos web, back-end e headless. Do seu próprio ponto de vista, cada entidade na infraestrutura pensa que está no limite.
A nuvem distribuída é o estágio mais recente na evolução do datacenter. A computação se tornou verdadeiramente onipresente, desde dispositivos móveis até a incorporação em objetos cotidianos conectados à rede. Coevoluíram com ele arquiteturas de software para permitir aplicativos distribuídos e escaláveis.
A abundância e a hiperdistribuição de computação e armazenamento em todos os lugares criaram uma oportunidade para uma rápida transformação digital da empresa. Mas essa rápida evolução tem suas consequências.
A maioria das empresas é normalmente composta por infraestrutura heterogênea, com ambientes não uniformes. O dimensionamento eficaz desses ambientes exige orquestração e automação complexas dos sistemas implantados. Mudanças rápidas nas necessidades do aplicativo, como mudanças nos requisitos de CPU e largura de banda, aumentam a complexidade das operações em uma nuvem distribuída. Isso aumenta o estresse das equipes de operações, que podem não estar bem equipadas para responder com eficiência às necessidades em constante mudança do aplicativo ou do cliente final.
As consequências desses problemas são a complexidade operacional, que neutraliza qualquer possível ganho para uma empresa que esteja passando por uma transformação digital.
Alguns dos problemas e artefatos interligados resultantes da complexidade são destacados a seguir.
Nuvens híbridas resultam em maior área de superfície que pode ser comprometida devido a uma variedade de vetores de ataque. Diferentes casos de uso criam múltiplos desafios de segurança e, à medida que a infraestrutura evolui, estamos constantemente perseguindo o disco. Portanto, o problema que antecipamos é: apenas as recomendações tecnológicas mudarão com frequência ou os padrões de design para implementar a segurança também mudarão?
Estes são alguns dos problemas com as abordagens existentes:
Um dos principais desafios com a hiperdistribuição de computação de baixo custo e baixo consumo de energia disponível na borda é a capacidade de orquestrar e programar a infraestrutura de maneira uniforme. As equipes de operações têm dificuldades para dimensionar e dar suporte a aplicativos que aproveitam a nuvem distribuída, pois esses aplicativos normalmente incluem tecnologias heterogêneas com diferentes requisitos de administração.
Embora plataformas de automação como o Terraform forneçam um meio sofisticado para personalizar a automação, as equipes de operações ainda precisam manter scripts para múltiplas permutações: por exemplo, cinco tipos diferentes de computação, quatro tipos diferentes de firewalls e três tipos de balanceadores de carga. O custo humano de ter que gerenciar e manter os scripts de automação não é escalável.
Isso leva à interação contínua do cliente de infraestrutura com as equipes de operações por meio de sistemas baseados em tickets, o que é uma barreira para automatizar os fluxos de trabalho existentes. O service desk fica sobrecarregado com tickets, precisando priorizar a segurança e a estabilidade em detrimento da agilidade.
Arquiteturas de microsserviços já se tornaram o método de fato para criar novos aplicativos com a evolução para multinuvem. As APIs são publicadas e podem ser instanciadas sempre que e onde for necessário, o que leva à proliferação de APIs. A descoberta, conectividade e gerenciamento dessas APIs de forma autônoma se torna um grande desafio.
É necessária uma mudança de paradigma para lidar com a proliferação de APIs. Nossos modelos internos demonstram que mesmo suposições moderadas de parâmetros, como o número de desenvolvedores globais de APIs, o número de APIs desenvolvidas por desenvolvedor por ano e a vida útil das APIs, resultam em centenas de milhões (se não bilhões) de APIs ativas simultaneamente até 2030 (Figura 2). O relatório API Sprawl de 2021 fornece uma visão abrangente deste tópico emergente.
O aumento da complexidade exige que as empresas permitam uma visibilidade granular e significativa de ponta a ponta do sistema. Em ambientes de nuvem distribuída, os aplicativos transcendem diversas pilhas de infraestrutura heterogêneas gerenciadas por entidades separadas.
Além disso, nenhuma das operadoras hoje é incentivada a expor a telemetria nativa de sua infraestrutura para clientes empresariais. As empresas estão basicamente operando às cegas ao implantar aplicativos em uma nuvem distribuída e precisam recorrer a diversas ferramentas de observação. Para preencher essas lacunas de visibilidade, as ferramentas normalmente são de diferentes empresas fornecedoras, trabalhando em diferentes pontos da infraestrutura ou das pilhas de aplicativos.
Métricas de infraestrutura não padronizadas aumentam os problemas dentro de uma empresa. Normalmente, as métricas não são unificadas devido a silos operacionais e outros fatores, como infraestrutura não uniforme em diferentes ambientes de infraestrutura. Por exemplo, as métricas entre provedores de nuvem pública são diferentes, e as tecnologias de data center local também não seguem nenhuma métrica padrão.
Cargas de trabalho geradoras de receita e sistemas de missão crítica normalmente utilizam a maioria dos recursos operacionais e do orçamento disponíveis em uma empresa. Enquanto isso, projetos menores, embora de menor complexidade, tendem a compor o volume de aplicações da empresa. A Figura 3 descreve isso como uma distribuição de cauda longa do número de projetos que uma empresa provavelmente terá em comparação com sua complexidade operacional.
Embora aplicativos menores possam ter menor complexidade operacional, os processos de operacionalização e fluxos de trabalho ainda são, em muitos casos, manuais, e pode levar semanas para que os tíquetes de serviço transitem com sucesso por várias equipes operacionais. Por exemplo, a implantação de um aplicativo que requer recursos de rede dedicados com políticas de segurança granulares pode exigir primeiro que as equipes de segurança globais elaborem as aprovações da política de segurança. Em seguida, o tíquete de serviço pode ser enviado à equipe de rede para planejar as configurações de sub-rede e rota necessárias. Por fim, a validação das regras de firewall pode ser exigida de outra equipe operacional responsável pelo gerenciamento do firewall.
Agora vamos imaginar que a complexidade acima precisa ser abordada para cada aplicativo implantado em uma nuvem distribuída, onde a empresa não possui nenhuma parte da infraestrutura subjacente. O grande volume de pequenos projetos ou aplicativos que precisam ser integrados e suportados torna irrealista que as equipes de operações ofereçam suporte a todos os projetos, criando um problema de priorização e uma oportunidade de autoatendimento.
Esse problema de priorização é especialmente perceptível porque os investimentos das equipes de infraestrutura estão focados em dar suporte a sistemas críticos e geradores de receita, deixando pouco tempo ou orçamento para novos projetos líquidos que envolvem seu próprio ciclo de vida de desenvolvimento, teste e preparação antes da produção. Isso resulta em capacidades e investimentos reduzidos em velocidade de recursos, personalização e inovação que dão suporte a novos produtos, o que culmina na estagnação do negócio e de suas ofertas.
A evolução do ecossistema de borda expande significativamente o espaço da solução ao oferecer uma oportunidade de superar esses desafios com uma plataforma de aplicações.
A Figura 4 mostra o espaço da solução Edge 2.0. Aqui afirmamos que tudo o que está sob uma arquitetura de nuvem distribuída é a totalidade do espaço da solução.
Portanto, no contexto do espaço da solução, o Edge 2.0 deve fornecer a experiência desejada por todos os seguintes:
O Edge 2.0 será operacionalmente simples, seguro e em conformidade e entregará uma experiência de alta qualidade a todas as entidades do ecossistema que participam dele.
Uma nuvem distribuída amplifica esse problema de segurança em escala à medida que o número de endpoints aumenta exponencialmente. Com uma escala tão grande, a complexidade de implementar uma solução também aumenta. A postura de segurança deve ser que o aplicativo assuma que o ambiente em que está implantado já está comprometido. Da mesma forma, a infraestrutura não deve confiar em nenhum aplicativo executado nela.
A base dessas ideias é capturada nos conceitos da mentalidade Zero Trust, e o exemplar BeyondCorp1 demonstra esses conceitos para o caso de uso de acesso a aplicativos. No futuro, o Edge 2.0 estende esse modelo, com base nos cinco princípios básicos a seguir:
O Edge 2.0 deve integrar a telemetria como um cidadão de primeira classe dentro da pilha de infraestrutura, fornecer um meio simples e escalável para coletar telemetria entre camadas dentro da infraestrutura e exibi-la em uma plataforma comum. Isso ajuda as equipes de observabilidade a levantar questionamentos sobre o “estado da infraestrutura” conforme necessário. Isso permite que as equipes de aplicativos se concentrem na lógica de negócios sem instrumentar explicitamente suas pilhas de aplicativos.
O estado atual da tecnologia de observabilidade tem sido amplamente específico e proprietário do fornecedor. Isso levou muitos agentes específicos de fornecedores a coletar sinais semelhantes que disputam memória e CPU caras.
A próxima etapa lógica é o uso de um coletor de telemetria independente do fornecedor que permite que os dados da infraestrutura e do tráfego sejam transmitidos para uma plataforma de dados centralizada.
Muitas equipes de produtos têm dificuldade para justificar o investimento em instrumentação, pois o esforço precisa ser mapeado para uma oportunidade de receita. A infraestrutura deve ser instrumentada como qualquer outra função ou processo empresarial, porque a equipe precisa entender seu comportamento para otimizá-lo para os objetivos do negócio. Portanto, o debate deveria ser mais sobre o que deve ser priorizado para instrumentação, em vez de sua necessidade.
Para se obter medições granulares e mais precisas do comportamento da aplicação, antecipamos que a instrumentação realizará o shift left testing invocando-a no momento da codificação — Figura 5.
Em consonância com a nuvem distribuída, descascando algumas camadas, cada nuvem dentro de seu escopo (local ou global) tem seu próprio gerente, administrador, orquestrador e muito mais. Cada um se comporta de forma independente, tomando suas próprias decisões, mas fornecendo interfaces para outras entidades usarem conforme necessário.
Assim, a noção de nuvem distribuída, em essência, é administração e controle descentralizados. Não há como fugir desse fato, e é importante que o reconheçamos para compreender melhor as nuances das interfaces adaptativas, declarativas e imperativas.
Para utilizar de maneira eficiente a infraestrutura do Edge 2.0, as interfaces declarativas e imperativas não são suficientes, pois elas ainda dependem de artefatos criados manualmente que são essencialmente construções estáticas que não se adaptam rapidamente o suficiente às condições altamente voláteis.
Precisamos nos basear em resultados, e os sistemas precisam ser inteligentes o suficiente para ajustar políticas em toda a infraestrutura (de ponta a ponta) para atingir esses resultados. Nós chamamos essas interfaces de adaptativas.
Para deixar claro, interfaces imperativas, declarativas e adaptadas não são mutuamente exclusivas:
Imperativo: Torna-se muito prescritivo e define detalhadamente uma série de ações para chegar ao estado desejado. A configuração de um roteador, por exemplo, é uma ação imperativa. No cenário acima, as ações prescritivas serão precisas: qual datacenter, quanta CPU/memória, largura de banda necessária, rotas específicas e muito mais. A qualidade de entrada do modelo de dados é muito alta e, portanto, requer um conhecimento e experiência mais profundos sobre a infraestrutura. Há uma expectativa de conhecer tanto o modelo quanto a estrutura da infraestrutura.
Declarativo: A nuance da declaração é que ela se concentra em descrever o estado desejado, em oposição às ações que alcançam o estado desejado. A qualidade da entrada é menor, embora ainda exija que o aplicativo conheça pelo menos a estrutura da infraestrutura subjacente.
Adaptável: É diferente do imperativo ou declarativo. Uma interface adaptável se concentra no objetivo ou meta desejada, e não no estado. O objetivo da interface adaptável é capturar o objetivo do stakeholder que deseja implantar o aplicativo, em vez de focar em um pré-conhecimento do sistema subjacente. Adaptativo é diferente, pois não tem noção de quais são as capacidades da infraestrutura subjacente. Não há restrições sobre como “fazer o trabalho” e, portanto, ele se sustenta por si só.
Com o adaptativo, a qualidade da entrada é baixa e se aproxima da linguagem natural. Os proprietários de aplicativos podem enviar uma solicitação para informar ao controlador de infraestrutura qual resultado eles esperam, em vez de precisar declarar a capacidade necessária ou configurar especificamente um recurso.
Uma nuvem distribuída, por definição, acomoda todos os tipos de arquiteturas de aplicativos: monolíticas, microsserviços ou sem servidor. Independentemente da arquitetura, os aplicativos usam APIs para oferecer serviços.
Os problemas de descoberta de API, conectividade e segurança da rede são amplamente corrigidos ao usar uma malha de serviços, mas uma malha de serviços apenas resolve isso dentro do cluster (intracluster).
Por outro lado, os aplicativos Edge 2.0 aproveitam APIs em uma infraestrutura de nuvem hiperdistribuída, essencialmente um ambiente multicluster. Novos aplicativos são escritos com APIs que cruzam fronteiras organizacionais e geográficas. Algumas das APIs podem ser APIs privadas ou de parceiros por trás de várias camadas de firewalls sem uma rota explícita entre elas, mesmo que sejam detectáveis. Esse problema de cluster heterogêneo (intercluster) não tem uma solução elegante, leve, escalável e segura que seja prática.
Cenário/Propriedades | Imperativa | Declarativa | Adaptada |
---|---|---|---|
Definição | A interface imperativa define o fluxo de controle detalhado com base nas capacidades específicas do recurso em questão. |
A interface declarativa define a lógica, mas não o fluxo de controle. Em termos programáticos, é o pseudocódigo. |
A interface adaptada expressa o estado desejado como um requisito sem fazer qualquer suposição das capacidades dos recursos em questão. Uma interface adaptada é de propriedade da infraestrutura e permite que ela responda dinamicamente às diferentes necessidades da aplicação. |
Cenário 1: O pacote precisa ir de SFO para NYC |
Jane diz a Mark: (a) Imprima a etiqueta de envio, (b) Vá até a loja da UPS, (c) Escolha a entrega em 72 horas, (d) Pague e envie Marca: Tem que seguir um conjunto muito específico de etapas |
Jane pede a Mark: (a) por favor, envie esse pacote para esse endereço, (b) o pacote precisa chegar em menos de 72 horas. Marca: Você pode escolher qualquer empresa de entrega (UPS, FedEx, DHL etc.). |
Jane afirma para Mark: (a) Esse pacote deve estar em NYC até sábado. Marca: Pode fazer o que quiser. Talvez até mesmo pegar o pacote pessoalmente, voar para Nova York e entregá-lo pessoalmente. |
Cenário 2: Exemplo de balanceador de carga |
O balanceador de carga já existe. Tarefa: precisa ser configurada com esta política. Aqui, a tarefa é específica para a marca, modelo, versão, etc. do balanceador de carga. |
Não existe um balanceador de carga. Tarefa: balancear a carga do aplicativo com uma determinada política aberta. A tarefa pressupõe que uma orquestração |
Nenhuma suposição sobre a infraestrutura subjacente. Certifique-se de que o aplicativo seja dimensionado conforme necessário, com uma latência máxima de 10 ms. |
Propriedade |
Propriedade conjunta: aplicação e infraestrutura |
Propriedade conjunta: aplicação e infraestrutura |
Somente a infraestrutura |
Qualidade dos dados |
Extremamente alto. Requer conhecimento profundo do escopo subjacente. Por exemplo, é preciso saber qual balanceador de carga F5, qual versão de software, etc. Uma CLI ou NMS seria um exemplo de interfaces imperativas. |
Alto: Requer conhecimento do que a infraestrutura é capaz de fazer. Por exemplo, no exemplo acima, há conhecimento prévio da infraestrutura que dá suporte a um balanceador de carga. |
Baixo: Não requer conhecimento das capacidades da infraestrutura. A qualidade da entrada se aproxima do equivalente em linguagem natural. |
Nível de habilidade (Pessoa) |
Habilidades específicas da função. Por exemplo, administrador de rede, administrador de computação, administrador de armazenamento. Cada aspecto da infraestrutura exige que o usuário seja um especialista naquela área. |
Habilidades de implantação de aplicativos. O usuário sabe o tipo de função necessária para implantar o aplicativo. Como no caso acima, o gerente do aplicativo sabe que é necessário um balanceador de carga e políticas de alto nível nas quais o LB deve ser configurado para oferecer suporte ao dimensionamento automático. |
Engenheiro de aplicação. Pode apenas sinalizar à infraestrutura quais são os requisitos não funcionais do aplicativo. Neste caso, a rapidez com que o aplicativo deve responder a uma solicitação do cliente. Outros fatores como localização geográfica, custo, etc., podem ser adicionados conforme necessário. |
Escopo |
As interfaces imperativas têm |
O escopo declarativo é maior. Normalmente, associado a um mecanismo de orquestração que se comunica com diversas interfaces imperativas para atingir o resultado necessário. |
Âmbito muito amplo porque o resultado de |
Exemplo |
- name: update web servers hosts: webservers remote_user: root tasks: - name: ensure apache is at the latest version yum: name: httpd state: latest - name: write the apache config file template: src: /srv/httpd.j2 dest: /etc/httpd.conf |
apache-server: version: “latest” |
latência da aplicação: - lt: 10ms infraestrutura-custo: - lt: $200 - faturamento: mensal |
Abordamos as APIs extensivamente no relatório API Sprawl de 20212 e abordamos nele muitas questões que podem surgir. A Figura 6 mostra a diferença entre intercluster e intracluster.
Intra-Cluster: Em uma arquitetura monolítica, pode haver muito poucas APIs expostas com comunicação interna entre módulos por meio de outros métodos de comunicação entre processos. Enquanto uma arquitetura de microsserviços é dividida em dezenas, se não centenas, de APIs.
Seja qual for o caso, cada cluster de aplicativos é desenvolvido e gerenciado de maneira opinativa. Por exemplo, em casos de arquitetura de microsserviços, uma equipe pode usar qualquer tipo de malha de serviço: Istio, Linkerd, Aspen Mesh ou outros. Cada abordagem tem seus próprios meios para gerenciar e controlar as APIs dentro de seu cluster, ou seja, intracluster.
Há muitas soluções aqui e o objetivo para o Edge 2.0 não é reinventar nem forçar as organizações ou equipes de desenvolvimento a adotar mais outra nova tecnologia.
Inter-Cluster: À medida que o número de serviços entregues via APIs aumenta, novos aplicativos são criados usando serviços já desenvolvidos ou adotados por diferentes equipes de aplicativos dentro da empresa, pois não há necessidade de reinventar a roda.
Novos aplicativos também estão sendo criados por meio de diferentes combinações de APIs públicas e privadas. Do ponto de vista da arquitetura, os aplicativos modernos aproveitam os serviços fornecidos por outros clusters. Em uma nuvem distribuída, esses clusters são implantados globalmente e, portanto, podem estar localizados em qualquer espaço que possa hospedar o aplicativo ou fazer parte do cluster de aplicativos.
Para reiterar, o escopo de um cluster de aplicativos não se limita apenas a uma organização. Os clusters podem estar em quaisquer duas redes, aplicativos, silos organizacionais ou até mesmo entre duas empresas.
O escopo abrange toda a gama de todas as permutações e combinações, aumentando exponencialmente a complexidade das operações. A Figura 7 mostra as permutações de tráfego dentro do escopo de implantação do aplicativo.
Uma empresa típica terá diferentes arquiteturas de aplicativos. Pode haver diferentes tipos de malha de serviço, ou um aplicativo web 2.0 baseado em arquitetura orientada a serviços, ou uma implantação de software monolítico, dependendo de qual equipe está desenvolvendo e implantando. As APIs são, portanto, espalhadas por toda a empresa, sejam elas APIs privadas ou uso de APIs públicas. Este problema ainda não foi resolvido. A comunicação de API entre vários locais é crítica e um problema com solução difícil em empresas de qualquer tamanho.
Existem várias soluções para gerenciar APIs dentro de um cluster (por exemplo, controlador de entrada, gateway de API e muito mais), enquanto a comunicação de API entre clusters não é resolvida de maneira prática, escalável e segura. Dessa forma, concentramos o escopo do controle e gerenciamento unificados de API para abordar apenas problemas entre clusters.
Um valor subestimado da nuvem é a autonomia que ela oferece ao “consumidor da nuvem”. Empresas e empreendedores podem instanciar suas próprias infraestruturas sob demanda, enquanto experimentam uma aparência de controle total.
O princípio fundamental de design que uma plataforma Edge 2.0 deve seguir é oferecer uma experiência autônoma ao cliente da nuvem, ao mesmo tempo em que implementa as proteções corretas. Como as entidades podem aparecer em qualquer infraestrutura (confiável ou não confiável), os guard-rails devem ser implementados de forma a não sobrecarregar a BU ou a equipe de DevOps responsável pela construção do aplicativo.
O desafio emergente com o Edge 2.0 será o da descoberta, identidade, confiança e observabilidade entre vários serviços.
Mesmo em empresas de médio porte, o número de APIs produzidas anualmente seria grande. Como as equipes descobrem esses serviços dentro da empresa? Ou, nesse caso, como eles podem saber se os serviços ainda são válidos e quem é o proprietário deles? Eles podem ter certeza de que este é um serviço validado e com confiança estabelecida? O problema é agravado quando as equipes querem consumir serviços criados por clusters que residem fora dos limites da empresa, por exemplo, provedores de SaaS ou aplicativos executados em dispositivos de ponta completamente fora do controle administrativo das equipes de infraestrutura empresarial.
Considerando os desafios apresentados nas seções anteriores, precisamos visualizar toda a nuvem distribuída como uma plataforma. Em um nível superior, articulamos o objetivo da solução: descobrir de forma autônoma (sem intervenção humana), dimensionar e proteger aplicativos distribuídos em infraestrutura descentralizada.
Em essência, podemos descrever a responsabilidade da Plataforma de aplicações do Edge 2.0 (EAP) da seguinte maneira:
A infraestrutura é a totalidade do espaço da solução onde elementos de infraestrutura podem aparecer e desaparecer continuamente. A propriedade da infraestrutura e seus recursos versus a administração e o controle desses recursos são duas construções distintas. O proprietário da infraestrutura pode atribuir uma infraestrutura específica ou uma instância dela a uma organização diferente que a gerencia e configura, ou o proprietário da infraestrutura pode retomar o controle conforme necessário. A organização que gerencia e configura os elementos pode atribuí-los ainda mais a projetos ou aplicativos individuais. Essa noção não é nova; por exemplo, provedores de serviços de nuvem oferecem controle administrativo hierárquico que pode ser usado pelas equipes de TI de uma empresa para oferecer infraestrutura como serviço (IaaS) para unidades de negócios internas, equipes, etc. A principal preocupação do Edge 2.0 é como fazer isso extensivamente em uma nuvem hiperdistribuída, que é o estado atual e futuro da infraestrutura de ponta.
É aqui que o escopo do EAP entra em cena. A Figura 8 abaixo mostra o escopo do EAP dentro do contexto de diferentes tipos de interfaces. Cada EAP orquestra seu escopo local usando interfaces declarativas e imperativas. Neste caso:
Para aproveitar a nuvem distribuída, o EAP deve ter a capacidade de aproveitar todos os nós e entidades disponíveis por meio de uma nuvem distribuída. A visão é que o EAP individual se torne equivalente ao conceito de sistema autônomo3 em redes IP, mas para a camada de aplicação.
Resumindo, (Figura 9 abaixo) agora podemos construir uma visualização de alto nível de como diversas EAPs podem ser implantadas em uma infraestrutura de nuvem descentralizada interagindo entre si de maneira autônoma.
Interfaces adaptáveis também facilitam a integração de CI/CD e outros aplicativos do ciclo de vida com a nuvem distribuída. As plataformas de CI/CD podem interagir diretamente com o EAP com interfaces adaptativas simples, informando apenas o resultado desejado.
É importante observar que a comunicação interEAP também pode ser obtida usando interfaces adaptadas.
A estrutura do EAP, conforme mostrado na Figura 10, organiza as responsabilidades em termos de capacidades de cada instância do EAP. A função do EAP é interagir com os controladores de infraestrutura subjacentes — seja Infraestrutura como Serviço (IaaS), Plataforma como Serviço (PaaS), Software como Serviço (SaaS) — e orquestrar e programar recursos apropriados conforme necessário.
O futuro será uma economia orientada por APIs, onde elas serão mais do que apenas uma abordagem de arquitetura de software simplificada por meio de malha de serviços. Uma API se tornará o principal meio pelo qual qualquer entidade participante de uma nuvem distribuída fornece seu serviço.
Conforme estabelecido, o número global de APIs públicas e privadas que estarão disponíveis será de centenas de milhões, se não bilhões, dentro de uma década. As APIs remodelarão nossa economia e, portanto, exigirão uma análise mais detalhada do que o EAP deve implementar para dar suporte a essa economia.
A proliferação de APIs que impede isso exige que cada API seja detectável dentro e fora do EAP. Com a nuvem distribuída, as APIs podem estar em qualquer lugar em vários clusters.
A suposição subjacente é que o problema de descoberta de API é realmente um problema entre clusters. O escopo de um EAP pode abranger muitos clusters de aplicativos que usam diferentes abordagens de software (de microsserviços a monolíticos), cada um implementando sua própria estratégia de gateway de API. Um EAP fornece um repositório comum para que todas as APIs sejam registradas e descobertas dentro de seu escopo, não apenas dentro do cluster. Essa distinção é essencial para derivar as limitações das estratégias de gateway de API existentes, por exemplo, como na malha de serviços.
O desafio do EAP é permitir a descoberta de uma API, fornecer a documentação correta sobre seu uso e gerenciar o ciclo de vida da API para consistência, precisão e controle de versão. O EAP implementa um meio de informar entidades que usam suas APIs sobre o estado atual de APIs específicas que estão sendo usadas. Isso pode ser feito simplesmente definindo datas de validade ou informando explicitamente por meio de algum sistema de mensagens.
A postura de segurança adotada é quando uma aplicação presume que a infraestrutura em que está atualmente implantada já está comprometida.
O pilar fundamental para implementar essa postura de segurança é orientado pela identidade. Cada ponto de extremidade da API deve ter uma identidade globalmente única. As políticas e controles de segurança são mantidos separadamente em um repositório central.
As APIs devem ser marcadas como públicas ou privadas, acionando os componentes de segurança da infraestrutura em questão para serem configurados automaticamente para a API específica.
Todas as conversas entre aplicativos começam com uma política de negação total. Só porque uma API é visível não significa que outro aplicativo pode chamá-la. Isso deve ser configurado explicitamente na política de segurança do aplicativo.
A EAP deve garantir que todas as APIs dentro de seu escopo sejam confiáveis e, ao mesmo tempo, que todas as APIs externas que estejam sendo utilizadas pelos serviços dentro de seu escopo também sejam confiáveis.
“Não se pode comprovar a confiança, por isso que é ‘confiança’” — Da série Traidores da Netflix
Confiança é essencialmente “reputação ao longo do tempo”, e você deve revalidar essa confiança continuamente para garantir que ela não caia abaixo de um nível aceitável. Essa tem se tornado uma abordagem cada vez mais comum na modelagem e implementação de confiança em sistemas, exigindo que a confiança seja avaliada continuamente em vez de ser afirmada estaticamente na execução inicial.
A fluidez da confiança ao longo do tempo pode ser um desafio para algumas empresas que não têm o luxo de tempo para estabelecer reputação mútua entre seus sistemas e os de terceiros. Tanto a infraestrutura quanto as APIs podem causar estragos se a reputação não for monitorada de perto.
Supondo que um serviço dentro do escopo EAP acesse uma API externa, a plataforma deve implementar um mecanismo pelo qual o serviço de chamada possa ter certeza da precisão da resposta recebida da API externa. Só porque a resposta da API parece válida, não significa que ela seja confiável. A resposta pode ser imprecisa devido a problemas de qualidade, ou imprecisões podem ter sido inseridas explicitamente para tornar o negócio menos competitivo. Ter essa capacidade de atribuir um fator de confiança a cada API, interna ou externa, é exclusivo da construção EAP.
Uma estratégia para implementar a confiança é fazer uma média em um “período de tempo” mais recente, em vez de todo o histórico do serviço. É como olhar “Principais avaliações” vs “Mais recentes” de um produto na Amazon. O produto pode até ter quatro estrelas, mas se a maioria das avaliações negativas ocorrer nos últimos seis meses, isso indica uma quebra recente de confiança, enquanto um fluxo de comentários positivos nos últimos seis meses indicaria uma correção ou reconstrução da confiança.
O fator confiança não é específico apenas para saber se uma API é uma fonte conhecida de dados falsos ou enganosos ou não. A reputação de um EAP também dependerá de quão bem ele gerencia e atualiza as APIs dentro de seu escopo. Além disso, “confiança” também é relativa. O Serviço A pode confiar no Serviço C, mas o Serviço B pode ter uma experiência diferente com o Serviço C.
Com uma nuvem distribuída sendo a base da infraestrutura do Edge 2.0, torna-se imperativo que os recursos dentro do escopo de um EAP sejam fáceis de descobrir, proteger e instrumentar. O seguinte pode ser lido como um conjunto de recomendações necessárias às capacidades do gerente de infraestrutura de ponta.
Dentro de um EAP, os recursos podem ser agendados conforme necessário. Novos recursos podem chegar ou sair dinamicamente devido à mobilidade. Um EAP também pode enviar ou receber solicitações de outros EAPs para descobrir e agendar recursos conforme necessário em seu nome.
Para reiterar a postura de segurança: a infraestrutura na qual o aplicativo é implantado já está comprometida. O EAP deve, portanto, garantir a segurança da aplicação implantada dentro de seu escopo.
Independentemente do nível administrativo, a estrutura da EAP deve considerar diversas faces da segurança, como (entre outras coisas):
Ameaças externas: Por exemplo, ataques de negação de serviço distribuído (DDoS) e ameaças persistentes avançadas (APT). Isso pode ser mitigado usando as melhores práticas de segurança existentes, como prevenção de DDoS, firewall e muito mais. A recomendação é que seja obrigatório para todo o tráfego.
Homem-no-meio: Todo o tráfego deve ser criptografado e não se pode presumir que a camada de aplicação fará a coisa certa. Isso garante a confidencialidade básica dos dados de quaisquer dispositivos de espionagem de tráfego e protege a integridade dos dados contra manipulação durante a transmissão.
Ameaças internas: O escopo da camada de infraestrutura deve ser restrito e direcionado principalmente para proteger a si mesmo. A recomendação é evitar que um recurso dentro da infraestrutura inicie um ataque interno ao gerenciador de infraestrutura.
Se o Edge 2.0 é sobre a experiência que ele oferece e não sobre o ativo ou seu local, naturalmente, a telemetria também deve ser centrada na experiência.
A questão é: a experiência de quem estamos nos referindo? A experiência é a de qualquer entidade que reside ou usa infraestrutura para produzir ou consumir um serviço: aplicativos, dispositivos, humanos, aplicativos de back-end, bancos de dados e muito mais. O ponto de vista experiencial é, portanto, o da entidade. Um serviço que uma entidade produz ou consome está diretamente relacionado aos recursos de computação, armazenamento e rede alocados a ele.
Mas ninguém pode apenas parar ao medir a experiência; deve haver uma maneira de remediar isso também.
Qualquer entidade que consome ou fornece um serviço pode determinar se está obtendo a experiência solicitada. No entanto, em ambientes de nuvem distribuída, pode ser quase impossível explicar o que aconteceu na camada de infraestrutura que levou à experiência ruim.
Métricas de alto nível, como utilização de CPU, memória, largura de banda e medições de latência, não são suficientes para determinar por que um aplicativo não está obtendo a experiência solicitada3. As métricas precisam ser granulares no tempo e coletadas profundamente na pilha de aplicativos e sempre que disponíveis em diferentes camadas da pilha de infraestrutura.
Uma estratégia de telemetria e dados robusta, escalável e expansível é essencial para o EAP. Estratégias de aprendizado de máquina (ML) e inteligência artificial (IA) podem então ser aproveitadas para tomar a melhor decisão sobre reservar novos recursos ou otimizar o uso dos existentes.
Embora conectividade e acessibilidade sejam consideradas problemas resolvidos, muitas equipes de rede ainda lutam para racionalizar sua estrutura de rede com as necessidades dinâmicas da camada de aplicação. Uma plataforma também deve abordar esses desafios.
O problema com as abordagens existentes é que traduzimos as necessidades de conectividade de aplicativos para conectividade WAN empresarial, especialmente em uma nuvem distribuída. Abordagens para abordar uma rede de nuvem distribuída podem usar diferentes estratégias de SDN ou métodos baseados em roteamento puro. Mas essas soluções dependem muito da homogeneidade da infraestrutura e, portanto, não conseguem fornecer um comportamento consistente.
A única maneira com a qual podemos obter uma rede globalmente escalável, segura e estável para a aplicação é separando o plano da conectividade da aplicação da rede subjacente, como discutiremos a seguir.
Na evolução rumo a uma arquitetura de nuvem distribuída, o padrão de SDN emergente é orquestrar em conjunto as redes subjacentes e sobrepostas e habilitar a capacidade de programação de ponta a ponta do caminho da aplicação.
Com o Edge 2.0, precisamos trazer essa aparência de estabilidade mesmo ao conectar redes corporativas. Propomos que o plano de conectividade do aplicativo seja separado da conectividade da rede corporativa. O padrão de conectividade do aplicativo pode ou não seguir a mesma conectividade SDN vista na sobreposição do data center (por exemplo, VXLAN, NVGRE ou outros) ou padrões SDN baseados em BGP.
Nem todas as redes foram separadas em sobreposição e subposição. As equipes de rede agora estão vendo a necessidade dessa programabilidade conjunta como um requisito importante para permitir a automação de ponta a ponta, para a qual a separação da rede subjacente e da rede sobreposta é fundamental.
Separar o plano de aplicação da rede subjacente e do transporte elimina a necessidade de as equipes de rede responderem ativamente a cada solicitação de aplicação. Seu escopo se limita a fornecer caminhos robustos, estáveis e bem definidos, com foco na otimização do uso da largura de banda agregada nas latências mais baixas.
O princípio fundamental de um EAP é que ele é independente, autônomo e gerencia um subconjunto do espaço geral da solução. Mas os EAPs precisam de um meio para se comunicar e oferecer seus recursos ou solicitar recursos de outros EAPs. Há várias vantagens nessa abordagem.
Uma interface baseada em resultados elimina a necessidade de o EAP conhecer os detalhes sobre a outra infraestrutura. Suponha que existam dois EAPs: A e B. Cada EAP tem um escopo local de sua infraestrutura para agendar e reservar recursos. O EAP-A não precisa conhecer os recursos fornecidos pelo EAP-B. Se, por exemplo, o EAP-A não puder satisfazer as necessidades da aplicação e exigir recursos na infraestrutura que estão no escopo do EAP-B, então ele pode simplesmente expressar seu objetivo desejado ao EAP-B. Torna-se então responsabilidade do EAP-B invocar interfaces declarativas ou imperativas para reservar, alocar e configurar a partir de seu pool de recursos livres. O EAP-B também é responsável por garantir que os SLOs para esse serviço dentro de sua infraestrutura sejam atendidos.
Embora uma sintaxe comum seja útil para inicializar um conjunto inicial de APIs adaptadas, a implementação fica mais sofisticada e madura ao longo do tempo com o uso de processamento de linguagem natural e de IA para reduzir a qualidade necessária dos dados.
Diferentes padrões operacionais também se tornam simples, onde apenas o estado desejado precisa ser especificado. Padrões de resiliência, por exemplo, podem ser baseados apenas em um SLO esperado. Torna-se responsabilidade do EAP que fornece o serviço garantir que os recursos dentro de seu escopo sejam alocados para atender aos objetivos de nível de serviço. O EAP que faz a chamada não precisa se importar, mas provavelmente precisaria monitorar as métricas de serviço para saber se elas estão sendo atendidas ou não.
A Figura 12 visualiza o papel de diferentes camadas ao implantar uma aplicação na nuvem distribuída.
Os destaques dessa representação são:
Este white paper tenta se aprofundar em mais algumas camadas do manifesto original do Edge 2.0. Introduzimos alguns novos temas, com o objetivo de informar diferentes partes interessadas dentro de organizações internas e externas ao setor.
O Edge 2.0 é construído com base na noção de uma nuvem distribuída, onde cada entidade pode participar tanto como origem quanto como destino dos serviços. O tema principal é que o Edge 2.0 será sobre a experiência e não sobre o ativo ou a localização.
A plataforma de aplicações de borda (EAP) é introduzida como uma pilha de capacidades para permitir que o Edge 2.0 seja realizado em uma nuvem distribuída.
Os detalhes da implementação foram ignorados deliberadamente para apresentar uma visualização independente do fornecedor.
2 https://www.f5.com/pdf/reports/f5-office-of-the-cto-report-continuous-api-sprawl.pdf
3 Wikipédia - Um sistema autônomo (AS) é uma coleção de prefixos de roteamento de Protocolo de Internet (IP) conectados sob o controle de um ou mais operadores de rede em nome de uma única entidade administrativa ou domínio que apresenta uma política de roteamento comum e claramente definida para a Internet.