Sem servidor está aumentando, por que Ali, Microsoft e AWS estão começando a lançar o OAM?

Autor | Zhang Lei Deng Hongchao

Introdução: Recentemente, a equipe do AWS ECS lançou um projeto de código aberto chamado Amazon ECS para Open Application Model no GitHub oficial.Mais e mais fabricantes começaram a explorar a prática do OAM. Qual é o charme do OAM, permita que vários fornecedores de nuvem se unam para adotar?

Sem servidor 与 AWS

A palavra sem servidor foi usada pela primeira vez em um artigo de 2012 chamado "Por que o futuro de software e aplicativos é sem servidor". No entanto, se você realmente estuda arqueologia, verá que o conteúdo deste artigo é realmente o conceito de engenharia de software de integração contínua e controle de versão de código.Vamos falar sobre a "escala zero" e "pagamento" mencionados hoje pela Serverless. como você vai ", FaaS / BaaS, essas coisas não são nada.

Em 2014, a AWS lançou um produto chamado Lambda. O conceito de design deste produto é muito simples: acredita que a computação em nuvem está fornecendo serviços para aplicativos e, quando os usuários desejam implantar um aplicativo, ele só precisa de um local para escrever seus próprios programas para executar tarefas específicas, sem ter que se preocupar com isso. Em qual máquina ou em qual máquina virtual o programa é executado.

Foi o lançamento do Lambda que trouxe o paradigma "sem servidor" a um nível totalmente novo. O Serverless fornece uma arquitetura de sistema totalmente nova para implantação e execução de aplicativos na nuvem, enfatizando que os usuários não precisam se preocupar com configurações complexas de servidor, mas apenas com seu próprio código e como empacotá-lo em uma plataforma de computação em nuvem que pode ser hospedada " Entidade operacional ". Depois de uma série de recursos clássicos, como dimensionar instâncias de aplicativos com base no tráfego real e faturamento com base no uso real, em vez de recursos pré-alocados, a AWS gradualmente estabeleceu o padrão de fato no campo de sem servidor.

Em 2017, a AWS lançou o serviço Fargate, que estendeu o conceito de sem servidor para entidades executáveis ​​em contêineres.Em breve, essa idéia também foi seguida pelo Google Cloud Run etc., e abriu o "next generation" runtime sem servidor para contêineres. Crescimento.

Sem servidor (Open Application Model (OAM))

Então, o que o Open Application Model (OAM) tem a ver com a AWS e sem servidor?

Primeiro, OAM (Open Application Model) é um conjunto de especificações de descrição de aplicativo (spec) iniciadas em conjunto pelo Alibaba Cloud e Microsoft e mantidas em conjunto pela comunidade nativa da nuvem. O conceito central do OAM é: "centrado no aplicativo", que enfatiza que a P&D e a operação e manutenção trabalham juntas em torno de um conjunto de abstrações declarativas, flexíveis e extensíveis de nível superior, em vez de usar diretamente APIs complexas e obscuras da camada de infraestrutura.

Por exemplo, para um aplicativo baseado em contêiner que usa o K8s HPA para expansão horizontal, ele será definido pelos dois arquivos YAML a seguir na especificação OAM.

O arquivo YAML preparado pela P & D:

apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
  name: web-server
spec:
  # 待部署的应用详情
  workload:
    apiVersion: core.oam.dev/v1alpha2
    kind: Server
    spec:
      containers:
        - name: frontend
          image: frontend:latest

O arquivo YAML gravado pela operação e manutenção (ou plataforma PaaS):

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  name: helloworld
spec:
  components:
    - name: frontend
      # 该应用运行所需的运维能力
      traits:
        - trait:
            apiVersion: autoscaling.k8s.io/v2beta2
            kind: HorizontalPodAutoscaler
            metadata:
              name: scale-hello
            spec:
              minReplicas: 1
                          maxReplicas: 10

Pode-se observar que, sob a especificação OAM, o foco de P&D e operação e manutenção é completamente separado. A P&D e a operação e manutenção precisam apenas escrever um número muito pequeno de campos relacionados a eles mesmos, em vez de concluir os objetos K8s Deployment e HPA, você pode definir e publicar aplicativos facilmente. Esse é o benefício que a "abstração superior" traz para nós.

Depois que o arquivo YAML, como o descrito acima, for enviado aos K8s, ele será automaticamente convertido em um objeto HPA e de Implantação completo pelo plug-in OAM para realmente ser executado.

Como o OAM regula uma série de padrões de definição de entrega de aplicativos nativos da nuvem, como "aplicativo", "recursos de operação e manutenção" e "limite de liberação", os desenvolvedores da plataforma de gerenciamento de aplicativos podem usar essa especificação para descrever cada um deles por meio de um arquivo YAML mais conciso. Vários aplicativos e estratégias de operação e manutenção e, finalmente, por meio do plug-in OAM para mapear esses arquivos YAML com os recursos reais dos K8s (incluindo CRD).

