BR112016029210B1 - Plataforma de interconexão para configuração e gerenciamento em tempo real de uma troca de serviços com base em nuvem - Google Patents

Abstract

PLATAFORMA DE INTERCONEXÃO PARA CONFIGURAÇÃO E GERENCIAMENTO EM TEMPO REAL DE UMA TROCA DE SERVIÇOS COM BASE EM NUVEM. Trata-se de uma troca de serviços com base em nuvem que compreende, em um exemplo, uma pluralidade de ativos de interconexão configurados para conectar um cliente da troca de serviços com base em nuvem a um ou mais provedores de serviço de nuvem, sendo que a pluralidade de ativos de interconexão inclui um circuito virtual por meio do que o cliente acessa um serviço de nuvem a partir do um ou mais provedores de serviço de nuvem; e um mecanismo de orquestração configurado para modificar a pluralidade de ativos de interconexão.

Description

[0001] Este pedido reivindica os benefícios do Pedido Provisório no U.S. 62/072.976, depositado em 30 de outubro de 2014; Pedido Provisório no U.S. 62/233.933, depositado em 28 de setembro de 2015; Pedido Provisório no U.S. 14/927.451, depositado em 29 de outubro de 2015, cujos conteúdos completos dos mesmos são incorporados ao presente documento a título de referência.

CAMPO DA TÉCNICA

[0002] A invenção refere-se a redes de computador e, mais especificamente, a uma plataforma que facilita interconectividade dentre clientes de serviço de nuvem e provedores de serviço de nuvem.

ANTECEDENTES

[0003] A computação em nuvem se refere ao uso de recursos de computação dinamicamente escalonáveis acessíveis por meio de uma rede, como a Internet. Os recursos de computação, em geral, referenciados como uma “nuvem”, fornecem um ou mais serviços para os usuários. Esses serviços podem ser categorizados de acordo com tipos de serviço, que podem incluir, por exemplo, aplicativos/software, plataformas, infraestrutura, virtualização e servidores e armazenamento de dados. Os nomes de tipos de serviço são, em geral, propensos à expressão “como Serviço” de modo que a entrega de aplicativos/software e infraestrutura, como exemplos, podem ser referenciados como Software como Serviço (SaaS) e Infraestrutura como Serviço (IaaS), respectivamente.

[0004] O termo “serviços com base em nuvem” ou, mais simplesmente, “serviços de nuvem” se refere não apenas a serviços fornecidos por uma nuvem, mas também a uma forma de provisionamento de serviço no qual os clientes de nuvem contratam provedores de serviço de nuvem para a entrega online de serviços fornecidos pela nuvem. Os provedores de serviço de nuvem gerenciam uma nuvem pública, privada ou híbrida para facilitar a entrega online de serviços de nuvem para um ou mais clientes de nuvem.

SUMÁRIO

[0005] Em geral, essa revelação descreve uma plataforma de interconexão para configurar e gerenciar dinamicamente uma troca de serviços com base em nuvem, ou “troca de nuvem,” para facilitar conexões virtuais para serviços de nuvem entrega de múltiplos provedores de serviço de nuvem para um ou mais clientes de nuvem. A troca de nuvem pode habilitar os clientes de nuvem para desviar a Internet pública para conectar diretamente para provedores de serviços de nuvem de modo a aprimorar desempenho, reduzir custos, aumentar a segurança e privacidade das conexões e impulsionar computação de nuvem para aplicações adicionais. Dessa maneira, aproveitamentos, portadoras de rede e clientes de SaaS, por exemplo, podem integrar serviços de nuvem com seus aplicativos internos como se tais serviços fossem parte de ou, de outro modo, acoplados diretamente a sua própria rede de centro de dados.

[0006] Em alguns exemplos, uma plataforma de interconexão para uma troca de nuvem expõe uma coleção de interfaces de software, também referenciada no presente documento como e descrita de acordo com interfaces de programação de aplicativo (APIs), que permite acesso às capacidades e ativos da plataforma de interconexão de um modo programável. Como tal, as interfaces de software fornecem um enquadramento extensível que permite que desenvolvedores de software associados a clientes e parceiros da troca para construir aplicativos de software que acessam a plataforma de interconexão que gerencia automaticamente interconexão com múltiplos provedores de serviço de nuvem que participam na plataforma de interconexão. Em outras palavras, desenvolvedores dos provedores de serviços de rede, provedores de serviço de nuvem, provedores de serviço gerenciado e outros aproveitamentos podem usar as interfaces de software expostas pela plataforma de interconexão e definidas pelas APIs para construir aplicativos personalizados e quadros para interação contínua com a plataforma de interconexão para facilitar a entrega de serviços de nuvem dos provedores de serviço de nuvem para os clientes de serviço de nuvem.

[0007] Essas interfaces de software definidas pelas APIs habilitam comunicação de máquina para máquina para configuração quase em tempo real e modificações de interconexões e também pode eliminar ou reduzir a necessidade por interação humana para toda a configuração de interconexão e processo de gerenciamento. Dessa maneira, as interfaces de software fornece, uma maneira automatizada e contínua para estabelecer, desinstalar e gerenciar interconexão com múltiplos provedores de nuvem que participam em uma plataforma de interconexão.

[0008] Em um exemplo, a plataforma de interconexão inclui um mecanismo de orquestração interno que organiza, direciona e integra software subjacente e subsistemas de rede para gerenciar diversos aspectos de interconexão para a troca de nuvem. O mecanismo de orquestração pode, por exemplo, fornecer um mecanismo de fluxo de trabalho acionado por regra que opera entre as APIs e a plataforma de interconexão subjacente da troca. Dessa maneira, o mecanismo de orquestração pode ser usado por aplicativos de propriedade do cliente e as APIs para participação direta dentro da plataforma de interconexão da troca de nuvem.

[0009] Conforme descrito no presente documento, o mecanismo de orquestração sintetiza as informações e ações para formular próximas etapas e respostas inteligentes para solicitações dinâmicas produzidas pelos aplicativos de cliente. Como tal, o mecanismo de orquestração abstrai a complexidade do software subjacente e subsistemas de rede da troca de nuvem fornecendo-se um meio uniforme, simplificado e seguro para acessar a plataforma de interconexão.

[0010] Em alguns exemplos, uma troca de serviços com base em nuvem compreende um centro de dados de rede que inclui respectivas portas pelas quais uma pluralidade de redes se conecta ao centro de dados de rede, em que cada uma das redes tem um espaço de endereço de rede diferente e associadas a uma diferente dentre uma pluralidade de clientes ou provedores de serviço de nuvem; uma pluralidade de ativos de interconexão dentro do centro de dados de rede e configurados para conectar, através de uma malha de comutação do centro de dados de rede, em que cada uma das redes é associada à pluralidade de clientes da troca de serviços com base em nuvem para uma ou mais das redes associadas aos provedores de serviço de nuvem, a pluralidade de ativos de interconexão que incluem um respectivo conjunto de um ou mais circuitos virtuais para cada uma das redes associadas à pluralidade de clientes e fornecer conectividade de rede dentro do centro de dados de rede entre as redes associadas à pluralidade de clientes e serviços de nuvem que são executados dentro das redes associadas à pluralidade de provedores de serviço de nuvem; e uma plataforma de interconexão executada em um ou mais dispositivos de gerenciamento dentro do centro de dados de rede e apresentar uma interface de software alcançável pelas redes associadas à pluralidade de clientes e configurada para, em resposta ao recebimento de uma solicitação emitida por um aplicativo executado dentro de qualquer uma das redes associadas ao cliente, acessar a pluralidade de ativos de interconexão para satisfazer a solicitação.

[0011] Em alguns exemplos, troca de serviços com base em nuvem compreende uma pluralidade de ativos de interconexão configurados para conectar um cliente da troca de serviços com base em nuvem a um ou mais provedores de serviço de nuvem, a pluralidade de ativos de interconexão que inclui um circuito virtual pelo qual o cliente acessa um serviço de nuvem do um ou mais provedores de serviço de nuvem; e um mecanismo de orquestração configurado para modificar a pluralidade de ativos de interconexão.

[0012] Em alguns exemplos, um método compreende executar, por uma troca de serviços com base em nuvem em um ou mais dispositivos de gerenciamento dentro de um centro de dados de rede, uma plataforma de interconexão para apresentar uma interface de software alcançável por redes associadas a uma pluralidade de clientes; e em resposta ao recebimento de uma solicitação emitida por um aplicativo executado dentro de qualquer uma das redes associadas ao cliente, acessar uma pluralidade de ativos de interconexão do centro de dados de rede para satisfazer a solicitação, em que o centro de dados de rede inclui respectivas portas pelas quais uma pluralidade de redes se conecta ao centro de dados de rede, em que cada uma das redes tem um espaço de endereço de rede diferente e associada a uma diferente dentre uma pluralidade de clientes ou provedores de serviço de nuvem, e em que uma pluralidade de ativos de interconexão dentro do centro de dados de rede conecta, através de uma malha de comutação do centro de dados de rede, cada uma das redes associadas à pluralidade de clientes da troca de serviços com base em nuvem para um ou mais das redes associadas aos provedores de serviço de nuvem, em que a pluralidade de ativos de interconexão inclui um respectivo conjunto de um ou mais circuitos virtuais para cada uma das redes associada à pluralidade de clientes e fornecer conectividade de rede dentro do centro de dados de rede entre as redes associadas à pluralidade de clientes e serviços de nuvem executados de dentro das redes associadas à pluralidade de provedores de serviço de nuvem.

[0013] Os detalhes de uma ou mais modalidades da invenção são apresentados nos desenhos anexos e a descrição abaixo. Outros recursos, objetivos e vantagens da invenção serão evidentes a partir da descrição e dos desenhos, e das reivindicações.

BREVE DESCRIÇÃO DOS DESENHOS

[0014] A Figura 1 A é um diagrama de blocos que ilustra uma vista de nível alto de um centro de dados que fornece um ambiente de operação para uma troca de serviços com base em nuvem.

[0015] A Figura 1B é um diagrama de blocos que ilustra troca de serviços com base em nuvem, de acordo com algumas implantações exemplificativas descritas no presente documento.

[0016] A Figura 1C ilustra outra implantação exemplificativa de uma troca de serviços com base em nuvem.

[0017] A Figura 1D é um diagrama de blocos que ilustra um exemplo no qual uma pluralidade de pontos de trocas de nuvem de uma troca de nuvem gerenciada por uma plataforma de interconexão, em conformidade com as técnicas dessa revelação, fornece disponibilidade de conexão cruzada entre portadoras geograficamente distribuídas.

[0018] A Figura 2 é um diagrama de blocos que ilustra detalhes de uma arquitetura exemplificativa para uma troca de nuvem de acordo com as técnicas descritas no presente documento.

[0019] As Figuras 3A a 3B representam um fluxograma for interconexão interfaces de software de acordo com as técnicas descritas no presente documento.

[0020] A Figura 4 é um diagrama de blocos que mostra uma representação alternativa de uma plataforma de interconexão 103 para uma troca em nuvem de acordo com técnicas descritas na presente revelação.

[0021] As Figuras 5 a 11 são fluxogramas, em que cada um ilustra um fluxo de chamada e operações realizadas por componentes exemplificativos de uma plataforma de interconexão para uma troca em nuvem, conforme descrito na presente revelação.

[0022] A Figura 12 é um diagrama de blocos que ilustra detalhes adicionais de um exemplo de um dispositivo de computação que opera de acordo com uma ou mais técnicas da presente revelação.

[0023] A Figura 13 é um diagrama de blocos que ilustra um sistema exemplificativo que mostra uma arquitetura lógica de um mecanismo de orquestração, em detalhes adicionais, de acordo com as técnicas descritas no presente documento.

[0024] A Figura 14 é um diagrama de blocos que ilustra um sistema exemplificativo que mostra arquitetura de referência de um mecanismo de orquestração, em detalhes adicionais, de acordo com técnicas descritas no presente documento.

[0025] A Figura 15 é um fluxograma que ilustra um fluxo de trabalho exemplificativo realizado por um mecanismo de orquestração de acordo com aspectos exemplificativos da presente revelação.

[0026] A Figura 16 é um diagrama lógico exemplificativo que ilustra um fluxo de trabalho de mecanismo de orquestração exemplificativo relacionado à criação de um circuito virtual de acordo com aspectos exemplificativos dessa revelação.

[0027] A Figura 17 é um diagrama lógico exemplificativo que ilustra um fluxo de trabalho de mecanismo de orquestração exemplificativo relacionado à obtenção de informações de pagamento de funcionários de acordo com aspectos exemplificativos dessa revelação.

[0028] As Figuras 18A a 18B são diagramas de blocos que ilustram infraestrutura de rede e provisionamento de serviço exemplificativos por uma plataforma de rede programável para uma troca de nuvem que agrega os serviços de nuvem de múltiplos provedores de serviço de nuvem para provisionamento para clientes do servidor de troca de nuvem e agrega acesso para múltiplos clientes para um ou mais provedores de serviço de nuvem, de acordo com técnicas descritas nessa revelação.

[0029] A Figura 19 é um diagrama de blocos que ilustra um exemplo de um ponto de troca de nuvem com base em centro de dados na qual roteadores do ponto de troca de nuvem são configurados por uma plataforma de interconexão com virtual roteamento de rede privada e encaminhar instâncias para rotear e encaminhar tráfego de serviço agregado das múltiplas redes de provedor de serviço de nuvem para uma rede de cliente, de acordo com técnicas descritas no presente documento.

[0030] A Figura 20 é um diagrama conceitual que ilustra uma vista lógica de um enquadramento de desenvolvimento de acordo com as técnicas descritas na presente revelação.

[0031] A Figura 21 é um diagrama de blocos que ilustra, mais detalhadamente, os componentes para um enquadramento de desenvolvimento que facilitam o scaffolding, a construção, o teste e a implantação de aplicações com base em microsserviço de acordo com as técnicas descritas na presente revelação.

[0032] A Figura 22 é um fluxograma que ilustra um processo de desenvolvimento exemplificativo para desenvolver aplicações de acordo com uma arquitetura de aplicação com base em microsserviço, com o uso do enquadramento de desenvolvimento e das técnicas descritas na presente revelação.

[0033] A Figura 23 é um diagrama conceitual que ilustra componentes de um projeto de enquadramento de desenvolvimento e um processo de scaffolding de extremidade a extremidade realizado pelo enquadramento de desenvolvimento e executado através das definições de orquestração e de microsserviço, de acordo com as técnicas descritas na presente revelação.

[0034] As Figuras 24 a 26 retratam interfaces e entrada/saída exemplificativas para um enquadramento de desenvolvimento, de acordo com as técnicas descritas no presente documento.

[0035] A Figura 27 é um diagrama de que retrata os componentes de uma plataforma de interconexão para uma troca de serviços com base em nuvem, desenvolvidos com o uso de um enquadramento de desenvolvimento de acordo com as técnicas descritas na presente revelação.

[0036] A Figura 28 é um diagrama de blocos que ilustra detalhes adicionais de um exemplo de um dispositivo de computação que opera de acordo com uma ou mais técnicas da presente revelação.

[0037] Os caracteres de referência similares denotam elementos similares por todas as Figuras e por todo o texto.

DESCRIÇÃO DETALHADA

[0038] Em geral, essa revelação descreve uma plataforma de interconexão para gerenciamento e configuração em tempo real de uma troca de serviços com base em nuvem (“troca de nuvem”). Conforme descrito no presente documento, a plataforma de interconexão fornece aos clientes da troca, por exemplo, aproveitamentos, portadoras de rede e clientes de SaaS, com conexões seguras, privadas, virtuais para múltiplos provedores de serviço de nuvem (CSPs) globalmente. Os múltiplos CSPs participam na troca de nuvem em virtude de terem pelo menos uma porta acessível na troca de nuvem pela qual um cliente pode se conectar ao um ou mais serviços de nuvem oferecidos pelos CSPs, respectivamente.

[0039] De acordo com diversos exemplos descritos no presente documento, uma troca de nuvem é descrita que permite que redes privadas de qualquer cliente sejam conectada de modo cruzado diretamente a qualquer outro cliente em um ponto comum permitindo, desse modo, tráfego de troca de rede direto entre as redes dos clientes. Os clientes podem incluir portadoras de rede (ou provedores de serviço de rede), aproveitamentos e outros usuários de serviços de nuvem oferecidos por um ou mais provedores de serviço de nuvem.

[0040] A Figura 1A é um diagrama de blocos que ilustra uma vista de nível alto de um centro de dados 101 que fornece um ambiente de operação para uma troca de serviços com base em nuvem 100. A troca de serviços com base em nuvem 100 (“troca de nuvem 100”) permite que uma rede correspondente de redes de cliente 104D, 104E e redes de portadora 104A a 104C (coletivamente, “redes privadas 104”) de quaisquer portadoras 106A a 106C (coletivamente, “portadoras 106”) ou outros clientes de nuvem que incluem clientes 107A, 107B a serem conectados de modo cruzado diretamente, por meio de uma conexão de camada virtual 2 (L2) ou camada 3 (L3) para qualquer outra rede de cliente e/ou para qualquer um dos provedores de serviço de nuvem 110A a 110N (coletivamente, “CSPs 110”) permitindo, desse modo, tráfego de troca de rede direto dentre as redes de cliente e CSPs 110.

[0041] As portadoras 106 podem, cada uma, representar um provedor de serviço de rede que é associado a uma rede de trânsito pela qual os assinantes de rede da portadora 106 podem acessar serviços de nuvem oferecidos por CSPs 110 por meio da troca de nuvem 100. Em geral, os clientes de CSPs 110 podem incluir portadoras de rede, aproveitamentos grandes, provedores de serviço gerenciado (MSPS), bem como clientes de Software como Serviço (SaaS), Plataforma-aaS (PaaS), Infraestrutura-aaS (IaaS), Virtualização-aaS (VaaS) e Armazenamento-aaS (dSaaS) de dados para tais serviços com base em nuvem conforme são oferecidos pelo CSPs 110 por meio da troca de nuvem 100.

[0042] Dessa maneira, troca de nuvem 100 agiliza e simplifica o processo de CSPs de parceria 110 e clientes (por meio de portadoras 106 ou diretamente) de uma maneira transparente e neutra. Uma aplicação exemplificativa de troca de nuvem 100 é um centro de dados de co-localização e interconexão no qual CSPs 110 e portadoras 106 e/ou clientes 107 já podem ter presença de rede, como tendo-se uma ou mais portas acessíveis disponíveis para interconexão dentro do centro de dados. Isso permite que as portadoras, clientes e CSPs participantes tenham uma ampla faixa de opções de interconectividade na mesma instalação. A troca de nuvem 100 de centro de dados 101 inclui infraestrutura de rede 122 que fornece uma de comutação L2/L3 malha através da qual CSPs 110 e clientes/portadoras se interconectam. Isso habilita uma portadora/cliente a terem opções para criar interconexões muitos para muitos com apenas um único tempo de conexão para a malha de comutador e plataforma de interconexão subjacente 103 de troca de nuvem 100. Em outras palavras, em vez de ter que estabelecer conexões separadas através de redes de trânsito para acessar provedores de serviço de nuvem diferentes ou serviços de nuvem diferentes de um ou mais provedores de serviço de nuvem, a troca de nuvem 100 permite que os clientes se interconectem aos múltiplos CSPs e serviços de nuvem com o uso de infraestrutura de rede 122 dentro do centro de dados 101.

[0043] Ao serem conectados a e utilizarem troca de nuvem 100, os clientes podem comprar serviços e alcançar muitos usuários finais em muitas áreas geográficas diferentes sem incorrer às mesmas despesas tipicamente associadas à instalação e manutenção de múltiplas conexões virtuais com múltiplos CSPs 110. Por exemplo, a portadora 106A pode expandir seus serviços com o uso de rede 104D de portadora 106D. Ao se conectar à troca de nuvem 100, uma portadora 106 pode ter capacidade para gerar rendimentos adicionais oferecendo-se a venda de sua serviços de rede para as outras portadoras. Por exemplo, a portadora 106D pode oferecer a oportunidade de usar a rede de portadora 104D para as outras portadoras.

[0044] Em algumas implantações exemplificativas descritas no presente documento, a troca de nuvem 100 inclui uma plataforma de interconexão 103 que expõe uma coleção de interfaces de software, também referenciada no presente documento como as interfaces de programação de aplicativo (APIs) 114 uma vez que as APIs 114 definem os métodos, campos e/ou outros software primitivos pelos quais os aplicativos podem recorrer à plataforma de interconexão 103. As interfaces de software permitem que as portadoras 106 e os clientes 107 acessem de modo programável capacidades e ativos da troca de nuvem 100.

[0045] Do lado do comprador, as interfaces de software apresentadas pela plataforma de interconexão subjacente fornecem um enquadramento extensível que permite que desenvolvedores de software associados aos clientes de troca de nuvem 100 criem aplicativos de software que permitem e impulsionam acesso à plataforma de interconexão pela qual os aplicativos podem solicitar que a troca de nuvem estabeleça conectividade para serviços de nuvem oferecidos por qualquer um dos CSPs 110. Por exemplo, essas interfaces de software de lado de comprador (ou “APIs de comprador” de APIs 114) podem permitir que aplicativos de cliente para NSPs e clientes corporativos, por exemplo, obtenham autorização para acessar a troca de nuvem, obtenham informações relacionadas a serviços de nuvem disponíveis, obtenham portas ativas e detalhes de área de metrô para o cliente, criar circuitos virtuais de largura de banda variada para acessar serviços de nuvem (incluindo seleção dinâmica de largura de banda com base em um serviço de nuvem comprado para criar circuitos virtuais com base em demanda e necessidade para provedores de serviço de nuvem), deletar circuitos virtuais, obter informações de circuito virtual ativo, obter detalhes que envolvem CSPs em parceria com o servidor de troca de nuvem, obter dados analíticos personalizados e validar acesso de parceria para ativos de interconexão.

[0046] No lado de provedor de nuvem (vendedor), as interfaces de software podem permitir que os desenvolvedores de software associados aos provedores de nuvem para gerenciar seus serviços de nuvem e para habilitar os clientes a se conectarem aos seus serviços de nuvem. Por exemplo, essas interfaces de software de lado de vendedor (ou “APIs de vendedor” de APIs 114) podem permitir que os aplicativos de provedor de nuvem obtenham autorização para acessar a troca de nuvem, obter informações relacionadas aos serviços de nuvem disponíveis, obter portas ativas e detalhes de área de metrô para o provedor, obter detalhes de porta ativa em um determinado centro de dados para o provedor, aprovar ou rejeitar circuitos virtuais de largura de banda variada para acessar serviços de nuvem criados por clientes, obter adição pendente de circuitos virtuais e confirmar adição de circuitos virtuais, obter exclusão pendente de circuitos virtuais e confirmar exclusão de circuitos virtuais, obter dados analíticos personalizados e validar acesso de parceria para ativos de interconexão.

[0047] Conforme adicionalmente descrito no presente documento, as APIs 114 facilitam comunicação máquina para máquina para habilitar provisionamento dinâmico de circuitos virtuais na troca de nuvem para cliente de interconexão e redes de provedor. Dessa maneira, a plataforma de interconexão 103 habilita a automação de aspectos de provisionamento de serviços de nuvem. Por exemplo, as interfaces de software podem fornecer uma maneira automatizada e contínua para clientes para estabelecer, desinstalação e gerenciar interconexão com múltiplos provedores de nuvem, diferentes que participam da troca de nuvem.

[0048] Em alguns exemplos, troca de nuvem 100 inclui uma porta de comunicação de API 112 que tem um ou mais processadores que executam um ou mais aplicativos que expõem interfaces de software definidas de acordo com APIs 114. Os aplicativos podem recorrer a serviços que correspondem a pontos de extremidade das APIs 114, e os próprios serviços podem recorrer ao serviço de plataforma de troca de nuvem de mecanismo de orquestração 118. A porta de comunicação de API 112 pode executar em um dispositivo de gerenciamento, como uma ou mais máquinas virtuais e/ou servidores reais de centro de dados 101. Embora mostrado como um elemento único na Figura 1A, a porta de comunicação de API 112 pode compreender um agrupamento de uma ou mais máquinas de computação físicas e/ou virtuais executadas em um ou mais processadores físicos.

[0049] Em alguns exemplos, troca de nuvem inclui um mecanismo de orquestração 118 que organiza, direciona e integra subsistemas de software subjacente 120 para gerenciar diversos aspectos de interconexão dentro da infraestrutura de rede 122, bem como gerenciamento de serviços de nuvem. O mecanismo de orquestração 118 pode, por exemplo, fornecer um mecanismo de fluxo de trabalho acionado por regra que opera entre as APIs 114 e a plataforma de interconexão subjacente de troca de nuvem 100 que inclui subsistemas 120 e infraestrutura de rede 122. Dessa maneira, o mecanismo de orquestração 118 pode ser usado por aplicativos de propriedade do cliente e as APIs 114 para participação direta com a plataforma de interconexão 103 da troca de nuvem 100. Em outras palavras, o mecanismo de orquestração 118 oferece um “serviço de plataforma de troca de nuvem” que tem diversos mecanismos ou fluxos de trabalho de aplicativo para atender às solicitações de serviço de porta de comunicação de API 112.

[0050] Os subsistemas 120 e o mecanismo de orquestração 118 podem, cada um, ser aplicativos centralizados ou distribuídos e podem ser executados em um dispositivo de gerenciamento, como uma ou mais máquinas virtuais e/ou servidores reais de centro de dados 101.

[0051] A infraestrutura de rede 122 representa a malha de comutação de troca de nuvem e inclui múltiplas portas que podem ser interconectadas de modo dinâmico com circuitos virtuais com o uso de APIs de invocação 114 de acordo com técnicas descritas no presente documento. Cada uma das portas é associada a um dentre as portadoras 106, clientes 107 e CSPs 110. Um circuito virtual pode se referir a, por exemplo, uma conexão de Ethernet, como uma VPN de Camada 2 ou LAN privada virtual (por exemplo, E-LINE, E-LAN, E-TREE, ou E-Acesso), uma interconexão com base em troca de Internet na qual respectivos roteadores de clientes interconectados emparelham e trocam diretamente rotas de camada 3 para tráfego de serviço trocado por meio da troca 100, e uma troca de nuvem na qual roteadores de cliente emparelham com roteadores de troca 100 (ou “provedor”) em vez de diretamente com outros clientes. Detalhes exemplificativos de uma troca de nuvem são fornecidos abaixo em relação às Figuras 18A, 18B e 19.

[0052] Para interconexões na camada-3 ou acima, clientes 107 e portadoras 106 podem receber serviços diretamente por meio de um emparelhamento de camada 3 e conexão física para troca 100 ou indiretamente por meio de uma das portadoras 106. As portadoras 106 fornecem “transito” mantendo-se uma presença física dentro de um ou mais de trocas e agregando acesso de camada 3 de um ou clientes 107. As portadoras 106 podem emparelhar, na camada 3, diretamente com uma ou mais trocas e, ao fazer isso, oferecem conectividade e emparelhamento de camada 3 indiretos para um ou mais clientes 107 através dos quais os clientes 107 podem obter serviços da troca 100.

[0053] A Figura 1B é a diagrama de blocos que ilustra troca de serviços com base em nuvem 100, de acordo com algumas implantações exemplificativas descritas no presente documento. Nessa arquitetura exemplificativa, a troca de nuvem 100 inclui múltiplos pontos de troca de nuvem 128A-128C (também descritos como “pontos de troca de nuvem” e coletivamente referenciados como “pontos de troca de nuvem 128”), que podem representar centros de dados geograficamente distribuídos dentro de uma área metropolitana e na qual a troca de nuvem 100 pode interconectar direta ou indiretamente (por meio de NSPs 106) provedores de serviços de nuvem 110 com clientes de nuvem 108 que acessam serviços de nuvem.

[0054] Os aplicativos 130 desenvolvidos e desenvolvidos por CSPs 110, NSPs 106, e clientes 108 recorrem às APIs 114 de plataforma de interconexão 103 to, por exemplo, controlam automaticamente provisionamento e gerenciam aspectos de troca de nuvem 100 para aspectos de interconexão com um ou mais provedores de nuvem/clientes, que incluem: (1) provisionamento de interconexões, (2) identificação e autorização de portadoras, (3) gerenciamento e cumprimento de ordem, (4) entrega de serviços de rede, (5) gerenciamento de inventário e capacidade, (6) gerenciamento e relato/alerta de incidentes e (7) gerenciamento de conteúdo.

[0055] Nesse exemplo, APIs 114 incluem pontos de extremidade 116A a 116K (coletivamente, “pontos de extremidade 116”) em que cada um representa um recurso exposto por plataforma de interconexão 103. Exemplos de pontos de extremidade são descritos abaixo em detalhes adicionais em relação à Figura 3A. Os aplicativos 130 podem interagir com a porta de comunicação de API 112 de acordo com modelo de cliente/servidor. Os aplicativos 130 podem enviar uma solicitação direcionada a qualquer um dos pontos de extremidade 116 de APIs 114. A porta de comunicação de API 112, em resposta às solicitações, recorre ao serviço de plataforma de troca de nuvem de mecanismo de orquestração 118, que pode orquestrar um fluxo de trabalho de tarefas de serviço para os subsistemas subjacentes 120 para satisfazer a solicitação. Em resposta à solicitação, por exemplo, mediante a completação do fluxo de trabalho, a porta de comunicação de API 112 pode enviar uma resposta ao aplicativo de solicitação 130 do ponto de extremidade 116 referido.

[0056] Em alguns exemplos, APIs 114 podem se conformar a um modelo de Transferência de Estado Representacional, isto é, ser uma interface RESTful, com pontos de extremidade 116 que representam métodos diferentes da interface RESTful. Os aplicativos 130 podem recorrer a qualquer um dos pontos de extremidade 116 com o uso de um protocolo de comunicação para transferir dados de aplicativo (por exemplo, HTTP) que especifica o método, um Identificador de Recuso Uniforme de recurso (URI) e, opcionalmente, parâmetros para o método. A porta de comunicação de API 112 traduz o URI de recurso e os parâmetros opcionais para construções relacionadas à plataforma de troca de nuvem e recorre à plataforma de troca de nuvem de mecanismo de orquestração 118 de acordo com uma dentre uma ação de criar, ler, atualizar e deletar (CRUD) ou de confirmação que corresponde ao ponto de extremidade 116 especificado pelos dados de aplicativo. Em linguagem de HTTP, a ação de criar corresponde ao método de POST, leitura para o método de GET e a confirmação para o método de PATCH, por exemplo.

[0057] Os subsistemas 120 podem aplicar as tarefas de serviço orquestradas pelo mecanismo de orquestração 118, que pode incluir modificar qualquer um dos pontos de troca de nuvem 128 para realizar a configuração sob demanda de circuitos virtuais entre CSPs 110 e clientes 108, por exemplo, ou de outro modo, gerenciar ativos de interconexão de pontos de troca de nuvem 128, como portas, metrôs, centros de dados, circuitos virtuais e largura de banda de circuito virtual, perfis e configuração.

[0058] A troca de nuvem 100 da Figura 1B ilustra uma troca de nuvem com base em metrô que fornece múltiplos pontos de troca de nuvem de acordo com técnicas descritas no presente documento. Cada um dos pontos de troca de serviços com base em nuvem 128A a 128C de troca de serviços com base em nuvem 100 pode representar um centro de dados diferente geograficamente localizado dentro da mesma área metropolitana (“com base em metrô”, por exemplo, na cidade de Nova Iorque, Nova Iorque; Vale do Silício, Califórnia; Seattle-Tacoma, Washington; Minneapolis-St. Paul, Minnesota; Londres, UK; etc.) para fornecer troca de serviços com base em nuvem resiliente e independente através da qual serviços com base em clientes de nuvem (“clientes de nuvem”) e provedores de serviço com base em nuvem (“provedores de nuvem”) se conectam para receber e fornecer, respectivamente, serviços de nuvem. Em diversos exemplos, a troca de nuvem 100 pode incluir mais ou menos pontos de troca de nuvem 128. Em alguns exemplos, uma troca de nuvem 100 inclui apenas um ponto de troca de nuvem 128. Conforme usado no presente documento, referência a uma “troca de nuvem” ou “troca de serviços com base em nuvem” pode se referir a um ponto de troca de nuvem. Um servidor de troca de nuvem pode implantar exemplos de trocas de nuvem 100 em múltiplas áreas metropolitanas diferentes, em que cada exemplo de troca de nuvem 100 tem um ou mais pontos de troca de nuvem 128.

[0059] Cada um dos pontos de troca de nuvem 128 inclui infraestrutura de rede e um ambiente de operação através do qual os clientes de nuvem 108A a 108D (coletivamente, “clientes de nuvem 108”) recebem serviços de nuvem de múltiplos provedores de serviço de nuvem 110A a 110N (coletivamente, “provedores de serviço de nuvem 110”). Os clientes de nuvem 108 podem receber serviços de nuvem diretamente por meio de um emparelhamento de camada 3 e conexão física para um dos pontos de troca de nuvem 128 ou indiretamente por meio de um dos provedores de serviço de rede 106A a 106B (coletivamente, “NSPs 106”, ou de modo alternativo, “portadoras 106”). NSPs 106 fornece “nuvem transito” mantendo-se uma presença física dentro de um ou mais de pontos de troca de nuvem 128 e agrega acesso de camada 3 de um ou mais clientes 108. NSPs 106 pode emparelhar, na camada 3, diretamente com um ou mais pontos de troca de nuvem 128 e, ao fazer isso, oferecer conectividade e emparelhamento de camada 3 indiretos para um ou mais clientes 108 através dos quais os clientes 108 podem obter serviços de nuvem da troca de nuvem 100. Cada um dos pontos de troca de nuvem 128, no exemplo da Figura 1B, pode ser destinado a um número de sistema autônomo diferente (ASN). Por exemplo, ponto de troca de nuvem 128 A pode ser designado por ASN 1, ponto de troca de nuvem 128B pode ser designado por ASN 2 e assim por diante. Cada ponto de troca de nuvem 128 é, desse modo, um próximo salto em um vetor de caminho que roteia caminho de protocolo (por exemplo, BGP) dos provedores de serviço de nuvem 110 para clientes 108. Como resultado, cada ponto de troca de nuvem 128 pode, independente de não ser uma rede de trânsito que tem um ou mais enlaces de rede de área ampla e políticas de acesso e trânsito de Internet concomitantes, emparelhamento com múltiplos sistemas autônomos diferentes por meio de BGP externo (eBGP) ou outro protocolo de roteamento de porta de comunicação exterior a fim de trocar, agregar e rotear tráfego de serviço de um ou mais provedores de serviço de nuvem 110 para clientes. Em outras palavras, os pontos de troca de nuvem 128 podem internalizar as relações de emparelhamento de eBGP que provedores de serviço de nuvem 110 e clientes 108 manteriam em uma base em pares. Em vez disso, um cliente 108 pode configurar uma única relação de emparelhamento de eBGP com um ponto de troca de nuvem 128 e receber, por meio da troca de nuvem, múltiplos serviços de nuvem de um ou mais provedores de serviço de nuvem 110. Embora descrito no presente documento principalmente em relação ao eBGP ou outro emparelhamento de protocolo de roteamento de camada 3 entre pontos de troca de nuvem e cliente, NSP, ou redes de provedor de serviço de nuvem, em que os pontos de troca de nuvem podem aprender rotas a partir dessas redes de outra maneira, como por configuração estática, ou por meio de Protocolo de Informações de Roteamento (RIP), Primeiro Caminho mais Curto Aberto (OSPF), Sistema Intermediário para Sistema Intermediário (IS-IS) ou outro protocolo de distribuição de rota.

[0060] Como exemplos dos citados acima, o cliente 108D é ilustrado como tendo contratado um servidor de troca de nuvem para troca de nuvem 100 para acessar diretamente serviços de nuvem de camada 3 por meio de pontos de troca de nuvem 128C, 128D. Dessa maneira, o cliente 108D recebe conectividade camada 3 redundante para serviço de provedor de nuvem 110A, por exemplo. O cliente 108C, ao contrário, é ilustrado como tendo contratado o provedor de troca em nuvem para troca em nuvem 100 para acessar diretamente a serviços de nuvem de camada 3 através do ponto de troca em nuvem 128C e também para ter contratado o NSP 106B para acessar os serviços de nuvem de camada 3 através de uma rede de trânsito do NSP 106B. O cliente 108B é ilustrado como tendo contratado múltiplos NSPs 106A, 106B para ter acesso de nuvem redundante aos pontos de troca em nuvem 128 A, 128B através das respectivas redes de trânsito dos NSPs 106A, 106B. Os contratos descritos acima são instanciados na infraestrutura de rede dos pontos de troca em nuvem 128 por configurações de emparelhamento L3 dentro de dispositivos de comutação de NSPs 106 e pontos de troca em nuvem 128 e conexões L3, por exemplo, circuitos virtuais de camada 3, estabelecidos dentro de pontos de troca em nuvem 128 para interconectar as redes de provedor de serviço de nuvem 110 às redes de NSPs 106 e redes de cliente 108, em que todas têm pelo menos uma porta que oferece conectividade dentro de um ou mais dos pontos de troca em nuvem 128.

