Índice
Introdução
A definição da borda sempre esteve interconectada com a evolução da arquitetura do data center. Na última década, houve uma rápida transformação na arquitetura da infraestrutura corporativa, expandindo de data centers no local para as arquiteturas de nuvem distribuídas de hoje. Reconhecemos o Edge 2.0 como uma mudança de tecnologia que permitirá que as aplicações alavanquem uma arquitetura de nuvem distribuída.
Cada pessoa, organização ou entidade possui uma interpretação diferente da borda. 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 superfície de infraestrutura gerenciada que se integra perfeitamente em seu back-end. Para aplicações militares, a borda é o palco da batalha, seja ele em terra, no mar ou no ar. Sempre que lemos sobre a borda, a interpretação é geralmente resumida como capacidades de computação, networking e armazenamento da infraestrutura e/ou seu local.
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.
Esse documento descreve o que deveria ser a funcionalidade do Edge 2.0, independentemente de sua infraestrutura física ou virtual, ou se está localizada ou instanciada. A intenção não é explicar como criar uma aplicação mais bem distribuída, mas iluminar as capacidades que devem estar no Edge 2.0 para suportar a criação das aplicações distribuídas ideais que sejam adequadas a um requisito em particular.
O que é o Edge 2.0?
Do ponto de vista de uma entidade que resida nessa nuvem distribuída, a borda é qualquer lugar em que a entidade esteja atualmente localizada. Portanto, propomos uma definição do Edge 2.0 que seja centrada na experiência, não vinculada apenas ao local da infraestrutura, ao tipo de infraestrutura ou à entidade de controle.
O foco do Edge 2.0 está no aprimoramento de experiências centradas na aplicação, no operacional e no desenvolvedor. O 2.0 deve abordar metapropriedades (como SLAs e SLOs) da aplicação adaptando se às diferentes necessidades da aplicação. O Edge 2.0 deve ser simples de operar e deve tirar a carga das equipes de operações d criar uma nova automação para cada aplicação distribuída. O Edge 2.0 deve reduzir o atrito enfrentado por desenvolvedores quando eles desenvolverem e implementarem aplicações distribuídas em escala, ao suportar perfeitamente a segurança, a governança e os objetivos de nível de serviço.
Como um exemplo, vamos usar uma aplicação de banco. A meta do Edge 2.0 não é melhorar a lógica comercial da transação. Trata-se de torná-la mais segura, mais rápida, privada, utilizável em todas as geografias (se necessário) e redimensionável para mais ou para menos conforme necessário para suportar as metas corporativas.
Conceitos e declarações
A seguir, estão os principais conceitos e declarações desse white paper:
- Borda centrada na experiência: estabelece uma base para o Edge 2.0 ao redor da experiência que ele oferece, em vez de um ativo ou seus locais.
- Considerações de design: especifica as principais considerações de design para uma implementação bem-sucedida da arquitetura do Edge 2.0.
- Infraestrutura heterogênea: destaca que o design para uma nuvem distribuída significa considerar o controle descentralizado da infraestrutura.
- Telemetria como uma base: enfatiza a telemetria como bloco de construção fundamental que deve ser suportado em todas as camadas da infraestrutura. Sem a telemetria, a estratégia de dados primeiro se torna diluída.
- Desafios interclusters: enfatiza um desafio fundamental com o Edge 2.0 como sendo interclusters em vez de intraclusters.
- Interfaces adaptadas: introduz as interfaces adaptadas, oferecendo uma comparação distinta com interfaces declarativas e imperativas.
- Plataforma de aplicações do Edge 2.0 (EAP): apresenta a EAP como uma estrutura para permitir que o Edge 2.0 se adapte às necessidades das aplicações.
Tópico(s) não abordado(s)
Há diversos tópicos que ainda não foram abordados nesse white paper:
- Distribuição de dados de aplicação: há muitos subtópicos aqui, como redes de entrega de conteúdo (CDNs), distribuição de armazenamento, distribuição de dados, armazenamento em cache, etc. Também há tecnologias emergentes como Tipo de dados replicados sem conflito (CRDT). Uma estrutura de Edge 2.0 deve incluir o suporte para distribuição de dados de aplicação em seu escopo.
- Distribuição de funções: o avanço da computação de borda pode ser considerado como lógica e funções de nuvem principais, mudando para mais perto do local em que o evento é gerado ou em que os dados residem. Devido à quantidade significativa de computação se tornando disponível na borda, agora, devemos resolver problemas semelhantes aos tipicamente resolvidos em arquiteturas de nuvem legadas se desejarmos aproveitar essa computação. Por exemplo, sobreposições de rede, cargas de trabalho de middleware e outros tipos de cargas de trabalho que estão interconectados e são mais complexos do que casos de uso simples que temos visto na borda anterior; por exemplo, storlets, que são fluxos simples sem estado que devem ser executados juntos com os dados.
- Provavelmente, há outras áreas não discutidas. A meta da estrutura é ser ampliável de forma que as responsabilidades possam ser adicionadas conforme necessário.
Evolução da borda
A Figura 1 demonstra bem a coevolução das arquiteturas da borda e de datacentes. O Edge 1.0 e o 1.5 eram baseados na noção de um site de origem e na movimentação dos dados e serviços da origem para o consumidor. O Edge 1.0 era a implantação da infraestrutura de Internet com foco principalmente na otimização do uso da largura de banda com cache de conteúdo distribuído, também conhecido como redes de distribuição de conteúdo (CDN). CDNs são um padrão de design fundamental, uma vez que o conteúdo agregado a ser transferido sempre será maior do que a largura de banda disponível.
À medida que os custos de CPU e memória diminuíram rapidamente, fazendas de computação surgiram junto com nós de CDN. As aplicações eram consumidas como serviços por meio de arquiteturas orientadas a serviços (SOA). Por isso, a referência ao Edge 1.5 como uma Rede de distribuição de serviço.
Uma característica comum do Edge 1.0 e do Edge 1.5 é a ideia de um site de origem. Antes do crescimento do mundo móvel, as pessoas, dispositivos e coisas baixavam principalmente conteúdo ou atuavam como consumidores do serviço. O site que originava o serviço ainda era diferente do site do consumidor.
No entanto, no Edge 2.0, 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. Aplicações estão se tornando consumidores à medida que dependem de outras aplicações. Todas as entidades podem atuar como produtores ou consumidores de um serviço — APIs, humanos, dispositivos de IoT, ou aplicações da Web, de back-end e sem interface. do seu próprio ponto de vista, cada entidade na infraestrutura pensa que está na borda.
A nuvem distribuída é o estágio mais recente na evolução do datacenter. A computação se tornou verdadeiramente onipresente, de dispositivos móveis até mesmo sendo integrada em objetos do cotidiano que estão conectados à rede. Co-evoluindo com isso, estão as arquiteturas de software para permitir aplicações distribuídas e dimensionáveis.
Consequências da borda: maior complexidade
A abundância e hiperdistribuição da computação e do armazenamento em todos os lugares criaram uma oportunidade para rápida transformação digital das empresas. Mas essa rápida evolução tem suas consequências.
A maioria das empresas normalmente é composta por uma infraestrutura heterogênea, com ambientes não uniformes. Redimensionar com eficiência esses ambientes demanda orquestração e automação complexas dos sistemas implementados. Rápidas alterações nas necessidades das aplicações, como mudanças nos requisitos de CPU e de largura de banda, aumentam a complexidade das operações em uma nuvem distribuída. Isso adiciona stress às equipes de operações, que podem não estar bem equipadas para responder com eficiência às inconstantes necessidades da aplicação 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 uma maior área de superfície que pode ser comprometida devido a uma variedade de vetores de ataque. Diferentes casos de uso criam diversos desafios de segurança e, à medida que a infraestrutura evolui, estamos constantemente correndo atrás do prejuízo. Portanto, o problema que antecipamos é: somente as recomendações de tecnologia 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:
- O Perímetro definido por software (SDP) não é redimensionado facilmente, pois as soluções populares são baseadas em agente, o que são adequadas para implementações operacionais simples.
- Muitas vezes, a implementação de Acesso à rede Zero Trust (ZTNA) é impraticável, porque as soluções de ZTNA exigem uma constelação de serviços de produção implementados como a inspeção do tráfego, gerenciamento de logs centralizado, PKI global, gerenciamento de identidade e muito mais.
- A Borda de serviço de acesso seguro (SASE) combina a rede como um serviço e a segurança como um serviço, um aglomerado de acrônimos de diversas tecnologias não triviais para implementar. Além disso, o foco da SASE tende a ser centrado na rede de longa distância definida por software (SD-WAN), englobando um pequeno segmento dos casos de uso da borda da rede corporativa.
- A disparidade entre a infraestrutura de diferentes provedores de nuvem pública e os modelos de segurança já complexos, por exemplo o Gerenciamento de acesso e identidade (IAM), geralmente leva as equipes a um fortalecimento de uma colcha de retalhos de provedores e configurações de multinuvem complicadas.
Um dos principais desafios com a hiperdistribuição de computação de baixa potência e baixo custo na borda é a capacidade de orquestrar e programar a infraestrutura de maneira uniforme. As equipes de operações têm dificuldades com o redimensionamento e o suporte de aplicações que aproveitam a nuvem distribuída, pois, normalmente, essas aplicações incluem tecnologias heterogêneas com diferentes requisitos de administração.
Embora plataformas de automação como Terraform forneçam um meio sofisticado de personalizar a automação, as equipes de operações ainda precisam manter os scripts para diversas 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 precisar gerenciar e manter os scripts de automação não escalam.
Isso leva à interação continuada do consumidor da infraestrutura com as equipes de operações por meio de sistemas movidos por tíquetes, que são uma barreira para a automatização de fluxos de trabalho existentes. A central de serviços fica sobrecarregada com tíquetes, precisando priorizar a segurança e a estabilidade em relação à agilidade.
As arquiteturas de microsserviços já se tornaram o método de fato para criação de novas aplicações com a evolução rumo a multinuvem. APIs são publicadas e podem ser instanciadas sempre e quando necessário, levando a uma expansão de API. A descoberta, a conectividade e o gerenciamento dessas APIs de maneira autônoma se torna um grande desafio.
Uma mudança de paradigma é necessária para corrigir a expansão de API. Nossos modelos internos demonstram que mesmo previsões de parâmetros moderadas, como o número de desenvolvedores de API globais, o número de APIs desenvolvidas por desenvolvedor por ano e a vida útil da API, resultam em centenas de milhões (se não bilhões) de APIs ativas simultaneamente em 2030 (Figura 2). O Relatório de expansão de API de 2021 fornece uma visualização abrangente desse tópico emergente.
A maior complexidade exige que as empresas ativem a visibilidade de ponta a ponta granular e significativa de todo o sistema. Em ambientes de nuvem distribuída, as aplicações transcendem diversas pilhas de infraestruturas heterogêneas gerenciadas por diferentes entidades.
Além do mais, nenhum dos operadores de hoje é incentivado a expor a telemetria nativa de sua infraestrutura para os clientes corporativos. As empresas estão essencialmente operando às cegas ao implantar aplicações em uma nuvem distribuída e precisam reclassificar diversas ferramentas de observabilidade. Para preencher essas lacunas na visibilidade, as ferramentas normalmente se originam de diferentes empresas de fornecimento que trabalham em diferentes pontos na infraestrutura ou nas pilhas de aplicações.
Métricas de infraestrutura fora do padrão pioram as coisas 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, métricas entre provedores de nuvem pública são diferentes e as tecnologias de data center no local também não seguem nenhuma métrica padrão.
Resultado comercial: experiência reduzida
Cargas de trabalho que geram receita e sistemas críticos para a missão normalmente utilizam a maioria dos recursos operacionais e orçamento disponíveis em uma empresa. Enquanto isso, projetos menores, embora menores na complexidade, tendem a constituir o volume das aplicações da empresa. A Figura 3 demonstra 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 aplicações menores possam ter uma menor complexidade operacional, os processos e fluxos de trabalho para operacionalizar ainda são, em muitos casos, manuais e isso pode levar semanas para que os tíquetes de serviço passem com êxito para diversas equipes operacionais. Por exemplo, implantar uma aplicação que exige recursos de rede dedicados com políticas de segurança granulares pode primeiro exigir que as equipes de segurança global trabalhem com as aprovações das políticas de segurança. Em seguida, o tíquete de serviço pode ir para a equipe de rede para planejar a subrede e as configurações de roteamento que precisam ocorrer. por fim, a validação das regras de firewall podem ser necessárias por parte de outra equipe operacional que é responsável pelo gerenciamento de firewall.
Agora, vamos imaginar que a complexidade acima precise ser gerenciada para cada aplicação implementada em uma nuvem distribuída em que a empresa não possui nenhuma parte da infraestrutura em questão. O volume total de pequenos projetos ou aplicações que precisam ser integrados e suportados torna impossível para as equipes de operações suportarem cada projeto, criando um problema de priorização e oportunidade de autoatendimento.
Esse problema de priorização pode ser observado especialmente à medida que os investimentos das equipes de infraestrutura são focados no suporte de sistemas críticos e de geração de receitas, deixando pouco tempo ou orlamento para novos projetos que envolvem seu próprio ciclo de vida de desenvolvimento, teste e preparo antes da produção. Isso resulta em capacidades e investimento reduzidos para a velocidade, a personalização e inovação de recursos que suportam novos produtos, culminando na estagnação dos negócios e de suas ofertas.
Espaço da solução de borda
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 exibe o espaço da solução do Edge 2.0. Aqui, definimos que tudo que vem em 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:
- Todas as entidades que residem no escopo da solução; aplicações, humanos e dispositivos que atuam como aplicações consumidoras, ou de back-end da Web ou sem interface que compõem os serviços.
- As equipes de SRE e proprietários de aplicações dessas aplicações, ao mesmo tempo que preservam a segurança e proteções regulatórias esperadas da infraestrutura.
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.
Considerações de design do Edge 2.0
Seguro por padrão
Uma nuvem distribuída amplifica esse problema de segurança em escala, à medida que o número de pontos de extremidade aumenta exponencialmente. Com essa enorme escala, a complexidade de implementar uma solução também escala. A postura da segurança deve ser que a aplicação presume que o ambiente em que ela está atualmente implantada já esteja comprometido. Da mesma maneira, a infraestrutura não deve confiar em nenhuma aplicação que seja executada nela.
A base dessas ideias é capturada nos conceitos da mentalidade Zero Trust e o exemplo BeyondCorp1 demonstra esses conceitos para o caso de uso de acesso à aplicação. Adiante, o Edge 2.0 estende esse modelo, com base nos cinco princípios essenciais a seguir:
- A identidade é fundamental: no Edge 2.0, a identidade está no cerne, com cada instância de entidade tendo sua própria identidade globalmente exclusiva, mas também seu lugar na hierarquia da organização junto com seu nível de privilégio. A identidade deve ser uma consideração principal não apenas para o tráfego de norte a sul, mas também internamente para o acesso de leste a oeste.
- Menor privilégio: as ações permitidas por um agente devem ser restringidas apenas às que o agente precisa para realizar seu papel no sistema. Um exemplo é limitar o subconjunto de cargas de trabalho que são permitidas para se comunicarem com o servidor do banco de dados com base na especificação do design.
- Autenticação contínua: qualquer declaração que um agente do sistema faça deve ter um meio de verificação e deve ser verificada explicitamente sempre que tal declaração ocorrer. A autenticação não deve ser unicamente explícita por meio de segredos compartilhados ou cadeia de confiança, mas também deve fatorar em padrões implícitos de comportamento e metadados contextuais.
- Monitoramento e avaliação constantes: as ações de todos os agentes no sistema devem ser monitoradas, reforçando o papel principal das tecnologias de coleta e armazenamento de dados em uma arquitetura do Edge 2.0. Além disso, essas atividades devem ser avaliadas continuamente para detectar e mitigar tentativas de realizar ações proibidas ou perigosas. A avaliação deve ser quase em tempo real, em escala, implicando o uso liberal da automação e das técnicas de aprendizado de máquina.
- Presumir uma violação: com os recursos disponíveis para os adversários sofisticados de hoje, devemos sempre presumir que todo qualquer sistema tenha sido comprometido de alguma maneira. Como resultado, as políticas totalmente determinísticas enraizadas na carga de trabalho e em identidades de usuários, que aplicam o acesso com base em privilégios representado por A e B, geralmente são insuficientes para evitar todos os ataques. Portanto, um sistema de Edge 2.0 totalmente maduro também deve ser capaz de fazer avaliações de recompensa/riscos em tempo real com base em monitoramento e avaliações contínuos.
Oferece observabilidade nativa
O Edge 2.0 deve integrar a telemetria como um cidadão de primeira classe bem profundamente na pilha da infraestrutura, fornecer meios simples e redimensionáveis para coletar a telemetria entre camadas dentro da infraestrutura e levá-la para uma plataforma comum. Isso ajuda as equipes de observabilidade a revelar a interrogação do “estado da infraestrutura” conforme necessário, permitindo que as equipes de aplicação se concentrem na lógica dos negócios sem instrumentar especificamente suas pilhas de aplicações.
O estado atual da tecnologia de observabilidade tem sido amplamente específico e de propriedade do fornecedor. Isso faz com que muitos agentes específicos do fornecedor coletem sinais similares, competindo pela memória e CPU, que são 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 produto têm dificuldades em justificar o investimento na instrumentação, pois o esforço precisa mapear para uma oportunidade de receita. A infraestrutura deve ser instrumentada como qualquer outra função ou processo dos negócios, porque a equipe precisa compreender seu comportamento para otimizá-la para os objetivos comerciais. Assim, o debate deve ser mais sobre o que deve ser priorizado para instrumentar do que 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.
Suporta interfaces adaptadas
De acordo com a nuvem distribuída, ao se aprofundar um pouco, cada nuvem dentro de seu escopo (local ou global) tem seu próprio gerente, administrador, orquestrador e muito mais. Cada um deles se comportando de maneira independente, tomando suas próprias decisões, mas fornecendo interfaces para outras entidades usarem conforme necessário.
Portanto, a noção de uma nuvem distribuída é essencialmente uma administração e controle descentralizados. Ninguém pode se livrar desse fato e é importante para nós reconhecermos isso para descobrirmos as nuances das interfaces adaptadas em relação às 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.
O objetivo é ser baseado em resultados e os sistemas precisam ser inteligentes o suficiente para ajustar as políticas na infraestrutura (de ponta a ponta) para atingir esses resultados. Chamamos isso de interfaces adaptadas.
Para deixar claro, interfaces imperativas, declarativas e adaptadas não são mutuamente exclusivas:
Imperativa: é muito prescritiva e define detalhadamente uma série de ações para obter o 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, quanto de CPU/memória, largura de banda necessária, rotas específicas e mais). A qualidade dos dados do modelo de dados é muito alta e, portanto, requer um conhecimento mais profundo sobre a infraestrutura. Há uma expectativa do conhecimento sobre o modelo e a estrutura da infraestrutura.
Declarativa: a nuance da declarativa é que ela se concentra em descrever o estado desejado e não em ações que atingem o estado desejado. A qualidade dos dados é menor, embora ela ainda exija que a aplicação conheça pelo menos a estrutura da infraestrutura em questão.
Adaptada: difere-se totalmente da imperativa ou declarativa. Uma interface adaptada se concentra na meta ou objetivo desejados, em vez de no estado. A meta da interface adaptada é capturar o objetivo da parte interessada que deseja implantar a aplicação em vez de se concentrar em um pré-conhecimento do sistema em questão. A interface adaptada é diferente, pois não tem nenhuma noção de quais são as capacidades da infraestrutura em questão. Não há nenhuma restrição sobre como “realizar o trabalho” e, portanto, ela é independente.
Com a interface adaptada, a qualidade dos dados é baixa e se aproxima da linguagem natural. Os proprietários da aplicação podem enviar uma solicitação informando ao controlador da infraestrutura qual resultado esperam, em vez de precisarem declarar a capacidade necessária ou configurarem especificamente um recurso.
Resolve o problema interclusters
Uma nuvem distribuída, por definição, acomoda todos os tipos de arquiteturas de aplicação: monolíticas, microsserviços ou sem servidor. Independentemente da arquitetura, as aplicações usam APIs para oferecer os 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, as aplicações Edge 2.0 aproveitam as APIs em uma infraestrutura de nuvem hiperdistribuída, em essência, um ambiente multiclusters. Novas aplicações são criadas com APIs que cruzam limites organizacionais e geográficos. Algumas das APIs podem ser privadas ou de parceiros atrás de diversas camadas de firewalls sem uma rota explícita entre elas, mesmo se puderem ser descobertas. Esse problema de clusters heterogêneos (interclusters) 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. No jargão programático, é 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 Mark: precisa seguir uma série de etapas muito específicas |
Jane pede a Mark: (a) por favor, envie esse pacote para esse endereço, (b) o pacote precisa chegar em menos de 72 horas. Mark: pode escolher qualquer empresa de transportes (UPS, FedEx, DHL, etc). |
Jane afirma para Mark: (a) Esse pacote deve estar em NYC até sábado. Mark: pode fazer como quiser. Pode até ele mesmo levar o pacote, voando para NYC e entregando em mãos. |
Cenário 2: exemplo de balanceador de carga |
O balanceador de carga já existe. Tarefa: precisa ser configurado 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: faça o balanceamento da carga da aplicação com uma determinada política aberta. A tarefa presume que uma camada de orquestração |
Nenhuma suposição sobre a infraestrutura em questão. Certifique-se de que a aplicação é redimensionada conforme aplicável, 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 alta: requer um profundo conhecimento do escopo em questão. Por exemplo, precisa saber qual balanceador de carga da F5, qual versão de software, etc. uma CLI ou NMS seria um exemplo de interfaces imperativas. |
Alta: requer o conhecimento sobre o que a infraestrutura é pode fazer. Por exemplo, nos exemplos acima, há um pré-conhecimento de que a infraestrutura suporta um balanceador de carga. |
Baixa: não requer nenhum conhecimento das capacidades da infraestrutura. A qualidade dos dados se aproxima da 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 requer que o usuário seja um especialista nessa área. |
Habilidades de implantação de aplicação. O usuário conhece o tipo de função necessária para implantar a aplicação. Como no caso acima, o gerente da aplicação sabe que um balanceador de carga é necessário e as políticas de alto nível sobre as quais o LB deve ser configurado para suportar o redimensionamento automático. |
Engenheiro de aplicação: pode apenas sinalizar para a infraestrutura quais são os requisitos não funcionais da aplicação. Nesse exemplo, a velocidade com que a aplicação deve responder a uma solicitação do cliente. Outros fatores como local geográfico, custos, etc. podem ser adicionados se necessário. |
Escopo |
As interfaces imperativas possuem |
O escopo declarativo é maior. Normalmente, associado a um mecanismo de orquestração que informa a diversas interfaces imperativas para atingir o resultado desejado. |
Escopo muito grande, porque o resultado da |
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” |
application-latency: - lt: 10ms infrastructure-cost: - lt: $200 - billing: monthly |
Cobrimos as APIs de forma extensa no relatório2 de Expansão de API de 2021 e abordamos nele diversas questões que podem surgir. A Figura 6 exibe a diferença entre interclusters e intracluster.
Intracluster: 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ço é dividida em dezenas, se não centenas, de APIs.
Independentemente do caso, cada cluster de aplicação é desenvolvido e gerenciado de maneira opinativa. Por exemplo, em casos de arquitetura de microsserviço, uma equipe pode usar qualquer tipo de malha de serviços, Istio, Linkerd, Aspen Mesh, entre outras. Cada abordagem possui seus próprios meios de gerenciar e controlar as APIs dentro de seu cluster, em outras palavras, 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.
Interclusters: à medida que o número de serviços fornecidos por APIs aumenta, novas aplicações são criadas usando serviços já desenvolvidos ou adotados por diferentes equipes de aplicação na empresa eliminando a necessidade de reinventar a roda.
Novas aplicações também estão sendo criadas por meio de diferentes combinações de APIs públicas e privadas. Do ponto de vista da arquitetura, aplicações modernas aproveitam serviços fornecidos por outros clusters. Em uma nuvem distribuída, esses clusters são desenvolvidos globalmente, por isso, podem estar localizados em qualquer imóvel que possa hospedar a aplicação ou ser parte do cluster da aplicação.
Para reiterar, o escopo de um cluster de aplicação não está limitado apenas em uma organização. Os clusters podem estar entre duas redes, aplicações, silos organizacionais ou até mesmo entre duas empresas.
O escopo abrange a gama completa de todas as permutações e combinações, aumentando assim de maneira exponencial a complexidade das operações. A Figura 7 exibe as permutações de tráfego dentro do escopo de implantação da aplicação.
Uma empresa comum terá diferentes arquiteturas de aplicação. Pode haver diferentes tipos de malha de serviços, ou uma aplicação da Web 2.0 baseada em uma arquitetura orientada para serviços, ou uma implantação de software monolítica, dependendo de qual equipe a estiver desenvolvendo e implantando. Portanto, as APIs estão espalhadas em toda a empresa, sejam elas APIs privadas ou APIs públicas. Esse problema ainda não foi resolvido. A comunicação de API entre diversos locais é essencial e um problema com uma solução elusiva em empresas de qualquer porte.
Há diversas 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 interclusters não é resolvida de maneira prática, redimensionável e segura. Dessa maneira, concentramos o escopo de controle e gerenciamento de API unificados apenas para corrigir problemas interclusters.
Fornece autonomia
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 ao mesmo tempo que experimentam uma semelhança com o controle total.
O princípio de design fundamental que uma plataforma de Edge 2.0 deve seguir é fornecer uma experiência autônoma ao consumidor da nuvem ao mesmo tempo que implementa as proteções certas. Como as entidades podem aparecer em qualquer infraestrutura (confiável ou não confiável), as proteções devem ser implementadas de maneira que não sobrecarregue a BU ou a equipe de DevOps responsável por criar a aplicação.
O desafio emergente com o Edge 2.0 será o da descoberta, identidade, confiança e observabilidade entre vários serviços.
Até mesmo em empresas de médio porte, o número de APIs produzidas por ano seria grande. Como as equipes descobrem esses serviços dentro da empresa? Ou, para esse caso, como elas podem saber se os serviços ainda são válidos e quem é o proprietário? Elas podem ter certeza de que este é um serviço validado com uma confiança estabelecida? O problema é agravado quando as equipes desejam consumir serviços criados por clusters que residem fora dos limites da empresa, por exemplo, em provedores de SaaS ou aplicações executadas em dispositivos de borda completamente fora do controle administrativo das equipes de infraestrutura da empresa.
Plataforma de aplicações do Edge 2.0
Em consideração aos desafios apresentados nas seções anteriores, precisamos visualizar toda a nuvem distribuída como uma plataforma. Em um nível da Uber, definimos o objetivo da solução: descobrir, dimensionar e proteger de maneira autônoma (sem intervenção humana) aplicações distribuídas na infraestrutura descentralizada.
Em essência, podemos descrever a responsabilidade da Plataforma de aplicações do Edge 2.0 (EAP) da seguinte maneira:
- Descoberta de API, identidade e confiança
- Programação e orquestração da infraestrutura
- Conectividade segura de aplicação
Escopo da EAP
A infraestrutura é a totalidade do espaço da solução onde os elementos da infraestrutura podem aparecer ou desaparecer continuamente. A propriedade da infraestrutura e seus recursos e a administração e controle desses recursos são duas construções separadas. Um proprietário de infraestrutura pode atribuir uma infraestrutura específica ou uma instância dela a uma organização diferente da que a gerencia e a configura, ou o proprietário da infraestrutura pode assumir de volta o controle conforme necessário. A organização que gerencia e configura os elementos pode atribuí-la também a projetos ou aplicações individuais. Essa noção não é nova; por exemplo, provedores de serviço na nuvem oferecem um controle administrativo hierárquico que pode ser usado pelas equipes de TI de uma empresa para fornecer adicionalmente a Infraestrutura como um serviço (IaaS) para unidades de negócios internas, equipes, etc. A principal preocupação para o Edge 2.0 é conseguir isso de maneira extensa em uma nuvem hiperdistribuída, que é o estado atual e futuro da infraestrutura de borda.
É aí que o escopo da EAP entra em ação. A Figura 8 abaixo exibe o escopo da EAP dentro do contexto de diferentes tipos de interface. Cada EAP orquestra com seu próprio escopo legal usando interfaces declarativas e imperativas. Nesta instância:
- Declarativas/imperativas seriam as APIs AWS, APIs Azure, etc.
- Interfaces adaptadas seriam as novas que precisam ser definidas caso a caso.
Para aproveitar a nuvem distribuída, a EAP deve ter a capacidade de aproveitar todos os nós e entidades disponíveis em uma nuvem distribuída. A previsão é que a EAP individual se torne equivalente ao conceito de sistema3 autônomo em redes de IP, mas, para a camada de aplicações.
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 adaptadas também facilitam a integração de CI/CD e outras aplicações de ciclo de vida da aplicação na nuvem distribuída. Plataformas de CI/CD podem se comunicar diretamente com a EAP com interfaces adaptadas simples definindo apenas o resultado desejado.
É importante observar que a comunicação interEAP também pode ser obtida usando interfaces adaptadas.
A estrutura da EAP
A estrutura da EAP, como exibido na Figura 10, organiza as responsabilidades em termos de capacidades de cada instância da EAP. O papel da EAP é realizar uma interface com os controladores da infraestrutura de base — seja Infraestrutura como serviço (IaaS), Plataforma como serviço (PaaS), Software como serviço (SaaS) — e orquestrar e programar recursos adequados conforme necessário.
Gerenciamento e controle de API unificados
O futuro será uma economia acionada por API, em que as APIs serão mais do que apenas uma abordagem de arquitetura de software simplificada por uma malha de serviços. Uma API será a principal maneira da qual uma entidade que participa 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 estará na casa das centenas de milhões, se não bilhões, nessa década. As APIs reformularão nossa economia e, portanto, demandarão uma atenção maior sobre o que a EAP deve implementar para suportar essa economia.
A impeditiva expansão de API exige que cada API possa ser descoberta dentro e fora da EAP. Com a nuvem distribuída, as APIs podem estar em qualquer lugar em diversos clusters.
A suposição inerente é que o problema da descoberta de API é realmente um problema interclusters. O escopo de uma EAP pode abranger diversos clusters de aplicação que usam diferentes abordagens de software (microsserviços a monolíticas), cada um implementando sua própria estratégia de gateway de API. Uma EAP oferece um repositório comum para todas as APIs que devem ser registradas e podem ser descobertas dentro de seu escopo, e não apenas intracluster. Essa distinção é o segredo para derivar as limitações das estratégias de gateway de API existentes, por exemplo, como na malha de serviços.
O desafio para a EAP é permitir a descoberta de uma API, fornecer a documentação correta sobre seu uso e gerenciar o ciclo de vida da API quanto à consistência, precisão e controle de versão. A EAP implementa um meio de informar as entidades usando suas APIs no estado atual das APIs específicas que estão sendo usadas. Isso pode ser feito simplesmente definindo as datas de expiração 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 principal pilar para implementar essa postura de segurança é acionado pela identidade. Cada ponto de extremidade de API deve ter uma identidade globalmente exclusiva. 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 aplicações começam com uma política de “negar tudo”. Só porque uma API está visível, isso não significa que outra aplicação pode chamá-la. isso deve ser configurado explicitamente dentro da política de segurança da aplicação.
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
A confiança é, essencialmente, a “reputação ao longo do tempo” e é necessário revalidar continuamente essa confiança para garantir que ela não tenha ficado abaixo de um nível aceitável. Essa tem sido uma abordagem cada vez mais comum ao modelar e implementar a confiança em sistemas, exigindo que a confiança seja continuamente avaliada em vez de declarada de maneira estática na execução inicial.
A fluidez da confiança ao longo do tempo pode ser um desafio para algumas empresas que não possuem o valioso tempo para estabelecer uma reputação mútua entre elas e sistemas de terceiros. A infraestrutura e as APIs podem igualmente ser comprometidas se a reputação não for observada cuidadosamente.
Supondo que um serviço no escopo da EAP acesse uma API externa, a plataforma deve implementar um mecanismo com o qual o serviço que realiza a chamada tenha a garantia da precisão da resposta recebida da API externa. Apenas o fato de a resposta da API parecer válida não significa que ela é confiável. A resposta pode ser imprecisa por problemas de qualidade ou as imprecisões podem ter sido inseridas de maneira explícita para tornar os negócios menos competitivos. Ter essa capacidade de atribuir um fator de confiança a cada API, interna ou externa, é exclusiva da construção da EAP.
Uma estratégia para implementar a confiança é fazer a média dela em um “período de tempo” mais recente em vez de em todo o histórico do serviço. Isso é como olhar as “Principais avaliações” vs “Mais recentes” para um produto na Amazon. O produto pode ter quatro estrelas, mas, se a maioria das classificações negativas estão nos últimos seis meses, isso indica uma quebra na confiança recente, ao passo que um influxo de comentários positivos nos últimos seis meses indicaria uma correção ou reconstrução da confiança.
O fator de confiança não é apenas específico ao fato de a API ser ou não uma fonte conhecida de dados falsos ou enganosos. A reputação de uma EAP também dependerá do seu desempenho ao gerenciar e atualizar as APIs dentro de seu escopo. Além disso, a “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.
Gerenciador de infraestrutura da borda
Com uma nuvem distribuída sendo a base da infraestrutura do Edge 2.0, é imperativo que os recursos dentro do escopo de uma EAP sejam fáceis de descobrir, protegidos e instrumentados. Os itens a seguir podem ser interpretados como um conjunto de recomendações necessárias das capacidades do gerenciador de infraestrutura da borda.
Em uma EAP, os recursos podem ser programados conforme necessário. Novos recursos podem chegar ou sair dinamicamente devido à mobilidade. Uma EAP também pode enviar ou receber solicitações de outras EAPs para descobrir e programar recursos conforme necessário em seu nome.
Para reiterar a postura de segurança: a infraestrutura na qual a aplicação é implantada já está comprometida. Assim, a EAP deve garantir a segurança da aplicação implantada em 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). Eles podem ser mitigados usando as práticas recomendadas existentes na segurança como a prevenção de DDoS, aplicação de firewalls entre outras. A recomendação é que isso é necessário para todo o tráfego.
Man-in-the-Middle: todo o tráfego deve ser criptografado e não se pode presumir que a camada de aplicações fará a coisa certa. Isso garante a confidencialidade básica dos dados contra qualquer dispositivo 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 da infraestrutura deve ser restringido e, principalmente, direcionado para proteger a si mesmo. A recomendação é evitar que um recurso dentro da infraestrutura inicie um ataque interno no gerenciador da 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 pergunta é: estamos falando da experiência de quem? A experiência de qualquer entidade que resida ou use a infraestrutura para produzir ou consumir um serviço: aplicações, dispositivos, humanos, aplicações de back-end, bancos de dados e muito mais. Portanto, o ponto de vista experimental é o da entidade. Um serviço que uma entidade produz ou consome está diretamente relacionado aos recursos de computação, armazenamento e networking alocados para ela.
Mas ninguém pode apenas parar ao medir a experiência; deve haver uma maneira de remediar isso também.
Qualquer entidade que consuma ou forneça um serviço pode determinar se ela está recebendo a experiência solicitada. No entanto, em ambientes de nuvem distribuída, pode ser quase impossível explicar o que aconteceu na camada da infraestrutura que gerou uma experiência ruim.
Métricas de alto nível como medições de utilização de CPU, memória, largura de banda e latência não são suficientes para determinar porque uma aplicação não está recebendo a experiência solicitada3. As métricas precisam ser granulares em relação ao tempo e coletadas profundamente na pilha da aplicação e, sempre que possível, de diferentes camadas da pilha da infraestrutura.
Uma estratégia de dados e telemetria robusta, dimensionável e expansível é essencial para a EAP. As estratégias de Aprendizado de máquina (ML) e de inteligência artificial (IA) podem ser aproveitadas para tomar a melhor decisão sobre a reserva de novos recursos ou a otimização do uso dos existentes.
Conectividade de aplicação definida por software
Embora seja presumível que a conectividade e a acessibilidade sejam problemas resolvidos, muitas equipes de rede têm dificuldades em racionalizar sua malha de rede com as necessidades dinâmicas da camada de aplicações. Uma plataforma deve superar esses desafios também.
O problema com as abordagens existentes é que traduzimos as necessidades de conectividade da aplicação em conectividade de WAN da empresa, especialmente em uma nuvem distribuída. Abordagens para corrigir uma rede de nuvem distribuída podem usar diferentes estratégias de SDN ou métodos puramente baseados em roteamento. Mas essas soluções dependem muito da homogeneidade da infraestrutura e, consequentemente, falham em entregar 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 semelhança de estabilidade, mesmo com redes corporativas de conexão. Propomos que o plano de conectividade da aplicação deve ser separado da conectividade da rede corporativa. O padrão de conectividade da aplicação pode seguir ou não a mesma conectividade de SDN como visto na sobreposição de data centers (por exemplo, VXLAN, NVGRE ou outras), ou em padrões de SDN com base em BGP.
Nem todas as redes foram separadas entre sobreposta e subjacente. As equipes de rede estão vendo a necessidade dessa capacidade de programação conjunta como um requisito importante para permitir a automação de ponta a ponta, para a qual a separação da rede subjacente da sobreposta é essencial.
Separar o plano de aplicação do transporte e da rede subjacente elimina a necessidade de as equipes de rede responderem ativamente a cada solicitação da aplicação. Seu escopo se torna mais limitado a fornecer caminhos robustos, estáveis e bem definidos com um foco na otimização o uso de largura de banda agregada com menores latências.
Modelo de interface adaptada
O princípio fundamental de uma EAP é que ela seja independente, autônoma e gerencie um subconjunto do espaço geral da solução. Mas as EAPs precisam de uma maneira com a qual se comunicar e oferecer seus recursos ou solicitar recursos de outras EAPs. Há muitas vantagens nessa abordagem.
Uma interface baseada nos resultados elimina a necessidade de a EAP conhecer os detalhes sobre a outra infraestrutura. Suponha que haja duas EAPs: A e B. Cada EAP tem um escopo local de sua infraestrutura para programar e reservar recursos. A EAP-A não precisa conhecer os recursos fornecidos pela EAP-B. Se, por exemplo, a EAP-A não atender às necessidades da aplicação e solicitar recursos na infraestrutura que estejam no escopo da EAP-B, então, ela poderá simplesmente expressar seu objetivo desejado para a EAP-B. Então, será responsabilidade da EAP-B invocar interfaces declarativas ou imperativas para reservar, alocar e configurar de seu pool de recursos disponíveis. A EAP-B também é responsável por garantir que os SLOs para esse serviço em 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 foram simplificados em que apenas o estado desejado precisa ser especificado. Padrões de resiliência, por exemplo, podem meramente ser baseados em um SLO esperado. Será responsabilidade da 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. A EAP que realiza a chamada não precisa se importar, mas, provavelmente, precisaria monitorar as métricas de serviço para saber se estão sendo atendidas ou não.
Recursos de EAP
- Multilocatário: ao passo que a malha de EAPs exibida na Figura 9 seja para uma única implantação, diversas EAPs por nuvem também são possíveis. Outra aplicação poderia falar com uma EAP diferente ou com uma malha de EAPs.
- Projetada para escalonamento: cada malha é uma malha ponto a ponto (P2P) e pode ser escalonada horizontalmente. EAPs em pares podem acompanhar de maneira independente quais EAPs possuem qual tipo de recurso e como se conectar com o recurso. A IA e o ML aprimorarão ainda mais a maneira como cada EAP programa recursos dentro de seu próprio escopo e entra em contato com outras EAPs conforme necessário.
- Networking integrado: para aplicações se conectarem na nuvem distribuída, a EAP deve suportar o networking integrado independentemente da infraestrutura subjacente.
Juntando tudo
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:
- Cada EAP possui um escopo localizado e todas as suas capacidades não estão indicadas na Figura 10. A EAP deve suportar a função de descoberta e programação de recursos. As EAPs programam recursos ao realizar a interface com o controlador de infraestrutura adequado por meio de APIs adaptadas.
- A conectividade da aplicação não é a mesma que a conectividade da rede. Como no modelo secundário de malha de serviços, os recursos para conectar aplicações em multinuvem devem fazer parte da infraestrutura das aplicações. Algumas pessoas podem dizer que o plano da infraestrutura também fornece a conectividade de rede da aplicação e, portanto, deve estar abaixo da camada da rede. Isso também estaria tecnicamente certo, mas decidimos incorporá-lo dentro do plano da “conectividade da aplicação”, uma vez que essas são principalmente funções de rede.
- O plano da infraestrutura deve ser considerado separadamente do plano da aplicação.
- A conectividade de rede é diferente do transporte, uma vez que estamos falando essencialmente sobre redes roteáveis específicas que são separadas da conectividade da aplicação.
- O plano do transporte pode ser considerado como redes de backbone agregadas que podem ser provisionadas, desde que o provedor de telecomunicações permita que processos e APIs se conectem com a camada de rede acima.
Resumo
Esse white paper tenta detalhar mais algumas camadas do Edge 2.0 manifesto original. Apresentamos alguns novos temas, com o objetivo de informar diferentes partes interessadas nas organizações internas e, externamente, para o setor.
O Edge 2.0 é baseado na noção de uma rede distribuída em que cada entidade pode participar como a origem e o destino dos serviços. O tema principal é que o Edge 2.0 serpa sobre a experiência e não sobre o ativo ou o local.
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.
Recursos
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 conectados do Protocolo de Internet (IP) sob o controle de um ou mais operadores de rede em nome de uma única entidade ou domínio administrativos que apresente uma política de roteamento comum e claramente definida para a Internet.