Sem servidor está aumentando, por que Ali, Microsoft e AWS adotam o OAM de código aberto?

[Prefácio] Como o primeiro modelo de arquitetura e definição padrão de aplicativo nativo da nuvem do mundo, o conceito principal do OAM (Open Application Model) é: "centrado no aplicativo", que enfatiza a pesquisa e o desenvolvimento, a operação e a manutenção em torno de um conjunto declarativo e flexível Abstrações estendidas de nível superior colaboram em vez de usar diretamente APIs complexas e obscuras da camada de infraestrutura. 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, para que vários fornecedores de nuvem possam se unir e adotar?

Zhang Lei, especialista técnico sênior da Alibaba Cloud Native Application Platform

Deng Hongchao, especialista técnico da Alibaba Cloud

Editor-Chefe Tang Xiaoyin

Cabeça Figura | baixar CSDN do Leste IC

Venda | CSDN (ID: CSDNnews)

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 é orientada para fornecer serviços para aplicativos e, quando os usuários desejam implantar um aplicativo, ele precisa apenas de um local para escrever seus próprios programas para executar tarefas específicas sem preocupação. Em qual máquina ou em qual máquina virtual esse 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 implantar e executar 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 empacotar o código 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 faturar com base no uso real, em vez de recursos pré-alocados, a AWS gradualmente estabeleceu o padrão de fato no campo da ausência de servidores.

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

Sem servidor (Open Application Model (OAM))

Então, o que o OAM tem a ver com a AWS e sem servidor?

Primeiro, o Open Application Model (OAM) é um conjunto de especificações de descrição de aplicativo (spec) iniciadas em conjunto pela 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:

# 研发负责编写这个 YAML 文件
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
---
# 运维(或者 PaaS 平台)负责编写这个 YAML 文件
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

Após o envio de um arquivo YAML para o K8s, ele será automaticamente convertido em um objeto Deployment and HPA completo pelo plug-in OAM e executado. Pode-se observar que, sob a especificação do OAM, o foco de P&D e operação e manutenção é completamente separado. O P&D apenas precisa escrever um número muito pequeno de campos relacionados a si mesmo e não precisa aprender a API completa do K8s. Definição e liberação do aplicativo.

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 traz para os desenvolvedores é muito interessante, vamos dar uma olhada.

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

  • 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.

  • Compile o projeto e, em seguida, você pode obter um arquivo executável chamado oam-ecs.

  • 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 dessa vez consiste em três arquivos YAML, que ainda estão divididos em duas preocupações: P&D e operação e manutenção:

  • R & D é responsável por escrever:

server-component.yaml

O conteúdo deste arquivo é o primeiro componente do aplicativo e descreve o contêiner do aplicativo que queremos implantar.

worker-component.yaml

O segundo componente do aplicativo de conteúdo neste arquivo descreve especificamente uma tarefa de loop responsável por verificar se a rede no ambiente atual está desobstruída.

  • A operação e manutenção é responsável por escrever:

example-app.yaml

O conteúdo desse arquivo é a topologia completa do componente de aplicativo e os traços de operação e manutenção 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 se 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 logo lança a próxima geração de experiência em produtos "centrados em aplicativos"; na comunidade CNCF, na conhecida comunidade 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 a AWS Fargate, 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 e definição de aplicativo orientada ao desenvolvedor, 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 ao "aplicativo-centrado" 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 do aplicativo CNCF SIG: https: //github.com/cncf/sig-app-delivery

Sobre o autor:

Zhang Lei, especialista técnico sênior da Alibaba Cloud Native Application Platform, embaixador da CNCF na China, presidente da CNCF Application Delivery Sig.

Deng Hongchao, especialista técnico em Alibaba Cloud e um dos autores originais do mecanismo Kubernetes Operator, tem mais pesquisas e experiência no sistema de gerenciamento de aplicativos K8s.

【FIM】

Benefícios de hoje

Conheça Lu Qi

Também como parte importante de "Um milhão de pessoas aprendem IA", a Conferência Dez Mil para Desenvolvedores da AIProCon 2020 será transmitida ao vivo on-line de 3 a 4 de julho, permitindo que os desenvolvedores aprendam sobre a tecnologia de ponta da IA ​​em uma parada Pesquisa, tecnologia e aplicação principais, e experiência prática de casos empresariais, e também pode participar de emocionantes e diversos salões de desenvolvedores e projetos de programação online. Participando da série de atividades prospectivas e da interação da transmissão ao vivo on-line, não apenas é possível se comunicar com dezenas de milhares de desenvolvedores, mas também a oportunidade de ganhar presentes exclusivos para transmissões ao vivo e até se juntar à gigante da tecnologia.

Os ingressos são limitados ao grande show! A partir de hoje, clique para ler o registro original "2020 AI Developer Ten Thousand Conference", use o código de cupom "AIP211", você pode obter um bilhete de conferência on-line gratuito no valor de 299 yuan. Limitado a 100 folhas, primeiro a chegar, primeiro a ser servido! Venha e use seu dedo para obter uma associação de graça!

Clique para ler o texto original e vá diretamente para o site oficial da conferência.

Artigos publicados em 1969 · mais de 40.000 elogios · 18,25 milhões de visualizações

Acho que você gosta

Origin blog.csdn.net/csdnnews/article/details/105608895
Recomendado
Clasificación