[0061] Para os serviços de nuvem de camada 3, um circuito virtual pode representar uma caminho de camada 3 através de um malha de IP/MPLS de um ou mais dos pontos de troca em nuvem 128, entre um circuito de fixação que conecta uma rede de cliente ao ponto de troca em nuvem e um circuito de fixação que conecta uma rede de provedor de serviço de nuvem ao ponto de troca em nuvem. Cada circuito virtual pode incluir pelo menos um túnel (por exemplo, um túnel de LSP e/ou Encapsulação de Rota Genérica (GRE)) que tem pontos de extremidade na borda de provedor/contorno de sistema autônomo do ponto de troca em nuvem.

[0062] Os pontos de troca em nuvem 128 podem ser configurados para implantar múltiplos circuitos virtuais de camada 3 para interconectar as redes de cliente/NSP e as redes de provedor de serviço de nuvem com caminhos de IP de extremidade a extremidade. Cada um dos provedores de serviço de nuvem e clientes/NSPs pode ser um ponto de extremidade para múltiplos circuitos virtuais, com múltiplos circuitos virtuais que atravessam um ou mais pontos de troca em nuvem 128 para conectar os pontos de extremidade. Uma implantação exemplificativa de um ponto de troca em nuvem é descrita em mais detalhes abaixo em relação às Figuras 18A a 18B e 19.

[0063] A Figura 1C ilustra outra implantação exemplificativa de uma troca de serviços com base em nuvem. Nesse exemplo, a troca em nuvem 100 fornece circuitos de fixação de alta velocidade 208, 213, 218 e 223 e roteamento e a infraestrutura de comutação para provisionamento direto, circuitos virtuais 150, 155, 160, 165, 170, coletivamente referidos como uma plataforma de interconexão, para redes portadoras de conexão cruzada 205, 210, 215 e 220.

[0064] Conforme mostrado no exemplo da Figura IB, troca em nuvem 100 expõe uma coleta de interfaces de software 114, também referida no presente documento como interfaces de programação de aplicativo (APIs), que permite o acesso programático de sistemas de cliente 196 às capacidades e ativos da plataforma de interconexão 103 de troca em nuvem 100. Ou seja, as interfaces de software 114 fornecem um enquadramento extensível que permite que os desenvolvedores de software associados aos clientes de troca em nuvem 100 criem aplicativos de software executáveis nos sistemas de cliente 196 que permitem e impulsionam os subsistemas de aceso 120 de troca 100. Os subsistemas subjacentes 120 de troca 100 podem, por exemplo, controlar o provisionamento e gerenciamento de todos os aspectos de troca 100, incluindo: (1) provisionamento de interconexões entre sistema de cliente 196, (2) identificação e autorização de portadoras, (3) gerenciamento e cumprimento de ordens, (4) entrega de serviços de rede, (5) gerenciamento de inventário e capacidade, (6) gerenciamento e relato/alerta de incidentes e (7) gerenciamento de conteúdo.

[0065] Desse modo, as portadoras 106 e outros clientes de troca em nuvem 100, tais como provedores de serviços de rede, provedores de serviços de nuvem, provedores de serviços gerenciados e outras empresas podem utilizar as interfaces de software expostas pela plataforma de interconexão para gerenciar suas conexões cruzadas diretas com outras portadoras. Ou seja, as interfaces de software 114 permitem a comunicação máquina a máquina, mostrada como setas pontilhadas na Figura 1C, entre a infraestrutura de rede e provisionamento/ cobrança / contabilização / sistemas AAA posicionados dentro de diferentes redes de portadora 205, 210, 215 e 220 para portadoras 106 que estabelecem e gerenciam as conexões cruzadas diretas. Desse modo, as interfaces de software 114 permitem uma configuração quase em tempo real e modificações de interconexões, por exemplo, circuitos virtuais da Figura 1C, e podem também eliminar ou reduzir a necessidade de interação humana para a configuração de interconexão inteira e processo de gerenciamento. Dessa maneira, as interfaces de software fornecem um maneira automatizada e contínua para portadoras 106 para estabelecer, desinstalar e gerenciar a interconexão com múltiplos clientes diferentes que participam de uma plataforma de interconexão 103.

[0066] Ademais, conforme adicionalmente mostrado no exemplo da Figura IB, a troca em nuvem 100 inclui um mecanismo de orquestração interno 118 que organiza, direciona e integra os subsistemas de software e rede subjacentes 120 para o gerenciamento de vários aspectos dos serviços de interconexão fornecidos por troca em nuvem 100. O mecanismo de orquestração 118 pode, por exemplo, fornecer um mecanismo de fluxo de trabalho acionado por regra que opera entre APIs 114 e a plataforma de interconexão subjacente fornecida por subsistemas 120 de troca em nuvem 100. Dessa maneira, o mecanismo de orquestração 118 pode ser invocado por aplicativos de proprietário de cliente que executam sistemas de cliente 196 por meio de APIs 190 para participação direta dentro da plataforma de interconexão da troca em nuvem.

[0067] Conforme descrito no presente documento, o mecanismo de orquestração 118 sintetiza as informações e ações dos subsistemas subjacentes 120 da plataforma de interconexão para formular as etapas seguintes inteligentes e respostas para os aplicativos de cliente. Desse modo, o mecanismo de orquestração 118 abstrai a complexidade dos subsistemas de software e rede subjacentes 120 da troca em nuvem 100 fornecendo-se um meio uniforme, simplificado e seguro para acessar a plataforma de interconexão.

[0068] A Figura 1D é um diagrama de blocos que ilustra um exemplo no qual uma pluralidade de pontos de trocas de nuvem 100 de uma troca de nuvem gerenciada por uma plataforma de interconexão, em conformidade com as técnicas dessa revelação, fornece disponibilidade de conexão cruzada entre portadoras geograficamente distribuídas. Embora não mostrado, cada um dos pontos de troca em nuvem pode implantar as técnicas exemplificativas descritas em relação às trocas em nuvem 100 das Figuras 1A a 1C que incluem pontos de troca em nuvem 128 da Figura 1B

[0069] A Figura 2 é um diagrama de blocos que ilustra detalhes de uma arquitetura exemplificativa para uma troca de nuvem de acordo com as técnicas descritas no presente documento. Conforme mostrado nesse exemplo, a troca em nuvem exemplificativa 100 ilustra APIs 114, mecanismo de orquestração interno 118, e subsistemas 120 em mais detalhes.

[0070] A comunidade de desenvolvedor 300 ilustra entidades que podem desenvolver aplicativos que usam APIs 114 para acessar a plataforma de interconexão da troca em nuvem 100. Essas entidades incluem provedores de serviço de rede 300A, provedores de serviços gerenciados 300B, empresas 300C, provedores de serviço de nuvem 300D, desenvolvedores de terceiros 300E, e outros 300F. Os aplicativos desenvolvidos por essas entidades utilizam troca em nuvem 100 como uma plataforma de interconexão para interconectar clientes aos serviços de nuvem oferecidos pelos provedores de serviços de nuvem de acordo com as políticas e perfis das várias entidades.

[0071] Nesse exemplo, APIs 114 inclui agrupamentos dos vários métodos de API ou pontos de extremidade de acordo com a função. APIs de desenvolvedor 304 A podem ser úteis para realizar a disponibilidade de descoberta de local, descoberta de ativos, e descoberta de serviço de nuvem. As informações descobertas podem incluir áreas metropolitanas disponíveis, centros de dados, portas, serviços, circuitos virtuais, e outros ativos de interconexão pelos quais um cliente pode obter ou gerenciar serviços de nuvem. APIs de transação 304B podem ser úteis para a provisão de modo dinâmico extremidade a extremidade circuitos virtuais de larguras de banda variáveis através de interação entre máquinas, validar circuitos virtuais solicitados por um cliente, e confirmar a exclusão de circuitos virtuais, por exemplo. O uso de APIs 304C pode ser útil para permitir que provedores e clientes obtenham dinamicamente informações de recomendação conforme realizado por um mecanismo de recomendação de troca em nuvem 100, obtenham análise personalizada em relação à presença de competidor, presença/disponibilidade de serviço de nuvem, e presença/disponibilidade de cliente, obtenham estatísticas de uso, e gerem conteúdo, por exemplo. APIs de suporte 304D podem ser úteis pelos clientes ou provedores para gerenciar contas, realizar cobrança/faturamento automatizado, validar crédito, e configurar perfil e informações de configuração para a entidade, por exemplo.

[0072] Nesse exemplo, o mecanismo de orquestração 118 (ilustrado como “mecanismo de orquestração de interconexão 118”) organiza, direciona, e integra os subsistemas de software e subjacentes de rede 120 para o gerenciamento de vários aspectos de interconexão. Por exemplo, o mecanismo de orquestração 118 pode lidar com o ciclo de cotação em dinheiro total para o provisionamento de ativos de interconexão pela comunicação com subsistemas de capacitação de interconexão de miríade 120, tais como Sistemas Gerenciamento de Perfil e Conta de Cliente, Sistemas de Gerenciamento de Ativos de Cliente, Sistemas de Gerenciamento de Inventário, Sistemas de Gerenciamento de Capacidade, Sistema de Rede, Sistemas de Gerenciamento de Crédito, Sistemas de Gerenciamento de Conteúdo, e Sistemas de Gerenciamento de Tíquetes com Problemas (nem todos mostrados na Figura 2). Para isso, o mecanismo de orquestração 118 inclui um fluxo de trabalho e mecanismo de regras 306 que opera de modo responsivo de acordo com as políticas de troca configuradas 308A, perfis 308B, e configurações 308C para sintetizar informações e ações dos subsistemas 120 para formular etapas seguintes inteligentes e respostas para solicitações recebidas através de APIs 114. O componente de microsserviços 308D para a componentização de muitos, e em alguns casos, todos, os serviços de interconexão para aprimorar dimensionabilidade horizontal, eficiência de desempenho, e atualizações e aprimoramentos de recurso de tempo ocioso baixo a zero. Dessa maneira, o mecanismo de orquestração 118 pode abstrair a complexidade de software e subsistemas subjacentes 120 pelo fornecimento de um meio seguro, simplificado e uniforme para acessar a plataforma de interconexão para o acesso e o gerenciamento de ativos de interconexão.

[0073] Os subsistemas 120 orquestrados pelo mecanismo de orquestração 118 no exemplo da Figura 2 incluem a identificação (ID) e sistema de gerenciamento de acesso 31 OA. Em alguns exemplos, o sistema de gerenciamento de ID e acesso 31 OA incluem um Armazenamento de Dados de Permissão (PDS) para alojar o cliente, ativos e hierarquia de permissão. O sistema de gerenciamento de ID e acesso 31 OA pode realizar a federação com o uso de um sistema de terceiro que gera asserções de Linguagem de Marcada de Asserção de Segurança (SAML) e tem também capacidade para fornecer capacidade Single Sign-On (SSO).

[0074] O mecanismo de orquestração 118 pode orquestrar múltiplos sistemas de gerenciamento de ordem 310B (por exemplo, para diferentes regiões tais como Ásia Pacífico, Europa, Médio Oriente e África e América do Norte). O mecanismo de orquestração 118 passa as informações de criação de ordem virtual de circuito relevante para esses sistemas de gerenciamento de ordem 310B de modo que os parceiros possam ser cobrados. O mecanismo de orquestração 118 pode abstrair a complexidade dos sistemas de rede subjacentes pela integração de modo contínuo com o sistema de serviços de rede 3 IOC para interagir com os sistemas de rede subjacentes. O mecanismo de orquestração 118 pode impulsionar um sistema de gerenciamento de capacidade e inventário de ativos 310D em conjunto com o armazenamento de dados de permissão para obter as informações sobre o inventário de portas de cliente. O mecanismo de orquestração 118 pode impulsionar essas informações para colocar as solicitações de circuito virtual contra as portas apropriadas. O sistema de gerenciamento de capacidade e inventário de ativos 310D pode ser usado para avaliar a largura de banda disponível em cada porta antes do provisionamento dos circuitos virtuais.

[0075] O mecanismo de orquestração 118 aceita as solicitações de incidente dos parceiros e clientes e se comunica com o sistema de gerenciamento de incidente subjacente 310E para aumentar os tíquetes de serviço. O mecanismo de orquestração 118 se comunica com o sistema de gerenciamento de conteúdo 31 OF para, por exemplo, produzir conteúdo localizado e internacionalizado para um cliente com base na preferência de linguagem do cliente. O sistema de gerenciamento de conteúdo 310F ajuda na translação transparente de todos os rótulos, mensagens de erro, mensagens de sucesso e respostas exibidas na portal da web, dispositivos móveis ou em comunicação máquina a máquina através de APIs 114.

[0076] As Figuras 3A a 3B representam um fluxograma for interconexão interfaces de software de acordo com as técnicas descritas no presente documento. Nesse exemplo, a porta de comunicação de API 403 expõe um API 114 que tem múltiplos pontos de extremidade 406A-406L (coletivamente, “pontos de extremidade 406”) pelos quais os clientes de API 402 podem gerenciar as interconexões de troca em nuvem. A porta de comunicação de API 403, por sua vez, invoca a plataforma de serviço de nuvem de mecanismo de orquestração 407, que orquestra um fluxo de trabalho de tarefas de serviço representadas nas Figuras 3A a 3B pelos serviços de API de troca em nuvem 409. A porta de comunicação de API 403 pode representar uma instância exemplificativa de porta de comunicação de API 112 das Figuras 1A a 1D, o mecanismo de orquestração 407 pode representar uma instância exemplificativa de orquestração de porta de comunicação 118 das Figuras 1A a 1D, e subsistemas 120 das Figuras 1 a 2 podem oferecem serviços de API de troca em nuvem 409.

[0077] Os clientes de API 402 podem incluir aplicativos de comprador 402A e aplicativos de vendedor 402B, bem como desenvolvedores de API 402C que podem desenvolver tais aplicativos. A porta de comunicação de API 403 inclui diversos adaptadores de cliente 404 que facilitam as operações de porta de comunicação de API 403. Os adaptadores de cliente 404 incluem segurança 404 A, verificação de chave de API 404B, transformação 404C, memorização 404D, proteção contra ameaças 404E, detecção de ponto 404F, análises personalizadas 404G, e chamadas de HTTP 404H.

[0078] Os pontos de extremidade 406 representam recursos físicos e/ou lógicos disponíveis acessíveis para os clientes de API 402. Ou seja, os clientes de API 406 podem acessar os pontos de extremidade 406 para acessar a plataforma de interconexão de uma troca em nuvem para obter informações sobre, criar, modificar, deletar, e/ou confirmar as solicitações para os recursos correspondentes da troca em nuvem. Os pontos de extremidade 406 podem representar instâncias exemplificativas de pontos de extremidade 116 das Figuras 1B a 1C.

[0079] Nesse exemplo, os pontos de extremidade 406 incluem logon 406A, portas 406B, metrôs 406C, ativos 406D, circuitos virtuais 406E, serviços de nuvem 406F, perfis de serviço 406G, analíticas 406H, estatísticas de tráfego 4061, largura de bandas 406J, tíquetes de serviço 406K, e recomendações 406L. Em geral, os clientes de API 406 podem invocar qualquer ponto de extremidade 406 com o uso de um método correspondente e, em alguns casos, os parâmetros que determinam como a plataforma de interconexão executa o método.

[0080] Os pontos de extremidade 406 podem representar diferentes métodos de uma interface de REPOUSO. Os clientes de API 402 podem invocar qualquer ponto de extremidade 406 com o uso de um protocolo de comunicação para transferir os dados de aplicação (por exemplo HTTP) que especificam o método, um URI de recurso e, opcionalmente, os parâmetros para o método. A porta de comunicação de API 403 traduz o URI de recurso e os parâmetros opcionais para o ponto de extremidade 406 para construções relacionadas à plataforma de troca de nuvem e recorre à plataforma de troca de nuvem de mecanismo de orquestração 407 de acordo com uma dentre uma ação de criar, ler, atualizar, deletar ou de confirmação que corresponde ao ponto de extremidade 406 especificado pelos dados de aplicativo.

APIs - EXEMPLOS

[0081] As seções a seguir contêm os detalhes exemplificativos para os pontos de extremidade selecionados 406 de APIs 114 para uma troca em nuvem 100. O API 114 fornece funcionalidade para permitir que os desenvolvedores acessem a plataforma de interconexão para ordenar e visualizar os circuitos virtuais. Essa funcionalidade de API inclui obter informações sobre e realizar operações no Logon 406A, Portas 406B, Circuitos Virtuais 406E, Metrôs 406C, e Serviços em Nuvem 406F.

[0082] Em um exemplo, os pontos de extremidade 406 de APIs 114 podem ser categorizados em três categorias principais:

[0083] • APIs Fundamentais - esses APIs são comuns tanto para o comprador quanto para o vendedor.

[0084] • APIs de Comprador - Esses são os APIs que são usados pelas Empresas, Provedores de Serviço de Rede (NSP) e Provedores de Serviço Gerenciado (MSP) para estabelecer a conectividade para os serviços de nuvem oferecidos pelos diferentes Provedores de Serviço de Nuvem (CSPs).

[0085] • APIs de Vendedor - Esses APIs são usados pelos CSPs para gerenciar seus serviços de nuvem em troca em nuvem 100 e para permitir que os compradores se conectem a seus serviços.

[0086] Os APIs são amplamente categorizados em operações que podem ser realizadas em diferentes recursos. Essa seção também detalha os cabeçalhos de solicitação comum que são solicitados como estando incluídos como parte de cada solicitação e também os cabeçalhos de resposta que são devolvidos com cada resposta de API. Além disso, essa seção descreve a situação de HTTP e códigos de erro personalizados usados como parte da resposta de API no caso de qualquer condição de erro.

[0087] As tabelas abaixo mostram uma visão geral dos recursos de API, seus respectivos URIs, e operações suportadas em cada recurso. Os APIs são divididos em três seções principais: Comprador, Vendedor, e APIs Fundamentais. A referência no presente documento a XML se refere à Linguagem Marcada extensível, enquanto JSON se refere a Notação de Objeto JavaScript. VISÃO GERAL DE API FUNDAMENTAL

VISÃO GERAL DE API DE COMPRADOR

VISÃO GERAL DE API DE VENDEDOR

CÓDIGOS DE SITUAÇÃO DE HTTP

[0088] A tabela abaixo lista os códigos de situação de HTTP exemplificativos que podem ser utilizados pelos APIs 114. HÁ as mensagens e os códigos de erro específicos que são devolvidos em cenários de erro que são definidos juntamente com o relatório descritivo de API apropriado.

CABEÇALHOS DE SOLICITAÇÃO COMUM

[0089] Os cabeçalhos a seguir são solicitados em solicitações para todos os APIs.

CABEÇALHOS DE RESPOSTA COMUM

[0090] O cabeçalho a seguir está incluído como parte de todas as respostas de API

SINTASE DE RESPOSTA DE ERRO

[0091] As respostas de erro de todos os APIs seguem a síntese comum mostrada abaixo. { '’errors1': [ { "status": "string", "code": "string", "property": "string", "message": "string", "morernfo": "string" } ]} CAMPOS DE MENSAGEM DE RESPOSTA DE ERRO Erros

situação

Código

propriedade

mensagem

mais informações

