2019 tem sido um ano intenso, cheio de novidades e muitos novos padrões e standards. Kubernetes já se consolidou como plataforma de orquestração default há alguns anos e agora o movimento que vemos é na linha de criação de standards sobre o Kubernetes. Por outro lado, essa nova leva de padrões e especificações oferece um modelo de aplicações e serviços dinamicamente alocáveis, conectáveis e desalocáveis que parece vir de um futuro muito, mas muito distante. São iniciativas interessantes que muito provavelmente ainda sofrerão mutações e algumas fusões no percurso, mas que oferecem imenso potencial para viajarmos nas possibilidades de um futuro nem tão distante assim.

Assim começamos com o Open Application Model.

A microsoft Open Source fez uma publicação ontem a respeito do OAM, mas não é a única novidade a chegar ao mercado, temos também Open Service Broker API, e Cloud Native Application Bundle como novidades que chegaram agora no segundo semestre.

Vamos entender um pouco de cada um dessas especificações e standards.

Open Application Model (OAM)

[Texto traduzido e editado]

Desenvolvida entre com a parceria Microsoft e Alibaba, Open Application Model é uma especificação para descrever aplicações, para que a descrição da aplicação seja separada dos detalhes de como a aplicação é implantada e gerenciada pela infraestrutura. Essa separação de conceitos é útil por várias razões. No mundo real, cada cluster Kubernetes é diferente: Do Ingress ao CNI ao service mesh. A separação da definição de aplicação dos detalhes operacionais do cluster permite que os desenvolvedores de aplicações se concentrem nos elementos principais de seu aplicativo, e não nos detalhes operacionais de onde ele é implantado. Além disso, a separação de conceitos também permite que os arquitetos de plataformas desenvolvam componentes reutilizáveis e que os desenvolvedores de aplicativos se concentrem na integração desses componentes com seu código para criar aplicativos confiáveis e de maneira rápida e fácil. Em tudo isso, o objetivo do Open Application Model é tornar aplicativos simples, fáceis e complexos, administráveis.

No OAM, uma aplicação é feita a partir de vários conceitos. O primeiro são os componentes que compõem uma aplicação. Esses componentes podem ser serviços como um banco de dados MySQL ou um servidor PHP replicado com um balanceador de carga correspondente. Os desenvolvedores podem criar o código que empacotam como componente e, em seguida, criar manifestos que descrevem os relacionamentos entre esse componente e outros microsserviços. Os componentes permitem que arquitetos de plataforma e outros construam módulos reutilizáveis que são conhecidos por encapsular as práticas recomendadas em torno de segurança e implantação escalável. Eles também permitem a separação da implementação do componente da descrição de como esses componentes se reúnem em uma arquitetura completa de aplicativos distribuídos.

A especificação está disponível em openappmodel.io.

Notas:

Os modelos atuais de configuração oferecem uma visão sob medida para implantações pré-planejadas. Propostas como o OAM oferecem novas perspectivas, sob o ponto de vista de isolamento do que é um serviço e como este pode ser implantado. Sua utilização abre possibilidade para a composição de soluções como se fosse um grande lego, a partir de templates que expressam com fidelidade, as necessidades de cada elemento do stack, possibilitando encaixar um elemento com diversos papeis em um mesmo stack. Soluções assim tem muito potencial para a criação de dashboards de composição de topologias, oferecendo dados completos a respeito de como conectar cada elemento e sua arquitetura a oferecer recursos escaláveis e dinâmicos.

Alguns diagramas tendem a tornar mais claro como e o que se o OAM tende a solucionar.

A primeira visão que temos apresenta cada serviço descrito como um componente.

Note que na imagem acima, vemos um isolamento completo entre o que é um componente e quais de fato são os recursos que este componente está alocando. A separação entre deployment e estratégia de deployment é totalmente separada da definição de componente.

Com a visão acima vemos o isolamento entre aspectos da aplicação e aspectos de infraestrutura de aplicação e serviços de suporte como MQ, Cache, banco, Ausoscalling, Ingress, logging e persistência.

As visões de aplicação e infraestrutura de aplicação são isoladas de forma a permitir que sejam trabalhadas por profissionais de skills diferentes.

Embora isso não me pareça muito sadio, pelo aspecto de responsabilidades e times, isolar tem seus benefícios pelo aspecto de organização. Saber onde cada skill de informação está, faz diferença nesse modelo que cada vez mais ganha complexidade.

Rudr: A Kubernetes Implementation of the Open Application Model

Uma das primeiras implementações de OAM é o Rudr, que como o nome diz, é uma implementação de OAM baseada em Kubernetes.

O projeto está disponível em github.com/oam-dev/rudr.

Uma das possibilidades, a princípio a única até o momento, é via kubectl e HELM. A documentação para setup de um cluster kubernetes com Rudr está disponível no link.

O processo de instalação usa da infra de Custom Resources do Kubernetes para entregar 5 elementos custom resources: ApplicationConfigurations, ComponentInstances, ComponentSchematics, Scopes e Traits. Adicionalmente vemos configurações de ingress controlles com nginx-ingress e autoscalling com keda. Aparentemente esse é o escopo do setup.

apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: helloworld-python-v1
spec:
  name: helloworld-python
  workloadType: core.oam.dev/v1alpha1.Server
  containers:
    - name: foo
      image: oamdev/helloworld-python:v1
      env:
        - name: TARGET
          fromParam: target
        - name: PORT
          fromParam: port
      ports:
        - type: tcp
          containerPort: 9999
          name: http
  parameters:
    - name: target
      type: string
      default: World
    - name: port
      type: string
      default: '9999'

Isso habilita um novo KIND e um novo WORKLOAD TYPE, como apresentado no texto Create Component from Scratch.

Próximo Post

O próximo post é sobre CNAB – Cloud Native Application Bundle. Já faz algum tempo que queria falar sobre ele, e agora com o nascimento do OAM faz sentido tocar nesse assunto.