Em outras palavras, o OAM fornece um padrão de fato para definir "abstração superior", e o papel mais importante dessa "abstração superior" é impedir vários detalhes da infraestrutura (como HPA, Ingress, contêineres, Pod, Serviço) Etc.) Vazou para colegas de pesquisa e desenvolvimento, causando complexidade desnecessária. Portanto, uma vez lançado o OAM, ele é chamado de "arma de arma" para o desenvolvimento da plataforma de aplicativos K8s.

Mais importante, porém, essa idéia de "remover os detalhes da camada de infraestrutura e fornecer a abstração de nível superior mais amigável para os desenvolvedores" da descrição do aplicativo coincide com o conceito sem servidor de "desestruturação". Mais precisamente, o OAM é inerentemente sem servidor.

Por esse motivo, uma vez lançado o OAM, ele recebeu atenção significativa no campo de sem servidor. Entre eles, é claro, a AWS também é indispensável.

A melhor experiência: AWS ECS for OAM

No final de março de 2020, a equipe do AWS ECS lançou um projeto de código aberto chamado Amazon ECS for Open Application Model no GItHub oficial.

Endereço do projeto: https://github.com/awslabs/amazon-ecs-for-open-application-model

Este projeto é uma tentativa da equipe da AWS de oferecer suporte ao OAM com base no serviço sem servidor. O tempo de execução subjacente deste projeto é o serviço de contêiner sem servidor mencionado anteriormente: Fargate. E a experiência que esse projeto do AWS ECS para OAM oferece aos desenvolvedores é muito interessante, vamos dar uma olhada.

Existem três etapas para o trabalho preparatório.

1. O usuário precisa ter as informações de autenticação da conta da AWS localmente, que podem ser geradas com um clique através do comando aws configure do cliente oficial da AWS;
2. Compile o projeto e, em seguida, você poderá obter um arquivo executável chamado oam-ecs;
3. Você precisa executar o comando oam-ecs env para preparar o ambiente para sua implementação subsequente. Depois que esse comando terminar, a AWS criará automaticamente uma VPC e a sub-rede pública / privada correspondente para você.

Após a conclusão da preparação, você só precisa definir um arquivo YAML do aplicativo OAM localmente (como o exemplo de aplicativo helloworld mencionado acima) .Em seguida, você pode colocar um aplicativo completo com o HPA no Fargate através do seguinte comando de uma linha Ele é implantado na Internet e pode ser acessado diretamente na rede pública:

oam-ecs app deploy -f helloworld-app.yaml

É muito simples?

Na documentação oficial do projeto AWS ECS for OAM, ele fornece um exemplo mais complicado, vamos explicar.

O aplicativo que queremos implantar neste momento consiste em três arquivos YAML, que ainda estão divididos em duas preocupações: P&D e operação e manutenção:

1. Pesquisa e desenvolvimento

• server-component.yaml: O conteúdo deste arquivo é o primeiro componente do aplicativo, que descreve o contêiner do aplicativo que queremos implantar;
• worker-component.yaml: o segundo componente do aplicativo de conteúdo neste arquivo, que descreve especificamente uma tarefa de loop responsável por verificar se a rede do ambiente atual está desobstruída.

2. O&M é responsável por escrever

example-app.yaml: O conteúdo deste arquivo é a topologia completa do componente de aplicativo e as características de operação e manutenção (características) de cada componente.Ele descreve especificamente uma estratégia de operação e manutenção "escalonador manual", usada especificamente Para expandir o componente trabalhador.

Portanto, o exemplo-app.yaml acima, que é a descrição completa do aplicativo, é o seguinte:

apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
  name: example-app
spec:
  components:
    - componentName: worker-v1
      instanceName: example-worker
      traits:
        - name: manual-scaler
          properties:
            replicaCount: 2
    - componentName: server-v1
      instanceName: example-server
      parameterValues:
        - name: WorldValue
          value: Everyone

Como você pode ver, ele define dois componentes (worker-v1 e server-v1), e o componente worker-v1 possui uma estratégia de expansão manual chamada manual-scaler.

Todos os três arquivos YAML nesta demonstração podem ser visualizados neste diretório: https://github.com/awslabs/amazon-ecs-for-open-application-model/tree/master/examples

No entanto, a implantação dos aplicativos complexos acima ainda é um comando, muito simples:

oam-ecs app deploy \
  -f examples/example-app.yaml \
  -f examples/worker-component.yaml \
  -f examples/server-component.yaml

Após a execução das instruções acima (os estudantes na China podem precisar de um pouco de paciência devido a problemas especiais de rede), é possível visualizar as informações de acesso ao aplicativo e o nome DNS através do comando oam-ecs app show. Abra o navegador e insira as informações de acesso, você pode acessar diretamente o aplicativo, como mostrado abaixo:

Se você deseja modificar a configuração do aplicativo, como atualizar a imagem ou modificar o valor de replicaCount, precisará modificar apenas o arquivo YAML acima e implantar novamente, o que é um gerenciamento completamente declarativo.

De fato, se as operações acima forem feitas através do AWS Console, pelo menos 5 páginas de produtos em nuvem precisarão ser puladas entre si para várias configurações; ou você precisará aprender a sintaxe do CloudFormation e escrever um CF muito, muito longo Arquivo, para extrair todos os recursos exigidos pelo aplicativo para executar a instância do Fargate, o LoadBalancer, a rede, a configuração de DNS etc.

No entanto, por meio da especificação do OAM, a definição e implantação do processo de aplicativo acima mencionadas não apenas se tornaram extremamente simples, mas também converteram diretamente o processo original das operações de serviço em nuvem em um arquivo YAML declarativo mais conciso e amigável. O trabalho específico necessário para implementar a especificação OAM aqui é na verdade apenas algumas centenas de linhas de código.

Mais importante, quando um serviço sem servidor como o AWS Fargate é combinado com uma definição de aplicativo compatível com o desenvolvedor como o OAM, você realmente sente: Acontece que essa carga mental simples, atualizada e extremamente baixa é sem servidor A melhor experiência para desenvolvedores.

Por fim: quando o modelo de aplicativo atende Serverless

O modelo OAM causou enormes repercussões no ecossistema de entrega de aplicativos nativos da nuvem. Atualmente, o serviço EDAS da Alibaba Cloud se tornou a primeira plataforma de gerenciamento de aplicativos em nível de produção do setor, construída no OAM, e em breve lança a próxima geração de experiência em produtos "centrados em aplicativos"; na comunidade CNCF, na conhecida equipe de gerenciamento de aplicativos em nuvem cruzada e O projeto Crossplane da plataforma de entrega também se tornou um importante adotante e mantenedor da especificação OAM.

Site oficial do EDAS: https://help.aliyun.com/product/29500.html
Crossplane: https://github.com/crossplane/crossplane

De fato, não apenas o AWS Fargate, mas todos os serviços sem servidor em nosso ecossistema de computação em nuvem podem usar facilmente o OAM como uma camada de apresentação orientada ao desenvolvedor e uma definição de aplicativo, simplificando e abstraindo a API de infraestrutura complexa original. A operação original do processo complexo "clique com um clique" para atualizar para o gerenciamento de aplicativo declarativo no estilo Kubernetes. Mais importante, graças à alta escalabilidade do OAM, você não só pode implantar aplicativos de contêiner no Fargate, mas também pode usar o OAM para descrever Função, máquina virtual, WebAssembly e até qualquer tipo de carga de trabalho que possa imaginar. Eles são facilmente implantados em serviços sem servidor e até migram perfeitamente entre diferentes serviços em nuvem. Essas habilidades aparentemente "mágicas" são todas as faíscas da inovação que podem colidir quando um "modelo de aplicativo" padronizado e extensível atende a uma plataforma sem servidor.

O modelo de aplicativo + Sem servidor tornou-se gradualmente um dos tópicos mais importantes da ecologia nativa da nuvem.Você pode fazer parte do Grupo de Entrega de Aplicativos Nativos em Nuvem do CNCF (SIG App Delivery) para promover o ecossistema de computação em nuvem em direção a "centralizado no aplicativo" Continue seguindo em frente!

Projeto AWS ECS on OAM: https://github.com/awslabs/amazon-ecs-for-open-application-model/
Projeto de modelo de aplicativo aberto: https://github.com/oam-dev/spec
Entrega de aplicativos CNCF SIG : Https://github.com/cncf/sig-app-delivery

No momento, as especificações e modelos do OAM realmente resolveram muitos problemas existentes, mas sua jornada apenas começou. O OAM é um projeto de código aberto neutro e convidamos mais pessoas a participarem dele para definir conjuntamente o futuro da entrega de aplicativos nativos da nuvem.

Métodos de participação:

• Entre no grupo de discussão chinês do projeto OAM

• Participe diretamente das discussões através do Gitter
• Endereço de implementação de código aberto do OAM
• Clique na estrela

Sobre o autor

Zhang Lei   Alibaba Cloud especialista técnico sênior. Ele é um dos mantenedores do projeto Kubernetes. Zhang Lei atualmente trabalha na equipe Kubernetes de Ali. Suas áreas de trabalho incluem Kubernetes e sistemas de gerenciamento de aplicativos nativos da nuvem.

Deng Hongchao é um   especialista da Alibaba Cloud Container Platform. Ex-engenheiro do CoreOS e um dos principais autores do projeto K8s Operator.

"O Alibaba Cloud Native se concentra em microsserviços, sem servidor, contêineres, malha de serviço e outros campos técnicos, se concentra nas tendências de tecnologias populares nativas da nuvem, nas práticas de pouso em larga escala nativas na nuvem e é o número público que entende melhor os desenvolvedores nativos da nuvem."