Planos de controle de nuvem para todos: implemente plataformas internas com Crossplane

Nas últimas duas décadas, a ascensão da computação em nuvem permitiu a criação de inúmeros novos negócios e revolucionou a forma como as organizações existentes operam e se expandem. O valor oferecido pelos provedores de serviços em nuvem durante esta transição não pode ser exagerado, mas também houve enormes vantagens para os próprios provedores de serviços em nuvem.

As eficiências de escala distribuídas aos clientes são experimentadas internamente em um grau ainda maior, permitindo que essas plataformas cresçam e se expandam rapidamente. Com Plano cruzadouma estrutura de código aberto para a construção de planos de controle nativos da nuvem, os clientes podem começar a perceber essas eficiências em suas próprias plataformas internas.

O valor dos serviços básicos

A maioria dos provedores de serviços em nuvem começou com algumas ofertas básicas em armazenamento e computação. Amazon Web Services (AWS) famosa começou com apenas S3 antes expandindo para computação com EC2. Esses serviços forneceram e continuam a fornecer um valor imenso para clientes que anteriormente teriam que investir muito tempo e dinheiro no gerenciamento da infraestrutura física e na criação de software. No entanto, eles também servem como base para a AWS expandir rapidamente o catálogo de serviços que oferece.

A razão pela qual os fornecedores de serviços em nuvem conseguem lançar novos serviços a um ritmo cada vez mais rápido é que os novos serviços podem ser construídos com base nas capacidades da infra-estrutura existente.

Por exemplo, AWS Lambda, uma popular plataforma sem servidor, foi lançada em grande escala porque foi construída com base na computação testada em batalha oferecida pelo EC2. Além disso, estes novos serviços são capazes de se integrar com outros oferecidos pelo fornecedor de nuvem, tais como bases de dados e armazenamento, e uma estrutura comum de gestão de identidade e acesso (IAM) poderia ser alargada para suportar a nova funcionalidade. O resultado é um efeito volante onde, em conjunto, o custo de lançamento do próximo serviço diminui ao longo do tempo.

Quando um provedor de nuvem tem recursos robustos de computação, rede e armazenamento ao seu alcance, fica muito mais fácil implementar novos serviços além desses primitivos.

Embora os clientes tenham beneficiado desta capacidade através da disponibilização de novos serviços, normalmente não conseguem desenvolver a mesma competência ao construir as suas próprias plataformas internas. O impacto é duplo:

• Os clientes estão sujeitos às decisões dos provedores de nuvem quando se trata de quais novos serviços serão lançados. Muitas vezes estas decisões são fortemente influenciadas pelos maiores clientes do fornecedor.
• Os clientes devem assumir o fardo de integrar e “produzir” novos serviços, o que normalmente inclui testes extensivos, documentação e revisão de conformidade.

É raro que uma organização de tamanho razoável exponha a infraestrutura bruta de nuvem aos desenvolvedores. Em vez disso, eles implementam alguma camada de abstração na API para garantir que apenas a infraestrutura que atenda às políticas internas possa ser provisionada. Estas políticas podem impor determinados requisitos de segurança, fiabilidade ou custos. Por exemplo, os desenvolvedores podem ter apenas a capacidade de provisionar alguns subconjuntos de tipos de instâncias EC2 para evitar incorrer em custos elevados.

Infelizmente, sempre que um novo serviço de nuvem é introduzido em uma organização, essas políticas precisam ser mapeadas para a API desse serviço. Embora o provedor de nuvem possa oferecer novos produtos com base em seus próprios serviços fundamentais, cada novo serviço que eles expõem aos clientes é uma nova API líquida a ser integrada em uma organização.

Esse linear tendência nas despesas gerais de integração do próximo serviço contrasta fortemente com o logarítmico curva que os provedores de nuvem experimentam ao lançar o serviço.

Quando cada novo serviço oferece sua própria API, o esforço investido na verificação dos serviços anteriores não reduz o esforço necessário para a verificação do próximo.

Idealmente, o trabalho árduo de integração de um serviço em uma organização seria amortizado pelos serviços subsequentes que ele possibilita. Cada vez mais organizações estão migrando para a construção de plataformas internas, em vez de apenas consumir serviços primitivos de nuvem. Este padrão cria uma oportunidade única para estas organizações construírem os seus próprios serviços fundamentais, que podem posteriormente ser utilizados para construir serviços de nível superior no futuro.