Sample Error Response: Content-Type: application/]son { "errors’1: [ { "code": 40007, "message": "Invalid Field Value", "more info'1: "The field value port name already exists for the specified profile name", "property": "port name", "status": 400 } } }

[0092] Em alguns exemplos, espera-se que os desenvolvedores gerem Chave de cliente de API e Segredo do Cliente com o uso de uma plataforma de desenvolvedor antes de invocar os APIs.

AUTENTICAÇÃO

[0093] O desenvolvedor adquire um Token de Acesso através de uma senha válida antes de invocar quaisquer APIs 114. Refere-se à seção que descreve a senha 406A para detalhes.

APIs FUNDAMENTAIS

[0094] Recurso: Token de Acesso ou Senha 406 A.

[0095] Descrição OAuth de Token 2.0 para o acesso de APIs 114.

POSTAR TOKEN DE ACESSO

[0096] Descrição Esse API lida com a autenticação e autorização do desenvolvedor de API. Mediante a autenticação bem sucedida, um Token de Acesso é retornado como parte da resposta. Uma mensagem de erro é retornada em tentativas mal sucedidas. Solicitação URI de Solicitação: POSTAR http://<HostName>/ecx/vl/oauth/token Parâmetros de Filtro: Nenhum Cabeçalhos de Solicitação: Nenhum Campos de Solicitação: grant_ype

username

user_password

client_id

password_encoding

Solicitações de Amostra POSTAR http://<HostName>/ecx/v2/oauth/token Senha como texto simples: { “grant_type“: “client_credentials“, “nome de usuário”: “tempuserl”, “user_password”: “xxxxxxx”, “client id”: “QWERTY 1234567abcdefg”, “client_secret”: “tstCLNT 123 scrt” } Senha criptada com md5 e então b64: { “grant_type”:”senha”, “user_name”: “tempuserl”, “user_password”: “xxxxxxxxxxxx”, “client id”: “QWERTY 1234567abcdefg”, “client_secret”: “tstCLNT_123_scrt” , “password_encoding”: md5-b64 } Resposta: Campos de Resposta: access_token

token_timeout

user_name

token_type

refresh_token

refresh_token_timeout

Resposta de Amostra: HTTP/1.1 200 OK API-Version: vl Content-Type: application/json Accept: application/json { “Token de Acesso”: “HihiOtaY2JAT0QaTFaYYyzHOqqmb”, “token timeout”: “3599”, “user_name”: “tempuserl”, “token_type”: “Bearer”, “refresh_token”: “QvJdZg7nMSTNYBfeDLgECpe5b9FvgWgdpZRwv4u0nZ”, “refresh_token_timeout”: 86376. } Código de Erro em Resposta:

[0097] POSTAR Token de Restauração: Descrição Esse API permite que o desenvolvedor restaure OAuth de Token existente emitido que expirará de outro modo dentro de 60 minutos. Um token de restauração válido é necessário para recuperar um novo Token de Acesso de autenticação bem sucedida que será retornado como parte da resposta. Solicitação URI de Solicitação: POSTAR http://<HostName>/OAuth 2.0/vl/refreshaccesstoken Parâmetros de Filtro: Nenhum Cabeçalhos de Solicitação: Nenhum Campos de Solicitação: grant_type

client_id

refresh_token

Solicitações de Amostra POSTAR http://<HostName>/OAuth 2.0/yl/refreshaccesstoken Token de restauração { “grant_type”:”refresh_token”, “client_id”: “QWERTY1234567abcdefg”, “client_secret”: “tstCLNT_123_scrt” , “refreshjoken”: “5f752714hsdf07a3e41 c2a3311 £514e 1 “ } Resposta: Campos de Resposta: access_token

token_timeout

user_name

token_type

refresh_token

refresh_token_timeout Recurso: Metrôs Descrição Metrôs em que os serviços de Troca em Nuvem são oferecidos.

OBTER Metrôs:

[0098] Descrição Essa implantação da operação de OBTER retorna uma lista de todos os metrôs em que o usuário teve portas ou troca em nuvem é permitida. Solicitação URI de Solicitação: OBTER http://<HostName>/ecx/vl /metrôs Parâmetros de Filtro: cloud_exchange_enabled

Cabeçalhos de Solicitação:

Solicitação de Amostra OBTER ttp://<HostName>/ecx/vl/metrôs?cloud_exchange_enable=true Resposta: Campos de Resposta: metros

Nome

Código

Resposta de Amostra: Tipo de Conteúdo: application/json { “metrôs”: [ { “código”: “SV”, “nome”: “Vale do Silício”, }, { “código”: “SG”, “nome”: “Singapura” }]} Código de Erro em Resposta:

Recurso: Serviços em Nuvem Descrição Serviços em Nuvem em troca em nuvem 100

OBTER Serviços em Nuvem

[0099] Descrição Essa implantação da operação de OBTER retorna uma lista de todos os Serviços em Nuvem em troca de serviço de nuvem 100. Solicitação URI de Solicitação: OBTER http://<HostName>/ecx/vl/cloudservices, OBTER http://<HostName>/ecx/vl/cloudservices/{cloud_service_name} Parâmetros de Filtro: Nenhum Cabeçalhos de Solicitação:

Solicitação de Amostra OBTER http://<HostName>/ecx/vl/cloudservices Resposta: Campos de Resposta: cloud_services

Nome

metrôs

Nome

Código

ibxs

Resposta de Amostra: HTTP/1.1 200 OK Content-Type: application/j { “cloud_services”: [ { “nome”: “CSP1”, “metrôs”: [ { “código”: “SG”, “nome”: “Singapura” “ibxs”: [ “SV1”, “SV2” ]}]}]} Código de Erro em Resposta:

APIs de COMPRADOR

[0100] Nessa seção, descreveu-se os APIs que são relevantes para um comprador.

RECURSO: PORTAS

[0101] Descrição Portas na Malha de Comutação de Troca em Nuvem

OBTER PORTAS:

[0102] Descrição Essa implantação da operação de OBTER retorna uma lista de todas as portas de propriedade do emissor autenticado da solicitação. As portas podem ser filtradas por metrô e Nome de IBX. Se nenhuma porta que corresponde aos critérios for encontrada, então uma resposta de código de 204 HTTP é retornada sem uma carga. Solicitação URI de Solicitação: OBTER http://<HostName>/ecx/vl/portas?metro_code=SV&ibx_name=SVl Parâmetros de Filtro: metro_code

ibx_name

Largura de banda

encapsulação

is_buyout

Cabeçalhos de Solicitação:

Solicitação de Amostra OBTER http://<HostName>/ecx/v1/portas?metro_code=S V&ibx=S V 1 OBTER http://<HostName>/ecx/v1/portas?largura de banda= 100 OBTER http://<HostName>/ecx/vl/portas?encapsulação=DotlQ OBTER http://<HostName>/ecx/v1/portas?is_buyout=Y Resposta Campos de Resposta: portas

Nome

metro_code

metro_name

ibx_name

Larguras de banda

encapsulação

is_buyout

cross_connect_ids

RESPOSTA DE AMOSTRA 1: HTTP/1.1 200 OK Tipo de ConteúdoType: application/json { “portas”: [ { “nome”: “GSE QA-R-EE-02”, “metro_code”: “SV”, “metro_name”: “Silicon Valley”, “ibx_name”: “SV1” }, { “nome”: “GSE Q A-R-EE-01 “, “metro_code”: “SG”, “metro_name”: “Singapura”, “ibx_name”: “SGI” }]} RESPOSTA DE AMOSTRA 2: HTTP/1.1 200 OK Content-Type: application/json {“portas”:[ {“largura de banda”:” 10 G”, “larguras de banda”:[ “10 G”, “10 G”], “conexão cruzada ids”: [ 123456. “100000”,], “encapsulação”:”Qinq”, “ibx_name”:”SV3”, “is_buyout”:”N”, “metro_code”:”SV”, “metro_name”:”BAYM”, “nome”: “QinqVirtualPort” } Código de Erro em Resposta:

Recurso: Serviços de Vendedor Descrição Serviços de Vendedor na Troca em Nuvem URI de Solicitação de Método de HTTP OBTER /ecx/vl/sellerservices /ecx/v1/sellerservices/{seller_service_name} OBTER Serviços de Vendedor Descrição Essa implantação da operação de OBTER retorna uma lista de todos os Serviços de Vendedor na Troca em Nuvem. Solicitação URI de Solicitação: OBTER http://<HostName>/ecx/v1/sellerservices, OBTER http://<HostName>/ecx/yl/sellerservices/(seller_service_nam e|

[0103] Parâmetros de Filtro: Filtrar os resultados pelo metrô. Se esse parâmetro não estiver incluído, a resposta contém todos os serviços de vendedor na Troca em Nuvem Solicitação de Amostra OBTER http://<HostName>/ecx/yl/sellerservices/(seller_service_nam e} http://<HostName>/ecx/v1/sellerservices?metro_cod e=SV Resposta: Campos de Resposta: seller_services Uma lista de um Descrição Vendedor Tipo Lista Solicitado Sim Padrão Nenhum Exemplo Nenhum allow_custom_speed Descrição O comprador pode ver todos os serviços de vendedor em um determinado metrô que permite as velocidades personalizadas se o comprador tiver uma porta de aquisição. Os valores que a resposta incluirá podem ser ‘Y’ ou ‘N’. Tipo Coluna Solicitado Sim Padrão Exemplo Y ou N situação de disponibilidade: A situação de disponibilidade do perfil de serviço como "em Testagem de teste" ou Disponível para ordens. encapsulação Descrição Encapsulação de porta Tipo Coluna Padrão Nenhum Exemplo dotlq ou qinq Solicitado Sim exigem redundância Descrição Isso definirá se uma criação de circuito virtual secundária é exigida quando o comprador solicitar um circuito virtual a partir desse provedor de serviço de vendedor. Se sim, o comprador terá que fornecer primário e secundário, tanto a porta secundária quanto os VLAN IDs. Os valores aceitáveis são Y e N. Tipo Coluna Solicitado Sim Padrão Nenhum Exemplo VERDADEIRO

[0104] Velocidades padrão: As velocidades padrão permitidas associadas ao perfil de serviço quando a velocidade padronizada não é permitida pelo vendedor.

NOME DE SERVIÇO DE VENDEDOR

[0105] metrôs: Uma lista de Metrôs servida pelo vendedor. Nome de metrô. Código de metrô. Uma lista de nomes de IBX no metrô. Resposta de Amostra: HTTP/1.1 200 OK Content-Type: application/json “seller_services”: [ “allow_custom_speed”: “N”, “encapsulação”: “Dotlq”, “metrôs”: [ { “código”: “DC”, “ibxs”: [ “DC5”, “DC6” “nome”: “Ashburn” “código”: “SV”, “ibxs”: [ “SVl” I “nome”: “Vale do Silício” } “nome”: “testl”, “availability_status”: “in_trial_testing”, “require_redundancy”: “N”, “standard_speed" s”: [ “UptolOG”, “Upto200MB”, “Upto500MB”, “UptolG” ] } ] ] Recurso: Ativos de Usuário

[0106] Descrição Obter detalhes de ativos provenientes de um comprador em uma determinada localização de metrô. URI de Solicitação de Método de HTTP OBTER /ecx/vl/ativos OBTER ativos

[0107] Descrição Essa implantação da operação de OBTER para compradores retorna uma lista de todos os ativos de comprador incluindo portas e circuitos virtuais em um determinado metrô. Solicitação URI de Solicitação: OBTER http://<HosfName>/ecx/v1/ativos Parâmetros de Filtro: metro_code

asset_type Descrição Filtrar os resultados pelos tipos de ativos. Comprador: Para obter os ativos que o usuário teve como um comprador Tipo Coluna Solicitado Sim Padrão Nenhum Exemplo comprador Cabeçalhos de Solicitação: Atributo deDescrição Cabeçalho Autorização Solicitado. Especificar o token de Portadora OAuth Solicitação OBTER http://<HostName>/ecx/yl/ativos?código de metrô=SV&asset tvpe=buver Resposta: Campos de Resposta: buyer_assets Descrição Ativos relacionados ao comprador do usuário no metrô Tipo Objeto Solicitado Sim Padrão Nenhum Exemplo Nenhum seller_assets Descrição Detalhes relacionados ao vendedor do usuário no metrô Tipo Objeto Solicitado Sim Padrão Nenhum Exemplo Nenhum portas Descrição Lista de Portas Tipo Objeto Solicitado Sim Padrão Nenhum Exemplo Nenhum Nome Descrição Nome da porta Tipo Objeto Solicitado Sim Padrão Nenhum Exemplo Nenhum crossconnectids Descrição Série de conexão cruzada Tipo Arranjo Solicitado Sim Padrão Nenhum Exemplo 1111111100 metrocode Descrição Código do metrô em que a porta está Tipo Coluna Solicitado Sim Padrão Nenhum Exemplo SV metro_name Descrição Nome do metrô, em que a porta está Tipo Coluna Solicitado Sim Padrão Nenhum Exemplo Vale do Silício ibx_name Descrição Nome do IBX, em que a porta está Tipo Coluna Solicitado Sim Padrão Nenhum Exemplo SVI larguras de banda Descrição As larguras de banda da porta (Arranjo de valores para Portas defasadas) Tipo Arranjo Padrão Nenhum Exemplo 1 G, 1 G Solicitado NÃO encapsulação Descrição Encapsulação de porta Tipo Coluna Padrão Nenhum Exemplo dot1q ou qinq Solicitado Sim is_buyout Descrição Porta de aquisição ou Porta Padrão Tipo Coluna Solicitado Sim Padrão Nenhum Exemplo Y ou N virtualcircuits Descrição Listas de circuitos virtuais para cada Tipo Lista Solicitado Sim Padrão Nenhum Exemplo Nenhum

[0108] Id do circuito virtual. Esse id é exigido para realizar operações nos APIs de circuito virtual como Circuito Virtual de DELETAR ou OBTER redundantid Descrição ID de circuito virtual associado ao circuito virtual redundante Tipo Coluna Solicitado Sim Padrão Nenhum Exemplo 4D34239266A3952695956B

[0109] cross_connect_id [Depreciado, em vez disso, consulte "Portas" de campo. “conexão cruzada ids”] Descrição Id da porta física Tipo Coluna Solicitado Sim Padrão Nenhum Exemplo 1111111100 port speed[Depreciado, em vez disso, consulte "Portas" de campo. "velocidades de porta"] Descrição A capacidade da porta, por exemplo, 1 Tipo Coluna Solicitado Sim Padrão Nenhum Exemplo 1000000000 Nome Descrição Nome de circuito virtual Tipo Coluna Solicitado Sim Padrão Nenhum Exemplo VC1 de Teste de API created_by Descrição Nome do usuário que tem sido criado Tipo Coluna Solicitado Sim Padrão Nenhum Exemplo Primeiro Nome último Nome e-mail Descrição E-mail do usuário que tem sido criado circuito Tipo Coluna Solicitado Sim Padrão Nenhum Exemplo X@Y.com createddate Descrição Data e tempo quando o circuito virtual foi criado Tipo Coluna Solicitado Sim Padrão Nenhum Exemplo 02-15-2014 21:58:20 sellerservicename Descrição Nome do perfil de serviço de vendedor para o circuito virtual Tipo Coluna Solicitado Não Padrão Nenhum Exemplo Conexão Direta

[0110] Situação de disponibilidade - A situação de disponibilidade do perfil de serviço como "em Testagem de Teste" service_key Descrição Chave de Serviço ou Chave de Autorização Digital obtida a partir do Vendedor Tipo Coluna Solicitado Sim Padrão Nenhum Exemplo xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx estado Descrição Estado do circuito virtual Tipo Coluna Solicitado NÃO Padrão Nenhum Exemplo PROVISIONADO situação Descrição Estado do circuito virtual Tipo Coluna Solicitado NÃO Padrão Nenhum Exemplo FATURADO Resposta de Amostra: HTTP/1.1 200 OK Content-Type: application/json [ { “ativos de comprador”: { “portas”: [ { “largura de banda”: “1 G”, “larguras de banda”: [ “1 G, 1 G” “cross_connect_ids”: [ “123456”, 123457. “encapsulação”: “Qinq”, nome ibx”: “SV3”, “é comprado”: “N”, “código de metrô”: “SV”, “metro_name”: “BAYM”, “nome”: “QinqVirtualPort”, “virtualcircuits”: [ { “largura de banda”: “Up to 200MB”, “nome de serviço de nuvem”: “CSP1 “, “seller_service_name”: “CSP1”, “availability_status”: “in_trial_testing”, “criado por”: “usuário de confiança”, “created_date”: “1212-2014 22:08:06”, “conexão cruzada id”: “123456”, “e-mail”: “relianceuser@reliance.com”, “id”: “5566417575566047323754”, “redundant_id”: “6939666E3693916437C576”, “nome”: “TestCSPlvc2”, “velocidade de porta”: 100000000, “service_key”: “87f4f 12c-420a-4b3c-9087-c4f^071 fd7e’ “estado”: “Provisionado”, “situação”: “Permitido” “seller_asset”: ““ } ] Recurso: Circuitos Virtuais Descrição Circuitos Virtuais

Circuitos Virtuais de OBTER:

[0111] Descrição Essa implantação da operação de OBTER retorna uma lista de todos os circuitos virtuais provenientes do emissor autenticado da solicitação. Se o emissor não tiver circuitos virtuais, uma resposta com Código de HTTP 204 é retornada sem carga. Solicitação Cabeçalhos de Solicitação:

URI de Solicitação: /ecx/vl/virtualcircuits Parâmetros de Filtro Nenhum Campos de Solicitação Nenhum Solicitação de Amostra OBTER http://<HosfName>/ecx/v1/virtualcircuits/ {virtual_circuit_id} Resposta Campos de Resposta Id

redundant_id

Nome

buyer_port

cross_conect_id

port_speed

cloud_service_name

service_key

buyer_Wan

Largura de banda

estado

situação

created_date

e-mail

seller_port

metro_code

ibx_name

seller_service_name

metadados

"chave:valor"

Resposta de Amostra: HTTP/1.1 200 OK Content-Type: application/json { “virtualcircuits”: [ { “id”: “4D34239266A3952695956A”, “nome”: “Teste de Amostra VC-7”, “buyer_port”: “GSE QA-R-EE-01”, “cross_connect_id”: “14395166”, “port_speed”: “1G”, “cloud_service_name”: “CSP_A_1”, “chave de serviço”: “xxxxxxxx-xxxx-xxxx-xxxx- xxxxxxxxxxxx”, “buyer_vlan”: “2004.*”, “largura de banda”: “Up to 200MB”, “estado”: "PROVISIONADO", “situação”: “COBRADO”, “created_date”: “05/23/2014 01:21:54”, “created_by”: “testuserl”, “email”: “test@cloudexchange.com”, “seller_port”: “GSE QA-SJC-06GMR-CIS-2-SEC-A”, “metro_code”: “SV”, “ibx_name”: “SV1” “seller_service_name”: “cspcreatetest”, “metadados”: { “chave l” “valor 1 “; “chave 2” “valor 2”: “chave 3” “valor 3” “chave 4” “valor 4”. “chave 5”, “valor 5”, { “id”: “1432”, “nome”: “Steve CSP_ATest VC-5”, “buyer_port”: “GSE QA-R-EE-01”, “cross_connect_id”: “14395166”, “port_speed”: “1G”, “cloud_service_name”: “CSP_A_1”, “service_key”: “xxxxxxxx-xxxx-xxxx-xxxx- xxxxxxxxxxxx”, “buyer_vlan”: “2004.*”, “largura de banda”: “Up to 200MB”, “estado”: "PROVISIONADO", “situação”: “COBRADO”, “created_date”: “05/23/2014 01:21:54”, “created_by”: “testuserl”, “email”: “test@cloudexchange.com”, “seller_port”: “GSE_QA-SJC-1234-CIS-2-SEC-A”, “metro_code”: “SV”, “ibx_name”: “SV1” } ] } Código de Erro em Resposta:

POSTAR Circuitos Virtuais: Descrição Criar Circuito Virtual. Solicitação Cabeçalhos de Solicitação:

URI de Solicitação: POSTAR http://<hostname>/ecx/vl/virtualcircuits Parâmetros de Filtro Nenhum Campos de Solicitação metro_name

metro_code

cloud_service_name

seller_service_name

primary_vc_nane

pritmary_port_name

secondary_vc_name

secondary_pon name

secondary_vlan_id

service_key

vinual_circuit_speed

e-mail

[0112] Outros campos exemplificativos podem incluir número de conta de provedor de serviço de vendedor, chave autorização digital obtida a partir do vendedor serviço, número de configuração de protocolo de porta de comunicação de borda, o id da porta de comunicação privada virtual para um VPC, emparelhamento de comprador ip (endereço de IP atribuído ao/à comprador/interface de cliente), endereço de IP atribuído à interface de provedor de serviço de vendedor, email do usuário, metadados (conforme descrito acima), chave (Essa chave, seu valor associado que o usuário de API passou no objeto de metadados durante a criação de VC), e velocidade do circuito virtual.

Solicitação de Amostra POSTAR http://<HostName>/ecx/vl/virtualcircuits Autorização: Portadora <accessToken> Aceitação: application/xml ou application^ son “metro_name”: “Vale do Silício”, “metro_code”:”SV”, “cloud_service_name”: “ C SP_A_ 1 “, “primary_vc_name”: “twtca93 “, “primary jortjiame”:” “GSE QA-SJC-06GMR-CIS-2- SEC-A”, “primary_vlan_id”:”l 88”, “secondary_vc_name”: “twtcp94”, “secondary jort_name”:”GSE_QA-SJC-06GMR-CIS-2- SEC-B”, “secondary_vlan_id”:”188”, “service_key”:” xxxxxxxx-xxxx-xxxx-xxxx- xxxxxxxxxxxx”, “virtual_circuit_speedr to 200MB”, 1 ‘email”: test(^cloudexchange. com “metadados” } Resposta Campos de Resposta: result

mensagem

[0113] Outros campos exemplificativos podem incluir “mais info”, ID de circuito virtual primária, ID de circuito virtual secundária. Resposta de Amostra: HTTP/1.1 201 CRIADA Locação: 4D34239266A3952695956A { “resultado”: “SUCESSO”, “mensagem”: "Sua solicitação de Circuito Virtual foi bem sucedida." “more_info”: “https://api.desenvolvedor.cloudexchange.com/docs/api/messa ges/xx” } Código de Erro em Resposta:

[0114] Em alguns exemplos, APIs podem ser fornecidos para deletar os circuitos virtuais. A operação de DELETAR removerá o circuito virtual fornecido, um código de resposta com HTTP 200 é retornado se a operação for bem sucedida. Se o circuito virtual pertencer a certos provedores de serviço de vendedor, esse provedor de serviço de vendedor terá que confirmar a exclusão do circuito virtual. SOLICITAÇÃO DE AMOSTRA DELETAR http://<HostName>/ecx/vl/virtualcircuits/{virtual_circuit_i d) Resposta de Amostra: HTTP/1.1 200 DELETADO { “result”: “SUCESSO”, “mensagem”: “Seu Circuito Virtual foi deletado com sucesso.” “mais info”: ““ }

[0115] Em alguns exemplos, APIs podem ser fornecidos para a conexão de habilitação de PATCH. Essa implantação da operação de PATCH permite que os usuários habilitem o circuito virtual se o vendedor exigir a etapa adicional de autenticação antes de permitir a solicitação de conexão de comprador. Resposta de Amostra: HTTP/1.1 201 CRIADA { “resultado”: “SUCESSO”, “mensagem”: “Conexão que permite solicitação bem sucedida” “mais info”: ““

[0116] Em alguns exemplos, APIs são fornecidos para Perfis de Serviço de Vendedor a serem criados por vendedores em Troca em Nuvem. Os vendedores de Troca em Nuvem são solicitados para definir e configurar seus perfis de serviço para a conectividade a seus serviços de vendedor. Os vendedores podem criar um perfil para cada serviço distinto que os mesmos oferecem.

[0117] Em alguns exemplos, a implantação de “OBTER metadados de carga de circuito virtual” da operação de OBTER retorna os metadados de carga exigidos para criar os circuitos virtuais por um determinado perfil de serviço de vendedor. Solicitação de Amostra OBTER http://<HostName>/ecx/vl/sellerserviceprofiles/CloudSigma perfil/metadata Resposta de Amostra: HTTP/1.1 200 OK Content-Type: application/json { “campos”: [ { “descrição”: “Código do metrô em que esse circuito virtual será criado”, “nome”: “código de metrô”, “tipo”: “coluna” } , { “descrição”: “Nome de Serviço de Vendedor”, “nome”: “Nome de serviço de vendedor” , “tipo”: “coluna” } , { “descrição”: "Nome de Circuito Virtual Primário", “nome”: “primário vc nome”, “tipo”: “coluna” } , { “descrição”: “Nome de Porta Primária de Compradores”, “nome”: “Nome de porta primária”, “tipo”: “coluna” t { “descrição”: “Id de VLAN primária de compradores”, “nome”: “id de vlan primário”, “tipo”: “coluna” ( I “descrição”: "Nome de Circuito Virtual Secundário" “nome”: “secundário vc nome”, “tipo”: “coluna” { “descrição”: “Nome de Porta Secundária de Compradores”, “nome”: “secondary_buyer_port_name” , “tipo”: “coluna” }, { “descrição”: “Id de VLAN secundário de compradores”, “nome”: “secondary_buyer_vlan_id”, “tipo”: “coluna” }, { “descrição”: “Chave de Serviço ou Chave de Autorização Digital obtida por CSP”, “nome”: “service_key”: “tipo”: “coluna” { “descrição”: “Velocidade do circuito virtual”, “nome”: “velocidade de circuito virtual” , “tipo”: “coluna” I { “descrição”: “E-mail do usuário”, “nome”: “e-mail”, “tipo”: “coluna” } ] } APIs de vendedor Recurso: Portas Descrição Portas na Comutação de Troca em Nuvem

OBTER PORTAS:

[0118] Descrição Essa implantação da operação de OBTER retorna uma lista de todas as portas de propriedade do emissor autenticado da solicitação. As portas podem ser filtradas por metrô e Nome de IBX. Se nenhuma porta que corresponde aos critérios for encontrada, então uma resposta de 204 HTTP é retornada sem uma carga. Solicitação URI de Solicitação: OBTER http://<HostName>/ecx/vl/portas?metro_code=SV&ibx_name=SVl Parâmetros de Filtro: metro_code

ibx_name

Largura de banda

[0119] A largura de banda da porta. Se nenhuma largura de banda for fornecida, então as portas com qualquer capacidade de largura de banda é retornada. Cabeçalhos de Solicitação: Atributo de Cabeçalho Descrição

Solicitação de Amostra: OBTER http://<HostName>/ecx/vl/portas?metro_code=SV&ibx=SVl Resposta Campos de Resposta: portas Descrição Lista de Portas.

Nome

metrocódigo

metro_name

ibx_name

[0120] Outros campos de resposta exemplificativos: largura de bandas, encapsulação, is_buyout, cross_connect_ids (números de série de conexão cruzada). Resposta de Amostra: HTTP/1.1 200 OK Content-Type: application/json “portas”: [ “nome”: “GSE QA-R-EE-02”, “metro_code”: “SV”, “metro_name”: “Vale do Silício”, nome ibx”: “SVl” { “nome”: “GSE Q A-R-EE-01 “ , “código de metrô”: “SG”, “nome de metrô”: “Singapura”, nome ibx”: “SGI” }]} Código de Erro em Resposta:

Recurso: perfis de serviço de vendedor

[0121] Descrição Perfis de Serviço de Vendedor criados por vendedores em Troca em Nuvem de Equinix. Os vendedores de Troca em Nuvem de Equinix são solicitados para definir e configurar seus perfis de serviço para a conectividade a seus serviços de vendedor. Os vendedores podem criar um perfil para cada serviço distinto que os mesmos oferecem.

[0122] POSTAR perfis de serviço de vendedor. Essa implantação da operação de POSTAR ria um novo perfil de serviço de vendedor para o registrado no usuário. Os campos de solicitação exemplificativos incluem: nome, situação de disponibilidade (A situação de disponibilidade do perfil de serviço como "Em Testagem de Teste" ou "Disponível para Encomendas"), rótulo de circuito virtual, tipo de serviço, api disponível (Indica se a integração de API está disponível para esse serviço. A integração de API permite a conclusão do provisionamento de serviço virtual. Os valores aceitáveis são VERDADEIRO e FALSO.), O rótulo de chave de autorização (é isso que a organização do vendedor chama de chave de autorização), O método de encapsulação de porta usado para o lado de vendedor, Tipo de serviços de vendedor que essa conexão pode alcançar, Exigir redundância - Isso definirá se uma criação de circuito virtual secundária é exigida quando o comprador solicitar um circuito virtual a partir desse provedor de serviço de vendedor. Se sim, o comprador terá que fornecer tanto primário quanto secundário, porta e IDs de VLAN. Os valores aceitáveis são VERDADEIRO e FALSO; mesmo vlan secundário - Se esse campo tiver um valor de “VERDADEIRO”, o comprador será forçado a fornecer o mesmo vlan id tanto para circuitos virtuais primários quanto secundários; capturar buyer_peer_ip - Indicar se deve capturar o endereço de IP de emparelhamento de comprador. Os valores aceitáveis são VERDADEIRO e FALSO; Capturar BGP ASN de comprador; Capturar porta de comunicação privada virtual; capturar seller_peer_ip - Indicar se deve capturar endereço de IP de emparelhamento. Os valores aceitáveis são VERDADEIRO e FALSO.

[0123] Outros campos de solicitação exemplificativos incluem: Os contatos de alerta de limite de largura de banda. Múltiplos endereços de e-mail podem ser separados por vírgula, contatos de notificação: Os contatos que serão notificados de deleções e solicitações de circuito virtual, porcentagem de alerta: Limite de largura de banda por porta; As portas do provedor de serviço de vendedor permitirão que os compradores estabeleçam a conexão de circuito virtual; As velocidades de circuito virtual oferecidas; permitir a velocidade padronizada: O vendedor pode escolher permitir que os compradores selecionem velocidades personalizadas se o comprador tiver uma porta de aquisição. Solicitação de Amostra POSTAR http://<HostName>/ecx/vl/sellerserviceprofiles { “nome”: “TestServicel23”, “availability_status”: “In_Trial_Testing”, “virtual_circuit_label”: “Nome de Conexão Virtual”, “service_type”: “Conectividade de Serviço de Vendedor”, “api_available”: “VERDADEIRO”, “auth_key_label”: “Chave de Autorização”, “encapsulação de porta”: “QNQ”, “Tipo de serviço de conexão”: “Hybrid”, “exigir redundância”: “VERDADEIRO”, “secondary_vlan_same”: “VERDADEIRO”, “capture_buyer_bgp_asn”: “FALSO”, “capture_buyer_peer_ip”: “VERDADEIRO”, “capture_seller_peer_ip”: “VERDADEIRO”, “capture_jvdrtualj3rivate_gateway”: “VERDADEIRO” , “threshold_alert_contacts”: “userl @equinix.com,usuário@equinix.com”, “contatos de notificação”: “user2@equinix.com”, “permitir velocidade padronizada”: “VERDADEIRO”, “portas”: [ “GSE_Test-02”, “GSE_Test-03” ], “ vlan_speeds”: [ “até 200 MB”, “até 500 MB”, “até 1 G” ], “alert_percentage”: 90. } Campos de Resposta: resultado Descrição Resultado da operação que indica se o mesmo foi bem sucedido. Valores válidos são SUCCESS e ERROR Tipo Coluna Exigir Sim Padrão Nenhum Exemplo SUCCESS mensagem Descrição Mensagem de Sucesso Tipo Coluna Exigir Sim Padrão Nenhum Exemplo O perfil de serviço de vendedor foi criado moreinfo Descrição Adicional Tipo Coluna Exigir Não Padrão Nenhum Exemplo Resposta de Amostra: HTTP/1.1 200 Criado { “result”: “SUCCESS”, “mensagem”: “O perfil de serviço de vendedor foi criado com sucesso”, “mais info”: ““ }

[0124] POSTAR Portas para Perfis de Serviço de Vendedor

[0125] Descrição Essa implantação da operação de POSTAR permite que determinadas portas (provenientes ao usuário) para o serviço de troca de vendedor sejam oferecidas. Em particular, a operação adiciona portas a um perfil de serviço de vendedor existente.

[0126] Observação: Um perfil de serviço de vendedor terá que ser aprovado para essa operação para ser possível. Os Perfis de Serviço de Vendedor rejeitados ou pendentes não serão permitis para serem editados e as portas não podem ser adicionadas até estarem em situação Aprovada. URIs de solicitação: POSTAR http://<HostName>/ecx/vl/sellerserviceprofiles/{p rofile_name}/ports

[0127] Como outro exemplo, uma operação de DELETAR removerá a porta do perfil de serviço de Vendedor, uma resposta com código de HTTP 200 é retornada se a operação for bem sucedida. Não pode existir um VC ativo associado à porta que está sendo deletada, se um circuito virtual já existir na porta, uma mensagem de erro é exibida indicando que há um circuito virtual existente na porta.

[0128] Pelo menos uma porta deve estar presente em um perfil de serviço.

[0129] Como outro exemplo, uma operação de COLOCAR será usada para editar o perfil de serviço de Vendedor existente, uma resposta com Código de HTTP 200 é retornada se a operação for bem sucedida. O estado de perfil (Aprovado ou Aprovação Pendente) não alterará durante a operação de Editar.

[0130] Os campos que podem ser atualizados na operação de colocar são:

[0131] Como outro exemplo, “OBTER Meus Perfis de Serviço de Vendedor” pode ser usado pelos vendedores para obter uma lista de todos os perfis de serviço de vendedor que os mesmos criaram. Essa implantação da operação de OBTER retorna um perfil de serviço de vendedor passado como parte do parâmetro de caminho de nome de perfil. A filtragem pela situação de serviço de vendedor também está disponível pela definição de um parâmetro. Solicitação de Amostra: OBTER http://<HostName>/ecx/vl/sellerserviceprofiles (obter todos os meus perfis de serviço de vendedor) OBTER http://<HostName>/ecx/vl/sellerserviceprofiles/{profile_nam e} (obter perfil de serviço de vendedor por nome) OBTER http://<HostName>/ecx/vl/sellerserviceprofiles/{profile_nam e}?status={valid_status} (obter perfil de serviço de vendedor por nome e situação) OBTER http://<HostName>/ecx/vl/sellerserviceprofiles?status={vali d_status} (obter perfil de serviço de vendedor por situação)

[0132] Como outro exemplo, OBTER ativos pode ser usado por vendedores para obter detalhes de ativos provenientes de um Vendedor em uma determinada localização de metrô. Essa implantação da operação de OBTER para vendedores retorna uma lista de todos os ativos que inclui portas e circuitos virtuais em um determinado metrô. Um vendedor também pode ser um Comprador e, por conseguinte, o "tipo de ativos" para um vendedor pode ser tanto "comprador" quanto "vendedor". Recurso: Circuitos Virtuais Descrição Circuitos Virtuais

CIRCUITOS VIRTUAIS DE OBTER:

[0133] Descrição A presente implantação da operação OBTER retorna uma lista de circuitos virtuais de propriedade do usuário. Os circuitos virtuais podem ser filtrados com base em sua situação. Se nenhum circuito virtual for encontrado, o qual corresponda aos critérios, uma resposta com Código HTTP 204 é retornada sem nenhuma carga. Solicitação URI(s) de Solicitação: OBTER http://<HostName>/ ecx/v 1 /virtualcircuits?pending=add Parâmetros de Filtro:

[0134] pendente

Cabeçalhos de Solicitação:

Campos de Solicitação: Nenhum Solicitação de Amostra: OBTER http://<HostName>/ecx/vl/virtualcircuits?pending=add Resposta Campos de Resposta id

Nome

buyer_port

cross_connect_id

port_speed

cloud_service_name

service_key

buyer_vlan

Largura de banda

Situação

Created_date

created_by

e-mail

seller_port

metro_code

ibx_name

[0135] Outros campos de exemplo como aqueles incluídos acima em outros exemplos podem ser usados. Resposta de Amostra: HTTP/1.1 200 OK Content-Type: application/json { “virtualcircuits”: [ { “id”: “4D34239266A3952695956A”, “name”: “Test Virtual Circuit”, “buyer_port”: “GSE QA-R-EE-01”, “cross_connect_id”: “ 11111111 “, “port_speed”: “1G”, “cloud_service_name”: “CSP_A_1 “, “service_key”: “xxxxxxxx-xxxx-xxxx-xxxx- xxxxxxxxxxxx”, “buyer_vlan”: “2004.*”, “bandwidth”: “Up to 200MB”, “status”: “COBRADO”, “created_date”: “05/23/2014 01:21:54”, “created_by”: “temp usuário”, “email”: “test@cloudexchange.com”, “seller_port”: “sellerport”, “metro_code”: “SV”, ibx name”: “SVl” }]} Código de Erro em Resposta:

Circuito Virtual de PATCH:

[0136] Descrição A operação de PATCH pode ser usada para realizar os seguintes três tipos de operações em um circuito virtual através do vendedor:

[0137] • Aceitar um Circuito Virtual criado por um comprador

[0138] • Rejeitar um Circuito Virtual criado por um comprador

[0139] • Confirmar a exclusão do Circuito Virtual através de um comprador Solicitação URI(s) de Solicitação: PATCH http://<HosfName>/ecx/v 1 /virtualcircuits/ {virtual_circuit_id} Cabeçalhos de Solicitação:

Campos de Solicitação: ação

port_name

vlan_id

redundant_lan_id reject_comment - comentário de lado de vendedor para explicar a rejeição do circuito virtual Solicitação de Amostra PATCH http://<hostname>/ecx/vc2/virtualcircuit/4D34239266A3952695 956A { “action”: “approve”, “port_name”: “GSE QA-SJC-06GMR-CIS-2-SEC-A”, “vlan_id”: 188. }

[0140] Resposta:

[0141] Campos de Resposta: result

Resposta de Amostra: HTTP/1.1 200 OK { “result”: “SUCCESS”, “message”: “O circuito virtual solicitado foi rejeitado e o comprador foi notificado.”, “more_info”: “https://api.desenvolvedor.cloudexchange.eom/docs/api/messa ges/vcs/2” }

[0142] Código de Erro em Resposta:

Todos os Códigos de Erro

[0143] Outros pontos de extremidade 406 podem ter esquemas de solicitação/resposta similares àqueles fornecidos acima para Realizar Logon 406A, Portas 406B, Metrôs 406C, Circuitos Virtuais 406E, e Serviços de Nuvem 406F.

[0144] Realizar Logon 406A possibilita um canal seguro para acesso aos ativos de interconexão através de parceiros e clientes autenticados e autorizados. Ademais, a plataforma de interconexão fornece capacidade não incluída para solucionar problemas de segurança (proteção contra ameaças, proteção contra Injeção de SQL, prevenção contra ataque de DDoS, proteção contra bomba de JSON, etc.). Em alguns exemplos, uma entidade usa suas credenciais (por exemplo, nome de usuário, senha, chave de API, e/ou segredo de API) para obter um token de segurança (por exemplo, um token OAuth 2.0) com o uso de Realização de Logon 406A, o token de segurança, em seguida, assegura que as solicitações emitidas pela entidade agora autorizada para outros pontos de extremidade 406 são deu um cliente ou parceiro autorizado.

[0145] A porta de comunicação de API 403, em alguns exemplos, transforma os dados de aplicativo formatados de acordo com uma solicitação em qualquer um dentre os pontos de extremidade 406 e usa os dados de aplicativo transformados para realizar chamadas para o mecanismo de orquestração 407. O mecanismo de orquestração 407 pode representar um ou mais servidores reais e/ou máquinas virtuais configuradas para implantar os serviços de plataforma de troca em nuvem 408A a 408H (coletivamente, “serviços de plataforma 408”) no presente exemplo. Em resposta à invocação pela porta de comunicação de API 403A, o fluxo de trabalho e mecanismo de regras (não mostrados na Figura 3B) do mecanismo de orquestração 407 podem aplicar regras e políticas definidas para gerar um fluxo de trabalho de serviços de API de troca em nuvem 409 que, em geral, se encaixa em uma função geral associada a um dentre os serviços de plataforma 408. Conforme ilustrado, os serviços de plataforma 408 incluem gerenciamento de política 408A, perfis e configuração 408B, cobrança e faturamento 408C, integração de API de vendedor 408D, gerenciamento de circuito virtual 408E, gerenciamento de interface de rede 408F, pesquisa e recomendação 408G e inventário e descoberta de local 408H. Cada um dentre os serviços de plataforma pode representar um fluxo de trabalho e mecanismo de regras para um aspecto diferente de provisionamento de serviço de nuvem.

[0146] Os serviços de API de troca em nuvem 409A a 409R (coletivamente, “serviços de troca em nuvem 409”) representam serviços oferecidos pela plataforma de interconexão para modificar a infraestrutura de rede de troca em nuvem, gerenciar conteúdo, gerenciar incidentes, gerenciar inventário e capacidade, assegurar uma acesso seguro e gerenciar pedidos/cobrança para fornecedores e clientes, como exemplos. Qualquer um dos serviços de troca em nuvem 409 pode, em si, representar um agrupamento de microsserviços para transações de solicitação/resposta invocáveis por o mecanismo de orquestração 407 gerenciar um fluxo de trabalho.

[0147] Os serviços de troca em nuvem 409 incluem validação de solicitação 409A, autorização e auditoria 409B, gerenciamento de conta e perfil 409C, gerenciamento de inventário 409D, gerenciamento de capacidade 409E, provisionamento de rede 409F, validador de verificação de crédito 409G, cobrança 409H, integração de API de vendedor 4091, local 409J, gerenciamento de tíquetes com problemas 409K, localização 409L, estatísticas de uso 409M, recomendação 409N, agendadores e processadores de lote 409O, notificações 409P, analisador de erro 409Q e gerenciamento de conteúdo 409R. A integração de API de vendedor 4091 pode possibilitar que o mecanismo de orquestração 407 invoque interfaces de software de aplicativos de vendedor de CSPs para, por exemplo, solicitar que o aplicativo de vendedor confirme a adição ou exclusão de circuitos virtuais (conforme solicitado pelo NSP/cliente) por parte do vendedor.

[0148] A Figura 4 é um diagrama de blocos que mostra uma representação alternativa de uma plataforma de interconexão 103 para uma troca em nuvem de acordo com técnicas descritas na presente revelação. No presente diagrama, a arquitetura técnica para a plataforma de interconexão 103 inclui uma camada de serviços de API 420 para validar e satisfazer consultas de API, validar e satisfazer comandos de API e integrar subsistemas 120 com o mecanismo de orquestração de interconexão 407. Um ou mais servidores reais e/ou máquinas virtuais de um centro de dados pode executar cada um dentre os serviços de mecanismo de orquestração de interconexão 407 da camada de serviços de API 420 e subsistemas 120. Os pontos de extremidade de API de interconexão 406 são pontos de extremidade de API exemplificativos através dos quais os clientes de API 402 (Figura 3A) podem gerenciar interconexões de troca em nuvem.

[0149] O gerenciamento de fluxo de trabalho e componente de roteamento 410 gerenciam fluxos de trabalho e roteiam chamadas de API para pontos de extremidade 406 para os mecanismos 412A a 412J (coletivamente, “mecanismos 412”) que realizam uma funcionalidade consolidada invocando-se vários microsserviços da camada de serviços de API 420. Os mecanismos 412 incluem o mecanismo de autenticação e autorização 412A; o mecanismo de configuração, auditoria e rastreamento 412B; controladores de comando de API 412C; controladores de consulta de API 412D; mecanismos de composição de serviço 412E; mecanismo de gerenciamento de ordem 412F; mecanismo de notificação 412G; mecanismo de recomendação e análise 412H; mecanismo de interface de interconexão 4121; e repositório de fluxo de trabalho e regras de API 412J.

[0150] Os serviços de API exemplificativos da camada de serviços de API, conforme ilustrados, incluem serviços de consulta de API 422A que têm serviços de validador de parâmetro de solicitação 424A e serviços de provedor de consulta 424B; serviços de comando de API 422B que têm serviços de validador de corpo de solicitação 424C e serviços de provedor de comando 424D; e serviços de faixada de integração 422C que têm delegador de solicitação e adaptador de serviço 424E e análise de resposta e transformação 424F.

[0151] Os exemplos de subsistemas 120 são ilustrados na Figura 4. O sistema de gerenciamento de identificação e acesso 426A realiza autenticação e autorização para validar o acesso aos serviços de plataforma de interconexão. O módulo de integração de API de vendedor module 426B facilita a integração da plataforma de interconexão 103 com APIs de provedor de serviço de nuvem para criar e validar interconexões com redes de provedor de serviço de nuvem, conforme descrito em outra parte no presente documento. O banco de dados de troca em nuvem 428 representa um bando de dados de configuração que descreve a configuração da troca em nuvem gerenciada pela plataforma de interconexão 103. O sistema de rede 426C provisiona, configura, consulta e, de outro modo, controla a infraestrutura de rede da troca em nuvem gerenciada pela plataforma de interconexão 103. O sistema de gerenciamento de ordem 426D realiza gerenciamento de ponta a ponta de ordens de cliente para, por exemplo, circuitos virtuais. O sistema de gerenciamento de incidentes 426E facilita lidar com erros na troca em nuvem gerenciada pela plataforma de interconexão, como alertando-se ao provedor de troca em nuvem, notificando-se clientes, etc. O sistema de gerenciamento de conteúdo 426F gerencia conteúdo para a plataforma de interconexão 103.

[0152] As Figuras 5 a 11 são fluxogramas, em que cada um ilustra um fluxo de chamada e operações realizadas por componentes exemplificativos de uma plataforma de interconexão para uma troca em nuvem, conforme descrito na presente revelação.

[0153] No exemplo da Figura 5, os desenvolvedores de API 402 (por exemplo, um comprador/vendedor/terceiro) pode usar serviços 409 para gerenciar interconexões de troca em nuvem. A Figura 5 ilustra um processo que pode ser usado para criação de circuito virtual aplicável a todos os Provedores de Serviço de Nuvem (CSPs). Por exemplo, um dos desenvolvedores de API 402 pode passar informações de logon, como um ou mais dentre um nome de usuário, senha, chave de API e segredo de API, para porta de comunicação de API 403 (454A). A porta de comunicação de API 403 realiza validação de chave de API e segredo de API (454B), interage com o gerenciamento e federação de identidade 450 (454C, 454D) e fornece um token OAuth 2.0 de volta ao desenvolvedor de API 402 (454E). O desenvolvedor de API 402 recebe o token OAuth 2.0 e pode invocar um ponto de extremidade de API (por exemplo, um dentre os pontos de extremidade de API 406) fornecendo-se o token OAuth 2.0 e um ou mais parâmetros à porta de comunicação de API 403 (454F). A porta de comunicação de API 403 pode realizar uma transformação de formato de dados (por exemplo, XML, JSON) (454G) e validação de token OAuth 2.0 (454H). A porta de comunicação de API 403, então, entra em contato com o mecanismo de orquestração 407 para invocar o serviço de plataforma de troca em nuvem (456A).

[0154] O mecanismo de orquestração 407 orquestra um fluxo de trabalho de API com base em regras e respostas definidas. Por exemplo, o fluxo de trabalho e mecanismo de regras 306 do mecanismo de orquestração 407 pode orquestrar o fluxo de trabalho de API com base em um ou mais dentre políticas 308A, perfis 308B, configurações 308C e microsserviços 308D (Figura 2). De modo geral, o mecanismo de orquestração 407 pode invocar um ou mais serviços 409 paralelamente ou em uma ordem definida com base em regras e/ou políticas configuradas. No exemplo da Figura 5, o mecanismo de orquestração 407 invoca o serviço A (460A) e o serviço B (460B) dos serviços 409, então, recebe uma resposta do serviço A (460C) e recebe uma resposta do serviço B (460D). O mecanismo de orquestração 407, então, invoca o serviço C (460E) e recebe uma resposta do serviço C (460F). O mecanismo de orquestração 407 envia à porta de comunicação de API 403 uma resposta do serviço de plataforma de troca em nuvem (456B). A porta de comunicação de API 403 recebe a resposta do serviço de plataforma de troca em nuvem e pode realizar uma transformação de formato de dados (por exemplo, XML, JSON) nas informações recebidas na resposta (4541). A porta de comunicação de API 403 envia um ou mais cabeçalhos e corpos de resposta ao desenvolvedor de API 402 que invocou o ponto de extremidade de API (454J).

[0155] Dessa maneira, o mecanismo de orquestração 407 fornece uma plataforma de interconexão para uma troca em nuvem, que torna as informações de ativos de interconexão disponíveis aos desenvolvedores de API 402 através da interação entre máquinas. O processo esboçado na Figura 5 pode ser aplicado a diferentes casos de uso, como para permitir que os desenvolvedores de API obtenham informações a respeito de um ou mais circuitos virtuais, de modo a permitir que os desenvolvedores de API obtenham informações a respeito de um ou mais ativos de interconexão (por exemplo, trocas em nuvem com base em metrô, pontos de troca em nuvem, portas de trocas em nuvem), de modo a permitir que os vendedores definam parâmetros para conectividade, de modo a permitir que os desenvolvedores de API obtenham informações a respeito de perfil de serviço de nuvem e atributos esperados para a criação de um circuito virtual, ou exclusão próxima ao tempo real de circuitos virtuais por compradores.

[0156] A Figura 6 é um fluxograma que ilustra um fluxo de chamada e operações realizadas por componentes exemplificativos de uma plataforma de interconexão para uma troca em nuvem ao tornar informações de ativos de interconexão disponíveis para desenvolvedores de API 402 através da interação entre máquinas. A Figura 6 inclui algumas operações similares àquelas descritas acima em relação à Figura 5. Em resposta ao recebimento de uma solicitação da porta de comunicação de API 403 que invoca o serviço de plataforma de troca em nuvem, o mecanismo de orquestração 407 pode orquestrar um fluxo de trabalho de API com base em regras e respostas definidas. Por exemplo, a Figura 6 permite que desenvolvedores de API 402 obtenham informações como um token OAuth 2.0 do armazenamento de dados de permissão 452 através da interação entre máquinas. Especificamente, a porta de comunicação de API 403 pode enviar um nome de usuário e senha recebidos a partir do desenvolvedor de API 402 (454A), após a validação (454B), para o gerenciamento e federação de identidade 450 (454C), que, por sua vez, fornecem essas informações ao armazenamento de dados de permissão 452 (462A), que retorna um nome de usuário e chave de usuário para gerenciamento e federação de identidade 450 (462B). O gerenciamento e federação de identidade 450 pode realizar SAML em mapeamento de OAuth (462C), e fornece um token OAuth à porta de comunicação de API 403 (454D). A porta de comunicação de API 403 pode realizar um Token OAuth ao mapeamento de OAuth 2.0 de Porta de Comunicação (462D) e pode, opcionalmente realizar uma conversão entre XML/JSON (462E). A porta de comunicação de API 403, então, fornece o token OAuth 2.0 ao desenvolvedor de API 402 (454E).

[0157] A Figura 7 é um fluxograma que ilustra um fluxo de chamada e operações realizadas por componentes exemplificativos de uma plataforma de interconexão para uma troca em nuvem ao tornar informações de ativos de interconexão disponíveis para desenvolvedores de API 402 através da interação entre máquinas. A Figura 7 inclui algumas operações similares àquelas descritas acima em relação à Figura 5. Em resposta ao recebimento de uma solicitação da porta de comunicação de API 403 que invoca o serviço de plataforma de troca em nuvem (470E), o mecanismo de orquestração 407 pode orquestrar um fluxo de trabalho de API com base em regras e respostas definidas. Por exemplo, a Figura 7 mostra com o mecanismo de orquestração 407 pode invocar um serviço de validação de parâmetro de solicitação de porta de serviços 409 que especificam os parâmetros de porta que foram incluídos na solicitação inicial do desenvolvedor de API 402 que invoca o ponto de extremidade de portas (470F). O mecanismo de orquestração 407 recebe uma resposta do serviço de validação de parâmetro de solicitação de porta que indica se o(s) parâmetro(s) de solicitação de porta é/são válido(s) (470G). O mecanismo de orquestração 407, então, pode invocar um serviço de consulta de porta (470H) e receber uma resposta do serviço de consulta de porta (470I), por exemplo, que especifica informações de porta específicas com base nos parâmetros de solicitação de porta. O mecanismo de orquestração 407 pode incluir as informações de porta na resposta do serviço de plataforma de troca em nuvem para a porta de comunicação de API 403 (470J), e a porta de comunicação de API 403, por sua vez, pode fornecer as informações de porta aos desenvolvedores de API 402 (470L).

[0158] A Figura 8 é um fluxograma que ilustra um fluxo de chamada e operações realizadas por componentes exemplificativos de uma plataforma de interconexão para uma troca em nuvem ao tornar informações de ativos de interconexão disponíveis para desenvolvedores de API 402 através da interação entre máquinas. A Figura 8 inclui algumas operações similares àquelas descritas acima em relação à Figura 5. Em resposta ao recebimento de uma solicitação da porta de comunicação de API 403 que invoca o serviço de plataforma de troca em nuvem (472E), o mecanismo de orquestração 407 pode orquestrar um fluxo de trabalho de API com base em regras e respostas definidas. Por exemplo, a Figura 8 mostra com o mecanismo de orquestração 407 pode invocar um serviço de validação de parâmetro de solicitação de metrô de serviços 409 que especificam os parâmetros de metrô que foram incluídos na solicitação inicial do desenvolvedor de API 402 que invoca o ponto de extremidade de metrôs (472F). O mecanismo de orquestração 407 recebe uma resposta do serviço de validação de parâmetro de solicitação de metrô, por exemplo, que indica se o(s) parâmetro(s) de solicitação de metrô é/são válido(s) (472G). O mecanismo de orquestração 407, então, pode invocar um serviço de consulta de metrô (472H) e receber uma resposta do serviço de consulta de metrô (472I), por exemplo, que especifica informações de metrô específicas com base nos parâmetros de solicitação de metrô. O mecanismo de orquestração 407 pode incluir as informações de metrô na resposta do serviço de plataforma de troca em nuvem para a porta de comunicação de API 403 (472J), e a porta de comunicação de API 403, por sua vez, pode fornecer as informações de metrô aos desenvolvedores de API 402 (472L).

[0159] A Figura 9 é um fluxograma que ilustra um fluxo de chamada e operações realizadas por componentes exemplificativos de uma plataforma de interconexão para uma troca em nuvem ao tornar informações de ativos de interconexão disponíveis para desenvolvedores de API 402 através da interação entre máquinas. A Figura 9 inclui algumas operações similares àquelas descritas acima em relação à Figura 5. Em resposta ao recebimento de uma solicitação da porta de comunicação de API 403 que invoca o serviço de plataforma de troca em nuvem (474E), o mecanismo de orquestração 407 pode orquestrar um fluxo de trabalho de API com base em regras e respostas definidas. Por exemplo, a Figura 9 mostra com o mecanismo de orquestração 407 pode invocar um serviço de validação de parâmetro de solicitação de serviço de nuvem de serviços 409 que especificam os parâmetros de serviço de nuvem que foram incluídos na solicitação inicial do desenvolvedor de API 402 que invoca o ponto de extremidade de serviços de nuvem (474F). O mecanismo de orquestração 407 recebe uma resposta do serviço de validação de parâmetro de solicitação de serviço de nuvem, por exemplo, que indica se o(s) parâmetro(s) de solicitação de serviço de nuvem é/são válido(s) (474G). O mecanismo de orquestração 407, então, pode invocar um serviço de consulta de serviço de nuvem (474H) e receber uma resposta do serviço de consulta de serviço de nuvem, por exemplo, que especifica informações de serviço de nuvem específicas com base nos parâmetros de solicitação de serviço de nuvem (474I). O mecanismo de orquestração 407 pode incluir as informações de serviço de nuvem na resposta do serviço de plataforma de troca em nuvem para a porta de comunicação de API 403 (474J), e a porta de comunicação de API 403, por sua vez, pode fornecer as informações de serviço de nuvem aos desenvolvedores de API 402 (474L).

[0160] A Figura 10 é um fluxograma que ilustra um fluxo de chamada e operações realizadas por componentes exemplificativos de uma plataforma de interconexão para uma troca em nuvem ao tornar informações de ativos de interconexão disponíveis para desenvolvedores de API 402 através da interação entre máquinas. A Figura 10 inclui algumas operações similares àquelas descritas acima em relação à Figura 5. Em resposta ao recebimento de uma solicitação da porta de comunicação de API 403 para visualizar um circuito virtual e que invoca o serviço de plataforma de troca em nuvem (476E), o mecanismo de orquestração 407 pode orquestrar um fluxo de trabalho de API com base em regras e respostas definidas. Por exemplo, a Figura 10 mostra com o mecanismo de orquestração 407 pode invocar um serviço de validação de parâmetro de solicitação de circuito virtual de serviços 409 (476F) que especificam os parâmetros de circuito virtual que foram incluídos na solicitação inicial (476A) do desenvolvedor de API 402 que invoca o ponto de extremidade de circuito virtual. O mecanismo de orquestração 407 recebe uma resposta do serviço de validação de parâmetro de solicitação de circuito virtual, por exemplo, que indica se o(s) parâmetro(s) de solicitação de circuito virtual é/são válido(s) (476G). O mecanismo de orquestração 407, então, pode invocar um serviço de consulta de circuito virtual (476H) e receber uma resposta do serviço de consulta de circuito virtual, por exemplo, que especifica informações de serviço de nuvem específicas com base nos parâmetros de solicitação de circuito virtual (476I). O mecanismo de orquestração 407 pode incluir as informações de circuito virtual na resposta (476J) do serviço de plataforma de troca em nuvem para a porta de comunicação de API 403, e a porta de comunicação de API 403, por sua vez, pode fornecer as informações de circuito virtual aos desenvolvedores de API 402 (476L).

[0161] A Figura 11 é um fluxograma que ilustra um fluxo de chamada e operações realizadas por componentes exemplificativos de uma plataforma de interconexão para uma troca em nuvem no gerenciamento dinâmico de ativos de interconexão para desenvolvedores de API 402 através de interação entre máquinas. A Figura 11 inclui algumas operações similares àquelas descritas acima em relação à Figura 5. Em resposta ao recebimento de uma solicitação da porta de comunicação de API 403 que invoca o serviço de plataforma de troca em nuvem (480E), o mecanismo de orquestração 407 pode orquestrar um fluxo de trabalho de API com base em regras e respostas definidas. Por exemplo, a Figura 11 mostra como o mecanismo de orquestração 407 pode invocar um serviço de metrô (480F) para validar um código de metrô incluído na solicitação inicial do desenvolvedor de API 402 que invoca o ponto de extremidade de circuito virtual (480A). O mecanismo de orquestração 407 recebe uma resposta do serviço de metrô (480G).

[0162] O mecanismo de orquestração 407, então, pode validar um nome de provedor de serviço de nuvem com um serviço de nuvem (480H), e receber uma resposta do serviço de nuvem (4801). O mecanismo de orquestração 407, então, pode invocar um serviço de porta para validar as portas de vendedor e de comprador (480J), e receber uma resposta do serviço de porta que especifica se as portas são válidas para o circuito virtual solicitado (480K). O mecanismo de orquestração 407, então, pode invocar um serviço de provisionamento de serviço de rede (por exemplo, provisionamento de rede serviço 409F, Figura 3B) para configurar automaticamente o circuito virtual dentro da troca em nuvem (480L) e receber uma resposta do serviço de provisionamento de serviço de rede (480M). O mecanismo de orquestração 407, então, pode invocar um serviço de cobrança (por exemplo, serviço de cobrança 409H, Figura 3B) (480N) e receber uma resposta do serviço de cobrança (480O). O mecanismo de orquestração 407, então, pode invocar um API de CSP para completar a criação de circuito virtual (480P), e receber uma resposta da API de CSP (480Q). O mecanismo de orquestração 407 pode incluir as informações de circuito virtual que descrevem, por exemplo, se a criação de circuito virtual foi bem-sucedida, parâmetros de confirmação e parâmetros de conectividade, na resposta do serviço de plataforma de troca em nuvem para a porta de comunicação de API 403 (480R), e a porta de comunicação de API 403, por sua vez, pode fornecer as informações de circuito virtual aos desenvolvedores de API solicitantes 402 (480T).

[0163] Dessa maneira, as técnicas da presente revelação podem ser usadas para tornar as Informações de Ativos de Interconexão, como as informações de Circuitos Virtuais e de Portas disponíveis para desenvolvedores através da interação entre máquinas. Em alguns exemplos, as técnicas da presente revelação podem permitir o acesso a uma Plataforma de interconexão para possibilitar a criação ou modificação de Circuitos Virtuais de larguras de banda variáveis através da interação entre máquinas. Em alguns exemplos, as técnicas da presente revelação podem permitir aos Vendedores (por exemplo, CSPs, NSPs e SP gerenciados (MSPs)) o acesso à Plataforma de interconexão para obter análise personalizada a respeito da presença de concorrentes em diferentes metrôs e centros de dados através da interação entre máquinas.

[0164] Em alguns exemplos, as técnicas da presente revelação podem permitir aos Compradores (por exemplo, NSPs, Empresas) o acesso à Plataforma de Interconexão para obter análise personalizada a respeito da presença de serviço de nuvem em áreas em que os mesmos já têm presença de porta através da interação entre máquinas. Em alguns exemplos, as técnicas da presente revelação podem permitir aos Vendedores (CSPs, NSPs e MSPs) o acesso à Plataforma de interconexão para obter análise personalizada a respeito de densidade de porta de comprador ao longo de diferentes metrôs e centros de dados através de interação entre máquinas. Em alguns exemplos, as técnicas da presente revelação podem permitir uma intercepção de solicitação de API automatizada para validar acesso de parceiro a ativos de interconexão, garantindo, assim, a segurança de ativos de parceiro através da interação entre máquinas. Em alguns exemplos, as técnicas da presente revelação podem permitir acesso sob demanda para definir dinamicamente e desmontar circuitos virtuais através de interação entre máquinas e acesso direto aos recursos de plataforma de interconexão. Em alguns exemplos, as técnicas da presente revelação podem permitir acesso sob demanda para definição de agendamento e desmontagem de circuitos virtuais a intervalos predefinidos através da interação entre máquinas e acesso direto aos recursos de plataforma de interconexão. Em alguns exemplos, as técnicas da presente revelação podem aceitar e Permitir uma solicitação de impulso de velocidade de circuito virtual em determinados momentos pré-agendados para compradores (NSPs e empresas) para capitalizar sobre o uso de largura de banda inferior e possibilitar uma conclusão mais rápida de tarefas de processamento em lote, como cópia de segurança ou restauração de dados através de (impulso de velocidade de) interação entre máquinas.

[0165] Em alguns exemplos, as técnicas da presente revelação podem permitir uma análise detalhada e personalizada do uso de tráfego de circuito virtual ao longo de centros de dados, metrôs e regiões através da interação entre máquinas. Em alguns exemplos, as técnicas da presente revelação podem fornecer recomendações detalhadas e personalizadas através de APIs para desenvolvedores parceiros e times de negócios a respeito da configuração de suas portas e circuitos virtuais para desempenho ideal, interconectividade melhor e de latência baixa através de interação entre máquinas. Em alguns exemplos, as técnicas da presente revelação podem permitir o acesso com base em máquina aos ativos de interconexão através do uso das APIs. Em alguns exemplos, as técnicas da presente revelação podem permitir definição sob demanda de circuitos virtuais entre compradores e vendedores através do uso do ecossistema de API. Em alguns casos, as APIs podem possibilitar uma conectividade muito melhor entre compradores e vendedores através da disponibilidade de descoberta de local, descoberta de ativos, descoberta de serviço de nuvem, análise de tráfego personalizada, análise de uso personalizada, mecanismo de recomendação superior e um sistema de provisionamento de circuito virtual automatizado de ponta a ponta, por exemplo, ao passo que abstrai a complexidade de toda a plataforma de interconexão. As APIs também podem possibilitar um canal seguro para acesso aos ativos de interconexão fora do domínio de troca em nuvem através de parceiros e clientes autenticados e autorizados. A plataforma de API fornece capacidade não incluída para solucionar problemas de segurança (por exemplo, proteção contra ameaças, proteção contra Injeção de SQL, prevenção contra ataque de DDoS, proteção contra bomba de JSON, etc.).

[0166] Os detalhes exemplificativos de uma troca de serviço com base em nuvem são encontrados no Pedido de Patente Provisório no U.S. 62/149.374, intitulado “Cloud-based Services Exchange” e depositado em 17 de abril de 2015, que é incorporado no presente documento, a título de referência, em sua totalidade.

[0167] Os detalhes adicionalmente exemplificativos de trocas de serviços para Ethernet e L3/Internet com emparelhamento de L3/BGP direto são encontrados no documento de Patente no U.S. 8.537.845, intitulado “REAL TIME CONFIGURATION AND PROVISIONING FOR A CARRIER ETHERNET EXCHANGE”, depositado em 13 de setembro de 2012; Pedido de Utilidade Americano, intitulado “REAL TIME CONFIGURATION AND PROVISIONING FOR A CARRIER ETHERNET EXCHANGE”, depositado em 2 de setembro de 2010 que tem o no de série de pedido U.S. 12/875.054, que reivindica o benefício e a prioridade de todos os três: 1) Pedido Provisório Americano, intitulado “ETHERNET EXCHANGE”, depositado em 10 de dezembro de 2009, que tem o no de série de pedido U.S. 61/285.371 e está incorporado no presente documento, a título de referência, em sua totalidade; 2) Pedido Provisório Americano, intitulado “PRIVATE NETWORK CONNECTIVITY PLATFORM”, depositado em 4 de setembro de 2009, que tem o no de série de pedido U.S. 61/239.997 e está incorporado no presente documento, a título de referência, em sua totalidade; e 3) Pedido Provisório Americano, intitulado “ETHERNET EXCHANGE”, depositado em 12 de abril de 2010, que tem no de série de pedido U.S. 61/323.066 e é incorporado no presente documento, a título de referência, em sua totalidade, e Pedido Provisório Americano, intitulado “REAL TIME CONFIGURATION AND PROVISIONING FOR A CARRIER ETHERNET EXCHANGE”, depositado em 2 de setembro de 2010, que tem o no de série de pedido U.S. 12/875.054. Cada um dentre os documentos de patente e pedidos de patente acima está incorporado no presente documento a título de referência em suas respectivas totalidades

[0168] A Figura 12 é um diagrama de blocos que ilustra detalhes adicionais de um exemplo de um dispositivo de computação que opera de acordo com uma ou mais técnicas da presente revelação. A Figura 12 pode ilustrar um exemplo particular de um servidor ou outro dispositivo de computação 500 que inclui um ou mais processadores 502 para executar qualquer uma ou mais dentre a porta de comunicação de API 112 / 403, o mecanismo de orquestração 118 / 407, subsistemas 120, ou qualquer outro dispositivo de computação descrito no presente documento. Outros exemplos de dispositivo de computação 500 podem ser usados em outros casos. Embora seja mostrado na Figura 12 como um dispositivo de computação autônomo 500 para propósitos de exemplo, um dispositivo de computação pode ser qualquer componente ou sistema que inclui um ou mais processadores ou outro ambiente de computação adequado para executar instruções de software e, por exemplo, não precisa incluir necessariamente um ou mais elementos mostrados na Figura 12 (por exemplo, unidades de comunicação 506; e, em alguns componentes exemplificativos, como dispositivo(s) de armazenamento 508 podem não ser colocalizados ou no mesmo chassi como outros componentes). O dispositivo de computação 500 pode ser localizado e executar, por exemplo, dentro de qualquer um dentre pontos de troca em nuvem 128, outra instalação de interconexão, ou em um escritório de filial ou ambiente de computação em nuvem empregados ou usados por um provedor de troca em nuvem.

[0169] Conforme mostrado no exemplo específico da Figura 12, o dispositivo de computação 500 inclui um ou mais processadores 502, um ou mais dispositivos de entrada 504, uma ou mais unidades de comunicação 506, um ou mais dispositivos de saída 512, um ou mais dispositivos de armazenamento 508, e dispositivo de interface de usuário (UI) 510 e unidade de comunicação 506. O dispositivo de computação 500, em um exemplo, inclui adicionalmente um ou mais aplicativos 522, aplicativo de construção de conceito virtual 524 e sistema operacional 516 que são executáveis pelo dispositivo de computação 500. Cada um dentre os componentes 502, 504, 506, 508, 510 e 512 é acoplado (física, comunicativa e/ou operacionalmente) para comunicações intercomponentes. Em alguns exemplos, os canais de comunicação 514 pode incluir um barramento de sistema, uma conexão de rede, uma estrutura de dados de comunicação interprocesso, ou qualquer outro método para dados de comunicação. Como exemplo, os componentes 502, 504, 506, 508, 510 e 512 podem ser acoplados por um ou mais canais de comunicação 514. O dispositivo de computação 500 pode ser localizado e executar, por exemplo, dentro de qualquer um dentre pontos de troca em nuvem 128, outra instalação de interconexão, ou em um escritório de filial ou ambiente de computação em nuvem empregados ou usados por um provedor de troca em nuvem.

[0170] Os processadores 502, em um exemplo, são configurados para implantar instruções de funcionalidade e/ou processo para execução dentro do dispositivo de computação 500. Por exemplo, os processadores 502 têm capacidade para processar instruções armazenadas no dispositivo de armazenamento 508. Os exemplos de processadores 502 podem incluir, qualquer um ou mais dentre um microprocessador, um controlador, um processador de sinal digital (DSP), um circuito integrado específico quanto ao aplicativo (ASIC), uma matriz de porta programável em campo (FPGA), ou um conjunto de circuitos equivalente distinto ou integrado.

[0171] Um ou mais dispositivos de armazenamento 508 podem ser configurados para armazenar informações dentro do dispositivo de computação 500 durante a operação. O dispositivo de armazenamento 508, em alguns exemplos, é descrito como um meio de armazenamento legível por computador. Em alguns exemplos, o dispositivo de armazenamento 508 é uma memória temporária, o que significa que um propósito primário do dispositivo de armazenamento 508 é armazenamento de não longo prazo. O dispositivo de armazenamento 508, em alguns exemplos, é descrito como uma memória volátil, o que significa que o dispositivo de armazenamento 508 não mantém conteúdos armazenados quando o computador está desligado. Os exemplos de memórias voláteis incluem memórias de acesso aleatório (RAM), memórias de acesso aleatório dinâmico (DRAM), memórias de acesso aleatório estático (SRAM) e outras formas de memórias voláteis conhecidas na técnica. Em alguns exemplos, o dispositivo de armazenamento 508 é usado para armazenar instruções de programa para execução através de processadores 502. O dispositivo de armazenamento 508, em um exemplo, é usado por software ou aplicativos que funcionam no dispositivo de computação 500 para armazenar temporariamente informações durante a execução do programa.

[0172] Os dispositivos de armazenamento 508, em alguns exemplos, também incluem uma ou mais mídias de armazenamento legíveis por computador. Os dispositivos de armazenamento 508 podem ser configurados para armazenar quantidades de informações maiores do que a memória volátil. Os dispositivos de armazenamento 508 podem ser adicionalmente configurados para armazenamento de longo prazo de informações. Em alguns exemplos, os dispositivos de armazenamento 508 incluem elementos de armazenamento não volátil. Os exemplos de tais elementos de armazenamento não volátil incluem discos rígidos magnéticos, discos ópticos, disquetes, memórias flash, ou formas de memórias eletricamente programáveis (EPROM) ou memórias eletricamente apagáveis e programáveis (EEPROM).

[0173] O dispositivo de computação 500, em alguns exemplos, também inclui uma ou mais unidades de comunicação 506. O dispositivo de computação 500, em um exemplo, utiliza unidades de comunicação 506 para se comunicar com dispositivos externos por meio de uma ou mais redes, como uma ou mais redes com fio/sem fio/móveis. As unidades de comunicação 506 podem incluir um cartão de interface de rede, como um cartão de Ethernet, um transceptor óptico, um transceptor de radiofrequência ou qualquer outro tipo de dispositivo que possa enviar e receber informações. Outros exemplos de tais interfaces de rede podem incluir rádios de 3G e WiFi. Em alguns exemplos, o dispositivo de computação 500 usa a unidade de comunicação 506 para se comunicar com um dispositivo externo.

[0174] O dispositivo de computação 500, em um exemplo, também inclui um ou mais dispositivos de interface de usuário 510. Os dispositivos de interface de usuário 510, em alguns exemplos, são configurados para receber entrada de um usuário através de retroalimentação tátil, de áudio ou de vídeo. Os exemplos de dispositivos de interface de usuários 510 incluem um visor sensível à presença, um mouse, um teclado um sistema responsivo à voz, câmera de vídeo, microfone ou qualquer outro tipo de dispositivo para detectar um comando de um usuário. Em alguns exemplos, um visor sensível à presença inclui uma tela sensível ao toque.

[0175] Um ou mais dispositivos de saída 512 também podem ser incluídos no dispositivo de computação 500. O dispositivo de saída 512, em alguns exemplos, é configurado para fornecer saída a um usuário com o uso de estímulos tátil, de áudio ou de vídeo. O dispositivo de saída 512, em um exemplo, inclui um visor sensível à presença, um cartão sonoro, um cartão de adaptador de gráfico de vídeo ou qualquer outro tipo de dispositivo para converter um sinal em uma forma adequada para seres humanos ou máquinas. Os exemplos adicionais do dispositivo de saída 512 incluem um alto-falante, um monitor de tubo de raios de cátodo (CRT), um visor de cristal líquido (LCD) ou qualquer outro tipo de dispositivo que possa gerar saída inteligível a um usuário.

[0176] O dispositivo de computação 500 pode incluir sistema operacional 516. O sistema operacional 516, em alguns exemplos, controla a operação de componentes de dispositivo de computação 500. Por exemplo, o sistema operacional 516, em um exemplo, facilita a comunicação de um ou mais aplicativos 522 e aplicativo(s) de plataforma de interconexão 524 com processadores 502, unidade de comunicação 506, dispositivo de armazenamento 508, dispositivo de entrada 504, dispositivos de interface de usuário 510 e dispositivo de saída 512.

[0177] O aplicativo 522 e o(s) aplicativo(s) de plataforma de interconexão 524 também podem incluir instruções de programa e/ou dados que são executáveis pelo dispositivo de computação 500. O(s) aplicativo(s) de plataforma de interconexão exemplificativos 524 executáveis pelo dispositivo de computação 500 podem incluir qualquer um ou mais dentre o módulo de mecanismo de orquestração 550, o módulo de porta de comunicação de API 552 e subsistemas 554, cada um ilustrado com linhas tracejadas para indicar que esses podem ser ou não ser executados por qualquer determinado exemplo de dispositivo de computação 500.

[0178] O módulo de mecanismo de orquestração 550 pode incluir instruções para fazer com que o dispositivo de computação realize uma ou mais dentre as operações e ações descritas na presente revelação em relação ao mecanismo de orquestração 118 e ao mecanismo de orquestração 407. Como exemplo, o módulo de mecanismo de orquestração 550 pode incluir instruções que fazem com que o dispositivo de computação 500 organize, direcione e integre subsistemas de software subjacentes da plataforma de interconexão para uma troca em nuvem para gerenciar vários aspectos de interconexão dentro da infraestrutura de rede, assim como gerenciamento de serviços de nuvem. O módulo de mecanismo de orquestração 550, por exemplo, pode fornecer um mecanismo de fluxo de trabalho acionado por regra que opera entre as APIs e a plataforma de interconexão subjacente de uma troca em nuvem que inclui subsistemas e infraestrutura de rede.

[0179] O módulo de porta de comunicação de API 552 pode incluir instruções para fazer com que o dispositivo de computação realize uma ou mais dentre as operações e ações descritas na presente revelação em relação á porta de comunicação de API 112 à porta de comunicação de API 403. Como exemplo, o módulo de porta de comunicação de API 403 pode incluir instruções que fazem com que o dispositivo de computação 500 exponha uma coleção de interfaces de software, por exemplo, APIs 114, que definem os métodos, campos e/ou outros primitivos de software, através dos quais os aplicativos podem invocar a plataforma de interconexão. Essas interfaces de software permitem às portadoras e aos clientes acesso programável às capacidades e ativos de uma troca em nuvem.

[0180] Os subsistemas 554 podem incluir instruções para fazer com que o dispositivo de computação realize uma ou mais dentre as operações e ações descritas na presente revelação em relação aos subsistemas 120.

[0181] A Figura 13 é um diagrama de blocos que ilustra um sistema de troca em nuvem exemplificativo 700 que mostra uma arquitetura lógica exemplificativa de um mecanismo de orquestração 704 em maiores detalhes. O mecanismo de orquestração 704 pode representar, por exemplo, qualquer um dentre o mecanismo de orquestração 118 (Figuras 1A a 1C e Figura 2), o mecanismo de orquestração 407 (Figuras 3A a 3B, 4 a 5, 7 a 11) e o módulo de mecanismo de orquestração 550 do dispositivo de computação 500 (Figura 12).

[0182] O mecanismo de orquestração 704 opera como parte de uma plataforma de interconexão geral (por exemplo, plataforma de interconexão 103 das Figuras 1B, 1C) para definir continuamente os ativos de interconexão que incluem conexões virtuais (por exemplo, circuitos virtuais) entre compradores e vendedores, como entre uma empresa e um provedor de serviço de nuvem. No exemplo da Figura 13, o mecanismo de orquestração 704 inclui dois componentes principais: orquestrador 706 e microsserviços 708 fornecidos pelo sistema de troca em nuvem 700. O mecanismo de orquestração 704 também inclui mecanismo de descoberta de serviço 710 e gerenciador de processo 712. O mecanismo de orquestração 704 pode representar um aplicativo centralizado ou distribuído e pode executar em um dispositivo de gerenciamento, como uma ou mais máquinas virtuais e/ou servidores reais de centro de dados 101 (Figura 1A).

[0183] Cada um dentre os microsserviços 708 implanta um conjunto de recursos e funções focados e distintos, e um microsserviço se conforma a (ou é utilizável em) um padrão de arquitetura em que muitas dúzias ou até mesmo centenas de microsserviços podem ser independentemente desenvolvidos e instalados. O microsserviço 708 pode ser organizado ao redor de uma capacidade de negócios (por exemplo, mecanismo de plataforma de API 726, interfaces de REPOUSO 728, conexão de soquete 730, monitoramento 732 e notificações 734) e podem implantar uma “pilha ampla” de software para a capacidade de negócios, que inclui armazenamento persistente e qualquer colaboração externa. Os vários microsserviços 708 expõem as interfaces que possibilitam que os microsserviços 708 invoquem umas às outras para trocar dados e realizar os respectivos conjuntos de funções a fim de criar um aplicativo geral. Em alguns exemplos, os microsserviços 708 podem representar ou incluir outros exemplos de microsserviço descritos na presente revelação, por exemplo, microsserviços para implantar serviços de troca em nuvem 409, serviços de consulta de API 422A, serviços de comando de API 422B, serviços de faixada de integração 422C, quaisquer microsserviços fornecidos por subsistemas 120 e microsserviços 308D.

[0184] Cada um dentre os microsserviços 708 pode aderir a uma Interface de Programação de Aplicativo (API) bem definida e pode ser orquestrado, invocando-se a API do microsserviço 708, de acordo com um fluxo de trabalho realizado pelo orquestrador 706. O componente orquestrador 706 “orquestra” os microsserviços 706 com base em regras ou fluxo de trabalho definidos para várias APIs expostas pelo orquestrador 706 (por exemplo, por meio de um servidor/porta de comunicação de API como as portas de comunicação de API 112, 403 e 718) e invocáveis por solicitações de API que se conformam com os respectivos contratos de API. O orquestrador 706 pode manusear solicitações de API geralmente seguindo-se um conjunto estabelecido de regras, ou fluxos de trabalho, que permitem que um contrato de API completamente personalizável para cada canal externo para consumidores de API , independentemente de ser uma API de portal, de aplicativo móvel ou de desenvolvedor, por exemplo. O fluxo de trabalho pode ser implantado em alguns exemplos como uma máquina de estado. Devido à variabilidade nenhum contrato de solicitação/resposta para cada canal, o orquestrador 706 descrito na presente revelação pode englobar e fornecer suporte igual para as diferenças ao longo de canais diferentes.

[0185] O mecanismo de orquestração 704 organiza, direciona e integra subsistemas de software e de rede subjacentes para gerenciar vários aspectos de interconexão par a troca em nuvem. O orquestrador 706 do mecanismo de orquestração 704, por exemplo, pode executar um mecanismo de fluxo de trabalho acionado por regra que opera entre as APIs e a plataforma de interconexão subjacente da troca. Por exemplo, o orquestrador 706 pode corresponder ao mecanismo de fluxo de trabalho e de regras 306 da Figura 2 que opera de acordo com as políticas 308A. Dessa maneira, o mecanismo de orquestração 704 pode ser usado por aplicativos de cliente-proprietário e as APIs para participação direta com a plataforma de interconexão da troca em nuvem.

[0186] Conforme descrito no presente documento, o mecanismo de orquestração 704 sintetiza as informações e ações de subsistemas subjacentes da plataforma de interconexão para formular as etapas e respostas seguintes inteligentes para solicitações dinâmicas realizadas pelos aplicativos de cliente. Desse modo, o mecanismo de orquestração 704 abstrai a complexidade dos subsistemas de software e rede subjacentes da troca em nuvem fornecendo-se um meio uniforme, simplificado e seguro para acessar a plataforma de interconexão.

[0187] No exemplo da Figura 13, o sistema de troca em nuvem 700 fornece múltiplas plataformas que permitem o acesso à funcionalidade de troca em nuvem fornecida pelo sistema de troca em nuvem 700, que inclui proxy de web 714, portal de web de SaaS 716 e porta de comunicação de API 718. O mecanismo de orquestração 704 atende a todas as solicitações provenientes dessas plataformas, independentemente da possibilidade de as solicitações terem sido realizadas por meio de portal de troca em nuvem 713, portal de etiqueta branca 715 desenvolvido pelo provedor de troca em nuvem, porém, etiquetado para o cliente e as APIs 717. Por exemplo, o proxy de web 714, o portal de web de SaaS 716 e o proxy de Web 714, o portal de web de SaaS 716 e a porta de comunicação de API 718 representam diferentes canais para solicitações para acessar o orquestrador 706. Por exemplo, um cliente pode usar um aplicativo da web para realizar logon no portal 713 e acessar serviços da plataforma de interconexão. Como outro exemplo, um cliente ou desenvolvedor pode usar APIs para acessar dados de troca em nuvem. O mecanismo de orquestração 704 pode receber solicitações inseridas com o uso de um portal de troca em nuvem 713 por meio de proxy de web 714. O mecanismo de orquestração 704 pode receber solicitações inseridas com o uso de um portal de etiqueta branca 715 por meio de um portal de web de SaaS 716. O mecanismo de orquestração 704 pode se comunicar com o portal de web de SaaS 716 (por exemplo, um portal de CSP) com o uso de um protocolo de rede como Protocolo de Transferência de HyperTexto (HTTP), por exemplo, ou outro protocolo de rede. O mecanismo de orquestração 704 pode receber solicitações inseridas com o uso das APIs 717 por meio de uma porta de comunicação de API 718. A porta de comunicação de API 718 pode representar qualquer uma dentre as portas de comunicação de API descritas no presente documento e usa mecanismo de descoberta de serviço 710 para identificar os exemplos de serviço para os quais rotear solicitações recebidas por meio das APIs 717.

[0188] Conforme descrito brevemente acima, os microsserviços 708 representam funções de troca em nuvem que são decompostas em serviços menores (microsserviços) organizadas ao redor da capacidade de negócios. Os microsserviços 708 podem executar uma implantação de software de pilha ampla para tal área de negócios, inclusive armazenamento persistente e qualquer colaboração externa, como com sistemas de terceiros 724.

[0189] O orquestrador 706 recebe uma solicitação do proxy de web 714, do portal 716 ou da porta de comunicação de API 718 e coordena continuamente múltiplos microsserviços de microsserviços 708 para atender à solicitação. Por exemplo, com base na solicitação recebida, o orquestrador 706 pode determinar um fluxo de trabalho que chama automaticamente os microsserviços necessários para atender à solicitação. Por exemplo, a porta de comunicação de API 718 passa uma entrada, o mecanismo de orquestração 704 processa a entrada, chama múltiplos microsserviços 708 e obtém dados necessários para satisfazer os contratos necessários pela API e envia uma resposta à API que inclui os dados necessários pela API. Por exemplo, para criar um circuito virtual, p orquestrador 706 precisa de múltiplos pontos de extremidade de microsserviço. Por exemplo, o orquestrador 706 precisa de um metrô, uma porta e informações de cobrança. Essas são todas APIs internas que são continuamente orquestradas através do orquestrador 706, conforme descrito no presente documento. Como uma operação de solicitação/resposta, a API (por exemplo) pode invocar o microsserviço de metrô, e o mecanismo de orquestração invoca uma rotina de metrô gerenciada (fluxo de trabalho) e realiza os serviços exigidos para atender à solicitação em relação àquela rotina de metrô, por meio do microsserviço e, então, envia de volta quaisquer dados relevantes à operação. O mecanismo de orquestração 704 pode invocar os conectores de provedor de serviço de nuvem de um dos microsserviços. Dessa maneira, o mecanismo de orquestração 704 fornece o serviço ou dados solicitados pelo cliente de uma maneira contínua, de modo que o cliente não fique ciente dos detalhes subjacentes dos microsserviços individuais que são invocados de acordo com o fluxo de trabalho selecionado pelo orquestrador 706 para atender à solicitação do cliente.

[0190] Em alguns exemplos, os microsserviços 708 podem representar microsserviços desenvolvidos e fornecidos por provedores de serviço de nuvem. Ou seja, o orquestrador 706 pode invocar uma interface de provedor de serviço de nuvem acessível por meio de um dentre os microsserviços. Por exemplo, Azure (fornecida pela Microsoft Corporation) por fornecer serviços de nuvem e expor uma interface acessível por um dentre os microsserviços 708 desenvolvidos para o propósito de gerenciar os serviços de nuvem. O orquestrador 706 pode chamar uma interface RESTful (um exemplo de uma “API de CSP” descrita em outra parte no presente documento) para o microsserviço fornecido por Azure para atender uma parte da funcionalidade. Por exemplo, para criar uma conexão virtual do aplicativo de troca em nuvem com um provedor de serviço de nuvem, o mecanismo de orquestração 704 pode invocar um microsserviço fornecido por Azure para realizar determinadas funções, como habilitar uma porta. Após invocar o microsserviço fornecido por Azure, o orquestrador pode invocar outros microsserviços para implantar o fluxo de trabalho geral. Por exemplo, o orquestrador, então, pode invocar os microsserviços de ordem, validação e/ou autenticação. Os pontos de extremidade de API/canais RESTful podem fornecer acessibilidade aos microsserviços.

[0191] No exemplo da Figura 13, os microsserviços 708 incluem uma API de mecanismo de documento de API interna 726 (“API Doc Engine”), o microsserviço de interface REST 728, microsserviço de conexão de soquete 730, microsserviço de monitoramento 732, microsserviço de notificações 734 e enquadramento de serviço de API 722. O mecanismo de orquestração 704 também usa enquadramento de serviço de API interno 722 para interagir com vários sistemas internos ou de terceiros por meio das APIs, ao invocar um ou mais dentre os microsserviços 708. Os microsserviços 708 podem apresentar interfaces de API ao orquestrador 706 e executar no enquadramento de serviço de API 722. As APIs 721A a 721C (“APIs 721”) podem ser chamadas de componentes de uma camada de microsserviços de mecanismo de orquestração 704 e podem ser consideradas pontos de extremidade de microsserviço. As APIs 721 não são APIs voltadas para cliente.

[0192] No exemplo da Figura 13, o mecanismo de orquestração 704 usa enquadramento de serviço de API 722 para interagir com os sistemas de empresa 720 por meio da API privada 721A. O mecanismo de orquestração 704 usa enquadramento de serviço de API 722 para interagir com outros sistemas 723 por meio da API privada 721B. O mecanismo de orquestração 704 usa o enquadramento de serviço de API 722 para interagir com sistemas de terceiros por meio de uma API pública 721C e para integrar as plataformas de serviços com base em nuvem na troca em nuvem.

[0193] A Figura 14 é um diagrama de blocos que ilustra um sistema exemplificativo 800 que mostra uma arquitetura de referência para um mecanismo de orquestração 704 em maiores detalhes. O mecanismo de orquestração 704 pode representar, por exemplo, qualquer um dentre o mecanismo de orquestração 118 (Figuras 1A a 1C e Figura 2), o mecanismo de orquestração 407 (Figuras 3A a 3B, 4 a 5, 7 a 11), o módulo de mecanismo de orquestração 550 do dispositivo de computação 500 (Figura 12), o mecanismo de orquestração 704 da Figura 13. Como exemplo, o sistema 800 pode representar uma vista lógica diferente do sistema de troca em nuvem 700 da Figura 13.

[0194] O mecanismo de orquestração 704 opera como parte de uma plataforma de interconexão geral (por exemplo, plataforma de interconexão 103 das Figuras 1B, 1C) para definir continuamente os ativos de interconexão que incluem conexões virtuais (por exemplo, circuitos virtuais) entre compradores e vendedores, como entre uma empresa 840 e um provedor de serviço de nuvem 842. Por exemplo, o mecanismo de orquestração 704 pode definir continuamente os circuitos virtuais 150, 155, 160, 165, 170 entre os sistemas de cliente 196 da Figura 1C.

[0195] O mecanismo de orquestração 704 pode representar aplicativos centralizados ou distribuídos e pode executar em um dispositivo de gerenciamento, como uma ou mais máquinas virtuais e/ou servidores reais de centro de dados 101 (Figura 1A). O mecanismo de orquestração 704 pode receber solicitações para ativos de interconexão de vários sistemas de cliente. Por exemplo, o mecanismo de orquestração 704 pode receber solicitações de administradores internos (isto é, administradores que pertencem à mesma entidade que o mecanismo de orquestração 704) (“admin”), provedores de serviço de rede (NSP), provedores de serviço de nuvem (CSP) 842, empresas 840 e desenvolvedores. O mecanismo de orquestração 804 pode receber as solicitações em proxy de web 810 por meio do navegador 812A, em SaaS de etiqueta branca 814 por meio do navegador 812B ou na porta de comunicação de API 816 por meio da API 818.

[0196] O orquestrador 806 pode gerenciar fluxos de trabalho para realizar tais funções como gerenciar a porta, gerenciar o metrô, detalhes de CSP, gerenciamento de ordem, visualizar o circuito virtual, excluir o circuito virtual, pesquisar, suporte e tíquetes, monitoramento e estatística, análise e recomendação, por exemplo. O orquestrador 806 também pode realizar funções adicionais não mostradas, inclusive aquelas descritas acima em relação ao mecanismo de orquestração 407. Em alguns exemplos, o orquestrador 806 pode manter uma biblioteca de fluxos de trabalho, a partir da qual o orquestrador pode selecionar e carregar um fluxo de trabalho adequado em resposta ao recebimento de uma solicitação por meio de qualquer um dentre os canais mencionados acima.

[0197] Em alguns exemplos, o mecanismo de orquestração 704 pode funcionar como um conjunto de máquinas virtuais executado em um dispositivo de rede de servidor. O mecanismo de orquestração 704 pode ser construído e executado em uma plataforma de aplicativo de software como Node.js. Os microsserviços podem ser habilitados com o uso de um enquadramento de aplicativo de web. Os microsserviços e fluxos de trabalho podem ser construídos e executado como aplicativos distribuídos em recipientes de software. O mecanismo de orquestração 704 pode usar caching de grade em memória com o uso de um banco de dados de disco em memória e persistente.

[0198] Os aspectos do mecanismo de orquestração 704 podem ser embutidos no Node.js ou em outra plataforma semelhante que fornece, por exemplo, uma arquitetura acionada por evento e uma API de I/O de não bloqueio projetada para otimizar um rendimento e escalabilidade do aplicativo para aplicativo da web em tempo real. O node.js é uma plataforma leve de origem aberta tem facilita sistemas livremente acoplados e escalonáveis que se comunicam com o uso de, por exemplo, HTTP e JSON, que são embutidos no Node.js. Isso pode facilitar os princípios de projeto de microsserviço para criar e instalar microsserviços 708.

[0199] O orquestrador 706 pode usar máquinas de estado para implantar fluxos de trabalho que invocam múltiplos microsserviços 706 em um ordenamento definido para satisfazer um contrato de API. Os microsserviços 706 (e múltiplos exemplos de cada um dentre os microsserviços 706) podem ser instalados em recipientes separados para isolamento e modularidade ao mesmo tempo que também fornece qualidade e confiabilidade aprimoradas com teste, realização de logon, monitoramento e estratégias diagnósticas integradas. A tecnologia de recipiente é um mecanismo para implantar unidades de trabalho ao longo de um vasto agrupamento de recursos de computação e se tornou uma estratégia de implantação estratégica para escalabilidade. Os microsserviços e os recipientes fornecem uma convergências de abordagens técnicas a sistemas escaláveis de construção. Node.js é uma plataforma de origem aberta que é otimizada para construir processos de comunicação altamente escalonáveis leve assíncronos e expor as APIs a qualquer consumidor da Web. O mecanismo de orquestração 704 pode impulsionar o Node.js, os microsserviços e recipientes, para implantação e instalação como uma plataforma de interconexão com base em microsserviços para uma troca de serviços com base em nuvem.

[0200] O mecanismo de orquestração 704 também inclui funcionalidade para chamar funções de utilidade 819 que incluem enquadramento de erro, realização de logon, administração, notificações, auditoria e monitoramento, por exemplo. As funções de utilidade 819 podem incluir um gerenciador de processo para manter aplicativos ativos com tempo de inatividade igual a zero, e que realize monitoramento de processo, observação de registro de processo, gerenciamento de memória e similares.

[0201] A Figura 14 também ilustra uma pluralidade de microsserviços internos 708 de mecanismo de orquestração 704 que incluem, por exemplo, circuito virtual, porta, grupo de agregação de enlace (LAG), metrô, detalhe de CSP, Qualidade de Serviço (QoS), serviço de cliente e emissão de tíquete, pesquisa (por exemplo, CSP, NSP, locais, portas, circuitos virtuais), inventário de ativos e de rede, língua e definições de serviço. Os microsserviços 708 apresentam APIs internas individuais (ou seja, internas para o mecanismo de orquestração 706 e não expostas por meio da API 818, por exemplo) ou pontos de extremidade de microsserviço. Em alguns exemplos, os microsserviços 708 podem corresponder aos microsserviços 308D da Figura 2. Por exemplo, a API interna de “metrô” de microsserviços 708 corresponde a uma interface de microsserviço para uma operação de metrô que é interna ao mecanismo de orquestração 704. Um cliente de API como um dentre os clientes de API 402 (Figura 3A) pode solicitar um metrô por meio da API de metrôs voltada para cliente 406C das APIs 114 (Figura 3A), e o orquestrador 706 irá traduzir da API de metrôs voltada para cliente 406C para o microsserviço de metrô interno 806. O orquestrador 706 pode selecionar um fluxo de trabalho que une os microsserviços individuais que são necessários para satisfazer a operação de APO de metrô voltada para cliente.

[0202] O mecanismo de orquestração 704 também inclui funcionalidade para chamar trabalho assíncronos 817, inclusive o provisionamento/desprovisionamento manual, agendador de ordem, atualizador de situação de ordem, estatísticas de uso, provedor de serviço de nuvem descoberta de local, por exemplo. O orquestrador 706 pode chamar esses trabalho assincronamente.

[0203] O mecanismo de orquestração 704 pode fazer interface com vários subsistemas 820A a 820F (“subsistemas 820”), como o sistema de gerenciamento de conteúdo 820A, sistemas de gerenciamento de tráfego 820B, sistema de gerenciamento de incidência 820C, sistema de gerenciamento de porta 820D, sistema de gerenciamento de ID e acesso 820E e sistema de gerenciamento de ordem 820F, por exemplo. Os subsistemas 820 podem corresponder aos subsistemas 120 das Figuras 1B, 1C, 2 e 4, por exemplo. Por exemplo, o sistema de gerenciamento de conteúdo 820A inclui dados associados ao conteúdo que pode ser distribuído por meio de um portal de aplicativo da web, como o portal de web de SaaS 716. Por exemplo, os sistemas de gerenciamento de tráfego 820B fornecem dados relacionados ao tráfego para tráfego de plataforma de troca em nuvem interna, como no nível de porta ou nível de circuito virtual. Em um exemplo, quando o orquestrador 706 seleciona um fluxo de trabalho para fornecer uma função relacionada ao suporte e tíquetes, o orquestrador 706 usa um dentre os microsserviços 708 (por exemplo, o microsserviço de serviço de cliente e emissão de tíquete) para fazer interface com um dentre os subsistemas 820, como o sistema de gerenciamento de incidência 820C, de acordo com o fluxo de trabalho selecionado. O microsserviço pode se conectar com um banco de dados, se conectar com o uso de uma API de REST, se conectar com o uso de uma chamada de JSON, ou outro mecanismo, para fazer interface com os subsistemas 820.

[0204] Em alguns exemplos, os subsistemas 820 podem aplicar as tarefas de serviço orquestradas pelo mecanismo de orquestração 118, que podem incluir modificar qualquer um dentre os pontos de troca em nuvem 128 para realizar a definição sob demanda de circuitos virtuais entre CSPs 842 e empresas 840, por exemplo, ou, de outro modo, gerenciar ativos de interconexão de troca em nuvem como largura de banda, perfis e configuração de portas, metrôs, centros de dados, circuitos virtuais e circuito virtual.

[0205] O mecanismo de orquestração 704 pode fazer interface com um ou mais controladores de SDN 832 para a infraestrutura de rede da troca de serviços com base em nuvem. Os controladores de SDN 832 podem estar situados dentro do centro de dados de plataforma de troca em nuvem, como o centro de dados 101 da Figura 1. Os controladores de SDN 832 podem ser usados para conectar comutadores entre o ponto A e o ponto B dentro de uma infraestrutura de rede de troca em nuvem. As técnicas para orquestrar controladores de SDN no contexto de uma troca de serviços com base em nuvem são descritas em maiores detalhes no Pedido de Patente Provisório no U.S. 62/164.965, depositado em 21 de maio de 2015 e intitulado “Active Panel Demarcation”; e no Pedido de Patente Provisório no U.S. 62/216.804, depositado em 10 de setembro de 2015 e intitulado “Automated Fiber Cross-connect Service within a Multi-tenant Interconnection Facility;” em que cada um dos mesmos está incorporado, a título de referência, no presente documento em sua totalidade.

[0206] A Figura 15 é um fluxograma que ilustra um fluxo de trabalho exemplificativo realizado por um mecanismo de orquestração de acordo com aspectos exemplificativos da presente revelação. Para propósitos de exemplo, a Figura 15 é descrita em relação ao mecanismo de orquestração 704 das Figuras 13 e 14, porém, de modo semelhante, pode se aplicar a outros exemplos de um mecanismo de orquestração descrito no presente documento.

[0207] O mecanismo de orquestração 704 recebe solicitações de cliente para serviços de plataforma de troca em nuvem, como por meio do portal de troca em nuvem 814 ou da porta de comunicação de API 816 (1500). O mecanismo de orquestração 704 envia a solicitação de cliente por serviços de plataforma de troca em nuvem para o orquestrador 706 (1502). Com base na solicitação de cliente, o orquestrador 706 seleciona um fluxo de trabalho de uma biblioteca ou pasta de fluxo de trabalho (por exemplo, pasta de fluxos de trabalho 1612 da Figura 16, que inclui os fluxos de trabalho WF1, WF2, WF3 e WF4), em que o fluxo de trabalho selecionado contém o conjunto de tarefas necessário para atender à solicitação através de chamadas de microsserviço (1504). Por exemplo, o orquestrador 706 pode selecionar o fluxo de trabalho com base em regras configuradas ou políticas (por exemplo, políticas 308A da Figura 2) e/ou com base em um perfil associado ao cliente (por exemplo, perfis 308B da Figura 2). O orquestrador 706 irá carregar automaticamente o fluxo de trabalho selecionado e executar os microsserviços de acordo com o fluxo de trabalho (por exemplo, sequencial e/ou paralelamente) (1506). A pasta de fluxos de trabalho 1612 contém fluxos de trabalho que foram anteriormente definidos (por exemplo, através de desenvolvedores de troca em nuvem) para cada ponto de extremidade de cliente. Por exemplo, pode haver um primeiro fluxo de trabalho definido para um ponto de extremidade de cliente de metrô e um segundo fluxo de trabalho definido para um ponto de extremidade de cliente de porta. Os fluxos de trabalho fornecem um conjunto de lógica que usa uma ou mais máquinas de estado como um guia para indicar como transferir de um estado para outro para atender à solicitação. Um fluxo de trabalho define uma orquestração de tarefas. Os fluxos de trabalho fornecem uma forma para decompor uma série de operações complexas para uma sequência de tarefas discretas dentro de uma máquina de estado e executadas por microsserviços para satisfazer solicitações recebidas por meio de diferentes canais de solicitação como portais e API. Cada solicitação pode ter contratos de domínio associados diferentes. Para uma determinada solicitação, o orquestrador 706 seleciona um fluxo de trabalho que usa uma sequência de tarefas distintas dentro de uma máquina de estado para satisfazer o contrato de domínio associado à solicitação.

[0208] Os microsserviços, então, retornam respectivas respostas ao orquestrador 706 (1508). As respostas podem incluir dados fornecidos pelo microsserviço. O orquestrador 706 consolida os dados recebidos nas respostas de cada um dentre os fluxos de trabalho, conforme for necessário para atender à solicitação de cliente (1510). O mecanismo de orquestração 704, então, responde à solicitação de cliente para serviços de troca em nuvem (1512).

[0209] Nesse contexto, os microsserviços são pontos de extremidade, e uma tarefa está em ação atualmente, em execução para atender a uma solicitação. Uma tarefa pode ser chamar um conjunto de microsserviços (pontos de extremidade), coletivamente. Quando se chama um ponto de extremidade particular, alguns dados são retornados, os quais podem ser dados para serem usados pelo próximo ponto de extremidade, em uma sequência. Dessa maneira, o fluxo de trabalho pode definir uma sequência de tarefas a serem concluídas, em que os dados obtidos em uma tarefa podem ser usados na, e/ou podem determinar a próxima tarefa.

[0210] Como exemplo, um cliente de troca em nuvem pode querer se conectar a múltiplos diferentes provedores de serviço de nuvem por meio da plataforma de troca em nuvem. Nessa situação, o orquestrador 706 precisa chamar múltiplas APIs. Em outro exemplo, um provedor de serviço de nuvem pode criar um modelo para ativação de novos clientes e fornecer o modelo ao orquestrador, e o orquestrador pode facilmente usar o modelo para ativação de novos clientes que queiram se conectar com o provedor de serviço de nuvem. O orquestrador 706 pode orquestrar qualquer tipo de fluxos de trabalho, e mais de um cliente pode usar os fluxos de trabalho. O mesmo fluxo de trabalho pode ser usado por diferentes clientes para executar a funcionalidade que os mesmos precisam (por exemplo, criar um circuito virtual). Vários fluxos de trabalho exemplificativos são ilustrados e descritos em relação às Figuras 5 a 11 e 16 a 17.

[0211] A Figura 16 é um diagrama lógico exemplificativo que ilustra um fluxo de trabalho de mecanismo de orquestração exemplificativo relacionado à criação de um circuito virtual. Nesse exemplo, o orquestrador 706 recebe uma solicitação de cliente 1622 que invoca um ponto de extremidade de API de “/circuito virtual”, exposto pelo orquestrador 706, para provisionar um circuito virtual na troca de serviços com base em nuvem entre o cliente e um provedor de serviço de nuvem. O orquestrador 706 seleciona um fluxo de trabalho para provisionamento de um circuito virtual a partir da pasta de fluxos de trabalho 1612, carrega o fluxo de trabalho selecionado e envia por push um novo trabalho para o armazenamento de estrutura de dados 1610. O orquestrador 706 também é inscrito no servidor publicação-inscrição 1620 para situação de trabalho.

[0212] O fluxo de trabalho especifica um conjunto de tarefas. Por exemplo, o fluxo de trabalho para provisionamento do circuito virtual especifica um conjunto de tarefas que compreende: (i) obter detalhes de porta, (ii) obter detalhes de metrô e (iii) criar o circuito virtual com base nos detalhes de porta e nos detalhes de metrô. o orquestrador 706 pode distribuir tarefas do conjunto de tarefas ao longo de uma pluralidade de execuções de fluxo de trabalho 1616A a 1616D, que acessam um ou mais dentre os microsserviços 1630A a 1630D (pontos de extremidade) para realizar as tarefas. As execuções de fluxo de trabalho 1616 podem selecionar trabalhos a partir de uma fila mantida pelo armazenamento de estrutura de dados 1610. Em alguns exemplos, cada tarefa em um fluxo de trabalho selecionado pode ser executada em um encadeamento diferente. As tarefas podem ser executadas paralela ou sequencialmente. Conforme cada tarefa é finalizada, o servidor publicação-inscrição 1620 é atualizado e o servidor publicação-inscrição 1620 notifica o orquestrador 706. Por exemplo, “Trabalho Finalizado” é um método que é chamado uma vez que a execução do fluxo de trabalho é finalizada. Quando o orquestrador 706 determina que o circuito virtual foi estabelecido, o orquestrador 706 pode notificar o cliente que realizou a solicitação, por exemplo, retornando-se uma resposta de HTTP.

[0213] Em alguns casos, a sequência de tarefas em um fluxo de trabalho pode ser mais complexa do que apenas tarefas realizadas em uma série. As tarefas podem falhar e, então, o orquestrador 706 pode, por vezes, precisar lidar com esgotamentos de tempo, novas tentativas, fluxos “travados” e assim por diante. Uma forma de definir um fluxo de trabalho e suas tarefas é com o uso de uma linguagem arbitrariamente complexa. Outra forma pode envolver realizar suposições, como: (1) Código é a linguagem de definição; (2) Tarefas são independentes e podem ser usadas em diferentes fluxos de trabalho; (3) A única forma de se comunicar entre tarefas é o fluxo de trabalho. As tarefas podem adicionar, remover ou modificar propriedades do fluxo de trabalho. (4) Se uma tarefa exigir que uma propriedade específica do fluxo de trabalho esteja presente, a tarefa pode falhar ou se reagendar dentro do fluxo de trabalho. O sistema deve ser projetado com falhas em mente. As tarefas podem falhar e, como consequência, os fluxos de trabalho podem falhar. O orquestrador 706 pode precisar se recuperar de uma falha de tarefa, ou de um uma falha da totalidade do fluxo de trabalho. Em alguns exemplos, o orquestrador 706 usa um mecanismo de descoberta de serviço 710 (Figura 13) para descobrir um microsserviço alternativo para usar quando uma primeira tarefa falhar devido ao microsserviço não responder adequadamente ou retornar uma mensagem de erro.

[0214] Por exemplo, se houver cinco tarefas de microsserviço que o orquestrador 706 precisa executar para fornecer um serviço de troca em nuvem, o gerenciador de processo 712 do mecanismo de orquestração 704 pode decidir executar as tarefas paralela ou sequencialmente. Se o orquestrador 706 determinar que um microsserviço particular não responde adequadamente ou o microsserviço retornar uma mensagem de erro, o orquestrador 706 determina a possibilidade de executar o microsserviço novamente ou uma possibilidade de haver outro microsserviço reserva que o orquestrador 706 possa usar em seu lugar. O orquestrador 708 usa o mecanismo de descoberta de serviço 710 (Figura 13) para descobrir um microsserviço alternativo (por exemplo, que tem um localizador de recurso uniforme (URL) diferente).

[0215] O orquestrador 706 pode chamar um primeiro URL para um microsserviço, porém, tal microsserviço retorna um código de erro. O orquestrador 706 usa o mecanismo de descoberta de serviço 710 para determinar se o orquestrador 706 deve descobrir um microsserviço alternativo (por exemplo, que tenha um localizador de recurso uniforme (URL) diferente). Por exemplo, o orquestrador 706 pode invocar um microsserviço de porta, que inclui múltiplos URLs diferentes que são interfaces para aplicativos de porta diferentes que realizam o microsserviço de porta.

[0216] A Figura 17 é um diagrama lógico exemplificativo que ilustra um fluxo de trabalho de mecanismo de orquestração exemplificativo relacionado à obtenção de informações de pagamento de empregado. Nesse exemplo, o orquestrador 706 recebe uma solicitação de cliente 1642 que invoca um ponto de extremidade de API de “/pagamento de empregado”, exposto pelo orquestrador 706, para obter informações de pagamento de empregado. O orquestrador 706 seleciona um fluxo de trabalho para obter informações de pagamento de empregado a partir da pasta de fluxos de trabalho 1612, carrega o fluxo de trabalho selecionado e envia por push um novo trabalho para o armazenamento de estrutura de dados 1610. O orquestrador 706 também é inscrito no servidor publicação-inscrição 1620 para situação de trabalho.

[0217] O fluxo de trabalho especifica um conjunto de tarefas. Por exemplo, o fluxo de trabalho para obter informações de pagamento de empregado especifica um conjunto de tarefas que compreende: (i) obter detalhes de usuário, (ii) obter detalhes de pagamento de usuário com base nos detalhes de usuário. o orquestrador 706 pode distribuir tarefas do conjunto de tarefas ao longo de uma pluralidade de execuções de fluxo de trabalho 1616A a 1616D, que acessam um ou mais dentre os microsserviços 1650A a 1650D (pontos de extremidade) para realizar as tarefas. Os microsserviços 1650A a 1650D acessados pelas execuções de fluxo de trabalho 1616A a 1616D no exemplo da Figura 17 podem ser microsserviços diferentes dos microsserviços 1630A a 1630D no exemplo da Figura 16. As execuções de fluxo de trabalho 1616 podem selecionar trabalhos a partir de uma fila mantida pelo armazenamento de estrutura de dados 1610. Em alguns exemplos, cada tarefa em um fluxo de trabalho selecionado pode ser executada em um encadeamento diferente. As tarefas podem ser executadas paralela ou sequencialmente. Conforme cada tarefa é finalizada, o servidor publicação-inscrição 1620 é atualizado e o servidor publicação-inscrição 1620 notifica o orquestrador 706. Por exemplo, “Trabalho Finalizado” é um método que é chamado uma vez que a execução do fluxo de trabalho é finalizada. Quando o orquestrador 706 determina que as informações de pagamento de empregado foram obtidas, o orquestrador 706 pode notificar o cliente que realizou a solicitação, por exemplo, retornando-se uma resposta de HTTP.

[0218] As Figuras 18A a 18B são diagramas de blocos que ilustram uma infraestrutura de rede exemplificativa e provisionamento de serviço por uma plataforma de interconexão para uma troca em nuvem que agrega os serviços de nuvem de múltiplos provedores de serviço de nuvem para provisionamento aos clientes do provedor de troca em nuvem e agrega acesso para múltiplos clientes a um ou mais provedores de serviço de nuvem, de acordo com as técnicas descritas na presente revelação. Nesse exemplo, as redes de cliente 1808A a 1808C (coletivamente, “redes de cliente 1808”), cada uma associada a um cliente diferente, acessam um ponto de troca em nuvem dentro de um centro de dados 1800 a fim de receber serviços de nuvem agregados de uma ou mais redes de provedor de serviço de nuvem 1820, cada uma associada a um provedor de serviço de nuvem 110 diferente. Cada uma dentre as redes de cliente 1808 inclui dispositivos de ponto de extremidade que consomem serviços de nuvem fornecidos pela rede de provedor de serviço de nuvem 1820. Os dispositivos de ponto de extremidade exemplificativos incluem servidores, telefones inteligentes, decodificadores de televisão, estações de trabalho, computadores do tipo laptop/tablet, sistemas de jogos digitais, sistemas de teleconferência, reprodutores de mídia e assim por diante.

[0219] As redes de cliente 1808A a 1808B incluem respectivos roteadores de borda de sistema autônomos/borda de provedores (PE/ASB s) 1810A a 1810B. Cada um dentre os PE/ASBRs 1810A, 1810B pode executar protocolos de roteamento de porta de comunicação exterior para se emparelhar com um dentre os roteadores de PE 1802A a 1802B (“roteadores de PE 1802” ou mais simplesmente “PEs 1802”) através de um dos enlaces de acesso 1816A a 1816B (coletivamente, “enlaces de acesso 1816”). Nos exemplos ilustrados, cada um dentre os enlaces de acesso 1816 representa um enlaces de trânsito entre um roteador de borda de uma rede de cliente 1808 em um roteador de borda (ou roteador de borda de sistema autônomo) do ponto de troca em nuvem 1803. Por exemplo, o PE 1810A e PE 1802A podem se emparelhar diretamente por meio de um protocolo de porta de comunicação exterior, por exemplo, BGP exterior, para trocar rotas de L3 através do enlace de acesso 1816A e para trocar tráfego de dados de L3 entre a rede de cliente 1808A e as redes de provedor de serviço de nuvem 1820. Os enlaces de acesso 1816 podem, em alguns casos, representar e ser alternativamente chamados de um circuito de fixação para IP-VPNs configuradas em malha de IP/MPLS 1801, conforme descrito em maiores detalhes abaixo. Os enlaces de acesso 1816, cada um, podem incluir uma conexão física direta entre pelo menos uma porta de uma rede de cliente 1808 e pelo menos uma porta de ponto de troca em nuvem 1803, sem nenhuma rede de trânsito interferente. Os enlaces de acesso 1816 podem operar através de uma VLAN ou uma VLAN empilhada (por exemplo, QinQ), uma VxLAN, uma LSP, um túnel de GRE ou outro tipo de túnel.

[0220] Embora sejam ilustrados e principalmente descritos em relação à conectividade de L3, os roteadores de PE 1802 podem oferecer adicionalmente, por meio de enlaces de acesso 1816, conectividade de L2 entre as redes de cliente 1808 e as redes de provedor de serviço de nuvem 1820. Por exemplo, uma porta de roteador de PE 1802A pode ser configurada com uma subinterface de L2 que fornece, à rede de cliente 1808A, conectividade de L2 ao provedor de serviço de nuvem 1820A por meio de enlace de acesso 1816A. A porta de roteador de PE 1802A pode ser configurada adicionalmente com uma interface de L3 que fornece, à rede de cliente 1808A, conectividade de L3 ao provedor de serviço de nuvem 1820B por meio de enlaces de acesso 1816A.

[0221] Cada um dentre os enlaces de acesso 1816 e enlaces de agregação 1822 pode incluir um dispositivo de interface de rede (NID) que conecta a rede de cliente 1808 ou o provedor de serviço de nuvem 1828 a um enlace de rede entre o NID e um dentre os roteadores de PE 1802, 1804. Cada um dentre os enlaces de acesso 1816 e os enlaces de agregação 1822 pode representar ou incluir qualquer um dentre inúmeros tipos diferentes de enlaces que fornecem conectividade de L3/rede.

[0222] Nesse exemplo, a rede de cliente 1808C não é um sistema autônomo que tem um número de sistema autônomo. A rede de cliente 1808C pode representar uma empresa, provedor de serviço de rede ou outra rede de cliente que esteja dentro da área de atuação de roteamento do ponto de troca em nuvem. A rede de cliente inclui um dispositivo de borda de cliente (CE) 1811 que pode executar protocolos de roteamento de porta de comunicação exterior para se emparelhar com o roteador de PE 1802B através do enlace de acesso 1816C. Em vários exemplos, qualquer um dentre os PEs 1810A a 1810B pode ser alternativamente ou, de outro modo, representar dispositivos de CE.

[0223] Os enlaces de acesso 1816 incluem enlaces físicos. Os PE/ASBRs 1810A a 1810B, dispositivo de CE 1811 e roteadores de PE 1802A a 1802B trocam pacotes de L2/L3 por meio de enlaces de acesso 1816. Nesse sentido, os enlaces de acesso 1816 constituem enlaces de transporte para acesso à nuvem por meio do ponto de troca em nuvem 1803. O ponto de troca em nuvem 1803 pode representar um exemplo de qualquer um dentre os pontos de troca em nuvem 128. O centro de dados 1800 pode representar um exemplo de centro de dados 201.

[0224] O ponto de troca em nuvem 1803, em alguns exemplos, agrega acesso de clientes 1808 ao ponto de troca em nuvem 1803 e, portanto, a qualquer um ou mais provedores de serviço de nuvem 1820. As Figuras 18A a 18B, por exemplo, ilustram enlaces de acesso 1816A a 1816B que conectam respectivas redes de cliente 1808A a 1808B ao roteador de PE 1802A do ponto de troca em nuvem 1803 e o enlace de acesso 1816C que conecta a rede de cliente 1808C ao roteador de PE 1802B. Qualquer um ou mais dos roteadores de PE 1802, 1804 pode compreender ASBRs. Os roteadores de PE 1802, 1804 e malha de IP/MPLS 1801 podem ser configurados de acordo com técnicas descritas no presente documento para interconectar qualquer um dentre os enlaces de acesso 1816 a qualquer um dentre os enlaces de agregação em nuvem 1822. Como resultado, a rede de provedor de serviço de nuvem 1820A, por exemplo, precisa apenas ter configurado um único enlace agregado em nuvem (no presente documento, enlace de acesso 1822A) a fim de fornecer serviços a múltiplas redes de cliente 1808. Ou seja, o provedor de serviço de nuvem que opera a rede de provedor de serviço de nuvem 1802A não precisa provisionar e configurar enlaces de serviço separados da rede de provedor de serviço de nuvem 1802A para cada um dentre os roteadores de PE 1810, 1811, por exemplo, a fim de fornecer serviços a cada uma dentre as redes de cliente 1808. O ponto de troca em nuvem 1803 pode, em vez disso, conectar de modo cruzado o enlace de agregação em nuvem 1822A e PE 1812A da rede de provedor de serviço de nuvem 1820A a múltiplos enlaces de acesso em nuvem 1816 para fornecer à camada 3 o emparelhamento e viabilidade de rede para a entrega de serviços de nuvem.

[0225] Além disso, uma única rede de cliente, por exemplo, rede de cliente 1808A, precisa ter apenas configurado um único enlace de acesso em nuvem (no presente documento, enlace de acesso 1816A) ao ponto de troca em nuvem 1803 dentro do centro de dados 1800 a fim de obter serviços de múltiplas redes de provedor de serviço de nuvem 1820 que oferecem serviços de nuvem por meio do ponto de troca em nuvem 1803. Ou seja, o cliente ou provedor de serviço de rede que opera a rede de cliente 1808A não precisa provisionar e configurar enlaces de serviço separados que conectam a rede de cliente 1808A a diferentes roteadores de PE 1812, por exemplo, a fim de obter serviços de múltiplas redes de provedor de serviço de nuvem 1820. O ponto de troca em nuvem 1803 pode, em vez disso, conectar de modo cruzado o enlace de acesso em nuvem 1816A (novamente, como exemplo) a múltiplos enlaces agregados em nuvem 1822 para fornecer à camada 3 o emparelhamento e viabilidade de rede para a entrega de serviços de nuvem para a rede de cliente 1808A.

[0226] Cada uma dentre as redes de provedor de serviço de nuvem 1820 inclui servidores configurados para fornecer um ou mais serviços de nuvem aos usuários. Esses serviços podem ser categorizados de acordo com tipos de serviço, que podem incluir, por exemplo, aplicativos/software, plataformas, infraestrutura, virtualização e servidores e armazenamento de dados. Os serviços de nuvem exemplificativos podem incluir entrega de conteúdo/mídia, armazenamento com base em nuvem, computação em nuvem, jogos online, serviços de TI, etc.

[0227] As redes de provedor de serviço de nuvem 1820 incluem roteadores de PE 1812A a 1812D, em que cada um executa um protocolo de roteamento de porta de comunicação exterior, por exemplo, eBGP, para trocar rotas com os roteadores de PE 1804A a 1804B (coletivamente, “roteadores de PE 1804”) do ponto de troca em nuvem 1803. Cada uma dentre as redes de provedor de serviço de nuvem 1820 pode representar uma nuvem pública, privada ou híbrida. Cada uma das redes de provedor de serviço de nuvem 1820 pode ter um número de sistema autônomo atribuído ou pode ser parte da área de atuação do sistema autônomo do ponto de troca em nuvem 1803.

[0228] No exemplo ilustrado, uma malha de Protocolo de Internet/de comutação de etiqueta de Múltiplos protocolos (IP/MPLS) 1801 interconecta PEs 1802 e PEs 1804. A malha de IP/MPLS 1801 inclui um ou mais dispositivos de comutação e roteamento, inclusive PEs 1802, 1804, que fornecem comutação e roteamento de IP/MPLS de pacotes de IP para formar uma estrutura de IP. Em alguns exemplos, a malha de IP/MPLS 1801 pode implantar um ou mais protocolos de túnel diferentes (isto é, diferentes de MPLS) para rotear tráfego entre roteadores de PE e/ou associar o tráfego a diferentes IP-VPNs. De acordo com técnicas descritas no presente documento, malha de IP/MPLS 1801 implanta redes privadas virtuais de IP (IP-VPNs) para conectar qualquer um dentre os clientes 1808 com múltiplas redes de provedor de serviço de nuvem 1820 para fornecer um “transporte” com base em centro de dados e conexão cruzada da camada 3. Embora as rede de estrutura de IP com base em provedor de serviço exija conexões de rede de longa distância (WAN) com largura de banda limitada para transportar tráfego de serviço dos provedores de serviço da camada 3 para os clientes, o ponto de troca em nuvem 1803 conforme descrito no presente documento “transporta” tráfego de serviço e conecta de modo cruzado os provedores de serviço de nuvem 1820 aos clientes 1808 dentro do ambiente local de alta largura de banda do centro de dados 1800 fornecidos pela malha de IP/MPLS 1801 com base em centro de dados. Em alguns exemplos, a malha de IP/MPLS 1801 implanta IP-VPNs com o uso de técnicas descritas em Rosen & Rekhter, “BGP/MPLS IP Virtual Private Networks (VPNs)”. Solicitação de comentários 4364, fevereiro de 2006, “Internet Engineering Task Force (IETF) Network Working Group”, cuja totalidade do conteúdo se encontra incorporada, a título de referência, no presente documento. Em algumas configurações exemplificativas, uma rede de cliente 1808 e a rede de provedor de serviço de nuvem 1820 podem se conectar por meio de respectivos enlaces ao mesmo roteador de PE da malha de IP/MPLS 1801.

[0229] Os enlaces de acesso 1816 e os enlaces de agregação 1822 podem incluir um circuito de fixação que associa tráfego, trocado com a rede de cliente conectada 1808 ou a rede de provedor de serviço de nuvem 1820, com instâncias de roteamento virtual e encaminhamento (VRFs) configuradas em PEs 1802, 1804 e que correspondem a IP-VPNs que operam sobre a malha de IP/MPLS 1801. Por exemplo, o PE 1802A pode trocar pacotes de IP com PE 1810A em um caminho comutado de etiqueta bidirecional (LSP) que opera sobre o enlace de acesso 1816A, em que o LSP é um circuito de fixação para uma VRF configurada em PE 1802A. Como outro exemplo, o PE 1804A pode trocar pacotes de IP com PE 1812A em um caminho comutado de etiqueta bidirecional (LSP) que opera sobre o enlace de acesso 1822A, em que o LSP é um circuito de fixação para uma VRF configurada em PE 1804A. Cada VRF pode incluir ou representar uma tabela de roteamento e encaminhamento diferente com rotas distintas.

[0230] Os roteadores de PE 1802, 1804 de malha de IP/MPLS 1801 podem ser configurados em respectivas disposições de cubo e raio para serviços de nuvem, com PEs 1804 que implantam cubos e PEs de serviço de nuvem 1802 que são configurados como raios dos cubos (para vários casos/disposições de cubo e raio). Uma disposição de cubo e raio assegura que o tráfego de serviço possa fluir entre um PE de cubo e qualquer uma dentre os PEs de raio, mas não diretamente entre PEs de raio diferentes. Conforme descrito adicionalmente abaixo, em uma disposição de cubo e raio para malha de IP/MPLS com base em centro de dados 1801 e para tráfego de serviço descendente (isto é, de um CSP para um cliente) os PEs 1802 anunciam rotas, recebidas de PEs 1810, para PEs 1804, que anunciam as rotas aos PEs 1812. Para tráfego de serviço ascendente (isto é, de um cliente para um CSP), os PEs 1804 anunciam rotas, recebidas dos PEs 1812, para PEs 1802, que anunciam as rotas aos PEs 1810.

[0231] Para alguns clientes de ponto de troca em nuvem 1803, o provedor de ponto de troca em nuvem 1803 pode configurar uma disposição de malha completa, por meio da qual um conjunto de PEs 1802, 1804, cada um se acopla a uma rede de local de cliente diferente para o cliente. Em tais casos, a malha de IP/MPLS 1801 implanta uma VPN de camada 3 (L3VPN) para tráfego de entre gaiolas ou tráfego de redundância (também chamado de leste-oeste ou tráfego horizontal). A L3VPN pode efetuar um grupo de usuário fechado, por meio do qual, cada rede de local de cliente pode enviar tráfego umas para as outras, porém, não podem enviar ou receber tráfego fora da L3VPN.

[0232] Os roteadores de PE podem se acoplar um ao outro de acordo com um modelo de emparelhamento sem uso de redes de sobreposição. Ou seja, os PEs 1810 e os PEs 1812 não podem se emparelhar diretamente entre si para trocar rotas, mas, em vez disso, trocam rotas indiretamente por meio de malha de IP/MPLS 1801. No exemplo da Figura 18B, o ponto de troca em nuvem 1803 é configurado para implantar múltiplos circuitos virtuais de camada 3 1830A a 1830C (coletivamente, “circuitos virtuais 1830”) para interconectar a rede de cliente 1808 e as redes de provedor de serviço de nuvem 1822 com caminhos de IP de ponta a ponta. Cada um dentre os provedores de serviço de nuvem 1820 e os clientes 1808 pode ser um ponto de extremidade para múltiplos circuitos virtuais 1830, com múltiplos circuitos virtuais 1830 que atravessam um ou mais circuitos de fixação entre um par de PE/PE ou para de PE/CE para a malha de IP/MPLS 1801 e o CSP/cliente. Um circuito virtual 1830 representa um caminho de camada 3 através da malha de IP/MPLS 1801 entre um circuito de fixação que conecta uma rede de cliente à malha 1801 e um circuito de fixação que conecta uma rede de provedor de serviço de nuvem à malha 1801. Cada circuito virtual 1830 pode incluir pelo menos um túnel (por exemplo, um túnel de LSP e/ou Encapsulação de Rota Genérica (GRE)) que tem pontos de extremidade nos PEs 1802, 1804. Os PEs 1802, 1804 podem estabelecer uma malha completa de túneis que se interconectam.

[0233] Cada circuito virtual 1830 pode incluir uma rede de cubo e raio diferente configurada na rede de IP/MPLS 1801 que tem roteadores de PE 1802, 1804 que trocam rotas com o uso de uma malha completa ou parcial de sessões de emparelhamento de protocolo de porta de comunicação de borda, nesse exemplo, uma malha completa de sessões de emparelhamento de Protocolo de Porta de Comunicação de Borda Interior (MP-iBGP). O MP-iBGP ou simplesmente MP-BGP é um exemplo de um protocolo através do qual os roteadores trocam rotas etiquetadas para implantar VPNs com base em MPLS. Entretanto, os PEs 1802, 1804 podem trocar rotas para implantar IP-VPNs com o uso de outras técnicas e/ou protocolos.

[0234] No exemplo do circuito virtual 1830A, o roteador de PE 1812A da rede de provedor de serviço de nuvem 1820A pode enviar uma rota para a rede de provedor de serviço de nuvem 1820A para PE 1804A por meio de uma conexão de emparelhamento de protocolo de roteamento (por exemplo, eBGP) com PE 1804A. O PE 1804A associa a rota a uma rede de cubo e raio, que pode ter uma VRF associada, que inclui roteador de PE de raio 1802A. O PE 1804A, então, exporta a rota para o roteador de PE 1802A; O roteador de PE 1804A pode exportar a rota que especifica o roteador de PE 1804A como o próximo roteador de salto, juntamente com uma etiqueta que identifica a rede de cubo e raio. O roteador de PE 1802A envia a rota para o roteador de PE 1810B por meio de uma conexão de protocolo de roteamento com PE 1810B. O roteador de PE 1802A pode enviar a rota após adicionar um número de sistema autônomo do ponto de troca em nuvem 1803 (por exemplo, um atributo de caminho de sistema autônomo de BGP (CAMINHO AS)) e que especifica o roteador de PE 1802A como o próximo roteador de salto. O ponto de troca em nuvem 1803, portanto, é um “salto” de sistema autônomo no caminho dos sistemas autônomos de clientes 1808 para os provedores de serviço de nuvem 1820 (e vice-versa), embora o ponto de troca em nuvem 1803 possa ter por base em um centro de dados. O roteador de PE 1810B instala a rota em um banco de dados de roteamento, como uma base de informações de roteamento de BGP (RIB) para fornecer viabilidade da camada 3 à rede de provedor de serviço de nuvem 1820A. Dessa forma, o ponto de troca em nuvem 1803 “vaza” rotas de redes de provedor de serviço de nuvem 1820 para redes de cliente 1808, sem que as redes de provedor de serviço de nuvem 1820 para redes de cliente 1808 precisem de uma conexão de emparelhamento de camada direta.

[0235] Os roteadores de PE 1810B, 1802A, 1804A e 1812A podem realizar uma operação similar na direção inversa para encaminhar rotas originadas pela rede de cliente 1808B ao PE 1812A e, portanto, fornecer conectividade de rede de provedor de serviço de nuvem 1820A para rede de cliente 1808B. No exemplo do circuito virtual 1830B, os roteadores de PE 1812B, 1804A, 1802A e 1810B trocam rotas para a rede de cliente 1808B e o provedor de serviço de nuvem 1820B de uma maneira similar àquela descrita acima para estabelecer o circuito virtual 1830B. Como resultado, o ponto de troca em nuvem 1803 dentro do centro de dados 1800 internaliza as conexões de emparelhamento que, de outro modo, seriam estabelecidas entre PE 1810B e cada um dos PEs 1812A, 1812B, de modo a realizar agregação de nuvem para múltiplos serviços de nuvem de cama 3 fornecidos por diferentes redes de provedor de serviço de nuvem 1820A, 1820B e entrega the múltiplos serviços de nuvem de camada 3 agregados a uma rede de cliente 1808B que tem um único enlace de acesso 1816B ao ponto de troca em nuvem 1803. Na ausência das técnicas descritas no presente documento, interconectar completamente as redes de cliente 1808 e redes de provedor de serviço de nuvem 1820 exigiria conexões de emparelhamento de 3x3 entre cada um dos PEs 1810 e pelo menos um dos PEs 1812 para cada uma dentre as redes de provedor de serviço de nuvem 1820. Por exemplo, o PE 1810A exigiria uma conexão de emparelhamento de camada 3 com cada um dos PEs 1812. Com as técnicas descritas no presente documento, o ponto de troca em nuvem 1803 pode interconectar completamente as redes de cliente 1808 e as redes de provedor de serviço de nuvem 1820 com uma conexão de emparelhamento por PE de local (isto é, para cada um dos PEs 1810 e dos PEs 1812) internalizando-se o emparelhamento de camada 3 e fornecendo-se "transporte" com base em centro de dados entre interfaces de acesso à nuvem e agregação em nuvem.

[0236] Em exemplos em que a malha de IP/MPLS 1801 implanta IP-VPNs de BGP/MPLS ou outras IP-VPNs que usam alvos de rota para controlar distribuição de rota dentro da estrutura de IP, os PEs 1804 podem ser configurados para importar rotas dos PEs 1802 e para exportar rotas recebidas dos PEs 1812, com o uso de diferentes alvos de rota assimétricos. De modo semelhante, os PEs 1802 podem ser configurados para importar rotas de PEs 1804 e para exportar rotas recebidas de PEs 1810 com o uso de alvos de rota assimétricos. Dessa forma, os PEs 1802, 1804 podem ser configurados para implantar L3VPNs avançadas, em que cada uma inclui uma L3VPN de estrutura básica de malha de IP/MPLS 1801 juntamente com extra-redes de qualquer uma dentre as redes de cliente 1808 e qualquer uma dentre as redes de provedor de serviço de nuvem 1820 fixadas à L3VPN de estrutura básica. Cada L3VPN avançada constitui uma rede de entrega de serviço de nuvem de uma rede de provedor de serviço de nuvem 1820 para uma ou mais redes de cliente 1808 e vice-versa. Dessa forma, o ponto de troca em nuvem 1803 possibilita que qualquer rede de provedor de serviço de nuvem 1820 troque tráfego de serviço de nuvem com qualquer rede de cliente 1808 ao passo que internaliza as conexões de emparelhamento de protocolo de emparelhamento de camada 3 que, de outro modo, seriam estabelecidas entre pares de redes de cliente 1808 e redes de provedor de serviço de nuvem 1820 para qualquer conexão de serviço de nuvem entre um determinado par. Em outras palavras, o ponto de troca em nuvem 1803 permite que cada uma dentre as redes de cliente 1808 e redes de provedor de serviço de nuvem 1820 estabeleça uma única (ou mais por motivos de redundância, entre outros) conexão de emparelhamento de protocolo de roteamento de camada de 3 com a conexão cruzada de camada 3 com base no centro de dados. Filtrando-se as rotas das redes de provedor de serviço de nuvem 1820 para as redes de cliente 1808, e vice-versa, os PEs 1802, 1804, portanto, controlam o estabelecimento de circuitos virtuais 1830 e o fluxo de tráfego de serviço de nuvem associado entre redes de cliente 1808 e redes de provedor de serviço de nuvem 1820 dentro de um centro de dados 1800. As rotas distribuídas na malha de MP-iBGP 183 podem ser rotas de VPN-IPv4 e podem ser associadas a diferenciadores de rota para diferenciar as rotas de diferentes locais que têm espaços de endereço sobrepostos.

[0237] A Plataforma de interconexão 103 pode receber solicitações de serviço para criar, ler, atualizar e/ou excluir serviços de ponta a ponta do ponto de troca em nuvem 1803. Em resposta, a plataforma de interconexão 103 pode configurar os PEs 1802, 1804 e/ou outra infraestrutura de rede da malha de IP/MPLS 1801 para provisionar ou obter desempenho ou outras informações de operações a respeito do serviço. As operações para provisionamento de um serviço e realizadas pela plataforma de interconexão 103 podem incluir configurar ou atualizar VRFs, instalar informações de encaminhamento de SDN, configurar LSPs ou outros túneis, configurar BGP, configurar enlaces de acesso 1816 e enlaces de agregação 1822 ou, de outro modo, modificar a configuração da malha de IP/MPLS 1801. Outras operações podem incluir realizar solicitações de serviço para um sistema de orquestração para redes de provedor de serviço de nuvem 1820, conforme descrito em maiores detalhes abaixo.

[0238] A Figura 19 é um diagrama de blocos que ilustra um exemplo de um ponto de troca de nuvem com base em centro de dados na qual roteadores do ponto de troca de nuvem são configurados por uma plataforma de interconexão 103 com instâncias de roteamento de rede e encaminhamento de VPN para rotear e encaminhar tráfego de serviço agregado das múltiplas redes de provedor de serviço de nuvem para uma rede de cliente, de acordo com técnicas descritas no presente documento. Nesse exemplo, para estabelecer circuitos virtuais 1830A a 1830B, os roteadores de PE 1802A e 1804A da malha de IP/MPLS 1801 são configurados com VRFs. O PE 1802A é configurado com VRFs 1902A e 1904A, ao passo que o PE 1804A é configurado com VRFs 1902B e 1904B. VRF 1902A é configurado para importar rotas exportadas por VRF 1902B, e VRF 1902B é configurado para importar rotas exportadas por VRF 1902A. A configuração pode incluir alvos de rota assimétrica para importar/exportar entre VRFs 1902A, 1902B. VRF 1904A é configurado para importar rotas exportadas por VRF 1902B, e VRF 1902B é configurado para importar rotas exportadas por VRF 1902A. A configuração pode incluir alvos de rota assimétrica para importar/exportar entre VRFs 1902A, 1902B.

[0239] Nesse exemplo, a PE 1804A opera o BGP ou outras conexões de emparelhamento de protocolo de distribuição de rota 1906B, 1908B com as PEs respectivas 1812A, 1812B para trocar rotas com as respectivas redes de provedor de serviço de nuvem 1820A, 1820B. A PE 1802A opera um BGP ou outra conexão de emparelhamento de protocolo de distribuição de rota 1910 com a PE 1810B a fim de trocar rotas com rede de cliente 1808B. Em alguns exemplos, as PEs 1802A, 1804A podem ser configuradas estatisticamente com rotas para as redes de site.

[0240] Um administrador ou uma plataforma de interconexão descrito no presente documento para ponto de troca de nuvem 1803 pode configurar as PEs 1802A, 1804A com o VRF 1902A a 1902B, 1904A a 1904B a fim de vazar rotas entre as PEs 1812 e PE 1810B e facilitar a conectividade de camada 3 para caminhos de IP de extremidade a extremidade ilustrados no presente contexto pelos circuitos virtuais 1830 ao mesmo tempo que otimizam potencialmente os caminhos de IP de extremidade a extremidade estimulando-se a conectividade com base em centro de dados ou com base pelo menos em metrô. O ponto de troca de nuvem 1803 pode, então, fornecer acesso de provedor de serviço de nuvem dedicado à rede de cliente 1808B por meio de rotas privadas e/ou públicas para as redes de provedor de serviço de nuvem 1820. Na direção ao norte, o ponto de troca de nuvem 1803 pode fornecer distribuição de provedor de serviço de nuvem dedicada a múltiplas redes de cliente 1808 por meio das rotas privadas e/ou públicas para as redes de cliente 1808. Nenhum dentre a PE 1810B ou as PEs 1802A, 1804A precisam acessar a tabela de roteamento de BGP de Internet completa a fim de atingir as redes de provedor de serviço de nuvem 1820 ou as redes de cliente 1808. Ademais, as PEs 1802A, 1804A podem ser configuradas para agregar rotas de cliente/CSP e/ou tráfego de serviço com base em qualquer um dentre físico, IP, serviço e VRFs.

[0241] A Figura 20 é um diagrama conceitual que ilustra abordagens de projeto para um enquadramento de desenvolvimento e benefícios que podem ser realizados com o uso do enquadramento de desenvolvimento, de acordo com as técnicas descritas na presente revelação. O enquadramento de desenvolvimento facilita uma arquitetura de aplicativo com base em microsserviços que reforça o projeto acionado por domínio e possibilita desenvolvimento acionado por teste. O enquadramento de desenvolvimento também facilita uma abordagem do tipo "primeiramente o contrato de API" na qual os desenvolvedores criam/refinam inicialmente a definição de API para um microsserviço, a partir do qual o enquadramento de desenvolvimento gera o scaffolding da infraestrutura de serviço de software. Os desenvolvedores podem, em seguida, implantar o microsserviço transformando- se a lógica de negócios na infraestrutura.

[0242] Novamente, esse enquadramento de desenvolvimento facilita uma abordagem de projeto com base modular e gera código "texto padronizado" com o uso das melhores práticas de geração de código. O enquadramento de desenvolvimento facilita geração de API extremidade a extremidade para scaffolding interativo, incluindo gerando- se impostores e predicados de stub com base na definição de contrato de API especificada inicialmente pelo desenvolvedor. Em alguns exemplos, O enquadramento de desenvolvimento realiza auditoria de um ou mais módulos com o uso de nodesecurity.io.

[0243] Os aspectos do enquadramento de desenvolvimento podem ser embutidos no Node.js ou em outra plataforma semelhante que fornece, por exemplo, uma arquitetura acionada por evento e uma API de I/O de não bloqueio projetada para otimizar um rendimento e escalabilidade do aplicativo para aplicativo da web em tempo real. O node.js é uma plataforma leve de origem aberta que facilita sistemas livremente acoplados e escalonáveis que se comunicam com o uso de, por exemplo, HTTP e JSON, que são embutidos no Node.js. Isso pode facilitar os princípios de projeto de microsserviço. Para o enquadramento de aplicativo de web, o enquadramento de desenvolvimento pode ser embutido, em alguns exemplos, no topo de Express js e nos módulos de nó existente / domésticos.

[0244] O orquestrador pode utilizar máquinas de estado para implantar fluxos de trabalho que invocam múltiplos microsserviços em um ordenamento definido para satisfazer um contrato de API. O enquadramento de desenvolvimento pode usar Mapeamento de Linha D'água e/ou Objeto Persistente/Relacional (ORJVI) ou outro enquadramento de ORM para interações de banco de dados. O enquadramento de desenvolvimento pode fornecer gerações de recursos de realização de logon integrados junto de outros aspectos do scaffolding. O enquadramento de desenvolvimento pode fornecer monitoramento e unidade integrados e módulos de teste de integração junto de outros aspectos do scaffolding.

[0245] O enquadramento de desenvolvimento pode facilitar implantação rápida e escalonável e desenvolvimento/teste de tempo de execução para fornecer um ambiente de desenvolvimento de "nuvem incluída". O enquadramento de desenvolvimento pode implantar cada microsserviço em um recipiente separado para isolamento e modularidade ao mesmo tempo que também fornece qualidade e confiabilidade aprimoradas com teste, realização de logon, monitoramento e estratégias diagnósticas integradas. O enquadramento de desenvolvimento pode facilitar também compartilhamento dinâmico e/ou de recurso de origem cruzada estática (CORS).

[0246] A tecnologia de recipiente é um mecanismo para implantar unidades de trabalho ao longo de um vasto agrupamento de recursos de computação e se tornou uma estratégia de implantação estratégica para escalabilidade. Os microsserviços estão se tornando um padrão de arquitetura de maior importância com a explosão de dispositivos que acessam a Internet, devido parcialmente ao fato de que os mesmos têm pouco o foco, são independentemente implantáveis, mais fáceis de manter e escalonáveis. Os microsserviços e os recipientes fornecem uma convergência de abordagens técnicas a sistemas escaláveis de construção. Node.js é uma plataforma de origem aberta que é otimizada para construir processos de comunicação altamente escalonáveis leve assíncronos e expor as APIs a qualquer consumidor da Web. O enquadramento de desenvolvimento descrito na presente revelação aproveita os Node.js, microsserviços e recipientes para fornecer um enquadramento de desenvolvimento geral para criação extremidade a extremidade, implantação e instalação de um aplicativo com base em microsserviço (tal como uma plataforma de interconexão para uma troca de serviços com base em nuvem).

[0247] Os princípios de projeto acima facilitados pelo enquadramento de desenvolvimento podem fornecer um ou mais dentre os seguintes benefícios: chegada ao mercado mais rápida, melhor desempenho, melhor experiência do usuário, construção mais fácil, um aplicativo com base em microsserviço mais responsivo e escalonável, tempo de implantação reduzido e um projeto de sistema livremente acoplado. O enquadramento de desenvolvimento pode ser executado em qualquer ambiente de execução adequado, incluindo um ou mais servidores, uma estação de trabalho e/ou um ambiente com base em nuvem que inclui um ou mais processadores configurados para executar componentes do enquadramento de desenvolvimento.

[0248] A Figura 20 é um diagrama conceitual que ilustra uma vista lógica de um enquadramento de desenvolvimento de acordo com as técnicas descritas na presente revelação. O enquadramento de desenvolvimento é ilustrado conceitualmente com o uso de uma representação hexagonal na qual uma API RESTful 1920 apresenta uma interface de múltiplos canais a diferentes bases de usuários para um aplicativo com base em microsserviço. O enquadramento de desenvolvimento inclui múltiplos componentes conceituais para modelagem de contrato de API ("modelo") 1922; banco de dados de notificação 1924 ou outra conectividade de armazenamento persistente ("dados") 1926, incluindo bancos de dados em memória 1904A, interfaces RESTful às fontes externas 1904B, bancos de dados com base em Oracle/SQL servidor/SQL 1904C e bancos de dados de oSQL 1904D (coletivamente, "bancos de dados 1904"); scaffolding automatizados 1928, desenvolvimento acionado por teste 1930 com o uso de um padrão de repositório 1908, um motor de fluxo de trabalho 1932 para executar os fluxos de trabalho projetado (pelo menos em algumas ocorrências) por um editor 1910 (por exemplo, uma interface de linha de comando (CLI), com a implantação, pelo menos um algumas ocorrências, alcançada com o uso de um enquadramento com base em recipiente 1906.

[0249] A API RESTful 1920 pode ser configurada com o uso do enquadramento de desenvolvimento para apresenta um contrato de API totalmente passível de personalização para cada canal 1902. Os canais exemplificativos 1902 ilustrados na Figura 20 incluem soquetes da web 1902A, solicitações de Ajax 1902B, API 1902C, Internet das Coisas (IoT) 1902D e aplicativos de HTML5 1902E. A orquestração é usada para orquestrar os microsserviços com base em regras e/ou fluxos de trabalho definidos para cada solicitação de contrato de API por canal 1902. O orquestrador pode lidar com a solicitação de API de modo genérico, no entanto, por meio da execução de um conjunto de regras que permite um contrato de API totalmente passível de personalização para cada um dos canais 1902. O enquadramento de desenvolvimento e a arquitetura de aplicativo com base em microsserviço, ilustrados conceitualmente na Figura 20 e descritos no presente documento, podem suportar a variabilidade nos contratos de solicitação/resposta de API. Em alguns exemplos, o projeto de orquestrador abrange as diferenças ao longo dos diferentes canais 1902 ao passo que fornece suporte igual para tais diferenças. Mais especificamente, a plataforma/enquadramento de desenvolvimento de orquestrador pode permitir a criação de pontos de extremidade personalizados para cada um dos canais 1902. O modelo de solicitação/resposta pode, portanto, ser especializado e, em alguns casos, otimizados para cada um dentre os canais 1902 a fim de se responsabilizar por exigências exclusivas e distintas. Um orquestrador construído com o uso da plataforma/ enquadramento de desenvolvimento pode lidar direta e transparentemente com toda a comunicação de rede com diferentes canais. Com base na solicitação, o orquestrador carrega o fluxo de trabalho associado e orquestra os diferentes microsserviços para preencher os contratos. A fim de garantir as interações eficientes para um canal diferente, o orquestrador de enquadramento de desenvolvimento pode aplicar uma variedade de diferentes otimizações.

[0250] A Figura 21 é um diagrama de blocos que ilustra, mais detalhadamente, os componentes para um enquadramento de desenvolvimento que facilitam o scaffolding, a construção, o teste e a implantação de aplicativos com base em microsserviço de acordo com as técnicas descritas na presente revelação. O enquadramento de desenvolvimento nesse exemplo inclui três componentes, plataforma de orquestrador 2000, plataforma de microsserviços 2018 e plugins 2038. A plataforma de orquestrador 2000 inclui componentes/aplicativos para descoberta de microsserviço (mecanismos de descoberta de serviço 2002, documentação/publicação de interface (mecanismos de documentação de API 2004), geração de código (gerador de código 2006), agregação e roteamento de resposta (agregador de resposta 2010), disposição de máquina de estado (máquina de estado 2012) e execução de fluxo de trabalho (executor de fluxo de trabalho 2014).

[0251] Os mecanismos de descoberta de serviço 2002 pode estender o Node.js e/ou o express.js. Os mecanismos de documentação de API 2004 pode estender o express.js e/ou o Swagger. O gerador de código 2006 pode estender o Swagger e/ou socket.io. O executor de fluxo de trabalho 2014 pode estender o PM2.

[0252] O executor de fluxo de trabalho 2014 executa os fluxos de trabalho montados a partir das máquinas de estado que definem um ordenamento e os eventos para execução de microsserviços para produzir um serviço geral e preencher um contrato exposto pela plataforma de orquestrador 2000. O executor de fluxo de trabalho orquestra os microsserviços invocando-se cada microsserviço no momento apropriado com entrada apropriada, mantém o estado para o fluxo de trabalho, passa dados e fornece confiabilidade e transparência à execução de fluxo de trabalho.

[0253] A plataforma de microsserviço 2018 para o desenvolvimento, monitoramento e execução de microsserviços inclui componentes/aplicativos para a geração de código (gerador de código 2020), documentação/publicação de interface (mecanismos de documentação de API 2022), realização de logon (agregador de log 2024), monitoramento de processamento (monitor de processo 2026), notificação (serviço de notificação 2028), desenvolvimento e execução de API (enquadramento de API 2030) e segurança (inspetor de CORS de segurança 2032).

[0254] O gerador de código 2020 pode estender o YAML. Os mecanismos de documentação de API 2022 podem estender o Swagger. O agregador de log 2024 pode estender o logstash. O monitor de processo 2026 pode estender o PM2. O serviço de notificação 2028 pode estender o Node.js. O enquadramento de API 2030 pode estender o Node.js e/ou express.js. O inspetor de CORS de segurança 2032 pode estender express.js.

[0255] Os componentes de plugin 2038 incluem, na ocorrência exemplificativa da Figura 21, os componentes/aplicativos para facilitar conexões de componente (conectores comuns 2040), ORM 2042, adaptadores de enquadramento de desenvolvimento (adaptadores Aqua 2044), uma interface de linha de comando (CLI) para o enquadramento de desenvolvimento (CLI Aqua 2046) pela qual os desenvolvedores pode solicitar que o enquadramento gere scaffolding para microsserviços e realize outas etapas descritas na presente revelação, conectores de sistema de empresa 2048 para conectar a sistemas de empresa, módulos de núcleo de enquadramento de desenvolvimento (módulos de núcleo Aqua 2050), plugins 2052, um mecanismo de modelos 2054 e um agregador de evento 2056.

[0256] Um usuário/desenvolvedor pode estender as capacidades do enquadramento de desenvolvimento carregando-se os plugins (módulos de nó). Os recursos de enquadramento de desenvolvimento de núcleo são desenvolvidos como plugins; o usuário pode estender adicionalmente quaisquer módulos de nó de terceiras como um plugin. Os mecanismos de plugin estende uma parte da funcionalidade de núcleo fornecida pelo Node.js e permite que os usuários desenvolvam e/ou carreguem plugins que estendem essa funcionalidade de núcleo de maneiras novas interessantes.

[0257] A Figura 22 é um fluxograma que ilustra um processo de desenvolvimento exemplificativo para desenvolver aplicativos de acordo com uma arquitetura de aplicativo com base em microsserviço, com o uso do enquadramento de desenvolvimento e das técnicas descritas na presente revelação. Inicialmente, um desenvolvedor instala/define o enquadramento de desenvolvimento (2101); cria o servidor de API que deve expor as APIs e recebe solicitações (2102); e instala dependências no enquadramento de execução de microsserviço subjacente (Node.js nesse exemplo) (2103). O desenvolvedor pode então começar o desenvolvimento de um aplicativo editando-se uma definição de API com o uso, por exemplo, de Swagger ou YAML (2104). A definição de API pode incluir informações em relação aos caminhos de API, assim como esquemas de modelo para classes de resposta para os caminhos de API e solicitações associadas (por exemplo, criar, ler, atualizar, excluir). O desenvolvedor pode, então, usar o CLI de enquadramento de desenvolvimento ou outra interface para inserir a definição de API e executar o enquadramento de desenvolvimento para realizar scaffolding do aplicativo de servidor de API (2105). Em resposta, o enquadramento de desenvolvimento gera automaticamente, por exemplo, um controlador, roteador, modelos de acordo com os esquemas de modelo, dados de configuração e de validação, dados de amostra, casos de teste e arquivos de implantação para o aplicativo de servidor de API. Nesse momento, o servidor de API cujo scaffolding foi realizado pode ser executado sem mais ações adicionais do desenvolvedor para implantar a lógica, interligar as interfaces entre si, definir o roteamento e o controle etc. Em vez disso, o desenvolvedor pode simplesmente executar o servidor de API (2106) criado na etapa 2102 para executar o aplicativo de servidor de API cujo scaffolding foi realizado. Invocando-se os caminhos de API do aplicativo de servidor de API executada, o desenvolvedor pode explorar a API e refinar a API (2107). Caso o desenvolvedor determine modificar a definição de API (SIM, ramificação de 2150), o desenvolvedor pode realizar novamente as etapas 2104 a 2107, repetidamente conforme necessário.

[0258] O desenvolvedor implanta subsequentemente os pontos de extremidade de API (2108) e pode executar testes automatizados gerados ao longo do scaffolding (2109). Uma vez implantados os pontos de extremidade de API, o desenvolvedor pode explorar e testar a API (2110). Caso o desenvolvedor determine a modificação da definição de API (SIM, ramificação de 2152), o desenvolvedor pode iniciar as etapas 2104 a 2110, repetidamente conforme necessário. Caso o desenvolvedor determine modificar os pontos de extremidade (SIM, ramificação de 2152), o desenvolvedor pode iniciar novamente as etapas 2108 a 2110, modificando repetidamente a implantação dos pontos de extremidade de API (microsserviços), conforme necessário.

[0259] O desenvolvedor pode definir também os fluxos de trabalho orquestrados, por exemplo, fluxos de trabalho WD1 a WD4 das Figuras. 16 a 17, com o uso do enquadramento de desenvolvimento (2111) e explorar e testar os fluxos de trabalho orquestrados (2112). Caso o desenvolvedor determine modificar os pontos de extremidade (SIM, ramificação de 2158), o desenvolvedor pode iniciar novamente as etapas 2108 a 2110, modificando repetidamente a implantação dos pontos de extremidade de API (microsserviços), conforme necessário. Caso o desenvolvedor determine modifique a definição de API (SIM, ramificação de 2156), o desenvolvedor pode iniciar as etapas 2104 a 2110, repetidamente conforme necessário. O desenvolvedor pode repetir adicionalmente as etapas 2111 a 2112 e mudar a interface/implantação para os microsserviços subjacentes realizando-se repetidamente as etapas 2104 a 2112. Dessa maneira, um desenvolvedor pode usar o enquadramento de desenvolvimento descrito no presente documento para realizar rapidamente o scaffolding de um aplicativo de servidor de API com base em serviço. Devido ao fato de que o enquadramento de desenvolvimento possibilita reequipagem rápida da definição de API, o enquadramento de desenvolvimento pode facilitar mudanças mais fáceis e interativas às APIs e a implantação subjacente para permitir que o desenvolvedor evite ter de recriar manualmente, ou pelo menos modificar, a infraestrutura de serviço toda vez que a definição de API for mudada.

[0260] A Figura 23 é um diagrama conceitual que ilustra componentes de um projeto de enquadramento de desenvolvimento e um processo de scaffolding de extremidade a extremidade realizado pelo enquadramento de desenvolvimento e executado através das definições de orquestração e de microsserviço, de acordo com as técnicas descritas na presente revelação. Um aplicativo com base em microsserviço desenvolvida com o uso do enquadramento de desenvolvimento e das técnicas descritas no presente documento inclui pelo menos um fluxo de trabalho e pelo menos um microsserviço. Consequentemente, um projeto de fluxo de trabalho 2207 inclui projeto de API de microsserviço 2201 e dependências de projeto de API de orquestração 2209 (junto de uma infraestrutura de Docker 2208 para propósitos de implantação). O desenvolvedor define pelo menos um esquema de orquestração/fluxo de trabalho (definição) 2210 para o projeto de API de orquestração 2209 e também define pelo menos um esquema de microsserviço (definição) 2202 para o projeto de API de microsserviço 2201. O esquema 2210 pode ser (ou derivar de) um ou mais esquemas de microsserviço 2202. O processo de scaffolding de múltiplos propósitos 2203 processa o pelo menos um esquema de orquestração/fluxo de trabalho 2210 para gerar as scaffolding de fluxo de trabalho incluindo rotas 2212, controladores 2213 e fluxos de trabalho 2214 para o orquestrador. O processo de scaffolding de múltiplos propósitos 2203 processa o pelo menos um esquema de microsserviço 2202 para gerar microsserviços scaffolding incluindo rotas 2204, controladores 2205 e arquivos de implantação 2206.

[0261] Um roteador de um aplicativo com base em microsserviço difere de um roteador de rede que, por exemplo, roteia pacotes. Um roteador de um aplicativo com base em microsserviço, de acordo com as técnicas descritas no presente documento, recebe as solicitações de API emitidas ao aplicativo e roteiam a API de acordo com o caminho, atributos de solicitação, aplicativo de cliente, identidade de cliente e outros parâmetros. Cada um dos parâmetros pode ser especificado ou faz referência por um ou mais roteadores 2212 gerados automaticamente pelo processo de scaffolding. Uma rota resolve para um controlador 2213 que também é gerado automaticamente pelo processo de scaffolding. Um controlador executa lógica de negócio para executar e orquestrar um ou mais fluxos de trabalho para realizar a funcionalidade associada ao ponto de extremidade de API invocado por uma solicitação de API roteada pelo roteador ao controlador em conformidade com as rotas. Por exemplo, um controlador pode ser configurado para executar a funcionalidade associada a ponto de extremidade de API "criação de circuito virtual" para a plataforma de interconexão. Um roteador para o aplicativo com base em solicitações de rotas de microsserviço que invoca o ponto de extremidade de API de "criação de circuito virtual" ao controlador, o que executa o um ou mais fluxos de trabalho para atender à solicitação.

[0262] A Figura 24 a 26 retrata interfaces e entrada/saída exemplificativas para um enquadramento de desenvolvimento, de acordo com as técnicas descritas no presente documento.

[0263] As interfaces 2300 e 2302 da Figura 24 retratam a execução da CLI de enquadramento de desenvolvimento e uma tela inicial para a CLI de enquadramento de desenvolvimento, respectivamente. A Interface 2300 também ilustra um comando do CLI de enquadramento de desenvolvimento utilizável para criar fácil e rapidamente um stub de microsserviço.

[0264] A interface 2400 da Figura 25 retrata um contrato de API exemplificativo criado por um desenvolvedor.

[0265] A interface 2402 da Figura 25 retrata um processo de scaffolding executado contra o contrato de API retratado na interface 2400. O processo de scaffolding gera um controlador e roteadores, modelos para cada um dos esquemas de modelo no contrato de API, um arquivo de implantação para os microsserviços, dados de amostra, casos de teste, um arquivo de validação e configuração para desenvolvimento, UAT, QA, produção e informações locais. Esse plano gráfico de microsserviço gerado automaticamente pelo enquadramento de desenvolvimento pode permitir que o desenvolvedor comece a implantar rapidamente a lógica de negócio para o microsserviço e evitar a criação desses aspectos do plano gráfico de microsserviço. Ou seja, o enquadramento de desenvolvimento pode fornecer um modo fácil e organizado de iniciar o desenvolvimento de aplicativos com base em microsserviço e de possibilitar que os desenvolvedores foquem na gravação de aplicativo reutilizável ou de lógica de negócios em vez de desperdiçar tempo construindo infraestrutura de software.

[0266] O enquadramento de desenvolvimento descrito no presente documento pode ser usado para desenvolver uma plataforma de interconexão para uma troca de serviços com base em nuvem, tal como a plataforma de interconexão 103. Conforme descrito acima em relação às Figuras 3A a 3B e, ao longo do presente documento, a plataforma de interconexão pode incluir uma porta de comunicação de API 403 que expõe interfaces especializadas para múltiplos canais, por exemplo, móveis, web, API 402C, aplicativos de comprador 402A, aplicativos de vendedor 402B. A plataforma de interconexão inclui um orquestrador (por exemplo, orquestrador 706) e múltiplos microsserviços (por exemplo, microsserviços 408D, 708, 1630), conforme descrito em relação a diferentes retratos da plataforma de interconexão das Figuras. 1, 2, 3A a 3B, 4, 13, 14, e ao longo da presente revelação. O orquestrador (e fluxos de trabalho associados) e os microsserviços podem ter o scaffolding dos mesmos realizado com o uso do enquadramento de desenvolvimento descrito na presente revelação para facilitar que o desenvolvimento rápido de recursos e de serviços sejam realizados por uma plataforma de interconexão para interconectar os serviços com base em nuvem e gerenciar tais interconexões em uma troca de serviços com base em nuvem.

[0267] A Figura 26 retrata a interface 2500 que mostra uma página de documentação e de teste para uma interface de microsserviço gerada do contrato de API retratado na interface 2400. O enquadramento de desenvolvimento pode gerar automaticamente um catálogo de microsserviço / API para o aplicativo. Com múltiplos microsserviços com base em HTTP, é fácil se perder dentro das várias interfaces, porém, o enquadramento de desenvolvimento constrói automaticamente um catálogo de API com base em contrato de API de YAML que descreve todos os microsserviços e a funcionalidade exposta dos mesmos. O catálogo de API pode ser buscável. O enquadramento cria automaticamente o ponto de extremidade /api-docs para cada um dentre os pontos de extremidade em que a descrição de Notação de Objeto JavaSripct estiver disponível.

[0268] Nesse exemplo modelo, um esquema de modelo de "ordens" define os campos para um modelo de ordens. A interface 2500 gerada pelo enquadramento de desenvolvimento, uma vez que tenha prosseguido o esquema de modelo de ordens, apresenta operações de HTTP 2500A a 2500D geradas automaticamente pelo enquadramento de desenvolvimento. O botão de operação POSTAR 2500A possibilita que um usuário entre e adicione um novo exemplo de ordem a partir da interface 2500 com o uso do ponto de extremidade gerado automaticamente para o microsserviço de ordens que, novamente, é gerado automaticamente pelo enquadramento de desenvolvimento. O botão de operação OBTER 2500B, botão de operação EXCLUIR 2500C e o botão de operação COLOCAR 2500D fornece a funcionalidade de teste OBTER, EXCLUIR E COLOCAR para as ocorrências das ordens. Com o uso da interface 2500, um usuário pode realizar teste e implantação repetitiva de microsserviços.

[0269] A Figura 27 é um diagrama de que retrata os componentes de uma plataforma de interconexão para uma troca de serviços com base em nuvem, desenvolvidos com o uso de um enquadramento de desenvolvimento de acordo com as técnicas descritas na presente revelação. O orquestrador 2630 realiza o microsserviço management 2606 e inclui um gerenciador de fluxo de trabalho e mecanismo de execução 2608 para executar os microsserviços de acordo com os fluxos de trabalho. Múltiplos microsserviços 2632 são retratados, incluindo um circuito virtual 2610 para definir e gerenciar as interconexões de circuito virtual na troca de nuvem e outros microsserviços 2612, 2614 para conexões externas a serviços de nuvem externos 2618, 2620. Ainda outros microsserviços podem corresponder aos microsserviços 708, 817, 819, aos serviços de API de troca de nuvem 409 e outros exemplos de microsserviços para uma plataforma de interconexão conforme descrito no presente documento. O orquestrador 2630 apresenta canais de API especializados a diferentes categorias de usuários 2600A a 2600D por meio de um portal de cliente 2602 e APIs externos 2604. Cada tal canal de API pode ser desenvolvido com o uso de um contrato de API totalmente passível de personalização, conforme descrito acima.

[0270] A Figura 28 é um diagrama de blocos que ilustra outros detalhes de um exemplo de um dispositivo de computação que opera em conformidade com uma ou mais técnicas da presente revelação. A Figura 28 pode ilustrar um exemplo particular de um servidor, estação de trabalho, dispositivo de computação do tipo laptop ou outro dispositivo de computação 2800 que inclui um ou mais processadores 2802 para executar um aplicativo com base em enquadramento de desenvolvimento de microsserviço ou qualquer outro dispositivo de computação descrito no presente documento. Outros exemplos de dispositivo de computação 2800 podem ser usados em outras ocorrências. Embora seja mostrado na Figura 28 com um dispositivo de computação autônomo 2800 a título de exemplo, um dispositivo de computação pode ser qualquer componente ou sistema que inclui um ou mais processadores ou outro ambiente de computação adequado para executar instruções de software e, por exemplo, não necessariamente incluem um ou mais elementos mostrados na Figura. 28 (por exemplo, unidades de comunicação 2806; e em alguns exemplos componentes, tais como dispositivo de armazenamento (ou dispositivos) 2808, podem não ser colocalizados ou estar no mesmo chassi que outros componentes). O dispositivo de computação 2800 pode estar localizado para executar, por exemplo, dentro de qualquer um dentre pontos de troca de nuvem 128, outra instalação de interconexão ou em uma filial ou ambiente de computação de nuvem empregadas ou usada por um provedor de troca de nuvem. As ocorrências de dispositivo de computação 2800 podem ser usadas pelos desenvolvedores de uma plataforma de interconexão para uma troca de nuvem. Dessa maneira, o dispositivo de computação 2800 pode representa um sistema de desenvolvimento de enquadramento de aplicativo.

[0271] Conforme mostrado no exemplo específico da Figura 28, o dispositivo de computação 2800 inclui um ou mais processadores 2802, um ou mais dispositivos de entrada 2804, uma ou mais unidades de comunicação 2806, um ou mais dispositivo de saída 2812, um ou mais dispositivos de armazenamento 2808 e dispositivo de usuário interface (UI) 2810 e unidade de comunicação 2806. O dispositivo de computação 2800, em um exemplo, inclui adicionalmente uma ou mais aplicativos 2822, aplicativo de construção de conceito virtual 2824 e o sistema operacional 2816 que são executáveis pelo dispositivo de computação 2800. Cada um dentre os componentes 2802, 2804, 2806, 2808, 2810 e 2812 são acoplados (física, comunicativa e/ou operacionalmente) para comunicações entre componentes. Em alguns exemplos, os canais de comunicação 2814 pode incluir um barramento de sistema, uma conexão de rede, uma estrutura de dados de comunicação entre processos ou qualquer outro método para comunicar dados. Como um exemplo, os componentes 2802, 2804, 2806, 2808, 2810 e 2812 podem ser acoplados por um ou mais canais de comunicação 2814.

[0272] Os processadores 2802, em um exemplo, são configurados para implantar a funcionalidade e/ou processar instruções para a execução dentro do dispositivo de computação 2800. Por exemplo, os processadores 2802 podem ter capacidade para processar as instruções armazenadas no dispositivo de armazenamento 2808. Os exemplos dos processadores 2802 podem incluir qualquer um ou mais dentre microprocessador, um controlador, um processador de sinal digital (DSP), um circuito integrado de aplicativo específica (ASIC), uma matriz de porta programável em campo (FPGA) ou um conjunto de circuitos equivalente distinto ou de lógica integrada.

[0273] Um ou mais dispositivos de armazenamento 2808 podem ser configurados para armazenar informações dentro do dispositivo de computação 2800 durante a operação. O dispositivo de armazenamento 2808, em alguns exemplos, é descrito como uma mídia de armazenamento legível por computador. Em alguns exemplos, o dispositivo de armazenamento 2808 é uma memória temporária, o que significa que um propósito primário do dispositivo de armazenamento 2808 não é um armazenamento a longo prazo. O dispositivo de armazenamento 2808, em alguns exemplos, é descrito como uma memória volátil, o que significa que o dispositivo de armazenamento 2808 não mantém os conteúdos armazenados quando o computador for desligado. Os exemplos de memórias voláteis incluem memórias de acesso aleatório (RAM), memórias de acesso aleatório dinâmicas (DRAM), memórias de acesso aleatório estáticas (SRAM) e outras formas de memórias voláteis conhecidas na técnica. Em alguns exemplos, o dispositivo de armazenamento 2808 é usado para realizar instruções de programa para execução pelos processadores 2802. O dispositivo de armazenamento 2808, em um exemplo, é usado por software ou por aplicativos em execução no dispositivo de computação 2800 para armazenar informações durante a execução de programa.

[0274] Os dispositivos de armazenamento 2808, em alguns exemplos, também incluem uma ou mais mídias de armazenamento legíveis por computador. Os dispositivos de armazenamento 2808 podem ser configurados para armazenar quantidades maiores de informações do que a memória volátil. Os dispositivos de armazenamento 2808 podem ser configurados para armazenamento a longo prazo de informações. Em alguns exemplos, os dispositivos de armazenamento 2808 incluem elementos de armazenamento não volátil. Os exemplos de tais elementos de armazenamento não volátil incluem discos rígidos magnéticos, discos ópticos, disquetes, memórias flash ou formas de memórias eletricamente programáveis (EPROM) ou memórias eletricamente apagáveis e programáveis (EEPROM).

[0275] O dispositivo de computação 2800, em alguns exemplos, também inclui uma ou mais unidades de comunicação 2806. O dispositivo de computação 2800, em um exemplo, utiliza unidades de comunicação 2806 para comunicar com dispositivos externos por meio de uma ou mais redes, tais como uma ou mais redes cabeadas/sem fio/móveis. As unidades de comunicação 2806 podem incluir um cartão de interface de rede, tal como um cartão de Ethernet, um transceptor óptico, um transceptor de radiofrequência ou qualquer outro tipo de dispositivo que possa enviar e receber informações. Outros exemplos de tal interfaces de rede podem incluir rádios 3G e WiFi. Em alguns exemplos, o dispositivo de computação 2800 usa unidade de comunicação 2806 para se comunicar com um dispositivo externo.

[0276] O dispositivo de computação 2800, em um exemplo, inclui também um ou mais dispositivos de interface de usuário 2810. Os dispositivos de interface de usuário 2810, em alguns exemplos, são configurados para receber entrada de um usuário através de retroalimentação táctil, de áudio ou de vídeo. Os exemplos de dispositivos(s) de interface de usuário 2810 incluem um visor com sensibilidade à presença, um mouse, um teclado, um sistema de resposta à voz, câmera de vídeo, microfone ou qualquer outro tipo de dispositivo para detectar um comando de um usuário. Em alguns exemplos, um visor com sensibilidade à presença inclui uma tela sensível ao toque.

[0277] Um ou mais dispositivos de saída 2812 podem ser incluídos também no dispositivo de computação 2800. O dispositivo de saída 2812, em alguns exemplos, é configurado para fornecer saída a um usuário com o uso de estímulos tácteis, de áudio ou de vídeo. O dispositivo de saída 2812, em um exemplo, inclui um visor com sensibilidade à presença, uma placa de som, uma placa de adaptador de gráfico de vídeo ou qualquer outro tipo de dispositivo para converter um sinal em uma forma apropriada compreensível por humanos ou máquinas. Os exemplos adicionais de dispositivo de saída 2812 incluem alto- falante, um tubo de raios catódicos (monitor de CRT, um visor de cristal líquido (LCD) ou qualquer outro tipo de dispositivo que pode gerar saída inteligível a um usuário.

[0278] O dispositivo de computação 2800 pode incluir o sistema operacional 2816. O sistema operacional 2816, em alguns exemplos, controla a operação de componentes de dispositivo de computação 2800. Por exemplo, o sistema operacional 2816, em um exemplo, facilita a comunicação de um ou mais aplicativos 2822 e aplicativo(s) de plataforma de interconexão 2824 com processadores 2802, unidade de comunicação 2806, dispositivo de armazenamento 2808, entrada dispositivo 2804, dispositivos de interface de usuário 2810 e dispositivo de saída 2812.

[0279] O aplicativo 2822 e o(s) aplicativo(s) enquadramento de desenvolvimento com base em microsserviço 2824 ("aplicativo(s) de enquadramento de desenvolvimento 2824") pode incluir também instruções e/ou dados de programa que são executáveis pelo dispositivo de computação 2800. O aplicativo (ou aplicativos) de enquadramento de desenvolvimento 2824 executável pelo dispositivo de computação 2800 pode incluir um ou mais dentre o servidor de API 2850, aplicativos de desenvolvimento e de execução de orquestração 2852, aplicativos de desenvolvimento e de execução de microsserviço 2854, e plugins 2856, sendo que cada um é ilustrado com linhas tracejadas para indicar que podem ou não ser executáveis por qualquer exemplo fornecido do dispositivo de computação 2800.

[0280] O servidor de API 2850 pode ser configurado para expor as APIs para microsserviços e para um orquestrador suja scaffolding foi realizado, de acordo com as técnicas descritas no presente documento. Os aplicativos de desenvolvimento e de execução de orquestração 2852 podem incluir componentes/aplicativos de plataforma de orquestrador 2000 da Figura 21. Os aplicativos de desenvolvimento e de execução de microsserviço 2852 podem incluir componentes/aplicativos de plataforma de microsserviço 2018 da Figura 21. Os plugins 2856 podem incluir componentes/aplicativos de plugins 2038 da Figura 21.

[0281] As técnicas descritas no presente documento podem ser implantadas em hardware, software, firmware ou em qualquer combinação dos mesmos. Vários recursos descritos como módulos, unidades ou componentes podem ser implantados juntos em um dispositivo de lógica integrada ou separadamente como dispositivos lógicos inoperáveis, porém, distintos ou como outros dispositivos de hardware. Em alguns casos, vários recursos de conjunto de circuitos eletrônicos podem ser implantados como um ou mais dispositivos de circuito integrado, tal como um chip ou conjunto de chips de circuito integrado.

[0282] Caso implantada em hardware, a presente revelação pode se referir a um aparelho, tal como um processador ou um dispositivo de circuito integrado, tal como um chip ou conjunto de chips de circuito integrado. Alternativa ou adicionalmente, caso implantadas em software ou hardware, as técnicas podem ser realizadas, pelo menos parcialmente, por uma mídia de armazenamento de dados legível por computador que compreende instruções que, quando executadas, fazem com que um processador realiza um ou mais métodos descritos acima. Por exemplo, a mídia de armazenamento legível por computador pode armazenar tais instruções para execução por um processador.

[0283] Um meio legível por computador pode formar parte de um produto de programa de computador, que pode incluir materiais de empacotamento. Um meio legível por computador pode compreender uma mídia de armazenamento de dados, tal como memória de acesso aleatório (RAM), memória de apenas leitura (ROM), memória de acesos aleatório não volátil (NVRAM), memória de apenas leitura eletricamente programável apagável (EEPROM), memória flash, mídias de armazenamento de dados óptica ou magnética e semelhantes. Em alguns exemplos, um artigo de fabricação pode compreender uma ou mais mídias de armazenamento legíveis por computador.

[0284] Em alguns exemplos, as mídias de armazenamento legíveis por computador podem compreender mídias não transitórias. O termo "não transitória" pode indicar que a mídia de armazenamento não é incorporado em uma onda portadora ou em um sinal de propagação. Em determinados exemplos, uma mídia de armazenamento não transitória pode armazenar dados que podem ao longo do tempo (por exemplo, em uma RAM em um cache).

[0285] Os códigos ou instruções podem ser software e/ou firmware executados por um conjunto de circuitos um que incluem ou mais processadores, tais como um ou mais processadores de sinal digital (DSPs), microprocessadores para propósitos gerais, circuitos integrados de aplicativo específica (ASICs), matrizes de chaveamento programáveis por campo (FPGAs) ou outro conjunto de circuitos lógicos equivalentes integrados ou distintos. Portanto, o termo "processador", conforme usado no presente documento pode se referir a qualquer uma das estruturas supracitadas ou qualquer outra estrutura adequada para a implantação das técnicas descritas no presente documento. Além disso, em alguns aspectos, a funcionalidade descrita na presente revelação pode ser fornecida dentro de módulos de software ou módulos de hardware.

[0286] Adicional ou alternativamente ao supracitado, os exemplos a seguir são descritos. Os recursos descritos em qualquer um dentre os exemplos a seguir podem ser utilizados com qualquer um dentre os outros exemplos descritos no presente documento.

[0287] Exemplo 1. Uma troca de serviços com base em nuvem que compreende um centro de dados de rede que inclui portas respectivas pelas quais uma pluralidade de redes se conecta ao centro de dados de rede, sendo que cada uma dentre as redes tem um espaço de endereço de rede diferente e associado a um diferente dentre uma pluralidade de clientes ou provedores de serviço de nuvem; uma pluralidade de ativos de interconexão dentro do centro de dados de rede e configurados para conectar, através de uma malha de comutação do centro de dados de rede, cada uma dentre as redes associadas à pluralidade de clientes da troca de serviços com base em nuvem a uma ou mais dentre as redes associadas aos provedores de serviço de nuvem, sendo que a pluralidade de ativos de interconexão inclui um conjunto respectivo de um ou mais circuitos virtuais para cada uma dentre as redes associadas à pluralidade de clientes e fornece conectividade de rede dentro do centro de dados de rede entre as redes associadas à pluralidade de clientes e serviços de nuvem em execução de dentro das redes associadas à pluralidade de provedores de serviço de nuvem; e uma plataforma de interconexão em execução em um ou mais dispositivos de gerenciamento dentro do centro de dados de rede e que apresenta uma interface de software alcançável pelas redes associadas à pluralidade de clientes e configurada para, em resposta ao recebimento de uma solicitação emitida por um aplicativo em execução dentro de qualquer uma dentre as redes associadas ao cliente, acessar a pluralidade de ativos de interconexão para satisfazer à solicitação.

[0288] Exemplo 2. A troca de serviços com base em nuvem do exemplo 1, em que a interface de software compreende uma interface de programação de aplicativo de descoberta que compreende pelo menos um método configurado para, em resposta a uma invocação do método por uma segundo aplicativo, retornar uma descrição da pluralidade de ativos de interconexão.

[0289] Exemplo 3. A troca de serviços com base em nuvem de qualquer um dentre os exemplos 1 a 2, em que a interface de software compreende uma interface de programação de aplicativo de transação que compreende pelo menos um método configurado para, em resposta a uma invocação do método por uma segundo aplicativo, provisionar um dentre os circuitos virtuais, validar um dentre os circuitos virtuais e confirmar a exclusão de um dentre os circuitos virtuais.

[0290] Exemplo 4. A troca de serviços com base em nuvem, de acordo com qualquer um dos exemplos 1 a 3, em que a interface de software compreende uma interface de programação de aplicativo que compreende pelo menos um método configurado para, em resposta à invocação do método por um aplicativo, retornar uma dentre as informações de definição recomendadas para serviços de nuvem, análise personalizada em relação à presença de competidor, presença de serviço de nuvem, disponibilidade de serviço de nuvem, presença de cliente, disponibilidade de cliente e estatística de uso para serviços de nuvem.

[0291] Exemplo 5. A troca de serviços com base em nuvem, de qualquer um dentre os exemplos 1 a 4, em que a interface de software compreende uma interface de programação de aplicativo de suporte compreende pelo menos um método configurado para, em resposta à invocação do método por uma segundo aplicativo, realizar pelo menos uma dentre as contas de gerenciamento, cobrar ao cliente, validar crédito do cliente, configurar um perfil de uma entidade associada ao aplicativo e configurar uma política de uma entidade associado ao aplicativo.

[0292] Exemplo 6. A troca de serviços com base em nuvem, de qualquer um dentre os exemplos 2 a 5, em que a segundo aplicativo compreende uma dentre o aplicativo associada ao cliente e um aplicativo associada a um provedor de serviço de nuvem dentre os um ou mais provedores de serviço de nuvem.

[0293] Exemplo 7. A troca de serviços com base em nuvem do exemplo 1, em que a interface de software compreende uma interface de programação de aplicativo e em que o recebimento da solicitação emitida pela aplicativo em execução dentro de qualquer uma dentre as redes associadas ao cliente compreendem receber uma invocação de método para um método da interface de programação de aplicativo.

[0294] Exemplo 8. A troca de serviços com base em nuvem de qualquer um dentre os exemplos 1 a 7, em que a interface de software compreende uma interface de Transferência de Estado Representativo (RESTful) e em que a solicitação compreende dados de aplicativo que especificam um método de interface e um identificador de recurso para um ativo de interconexão da pluralidade de ativos de interconexão.

[0295] Exemplo 9. A troca de serviços com base em nuvem, de qualquer um dentre os exemplos 1 a 8, em que a pluralidade dos ativos de interconexão inclui adicionalmente pelo menos um dentre uma porta, uma localização, uma ordem, o serviço de nuvem, uma largura de banda do circuito virtual e o circuito virtual.

[0296] Exemplo 10. A troca de serviços com base em nuvem de qualquer um dentre os exemplos 1 a 9, em que a plataforma de interconexão compreende: uma porta de comunicação de interface de programação de aplicativo configurada para: executar a interface de software para receber a solicitação; e validar o cliente com base em uma credencial de segurança incluída na solicitação.

[0297] Exemplo 11. A troca de serviços com base em nuvem de qualquer um dentre os exemplos 1 a 9, em que a plataforma de interconexão compreende: uma porta de comunicação de interface de programação de aplicativo configurada para: executar a interface de software para receber a solicitação; invocar um serviço de plataforma de troca de nuvem para acessar a pluralidade de ativos de interconexão a fim de satisfazer à solicitação; receber, do serviço de plataforma de troca de nuvem, uma resposta; e enviar, para o aplicativo em execução dentro de qualquer uma dentre as redes associadas ao cliente, uma representação da resposta.

[0298] Exemplo 12. A troca de serviços com base em nuvem de qualquer um dentre os exemplos 1 a 9, em que a plataforma de interconexão compreende: pelo menos um subsistema configurado para executar uma pluralidade de serviços de troca de nuvem, sendo que cada serviço de troca de nuvem da pluralidade de serviços de troca de nuvem é configurada para realizar uma tarefa de provisionamento de circuito virtual; e um mecanismo de orquestração configurado para orquestrar a pluralidade de serviços de troca de nuvem de acordo com um fluxo de trabalho para satisfazer a solicitação.

[0299] Exemplo 13. A troca de serviços com base em nuvem do exemplo 12, em que o mecanismo de orquestração é configurado para gerar o fluxo de trabalho aplicando-se um mecanismo de fluxo de trabalho e de regras à solicitação e a pelo menos uma dentre as políticas e perfis de serviço de nuvem, em que o fluxo de trabalho compreende uma série de solicitações para a pluralidade de serviços de troca de nuvem.

[0300] Exemplo 14. A troca de serviços com base em nuvem do exemplo 12, em que a plataforma de interconexão compreende: uma porta de comunicação de interface de programação de aplicativo configurada para invocar o mecanismo de orquestração com base pelo menos na solicitação.

[0301] Exemplo 15. Troca de serviços com base em nuvem, do exemplo 1, em que a fim de acessar a pluralidade de ativos de interconexão para satisfazer à solicitação, a plataforma de interconexão é configurada para provisionar um dentre os circuitos virtuais.

[0302] Exemplo 16. A troca de serviços com base em nuvem de qualquer um dentre os exemplos 1 a 9, em que a plataforma de interconexão compreende: um serviço de consulta de serviço de nuvem; um mecanismo de orquestração; uma porta de comunicação de interface de programação de aplicativo configurada para, em resposta ao recebimento da solicitação, invocar o mecanismo de orquestração para obter uma descrição do serviço de nuvem, em que o mecanismo de orquestração gera e executa um fluxo de trabalho para invocar o serviço de consulta de serviço de nuvem, em que o serviço de consulta de serviço de nuvem retorna a descrição do serviço de nuvem ao mecanismo de orquestração, em que o mecanismo de orquestração retorna a descrição do serviço de nuvem à porta de comunicação de interface de programação de aplicativo e em que, em resposta à solicitação, a porta de comunicação de interface de programação de aplicativo retorna a descrição do serviço de nuvem ao aplicativo em execução dentro de qualquer uma dentre as redes associadas ao cliente.

[0303] Exemplo 17. A troca de serviços com base em nuvem de qualquer um dentre os exemplos 1 a 9, em que a plataforma de interconexão compreende adicionalmente: um serviço de consulta de circuito virtual; um mecanismo de orquestração; uma porta de comunicação de interface de programação de aplicativo configurada para, em resposta ao recebimento da solicitação, invocar o mecanismo de orquestração para obter uma descrição do circuito virtual, em que o mecanismo de orquestração gera e executa um fluxo de trabalho para invocar o serviço de consulta de circuito virtual, em que o serviço de consulta de circuito virtual retorna a descrição do circuito virtual ao mecanismo de orquestração, em que o mecanismo de orquestração retorna a descrição do circuito virtual à porta de comunicação de interface de programação de aplicativo e em que, em resposta à solicitação, a porta de comunicação de interface de programação de aplicativo retorna a descrição do circuito virtual ao aplicativo em execução dentro de qualquer uma dentre as redes associadas ao cliente.

[0304] Exemplo 18. A troca de serviços com base em nuvem de qualquer um dentre os exemplos 1 a 9, em que a solicitação compreende uma solicitação para provisionar o circuito virtual a fim de fornecer ao cliente o acesso ao serviço de nuvem, em que a plataforma de interconexão compreende adicionalmente: um serviço de provisionamento de serviço de rede; um mecanismo de orquestração; uma porta de comunicação de interface de programação de aplicativo configurada para, em resposta ao recebimento da solicitação, invocar o mecanismo de orquestração a fim de provisionar o circuito virtual, em que o mecanismo de orquestração gera e executa um fluxo de trabalho para invocar o serviço de provisionamento de serviço de rede, em que o serviço de provisionamento de serviço de rede estabelece o circuito virtual de acordo com parâmetros da solicitação.

[0305] Exemplo 19. A troca de serviços com base em nuvem do exemplo 18, em que a plataforma de interconexão compreende adicionalmente: um serviço de integração de provedor de serviço de nuvem, em que o mecanismo de orquestração gera e executa o fluxo de trabalho para invocar o serviço de integração de provedor de serviço de nuvem para solicitar a confirmação do circuito virtual por um provedor de serviço de nuvem do um ou mais provedores de serviço de nuvem e em que o mecanismo de orquestração gera e executa um fluxo de trabalho para invocar o serviço de provisionamento de serviço de rede em resposta à confirmação de recebimento do circuito virtual pelo provedor de serviço de nuvem.

[0306] Exemplo 20. A troca de serviços com base em nuvem do exemplo 19, em que os parâmetros da solicitação especificam uma porta de comprador dentre as portas e uma porta de vendedor dentre as portas, e em que a plataforma de interconexão compreende adicionalmente: um serviço de porta, em que o mecanismo de orquestração gera e executa o fluxo de trabalho para invocar o serviço de porta a fim de validar a porta de comprador e a porta de vendedor, e em que o mecanismo de orquestração gera e executa um fluxo de trabalho a fim de invocar o serviço de provisionamento de serviço de rede em resposta a validação de recebimento da porta de comprador e da porta de vendedor.

[0307] Exemplo 21. A troca de serviços com base em nuvem do exemplo 18, em que os parâmetros da solicitação especificam uma largura de banda para o circuito virtual, e em que para estabelecer o circuito virtual de acordo com parâmetros da solicitação, o serviço de provisionamento de serviço de rede estabelece o circuito virtual que tem a largura de banda para o circuito virtual.

[0308] Exemplo 22. Troca de serviços com base em nuvem, de qualquer um dentre os exemplos 1 a 21, em que o cliente compreende um dentre um provedor de serviços de rede e uma empresa.

[0309] Exemplo 23. A troca de serviços com base em nuvem de qualquer um dentre os exemplos 1 a 22, em que cada uma dentre a pluralidade de redes é publicamente endereçável e tem um espaço de endereço de rede público diferente.

[0310] Exemplo 24. Uma troca de serviços com base em nuvem que compreende uma pluralidade de ativos de interconexão configurados para conectar um cliente da troca de serviços com base em nuvem a um ou mais provedores de serviço de nuvem, sendo que a pluralidade de ativos de interconexão inclui um circuito virtual pelo qual o cliente acessa um serviço de nuvem a partir do um ou mais provedores de serviço de nuvem; e um mecanismo de orquestração configurado para modificar a pluralidade de ativos de interconexão.

[0311] Exemplo 25. A troca de serviços com base em nuvem do exemplo 24 que compreende adicionalmente: pelo menos um subsistema configurado para executar uma pluralidade de serviços de troca de nuvem, sendo que cada serviço de troca de nuvem dentre a pluralidade de serviços de troca de nuvem é configurado para realizar uma tarefa de provisionamento de circuito virtual, em que para modificar a pluralidade de ativos de interconexão, o mecanismo de orquestração é configurado para orquestrar a pluralidade de serviços de troca de nuvem de acordo com um fluxo de trabalho a fim de satisfazer à solicitação.

[0312] Exemplo 26. A troca de serviços com base em nuvem do exemplo 25, em que o mecanismo de orquestração é configurado para gerar o fluxo de trabalho aplicando-se um mecanismo de fluxo de trabalho e de regras à solicitação e a pelo menos uma dentre as políticas e perfis de serviço de nuvem, e em que o fluxo de trabalho compreende uma série de solicitações para a pluralidade de serviços de troca de nuvem.

[0313] Exemplo 27. A troca de serviços com base em nuvem de qualquer um dentre os exemplos 24 a 26 que compreende adicionalmente: uma plataforma de interconexão que tem uma interface de software configurada para, em resposta ao recebimento de uma solicitação emitida por um aplicativo associada ai cliente, acessar a pluralidade de ativos de interconexão para satisfazer a solicitação; uma porta de comunicação de interface de programação de aplicativo configurada para invocar o mecanismo de orquestração com base pelo menos na solicitação, em que para modificar a pluralidade de ativos de interconexão, o mecanismo de orquestração é configurado para, em resposta à porta de comunicação de interface de programação de aplicativo que invoca a orquestração, modificar a pluralidade de ativos de interconexão.

[0314] Exemplo 28. Um método que compreende: executar, por uma troca de serviços com base em nuvem em um ou mais dispositivos de gerenciamento dentro de um centro de dados de rede, uma plataforma de interconexão para apresentar uma interface de software alcançável pelas redes associadas a uma pluralidade de clientes; e em resposta ao recebimento de uma solicitação emitidas por um aplicativo em execução dentro de qualquer uma dentre as redes associadas ao cliente, acessar uma pluralidade de ativos de interconexão do centro de dados de rede a fim de satisfazer a solicitação, em que o centro de dados de rede inclui portas respectivas pelas quais uma pluralidade de redes se conecta ao centro de dados de rede, sendo que cada uma dentre as redes tem um espaço de endereço de rede diferente e associado a um diferente dentre uma pluralidade de clientes ou provedores de serviço de nuvem, e em que uma pluralidade de ativos de interconexão dentro do centro de dados de rede conecta, através de uma malha de comutação do centro de dados de rede, cada uma dentre as redes associadas à pluralidade de clientes da troca de serviços com base em nuvem a uma ou mais dentre as redes associadas aos provedores de serviço de nuvem, sendo que a pluralidade de ativos de interconexão inclui um conjunto respectivo de um ou mais circuitos virtuais para cada uma dentre as redes associadas à pluralidade de clientes e que fornece conectividade de rede dentro do centro de dados de rede entre as redes associadas à pluralidade de clientes e serviços de nuvem em execução de dentro das redes associadas à pluralidade de provedores de serviço de nuvem.

[0315] Exemplo 29. O método do exemplo 28, em que a interface de software compreende uma interface de programação de aplicativo de descoberta que compreende pelo menos um método de descoberta, sendo que o método compreende adicionalmente: pelo método de descoberta em resposta a uma invocação do método de descoberta por uma segundo aplicativo, retornar uma descrição da pluralidade de ativos de interconexão.

[0316] Exemplo 30. O método de qualquer um dentre os exemplos 28 a 29, em que a interface de software compreende uma interface de programação de aplicativo de transação que compreende pelo menos um método de transação, sendo que o método compreende adicionalmente: pelo método de transação em resposta a uma invocação do método de transação por uma segundo aplicativo, provisionar um dentre os circuitos virtuais, validar um dentre os circuitos virtuais e confirmar exclusão de um dentre os circuitos virtuais.

[0317] Exemplo 31. O método de qualquer um dentre os exemplos 28 a 30, em que a interface de software compreende uma interface de programação de aplicativo de uso que compreende pelo menos um método de uso, sendo que o método compreende adicionalmente: pelo método de uso em resposta a uma invocação do método de uso por um aplicativo, retornar uma dentre as informações de definição recomendadas para serviços de nuvem, realizar análise personalizada em relação à presença de competidor, presença de serviço de nuvem, disponibilidade de serviço de nuvem, presença de cliente, disponibilidade de cliente e estatística de uso for serviços de nuvem.

[0318] Exemplo 32. O método de qualquer um dentre os exemplos 28 a 31, em que a interface de software compreende uma interface de programação de aplicativo de suporte que compreende pelo menos um método de suporte, sendo que o método compreende adicionalmente: pelo método de suporte em resposta a uma invocação do método de suporte por uma segundo aplicativo, realizar pelo menos uma dentre as contas de gerenciamento, cobrar o cliente, validar crédito do cliente, configurar um perfil de uma entidade associada ao aplicativo e configurar uma política de uma entidade associada ao aplicativo.

[0319] Exemplo 33. O método um dentre os exemplos 29 a 32, em que a segundo aplicativo compreende uma dentre o aplicativo associada ao cliente e um aplicativo associada a um provedor de serviço de nuvem dentre os um ou mais provedores de serviço de nuvem.

[0320] Exemplo 34. O método do exemplo 28, em que a interface de software compreende uma interface de programação de aplicativo e em que o recebimento da solicitação emitida pela aplicativo em execução dentro de qualquer uma dentre as redes associadas ao cliente compreendem receber uma invocação de método para um método da interface de programação de aplicativo.

[0321] Exemplo 35. O método de qualquer um dentre os exemplos 28 a 34, em que a interface de software compreende uma interface de Transferência de Estado Representativo (RESTful) e em que a solicitação compreende dados de aplicativo que especificam um método de interface e um identificador de recurso para um ativo de interconexão da pluralidade de ativos de interconexão.

[0322] Exemplo 36. O método de qualquer um dentre os exemplos 28 a 35, em que a pluralidade dos ativos de interconexão inclui adicionalmente pelo menos um dentre uma porta, uma localização, uma ordem, o serviço de nuvem, uma largura de banda do circuito virtual e o circuito virtual.

[0323] Exemplo 37. O método de qualquer um dentre os exemplos 28 a 36, em que a plataforma de interconexão compreende uma porta de comunicação de interface de programação de aplicativo, em que o recebimento da solicitação compreende executar a interface de software para receber a solicitação, sendo que o método compreende adicionalmente: validar o cliente com base em uma credencial de segurança incluída na solicitação.

[0324] Exemplo 38. O método de qualquer um dentre os exemplos 28 a 36, em que a plataforma de interconexão compreende uma porta de comunicação de interface de programação de aplicativo, em que o recebimento da solicitação compreende executar a interface de software para receber a solicitação, sendo que o método compreende adicionalmente: invocar, pela porta de comunicação de interface de programação de aplicativo, um serviço de plataforma de troca de nuvem para acessar a pluralidade de ativos de interconexão a fim de satisfazer a solicitação; receber, pela porta de comunicação de interface de programação de aplicativo a partir do serviço de plataforma de troca de nuvem, uma resposta; e enviar, pela porta de comunicação de interface de programação de aplicativo ao aplicativo em execução dentro de qualquer uma dentre as redes associadas ao cliente, uma representação da resposta.

[0325] Exemplo 39. O método de qualquer um dentre os exemplos 28 a 36, sendo que o método compreende adicionalmente: executar, pelo menos um subsistema da plataforma de interconexão, uma pluralidade de serviços de troca de nuvem, sendo que cada serviço de troca de nuvem da pluralidade de serviços de troca de nuvem é configurada para realizar uma tarefa de provisionamento de circuito virtual; e orquestrar, por um mecanismo de orquestração da plataforma de interconexão, a pluralidade de serviços de troca de nuvem de acordo com um fluxo de trabalho para satisfazer a solicitação.

[0326] Exemplo 40. O método do exemplo 39, compreende adicionalmente: gerar, pelo mecanismo de orquestração, o fluxo de trabalho aplicando-se um mecanismo de fluxo de trabalho e de regras à solicitação e a pelo menos uma dentre as políticas e perfis de serviço de nuvem, em que o fluxo de trabalho compreende uma série de solicitações para a pluralidade de serviços de troca de nuvem.

[0327] Exemplo 41. O método do exemplo 39, invocar, por uma porta de comunicação de interface de programação de aplicativo da plataforma de interconexão, o mecanismo de orquestração com base pelo menos na solicitação.

[0328] Exemplo 42. Método do exemplo 28, em que a fim de acessar a pluralidade de ativos de interconexão para satisfazer à solicitação, sendo que a plataforma de interconexão é provisiona um dentre os circuitos virtuais.

[0329] Exemplo 43. O método de qualquer um dentre os exemplos 28 a 36, em que a plataforma de interconexão compreende: um serviço de consulta de serviço de nuvem; um mecanismo de orquestração; uma porta de comunicação de interface de programação de aplicativo configurada para, em resposta ao recebimento da solicitação, invocar o mecanismo de orquestração para obter uma descrição do serviço de nuvem, em que o mecanismo de orquestração gera e executa um fluxo de trabalho para invocar o serviço de consulta de serviço de nuvem, em que o serviço de consulta de serviço de nuvem retorna a descrição do serviço de nuvem ao mecanismo de orquestração, em que o mecanismo de orquestração retorna a descrição do serviço de nuvem à porta de comunicação de interface de programação de aplicativo e em que, em resposta à solicitação, a porta de comunicação de interface de programação de aplicativo retorna a descrição do serviço de nuvem ao aplicativo em execução dentro de qualquer uma dentre as redes associadas ao cliente.

[0330] Exemplo 44. O método de qualquer um dentre os exemplos 28 a 36, em que a plataforma de interconexão compreende adicionalmente: um serviço de consulta de circuito virtual; um mecanismo de orquestração; uma porta de comunicação de interface de programação de aplicativo configurada para, em resposta ao recebimento da solicitação, invocar o mecanismo de orquestração para obter uma descrição do circuito virtual, em que o mecanismo de orquestração gera e executa um fluxo de trabalho para invocar o serviço de consulta de circuito virtual, em que o serviço de consulta de circuito virtual retorna a descrição do circuito virtual ao mecanismo de orquestração, em que o mecanismo de orquestração retorna a descrição do circuito virtual à porta de comunicação de interface de programação de aplicativo e em que, em resposta à solicitação, a porta de comunicação de interface de programação de aplicativo retorna a descrição do circuito virtual ao aplicativo em execução dentro de qualquer uma dentre as redes associadas ao cliente.

[0331] Exemplo 45. O método de qualquer um dentre os exemplos 28 a 36, em que a solicitação compreende uma solicitação para provisionar o circuito virtual a fim de fornecer ao cliente o acesso ao serviço de nuvem, em que a plataforma de interconexão compreende adicionalmente: um serviço de provisionamento de serviço de rede; um mecanismo de orquestração; uma porta de comunicação de interface de programação de aplicativo configurada para, em resposta ao recebimento da solicitação, invocar o mecanismo de orquestração a fim de provisionar o circuito virtual, em que o mecanismo de orquestração gera e executa um fluxo de trabalho para invocar o serviço de provisionamento de serviço de rede, em que o serviço de provisionamento de serviço de rede estabelece o circuito virtual de acordo com parâmetros da solicitação.

[0332] Exemplo 46. Método do exemplo 45, em que a plataforma de interconexão compreende adicionalmente: um serviço de integração de provedor de serviço de nuvem, em que o mecanismo de orquestração gera e executa o fluxo de trabalho para invocar o serviço de integração de provedor de serviço de nuvem para solicitar a confirmação do circuito virtual por um provedor de serviço de nuvem do um ou mais provedores de serviço de nuvem e em que o mecanismo de orquestração gera e executa um fluxo de trabalho para invocar o serviço de provisionamento de serviço de rede em resposta à confirmação de recebimento do circuito virtual pelo provedor de serviço de nuvem.

[0333] 47. O método do exemplo 46, em que os parâmetros da solicitação especificam uma porta de comprador dentre as portas e uma porta de vendedor dentre as portas, e em que a plataforma de interconexão compreende adicionalmente: um serviço de porta, em que o mecanismo de orquestração gera e executa o fluxo de trabalho para invocar o serviço de porta a fim de validar a porta de comprador e a porta de vendedor, e em que o mecanismo de orquestração gera e executa um fluxo de trabalho a fim de invocar o serviço de provisionamento de serviço de rede em resposta a validação de recebimento da porta de comprador e da porta de vendedor.

[0334] Exemplo 48. O método do exemplo 45, em que os parâmetros da solicitação especificam uma largura de banda para o circuito virtual, e em que para estabelecer o circuito virtual de acordo com parâmetros da solicitação, o serviço de provisionamento de serviço de rede estabelece o circuito virtual que tem a largura de banda para o circuito virtual.

[0335] Exemplo 49. O método de qualquer um dentre os exemplos 28 a 48, em que o cliente compreende um dentre um provedor de serviços de rede e uma empresa.

[0336] Exemplo 50. Método de qualquer um dentre os exemplos 28 a 29, em que cada uma dentre a pluralidade de redes é publicamente endereçável e tem um espaço de endereço de rede público diferente.

[0337] Exemplo 51. Uma troca de serviços com base em nuvem que compreende uma pluralidade de ativos de interconexão configurados para conectar um cliente da troca de serviços com base em nuvem a um ou mais provedores de serviço de nuvem, sendo que a pluralidade de ativos de interconexão inclui um circuito virtual pelo qual o cliente acessa um serviço de nuvem a partir do um ou mais provedores de serviço de nuvem; e um mecanismo de orquestração configurado para modificar a pluralidade de ativos de interconexão.

[0338] Exemplo 52. A troca de serviços com base em nuvem do exemplo 51 que compreende adicionalmente: pelo menos um subsistema configurado para executar uma pluralidade de serviços de troca de nuvem, sendo que cada serviço de troca de nuvem dentre a pluralidade de serviços de troca de nuvem é configurado para realizar uma tarefa de provisionamento de circuito virtual, em que para modificar a pluralidade de ativos de interconexão, o mecanismo de orquestração é configurado para orquestrar a pluralidade de serviços de troca de nuvem de acordo com um fluxo de trabalho a fim de satisfazer à solicitação.

[0339] Exemplo 53. A troca de serviços com base em nuvem do exemplo 52, em que o mecanismo de orquestração é configurado para gerar o fluxo de trabalho aplicando-se um mecanismo de fluxo de trabalho e de regras à solicitação e a pelo menos uma dentre as políticas e perfis de serviço de nuvem, e em que o fluxo de trabalho compreende uma série de solicitações para a pluralidade de serviços de troca de nuvem.

[0340] Exemplo 54. A troca de serviços com base em nuvem de qualquer um dentre os exemplos 25 a 53 que compreende adicionalmente: uma plataforma de interconexão que tem uma interface de software configurada para, em resposta ao recebimento de uma solicitação emitida por um aplicativo associada ai cliente, acessar a pluralidade de ativos de interconexão para satisfazer a solicitação; uma porta de comunicação de interface de programação de aplicativo configurada para invocar o mecanismo de orquestração com base pelo menos na solicitação, em que para modificar a pluralidade de ativos de interconexão, o mecanismo de orquestração é configurado para, em resposta à porta de comunicação de interface de programação de aplicativo que invoca a orquestração, modificar a pluralidade de ativos de interconexão.

[0341] Exemplo 55. Um meio legível por computador que compreende instruções que quando executadas fazem com que um ou mais processadores realizam qualquer um dentre os métodos dos exemplos 28 a 50.

[0342] Exemplo 56. Um centro de dados de rede que compreende meio para realizar qualquer um dentre os métodos dos exemplos 28 a 50.

[0343] Exemplo 57. Um dispositivo configurado para realizar o método de qualquer um dentre os exemplos 28 a 50.

[0344] Exemplo 58. Aparelho que compreende meio para realizar os métodos de qualquer um dentre os exemplos 28 a 50.

[0345] Exemplo 59. Um método que compreende : por um mecanismo de orquestração de uma troca de serviços com base em nuvem, receber uma indicação de uma solicitação de cliente para serviços de troca de nuvem oferecidos pela troca de serviços com base em nuvem; pelo mecanismo de orquestração, selecionar um fluxo de trabalho para fornecer os serviços de troca de nuvem, em que o fluxo de trabalho especifica um conjunto de tarefas a serem realizadas para atender à solicitação de cliente para os serviços de troca de nuvem; pelo mecanismo de orquestração, chamar um ou mais microsserviços para realizar as tarefas do conjunto de tarefas, conforme especificado pelo fluxo de trabalho selecionado; pelo mecanismo de orquestração, consolidar as respostas recebidas dos microsserviços após realizar as tarefas; e pelo mecanismo de orquestração, enviar uma resposta à solicitação de cliente para os serviços de troca de nuvem com base nas respostas consolidadas.

[0346] Exemplo 60. O método do exemplo 59, em que o recebimento da indicação da solicitação de cliente compreende receber uma indicação de uma solicitação de cliente para provisionar um circuito virtual para trocar os dados de serviço de nuvem entre uma rede de cliente localizada na troca de serviços com base em nuvem e uma rede de provedor de serviço de nuvem localizada na troca de serviços com base em nuvem, em que a seleção do fluxo de trabalho compreende selecionar um fluxo de trabalho para provisionar um circuito virtual, em que o fluxo de trabalho para provisionar o circuito virtual especifica um conjunto de tarefas que compreende: (i) obter detalhes de porta, (ii) obter detalhes de metrô e (iii) criar o circuito virtual com base nos detalhes de porta e nos detalhes de metrô.

[0347] Exemplo 61. O método de qualquer um dentre os exemplos 59 a 60, em que o mecanismo de orquestração distribui as tarefas do conjunto de tarefas ao longo de uma pluralidade de encadeamentos de execução de fluxo de trabalho para acessar o um ou mais microsserviços para realizar as tarefas.

[0348] Exemplo 62. O método de qualquer um dentre os exemplos 59 a 61, em que o mecanismo de orquestração executa em um ou mais dispositivos de gerenciamento dentro de um centro de dados de rede da troca de serviços com base em nuvem, em que o centro de dados de rede inclui portas respectivas pelas quais uma pluralidade de redes se conecta ao centro de dados de rede, sendo que cada uma dentre as redes tem um espaço de endereço de rede diferente e associado a um diferente dentre uma pluralidade de clientes ou provedores de serviço de nuvem.

[0349] Exemplo 63. O método de qualquer um dentre os exemplos 59 a 62, em que cada microsserviço dentre o um ou mais microsserviços compreende uma interface de programação de aplicativo correspondente alcançável por meio de um ponto de extremidade e em que a chamada dos um ou mais microsserviços compreende enviar, pelo mecanismo de orquestração, os dados de aplicativo aos pontos de extremidade para os microsserviços.

[0350] Exemplo 64. O método do exemplo 63, em que os dados de aplicativo compreendem dados de aplicativo codificados com o uso de um ou mais dentre Linguagem Marcada Extensível e Notação de Objeto Javascript.

[0351] Exemplo 65. O método de qualquer um dentre os exemplos 59 a 64, em que o recebimento da indicação da solicitação de cliente compreende receber uma indicação de uma solicitação de cliente para provisionar um circuito virtual na troca de serviços com base em nuvem para trocar dados de serviço de nuvem entre uma rede de cliente localizada na troca de serviços com base em nuvem e uma rede de provedor de serviço de nuvem localizada na troca de serviços com base em nuvem, em que o provisionamento do circuito virtual compreende, pelo mecanismo de orquestrador: invocar um primeiro microsserviço dos microsserviços para validar um provedor de serviço de nuvem para a rede de provedor de serviço de nuvem identificado na indicação; invocar um segundo microsserviço dos microsserviços para validar uma primeira porta da troca de nuvem para a rede de cliente e uma segunda porta da troca de nuvem para a rede de provedor de serviço de nuvem; e invocar um terceiro microsserviço dos microsserviços para configurar a troca de serviços com base em nuvem para criar o circuito virtual entre a primeira porta da troca de nuvem e a segunda porta da troca de nuvem.

[0352] Exemplo 66. O método de qualquer um dentre os exemplos 59 a 65, em que o circuito virtual compreende um dentre um caminho de camada 1 de extremidade a extremidade e um circuito virtual de Ethernet.

[0353] Exemplo 67. O método de qualquer um dentre os exemplos 59 a 65, compreende adicionalmente: pelo mecanismo de orquestração, em resposta à determinação de um primeiro microsserviço dentre o um ou mais microsserviços falhou em atender a uma solicitação enviada pelo mecanismo de orquestração, determinar a possibilidade de tentar novamente a solicitação com o primeiro microsserviço; pelo mecanismo de orquestração, em resposta à determinação de tentar novamente a solicitação com o primeiro microsserviço, enviar a solicitação ao primeiro microsserviço; e pelo mecanismo de orquestração, em resposta à determinação de não tentar novamente a solicitação com o primeiro microsserviço, identificar um segundo microsserviço do um ou mais microsserviços para executar a solicitação e enviar a solicitação ao segundo microsserviço.

[0354] Exemplo 68. O método de qualquer um dentre os exemplos 59 a 67, em que o mecanismo de orquestração recebe a indicação da solicitação de cliente por meio de uma interface de software alcançável por uma pluralidade de redes localizada na troca de serviços com base em nuvem e associada a respectivos clientes.

[0355] Exemplo 69. O método de qualquer um dentre os exemplos 59 a 68, em que o recebimento da indicação da solicitação de cliente compreende receber uma indicação de uma solicitação de cliente para visualizar um circuito virtual na troca de serviços com base em nuvem para trocar dados de serviço de nuvem entre uma rede de cliente localizada na troca de serviços com base em nuvem e uma rede de provedor de serviço de nuvem localizada na troca de serviços com base em nuvem, em que a satisfação da solicitação de cliente para visualizar o circuito virtual compreende, pelo mecanismo de orquestrador: invocar um primeiro microsserviço do microsserviços para validar um parâmetro de solicitação de circuito virtual identificado na indicação; invocar um segundo microsserviço dos microsserviços para consultar o circuito virtual para obter os dados que descrevem o circuito virtual; receber os dados que descrevem o circuito virtual do segundo microsserviço; e emitir uma resposta à solicitação de cliente que inclui os dados que descrevem o circuito virtual.

[0356] Exemplo 70. O método do exemplo 59, em que a seleção do fluxo de trabalho compreende, pelo mecanismo de orquestração, determinar um cliente que emitiu a solicitação de cliente e selecionar o fluxo de trabalho com base em um perfil associado ao cliente.

[0357] Exemplo 71. Uma troca de serviços com base em nuvem que compreende: uma pluralidade de ativos de interconexão configurada para conectar pelo menos um cliente da troca de serviços com base em nuvem a uma pluralidade de provedores de serviço de nuvem; e um mecanismo de orquestração configurado para modificar a pluralidade de ativos de interconexão através de: recebimento de uma indicação de uma solicitação de cliente para os serviços de troca de nuvem oferecidos pela troca de serviços com base em nuvem; seleção de um fluxo de trabalho para fornecer os serviços de troca de nuvem, em que o fluxo de trabalho especifica um conjunto de tarefas a ser realizado para atender à solicitação de cliente para os serviços de troca de nuvem; chamar um ou mais microsserviços para realizar as tarefas do conjunto de tarefas, conforme especificado pelo fluxo de trabalho selecionado; consolidação das respostas recebidas dos microsserviços após realizar as tarefas; e enviar uma resposta à solicitação de cliente para os serviços de troca de nuvem com base nas respostas consolidadas.

[0358] Exemplo 72. A troca de serviço com base em nuvem do exemplo 71.

[0359] em que a indicação da solicitação de cliente compreende uma indicação de uma solicitação de cliente para provisionar um circuito virtual para trocar dados de serviço de nuvem entre uma rede de cliente localizada na troca de serviços com base em nuvem e uma rede de provedor de serviço de nuvem localizada na troca de serviços com base em nuvem, em que para selecionar o fluxo de trabalho, o mecanismo de orquestração é configurado para selecionar um fluxo de trabalho para provisionar um circuito virtual, em que o fluxo de trabalho para provisionar o circuito virtual especifica um conjunto de tarefas que compreende: (i) obter detalhes de porta, (ii) obter detalhes de metrô e (iii) configurar os ativos de interconexão para criar o circuito virtual com base nos detalhes de porta e nos detalhes de metrô.

[0360] Exemplo 73. A troca de serviço com base em nuvem do exemplo 71, em que o mecanismo de orquestração é configurado para distribuir tarefas do conjunto de tarefas ao longo de uma pluralidade de encadeamentos de execução de fluxo de trabalho a fim de acessar o um ou mais microsserviços para realizar as tarefas.

[0361] Exemplo 74. A troca de serviço com base em nuvem do exemplo 71, em que o mecanismo de orquestração é configurado para executar em um ou mais dispositivos de gerenciamento dentro de um centro de dados de rede da troca de serviços com base em nuvem e em que o centro de dados de rede inclui portas respectivas pelas quais uma pluralidade de redes se conecta ao centro de dados de rede, sendo que cada uma dentre as redes tem um espaço de endereço de rede diferente e associado a um dentre uma pluralidade de clientes ou provedores de serviço de nuvem.

[0362] Exemplo 75. A troca de serviço com base em nuvem do exemplo 71, em que cada microsserviço dentre os um ou mais microsserviços compreende uma interface de programação de aplicativo correspondente alcançável por meio de um ponto de extremidade e em que, para chamar o um ou mais microsserviços, o mecanismo de orquestração é configurado para enviar dados de aplicativo aos pontos de extremidade para os microsserviços.

[0363] Exemplo 76. A troca de serviço com base em nuvem do exemplo 71, em que o recebimento da indicação da solicitação de cliente compreende uma indicação de uma solicitação de cliente para provisionar um circuito virtual na troca de serviços com base em nuvem para trocar dados de serviço de nuvem entre uma rede de cliente localizada na troca de serviços com base em nuvem e uma rede de provedor de serviço de nuvem localizada na troca de serviços com base em nuvem, em par provisionar o circuito virtual, o mecanismo de orquestrador é configurado para: invocar um primeiro microsserviço dos microsserviços para validar um provedor de serviço de nuvem para a rede de provedor de serviço de nuvem identificado na indicação; invocar um segundo microsserviço dos microsserviços para validar uma primeira porta da troca de nuvem para a rede de cliente e uma segunda porta da troca de nuvem para a rede de provedor de serviço de nuvem; e invocar um terceiro microsserviço dos microsserviços para configurar a troca de serviços com base em nuvem para criar o circuito virtual entre a primeira porta da troca de nuvem e a segunda porta da troca de nuvem.

[0364] Exemplo 77. A troca de serviços com base em nuvem do exemplo 76, em que o circuito virtual compreende um dentre um caminho de camada 1 de extremidade a extremidade e um circuito virtual de Ethernet.

[0365] Exemplo 78. A troca de serviços com base em nuvem que compreende: um centro de dados de rede que inclui portas respectivas pelas quais uma pluralidade de redes se conecta ao centro de dados de rede, sendo que cada uma dentre as redes tem um espaço de endereço de rede diferente e associado a um diferente dentre uma pluralidade de clientes ou provedores de serviço de nuvem; uma pluralidade de ativos de interconexão dentro do centro de dados de rede e configurada para conectar, através de uma malha de comutação do centro de dados de rede, cada uma dentre as redes associadas à pluralidade de clientes da troca de serviços com base em nuvem a uma ou mais dentre as redes associadas aos provedores de serviço de nuvem, sendo que a pluralidade de ativos de interconexão inclui um conjunto respectivo de um ou mais circuitos virtuais para cada uma dentre as redes associadas à pluralidade de clientes e fornece conectividade de rede dentro do centro de dados de rede entre as redes associadas à pluralidade de clientes e serviços de nuvem em execução de dentro das redes associadas à pluralidade de provedores de serviço de nuvem; e uma plataforma de interconexão configurada para execução para execução por um ou mais dispositivos de gerenciamento dentro do centro de dados de rede, sendo que a plataforma de interconexão compreende: um mecanismo de orquestração configurado para executar pelo menos um fluxo de trabalho que faz com que o mecanismo de orquestração invoque uma pluralidade de microsserviços para gerenciar os circuitos virtuais; e uma interface de software alcançável pelas redes associadas à pluralidade de clientes e configurada para, em resposta ao recebimento de uma solicitação de cliente, instruir o mecanismo de orquestração a executar o pelo menos um fluxo de trabalho.

[0366] Exemplo 79. Um sistema de enquadramento de desenvolvimento aplicativo que compreende: um ou mais processadores programáveis configurados para executar uma plataforma de microsserviço para desenvolver e executar uma pluralidade de microsserviços, em que cada microsserviço dos microsserviços compreende um serviço independentemente implantável configurado para executar uma ou mais funções para preencher um contrato de interface para uma interface para o microsserviço, em que os um ou mais processadores programáveis são configurados para executar uma plataforma de orquestração para desenvolver e executar um orquestrador para orquestrar os microsserviços a fim de executar um aplicativo com base em microsserviço.

[0367] Exemplo 80. O sistema de enquadramento de desenvolvimento aplicativo do exemplo 79, em que a plataforma de microsserviço é configurada para gerar, para um microsserviço da pluralidade de microsserviços e com base pelo menos em um microsserviço definição que define o contrato de interface para o microsserviço, um scaffolding de infraestrutura de serviço para o microsserviço.

[0368] Exemplo 81. O sistema de enquadramento de desenvolvimento aplicativo do exemplo 80, em que o scaffolding de infraestrutura de serviço compreende um ou mais dentre pelo menos um controlador, um roteador, pelo menos um arquivo de implantação, um modelo para cada esquema de modelo definido pelo microsserviço definição, dados de amostra e arquivo de validação.

[0369] Exemplo 82. O sistema de enquadramento de desenvolvimento aplicativo do exemplo 80, em que o scaffolding de infraestrutura de serviço compreende pelo menos um dentre um controlador e um roteador e em que o roteador é configurado para receber uma solicitação que invoca a interface para o microsserviço e para determinar, com base na solicitação, um controlador do pelo menos um controlador para processar a solicitação.

[0370] Exemplo 83. O sistema de enquadramento de desenvolvimento aplicativo do exemplo 80, em que a plataforma de microsserviço compreende um gerador de código para gerar, com base no microsserviço definição, código executável para o microsserviço.

[0371] Exemplo 84. O sistema de enquadramento de desenvolvimento aplicativo do exemplo 80, em que a plataforma de microsserviço compreende um mecanismo de documentação de interface de programação de aplicativo (API) para: gerar, com base no contrato de interface, dados legíveis por usuário que descrevem o contrato de interface; e emitir os dados legíveis por usuário para a exibição por um dispositivo de interface de usuário.

[0372] Exemplo 85. O sistema de enquadramento de desenvolvimento aplicativo do exemplo 80, em que a plataforma de microsserviço compreende um agregador de log para agregar informações de log para o microsserviço.

[0373] Exemplo 86. O sistema de enquadramento de desenvolvimento aplicativo do exemplo 80, em que a plataforma de microsserviço compreende um monitor de processo.

[0374] Exemplo 87. O sistema de enquadramento de desenvolvimento aplicativo do exemplo 80, em que a plataforma de microsserviço compreende um Enquadramento de Interface de Programação de aplicativo (API).

[0375] Exemplo 88. O sistema de enquadramento de desenvolvimento aplicativo da reivindicação 9, em que o enquadramento de API fornece uma arquitetura acionada por evento e uma API de I/O de não bloqueio.

[0376] Exemplo 89. O enquadramento de desenvolvimento de aplicativo do exemplo 79, em que a plataforma de microsserviço é configurada para gerar, para um microsserviço da pluralidade de microsserviços e com base pelo menos em um microsserviço definição que define o contrato de interface para o microsserviço, um conector de banco de dados externo com o qual o microsserviço realiza as operações de persistência.

[0377] Exemplo 90. O sistema de enquadramento de desenvolvimento aplicativo do exemplo 79, em que a plataforma de orquestração é configurada para gerar, com base pelo menos em definições de microsserviço respectivas que definem os contratos de interface respectivos para os microsserviços, um scaffolding de infraestrutura de serviço para o orquestrador.

[0378] Exemplo 91. O sistema de enquadramento de desenvolvimento aplicativo do exemplo 90, em que o scaffolding de infraestrutura de serviço compreende um ou mais dentre pelo menos um controlador, um roteador e pelo menos um fluxo de trabalho para os microsserviços.

[0379] Exemplo 92. O sistema de enquadramento de desenvolvimento aplicativo do exemplo 90, em que a plataforma de orquestração compreende um mecanismo de descoberta de serviço configurado para descobrir microsserviços disponíveis para rotear solicitações aos microsserviços.

[0380] Exemplo 93. O sistema de enquadramento de desenvolvimento aplicativo do exemplo 90, em que a plataforma de orquestração compreende um mecanismo de documentação de interface de programação de aplicativo (API) para: gerar, com base em um contrato de interface que define uma interface para o orquestrador, dados legíveis por usuário que descrevem o contrato de interface; e emitir os dados legíveis por usuário para exibir por um dispositivo de interface de usuário.

[0381] Exemplo 94. O sistema de enquadramento de desenvolvimento aplicativo do exemplo 90, em que a plataforma de orquestração compreende um gerador de código para gerar, com base no microsserviço definição, código executável para a orquestração.

[0382] Exemplo 95. O sistema de enquadramento de desenvolvimento aplicativo do exemplo 90, em que o orquestrador invoca múltiplos microsserviços e recebe respostas respectivas dos múltiplos microsserviços, e em que a plataforma de orquestração compreende um agregador de resposta para agregar as respostas e apresentar uma resposta uniforme a uma solicitação recebida pelo orquestrador.

[0383] Exemplo 96. Um sistema de enquadramento de desenvolvimento aplicativo que compreende: um ou mais processadores programáveis configurados para executar uma plataforma de microsserviço para desenvolver e executar uma pluralidade de microsserviços, em que cada microsserviço dentre os microsserviços compreende um serviço independentemente implantável configurado para executar uma ou mais funções para preencher um contrato de interface para um interface para o microsserviço, em que os um ou mais processadores programáveis são configurados para executar uma plataforma de orquestração para desenvolver e executar um orquestrador para orquestrar o microsserviços para executar uma plataforma de interconexão para uma troca de serviços com base em nuvem configurada para interconectar, com o uso de um ou mais circuitos virtuais, clientes da troca de serviços com base em nuvem.

[0384] Exemplo 97. O sistema de enquadramento de desenvolvimento aplicativo do exemplo 96, em que os microsserviços compreendem microsserviços para criar e gerenciar circuitos virtuais para interconectar clientes de empresa da troca de serviços com base em nuvem e clientes de provedor de serviço de nuvem da troca de serviços com base em nuvem.

[0385] Exemplo 98. O sistema de enquadramento de desenvolvimento aplicativo do exemplo 97, em que os microsserviços compreendem um ou mais dentre um circuito virtual microsserviço, um microsserviço de porta, um microsserviço de grupo de agregação de enlace, um microsserviço de metrô, um microsserviço de detalhe de provedor de serviço de nuvem, um microsserviço de qualidade de serviço, um microsserviço de serviço de cliente e de emissão tíquete, um microsserviço de busca, um microsserviço de inventário de ativos e de rede, um microsserviço de linguagem e um microsserviço de definições de serviço.

[0386] Exemplo 99. O sistema de enquadramento de desenvolvimento aplicativo do exemplo 97, em que o mecanismo de orquestração orquestra os fluxos de trabalho para preencher serviços oferecidos pela plataforma de interconexão.

[0387] Exemplo 100. O sistema de enquadramento de desenvolvimento aplicativo do exemplo 99, em que os serviços compreendem um ou mais dentre um serviço de gerenciamento de porta, um serviço de gerenciamento de metrô, um serviço de detalhe de provedor de serviço de nuvem, um serviço de gerenciamento de ordem, um serviço de visualização de circuito virtual, um serviço de exclusão de circuito virtual, um serviço de busca, um serviço de provedor de serviço de rede, um serviço de configuração de provedor de serviço de nuvem, um serviço de suporte e de tíquetes, um serviço de monitoramento e de estatística e um serviço de análise e de recomendação.

[0388] Exemplo 101. O sistema de enquadramento de desenvolvimento aplicativo do exemplo 99, em que os serviços correspondem a uma ou mais APIs de porta de comunicação de API.

[0389] Exemplo 102. Um método que compreende: configurar um enquadramento de desenvolvimento de aplicativo para execução por um ambiente de execução; criar um servidor de interface de programação de aplicativo (API); editar pelo menos um arquivo de definição, sendo que cada um dentre os arquivos de definição define uma interface para um orquestrador; processar, com o uso do enquadramento de desenvolvimento de aplicativo, o pelo menos um arquivo de definição para gerar infraestrutura de serviço para um aplicativo com base em microsserviço, incluindo um ou mais microsserviços; e executar, pelo servidor de API, o aplicativo com base em microsserviço.

[0390] Exemplo 103. O método do exemplo 102 que compreende adicionalmente: implantar um conjunto de pontos de extremidade de API para cada dentre o um ou mais microsserviços; e definir um fluxo de trabalho, em que o orquestrador executa o fluxo de trabalho para orquestrar o um ou mais microsserviços a fim de atender a uma solicitação recebida pelo servidor de API invocando-se os conjuntos respectivos de pontos de extremidade de API para cada um dentre o um ou mais microsserviços.

[0391] Exemplo 104. O método do exemplo 102 que compreende adicionalmente: definir um fluxo de trabalho, em que o orquestrador executa o fluxo de trabalho para orquestrar o um ou mais microsserviços a fim de atender à solicitação recebida pelo servidor de API.

[0392] Exemplo 105. O método do exemplo 102 em que o aplicativo com base em microsserviço compreende uma plataforma de interconexão para uma troca de serviços com base em nuvem.

[0393] Ademais, qualquer um dentre os recursos específicos apresentados em qualquer dentre os exemplos descritos acima podem ser combinados em exemplos benéficos dos técnicos descritos. Ou seja, qualquer um dentre os recursos específicos são aplicáveis de modo geral a todos os exemplos da invenção. Vários exemplos da invenção foram descritos.

[0394] Várias modalidades foram descritas. Essas e outras modalidades são abrangidas pelo escopo dos exemplos a seguir.

Claims (20)

1. Troca de serviços com base em nuvem CARACTERIZADA por compreender: um centro de dados de rede que inclui portas respectivas de uma malha de comutação à qual uma pluralidade de redes se conecta, sendo que cada uma dentre as redes que tem espaço de endereço de rede diferente e associado a um diferente dentre uma pluralidade de clientes e provedores de serviço de nuvem e em que cada rede associada a um provedor de serviço de nuvem compreende recursos de computação de cliente colocalizados dentro do centro de dados de rede que fornece pelo menos um serviço de nuvem a uma ou mais dentre as redes associadas à pluralidade de clientes; uma pluralidade de ativos de interconexão dentro do centro de dados de rede e configurada para se conectar, através da malha de comutação do centro de dados de rede, cada uma dentre as redes associadas à pluralidade de clientes dos serviços com base em nuvem troca para uma ou mais dentre as redes associadas aos provedores de serviço de nuvem, sendo que a pluralidade de ativos de interconexão inclui um conjunto respectivo de um ou mais circuitos virtuais, que cada um representa um caminho através da malha de comutação do centro de dados de rede, para cada uma dentre as redes associadas à pluralidade de clientes e fornece conectividade de rede dentro do centro de dados de rede a fim de possibilitar o acesso pelas redes associadas à pluralidade de clientes aos serviços de nuvem em execução dentro das redes associadas à pluralidade de provedores de serviço de nuvem; e uma plataforma de interconexão configurada para execução por um ou mais dispositivos de gerenciamento e que apresenta uma interface de software configurada para, em resposta ao recebimento de solicitação de um aplicativo, acessar a pluralidade de bens de interconexão para satisfazer a solicitação.

2. Troca de serviços com base em nuvem, de acordo com a reivindicação 1, CARACTERIZADA pela interface de software ser configurada para, em resposta à solicitação da aplicativo, retornar uma descrição da pluralidade de bens de interconexão.

3. Troca de serviços com base em nuvem, de acordo a reivindicação 1 ou 2, CARACTERIZADA pela interface de software compreende uma interface de programação de aplicativo de transação que compreende pelo menos um método configurado para, em resposta à solicitação da aplicativo, provisionar um dentre os circuitos virtuais, validar um dentre os circuitos virtuais e confirme a exclusão de um dentre os circuitos virtuais.

4. Troca de serviços com base em nuvem, de acordo com qualquer uma das reivindicações 1 a 3, CARACTERIZADA pela interface de software ser configurada para, em resposta à solicitação da aplicativo, retornar uma dentre as informações de definição recomendadas para serviços de nuvem, análise personalizada em relação à presença de competidor, presença de serviço de nuvem, disponibilidade de serviço de nuvem, presença de cliente, disponibilidade de cliente e estatística de uso para serviços de nuvem.

5. Troca de serviços com base em nuvem, de acordo com qualquer uma das reivindicações 1 a 4, CARACTERIZADA por: a solicitação especificar um cliente dentre os clientes, e em que a interface de software é configurada para, em resposta à solicitação da aplicativo, realizar pelo menos uma dentre as contas de gerenciamento, cobrar ao cliente, validar crédito do cliente, configurar um perfil de uma entidade associada ao aplicativo e configurar uma política de uma entidade associado ao aplicativo.

6. Troca de serviços com base em nuvem, de acordo com qualquer uma das reivindicações 1 a 5, CARACTERIZADA por: em que a interface de software compreende uma interface de Transferência de Estado Representativo (RESTful), e em que a solicitação compreende dados de aplicativo que especificam um método de interface e um identificador de recurso para um bem de interconexão dentre a pluralidade de bens de interconexão.

7. Troca de serviços com base em nuvem, de acordo com qualquer uma das reivindicações 1 a 6, CARACTERIZADA pela pluralidade dos bens de interconexão incluir adicionalmente pelo menos um dentre uma porta, uma localização, uma ordem, um serviço de nuvem, uma largura de banda do circuito virtual e o circuito virtual.

8. Troca de serviços com base em nuvem, de acordo com qualquer uma das reivindicações 1 a 7, CARACTERIZADA pela plataforma de interconexão compreender: um mecanismo de orquestração configurado para executar pelo menos um serviço de plataforma de troca de nuvem para gerenciar os bens de interconexão; uma porta de comunicação de interface de programação de aplicativo configurada para: executar a interface de software para receber a solicitação; invocar o pelo menos um serviço de plataforma de troca de nuvem para acessar a pluralidade de bens de interconexão para satisfazer à solicitação; receber, a partir do serviço de plataforma de troca de nuvem, uma resposta; e enviar, ao aplicativo, uma representação da resposta.

9. Troca de serviços com base em nuvem, de acordo com a reivindicação 1, CARACTERIZADA pela plataforma de interconexão compreender: uma pluralidade de microsserviços configurados para executar serviços de troca de nuvem; e um mecanismo de orquestração configurado para orquestrar a pluralidade de microsserviços a fim de executar os serviços de troca de nuvem de acordo com um fluxo de trabalho para satisfazer à solicitação.

10. Troca de serviços com base em nuvem, de acordo com a reivindicação 9, CARACTERIZADA por: o mecanismo de orquestração ser configurado para identificar o fluxo de trabalho aplicando-se pelo menos uma dentre as políticas e os perfis de serviço de nuvem a um identificador de cliente incluído na solicitação, em que o fluxo de trabalho compreende uma série de solicitações para a pluralidade de serviços de troca de nuvem.

11. Troca de serviços com base em nuvem, de acordo com a reivindicação 1, CARACTERIZADA por, a fim de acessar a pluralidade de bens de interconexão para satisfazer à solicitação, a plataforma de interconexão ser configurada para provisionar um dentre os circuitos virtuais.

12. Troca de serviços com base em nuvem, de acordo com a reivindicação 1, CARACTERIZADA pela plataforma de interconexão compreender: um serviço de consulta de serviço de nuvem; um mecanismo de orquestração; uma porta de comunicação de interface de programação de aplicativo configurado para, em resposta ao recebimento da solicitação, invocar o mecanismo de orquestração para obter uma descrição de um serviço de nuvem, que o mecanismo de orquestração gera e executa um fluxo de trabalho para invocar o serviço de consulta de serviço de nuvem, em que o serviço de consulta de serviço de nuvem retorna a descrição do serviço de nuvem ao mecanismo de orquestração, em que o mecanismo de orquestração retorna a descrição do serviço de nuvem à porta de comunicação de interface de programação de aplicativo, e em que, em resposta à solicitação, a porta de comunicação de interface de programação de aplicativo retorna a descrição do serviço de nuvem ao aplicativo.

13. Troca de serviços com base em nuvem, de acordo com a reivindicação 1, CARACTERIZADA pela plataforma de interconexão compreender adicionalmente: um serviço de consulta de circuito virtual; um mecanismo de orquestração; uma porta de comunicação de interface de programação de aplicativo configurada para, em resposta ao recebimento da solicitação, invocar o mecanismo de orquestração a fim de obter uma descrição de um circuito virtual, em que o mecanismo de orquestração gera e executa um fluxo de trabalho para invocar o serviço de consulta de circuito virtual, em que o serviço de consulta de circuito virtual retorna a descrição do circuito virtual ao mecanismo de orquestração, em que o mecanismo de orquestração retorna a descrição do circuito virtual à porta de comunicação de interface de programação de aplicativo, e em que, em resposta à solicitação, a porta de comunicação de interface de programação de aplicativo retorna a descrição do circuito virtual ao aplicativo.

14. Troca de serviços com base em nuvem, de acordo com a reivindicação 1, CARACTERIZADA por: a solicitação compreender uma solicitação de provisão de um circuito virtual a fim de fornecer a um cliente o acesso a uma rede de provedor de serviço de nuvem, em que a plataforma de interconexão compreende adicionalmente: um serviço de provisionamento de serviço de rede; um mecanismo de orquestração; uma porta de comunicação de interface de programação de aplicativo configurada para, em resposta ao recebimento da solicitação, invocar o mecanismo de orquestração para provisionar o circuito virtual, em que o mecanismo de orquestração gera e executa um fluxo de trabalho a fim de invocar o serviço de provisionamento de serviço de rede, em que o serviço de provisionamento de serviço de rede estabelece o circuito virtual de acordo com os parâmetros da solicitação.

15. Troca de serviços com base em nuvem, de acordo com a reivindicação 14, CARACTERIZADA pela plataforma de interconexão compreender adicionalmente: um serviço de integração de provedor de serviço de nuvem, em que o mecanismo de orquestração gera e executa o fluxo de trabalho para invocar o serviço de integração de provedor de serviço de nuvem para solicitar a confirmação do circuito virtual por um provedor de serviço de nuvem do um ou mais dentre os provedores de serviço de nuvem para a rede de provedor de serviço de nuvem, e em que o mecanismo de orquestração gera e executa um fluxo de trabalho para invocar o serviço de provisionamento de serviço de rede em resposta à confirmação de recebimento do circuito virtual pelo provedor de serviço de nuvem.

16. Troca de serviços com base em nuvem, de acordo com a reivindicação 1, CARACTERIZADA pelo cliente compreender um dentre um provedor de serviços de rede e uma empresa.

17. Troca de serviços com base em nuvem, de acordo com a reivindicação 1, CARACTERIZADA por compreender adicionalmente: um sistema autônomo de camada três (L3) localizado dentro de um centro de dados, em que o sistema autônomo de L3 é configurado para receber, a partir de cada uma dentre uma pluralidade de redes de provedor de serviço de nuvem da pluralidade de redes, o tráfego de serviço de nuvem para pelo menos um serviço de nuvem e para a distribuição a uma ou mais redes de cliente dentre a pluralidade de redes; uma pluralidade de circuitos de fixação configurada para conectar, dentro do centro de dados, a pluralidade respectiva de redes de provedor de serviço de nuvem ao sistema autônomo de L3; e um ou mais circuitos de fixação configurados para conectar, dentro do centro de dados, a uma ou mais redes respectivas de cliente ao sistema autônomo de L3, em que o sistema autônomo de L3 é configurado para interconectar a pluralidade de redes de provedor de serviço de nuvem e a uma ou mais redes de cliente estabelecendo-se caminhos de L3 de extremidade à extremidade para os circuitos virtuais entre a pluralidade de redes de provedor de serviço de nuvem e as um ou mais redes de cliente, sendo que cada caminho de L3 de extremidade à extremidade inclui um dentre a pluralidade de circuitos de fixação que conecta a pluralidade respectiva de redes de provedor de serviço de nuvem ao sistema autônomo de L3 e também incluir um ou mais circuitos de fixação que conectam a uma ou mais respectivas redes de cliente ao sistema autônomo de L3, em que o sistema autônomo de L3 é configurado para encaminhar o tráfego de serviço de nuvem, recebido na pluralidade de circuitos de fixação que conecta a pluralidade respectiva de redes de provedor de serviço de nuvem ao longo dos caminhos de L3 de extremidade a extremidade ao um ou mais circuitos de fixação que conectam a uma ou mais redes de cliente respectivas ao sistema autônomo de L3.

18. Troca de serviços com base em nuvem, de acordo com a reivindicação 17, CARACTERIZADA por: as rotas de L3 não especificarem acessibilidade de L3 às redes diferentes da pluralidade de redes de provedor de serviço de nuvem e a um ou mais redes de cliente.

19. Troca de serviços com base em nuvem, de acordo com a reivindicação 18, CARACTERIZADA por: roteadores de margem de sistema autônomo do sistema autônomo de L3 incluírem tabelas de roteamento de BGP configuradas com as rotas de L3, em que as rotas de L3 compreendem rotas de BGP, e em que as tabelas de roteamento de BGP não são tabelas de BGP completas e não oferecem conectividade à Internet.

20. Método CARACTERIZADO por compreender: executar, por uma troca de serviços com base em nuvem com o uso de um ou mais dispositivos de gerenciamento, uma plataforma de interconexão para apresentar uma interface de software alcançável pelas redes associadas a uma pluralidade de clientes; e pela plataforma de interconexão em resposta ao recebimento de uma solicitação de um aplicativo, acessar uma pluralidade de bens de interconexão do centro de dados de rede para satisfazer a solicitação, em que o centro de dados de rede inclui portas respectivas de uma malha de comutação a qual uma pluralidade de redes se conecta, sendo que cada uma dentre as redes tem um espaço de endereço de rede diferente e associado a um diferente dentre uma pluralidade de clientes e provedores de serviço de nuvem, e em que uma pluralidade de ativos de interconexão dentro do centro de dados de rede conecta, através da malha de comutação do centro de dados de rede, cada uma dentre as redes associadas à pluralidade de clientes da troca de serviços com base em nuvem a uma ou mais dentre as redes associadas aos provedores de serviço de nuvem, e em que cada rede associada a um provedor de serviço de nuvem compreende recursos de computação de cliente, colocalizados dentre do centro de dados de rede, que fornecem pelo menos um serviço de nuvem a uma ou mais dentre as redes associadas à pluralidade de clientes, sendo que a pluralidade de ativos de interconexão inclui um conjunto respectivo de um ou mais circuitos virtuais, que cada um representa um caminho através da malha de comutação do centro de dados de rede, para cada uma dentre as redes associadas à pluralidade de clientes e que fornece conectividade de rede dentro do centro de dados de rede para possibilitar o acesso pelas redes associadas à pluralidade de clientes aos serviços de nuvem em execução dentro das redes associadas à pluralidade de provedores de serviço de nuvem.

Images