As empresas se aproximam da experiência da loja de aplicativos com Kubernetes e GitOps

Comentário: O grande problema corporativo não é executar centenas de aplicativos em várias nuvens; não, o grande problema é executar o mesmo aplicativo de forma consistente em apenas uma nuvem ou data center.

Estamos acostumados a obter aplicativos móveis por meio da App Store da Apple ou do Google Play, mas quando se trata de aplicativos corporativos, a experiência é muito diferente e muito pior. De acordo com o CEO da Weaveworks, Alexis Richardson, no entanto, não precisa ser assim. Embora estejamos talvez décadas distantes da disponibilização de software empresarial por meio de uma experiência semelhante à loja de aplicativos, também estamos muito mais próximos desses benefícios do que imaginamos. O truque, disse Richardson, não é realmente facilitar a implantação de aplicativos em várias nuvens.

Não, para a maioria das empresas, na maioria das vezes, eles estão apenas tentando garantir consistência na configuração do aplicativo na mesma nuvem (ou data center). Felizmente, Kubernetes e GitOps se combinaram para tornar isso possível.

VEJO: Kit de contratação: engenheiro de nuvem (TechRepublic )

Mesmo aplicativo, lugares diferentes

Esta não foi a primeira vez que conversei com Richardson sobre a experiência da loja de aplicativos corporativos. Nem é um segredo que ele compartilhou apenas comigo. De fato, em uma conferência recente, Richardson abordou o assunto em sua palestra. O que eu não apreciei, no entanto, foi que o apelo dessa “loja de aplicativos corporativa” não é porque os clientes estão clamando por multinuvem. Em vez disso, trata-se de consistência dentro da mesma nuvem (ou data center). “Uma coisa importante que você precisa para habilitar o modelo de loja de aplicativos corporativos é quando você faz uma implantação, seja configurando um cluster ou implantando um aplicativo ou ambos, você deseja que os resultados sejam idênticos. Então você quer dizer que é o mesmo aplicativo em lugares diferentes”, ele me disse.

Agora, isso não significa necessariamente que todas as configurações subjacentes sejam idênticas porque, por exemplo, se você estiver executando na AWS, poderá usar o DynamoDB, mas se estiver executando no Microsoft Azure, poderá usar o CosmosDB. “Mas fundamentalmente para o usuário final é o mesmo aplicativo, baseado em um conjunto idêntico de componentes de software, e eles são executados da mesma maneira nos serviços subjacentes”, disse Richardson.

Isso soa como multi-nuvem, mas não é. Na verdade, não.

Você conhece a multinuvem: a ideia de que você pode pegar o mesmo aplicativo e movê-lo magicamente de nuvem para nuvem ou executar o mesmo aplicativo em nuvens diferentes. Alguns clientes se preocupam com isso, mas para Richardson, há um problema muito mais difícil de resolver. Ou seja, garantir que você possa implantar o mesmo aplicativo, ou plataforma de aprendizado de máquina ou qualquer outra coisa, repetidamente, de forma idêntica na mesma nuvem (ou no local), sob demanda.

“Isso é fácil de dizer”, disse Richardson, “mas muito difícil de fazer”.

VEJO: Multicloud: uma folha de dicas (PDF grátis) (TechRepublic)

Mesmo. Mesmo. Mesmo.

Se você não está na TI corporativa, executando código em escala, isso provavelmente parece uma afirmação estranha. Certamente deve ser simples garantir que um aplicativo funcione da mesma forma se você o mantiver na mesma nuvem/data center? A realidade é diferente. Digamos que você e eu, por exemplo, optamos por configurar o Kubernetes na mesma zona de disponibilidade da AWS (Hello, US-East!), com os mesmos componentes de machine learning. Mesmo. Mesmo. Mesmo. E esperamos disponibilizar essa plataforma para uma equipe de ciência de dados dentro de nossa empresa. No mundo da Apple App Store, podemos estar executando o mesmo hardware, versão do sistema operacional etc., e quaisquer diferenças subjacentes que a Apple cuida. Na empresa, apesar de toda essa aparente “mesmice”, não podemos saber se a plataforma de aprendizado de máquina realmente é a mesma, a menos que possamos comparar os sistemas em execução com um modelo configurado.

Pré-Kubernetes, pré-contêineres e GitOps, não tínhamos essa capacidade. Agora sim. O GitOps, disse Richardson, “fornece uma maneira para qualquer desenvolvedor gerenciar toda a pilha de forma segura, correta e automática”.

Com a combinação Kubernetes/containers e GitOps, as empresas finalmente têm a capacidade de instalar e operar facilmente em vários clusters e nuvens. Por sua vez, as empresas podem executar aplicativos e infraestrutura quando quiserem (desligando serviços conforme necessário), enquanto automatizam o patch/atualização de aplicativos, como os consumidores fazem com as lojas de aplicativos. E por ser a empresa, o Kubernetes/GitOps também garante a conformidade com base em políticas corporativas e operações verificadas. É isso que as empresas querem.

A maioria das empresas, em suma, não está tentando loucamente mover centenas ou milhares de aplicativos entre nuvens. Não. Em vez disso, eles estão tentando fazer com que centenas de aplicativos se comportem, sejam gerenciados, em um só lugar. Eles estão enfrentando problemas fundamentais, como atualizar esses aplicativos, criar uma nova região ou mover aplicativos da borda para outro lugar em sua área de cobertura de infraestrutura.

E, embora eles ainda não tenham uma experiência na Apple App Store, estamos nos aproximando muito, graças ao Kubernetes e ao GitOps.

.