No entanto, operar uma plataforma é complexo e os provedores de nuvem têm trabalhado muito para construir planos de controle que os potencializem, apresentando uma única superfície de API e garantindo que os serviços sejam resilientes a falhas. Replicar esta quantidade de esforço de engenharia na maioria das organizações não é viável. Felizmente, o projeto Crossplane aproveitou os recursos do Kubernetes e construiu uma estrutura que torna possível a construção de plataformas baseadas em plano de controle para qualquer pessoa.

Definindo a base da sua plataforma

Ao iniciar sua jornada de plataforma interna, cada organização deve determinar quais APIs servirão como serviços básicos. Inúmeros fatores podem determinar por onde começar, incluindo o tamanho da empresa, a complexidade do produto e a cultura da organização de engenharia. Começar com um primitivo comumente usado, como um banco de dados ou uma carga de trabalho em contêiner, geralmente é uma aposta segura.

No Crossplane, as APIs da plataforma são definidas usando Composição, que permite que uma equipe de plataforma defina uma API com a qual os desenvolvedores possam interagir e uma ou mais implementações dessa API. Por exemplo, se os desenvolvedores implantarem frequentemente aplicativos empacotados como Imagens OCIuma equipe de plataforma pode definir um Carga de trabalho em contêiner API com parâmetros para referência de imagem e um conjunto de variáveis ​​de ambiente.

Uma implementação dessa API poderia ser uma Função AWS Lambdaum Definição de tarefa ECS ou qualquer outro conjunto de primitivas de computação. Embora esses serviços da AWS ofereçam uma ampla variedade de opções de personalização, apenas os parâmetros importantes para o desenvolvedor são expostos na plataforma interna, permitindo que a equipe da plataforma incorpore quaisquer políticas organizacionais, como tags ou limites de memória, nos bastidores.

Uma plataforma interna codifica a política, permitindo que as organizações aproveitem o valor oferecido pela infraestrutura em nuvem, ao mesmo tempo que estabelecem barreiras para operações que os desenvolvedores são capazes de realizar por conta própria.

Fornecendo as implementações iniciais do Carga de trabalho em contêiner são atividades de alto contato que exigem compreensão das APIs de serviço em nuvem das quais dependem. Em outras palavras, esta é a parte inicial da curva logarítmica, onde ainda é necessário um esforço significativo para adicionar uma nova API. No entanto, sua plataforma agora conta com seu primeiro serviço totalmente compatível com a política organizacional. Você definiu um serviço de base.

Crescendo com confiança

Nas fases iniciais da construção de uma plataforma, grande parte do trabalho envolverá a construção de serviços adicionais de fundação. Talvez os desenvolvedores também precisem frequentemente provisionar bancos de dados, então um MySQLInstance API é definida e implementada. No entanto, à medida que o conjunto principal de serviços básicos é completado, o custo de adicionar o próximo serviço começa a diminuir.

Por exemplo, com uma API de carga de trabalho e de banco de dados em vigor, um Carga de trabalho com estado A API pode ser adicionada à plataforma com esforço mínimo porque depende de serviços básicos que possuem políticas organizacionais incorporadas. Em outras palavras: compliance compõe.

Validação e conformidade são transitivas. Se uma API de nível superior for construída apenas em outras APIs compatíveis, então ela também será compatível.

Além disso, implícita nesta arquitetura está a propagação de mudanças e melhorias de plataforma de serviços de nível inferior para serviços de nível superior. Novos mandatos organizacionais, para qualquer coisa, desde conformidade com SOC2 até mudança de provedores de nuvem, podem ser executados no nível básico, mas aplicados a todos os níveis acima.

Além disso, a transição de uma API de nível superior, como Carga de trabalho com estadoconfiar diretamente nos serviços de nuvem em vez de APIs de plataforma interna pode ser realizado a qualquer momento porque a plataforma é construída empilhando APIs, não empilhando implementações.

Sua primeira plataforma em 5 minutos ou menos

Definir uma plataforma é inerentemente iterativo e o Crossplane facilita o início da jornada. Obtenha um cluster Kubernetes do seu provedor favorito, instalar plano cruzado e escolha um pacote QuickStart para implementar suas primeiras APIs!

A postagem Planos de controle de nuvem para todos: implemente plataformas internas com Crossplane apareceu pela primeira vez em The New Stack.