Tecnologias do Azure para o processo de criação

Concluído

Nesta unidade, você aprenderá sobre a relação entre o processo de inovação e algumas das tecnologias do setor que podem ajudar a incorporar novas funcionalidades aos aplicativos.

DevOps

Após você iniciar a fase de criação para validar sua hipótese de inovação, os ciclos necessários de desenvolvimento, integração e implantação deverão ser os mais simplificados possíveis. É nessa fase que entra o DevOps. É possível definir DevOps como "processos e ferramentas para fornecer recursos de software de maneira rápida e confiável". Confira os detalhes dessa definição:

• Processos e ferramentas: o DevOps, bem como o processo de inovação de modo geral, é baseado em padrões culturais que incentivam mudanças. O Azure e o GitHub oferecem excelentes ferramentas para DevOps, mas comprar uma licença não é suficiente. Os processos e a cultura organizacional precisam evoluir a fim de adotar mudanças e inovações.

• Entrega rápida de recursos de software: os processos e as ferramentas de DevOps adotam o conceito de falhar rapidamente. No conceito de DevOps, é essencial criar MVPs ou protótipos para validar rapidamente se o recurso objeto do seu trabalho está na direção certa.

• Entrega confiável de recursos de software: organizações avessas a mudanças costumam associar mudanças rápidas com tempo de inatividade. No entanto, o DevOps promete exatamente o oposto: uma taxa de alteração rápida e um alto nível de confiabilidade. Essa confiabilidade é possibilitada pela integração dos testes às fases iniciais do ciclo de desenvolvimento, em um processo conhecido como "deslocamento para a esquerda".

  Se o desenvolvimento de um recurso ao longo do tempo é visto como uma linha da esquerda para a direita. Em seguida, um processo de desenvolvimento herdado faz a validação do usuário e o controle de qualidade no final do ciclo de desenvolvimento. No final "à direita" dessa linha. O DevOps orienta você a testar e validar o quanto antes, na porção "esquerda" dessa linha do tempo.

O DevOps incorpora os mesmos conceitos principais de uma cultura de inovação íntegra. A adoção dessa metodologia é fundamental para conquistar um ciclo de inovação ágil.

Arquiteturas de microsserviços

A modularidade é uma técnica bem conhecida para reduzir a complexidade na arquitetura de sistemas complexos. Se um sistema for uma interação complexa de muitas partes que não podem ser separadas (muitas vezes chamada de "monólito"), as interdependências estreitas entre os componentes dificultarão os aprimoramentos no sistema. Cada alteração precisa ser validada com o restante do sistema, de modo que o processo de teste é complexo.

Se o sistema for modular, ele poderá ser separado em subsistemas menores que interagem entre si por meio de interfaces bem definidas. Introduzir alterações em um desses subsistemas é mais fácil, pois desde que a interface dele com os outros módulos permaneça constante, o sistema geral continua funcionando.

Arquiteturas de microsserviços são padrões de aplicativo que exploram a modularidade. Os aplicativos são subdivididos em componentes pequenos e separados que podem ser desenvolvidos de maneira independente uns dos outros, podendo até mesmo usar linguagens de programação diferentes. Cada componente, ou microsserviço, pode operar por conta própria. Você pode dimensioná-lo conforme necessário, solucionar problemas dele como uma só unidade e modificá-lo independentemente dos outros microsserviços.

Muitas vezes, as organizações se perguntam o que devem fazer quando têm um aplicativo monolítico. A organização deve reprojetar o aplicativo com uma arquitetura de microsserviços antes de introduzir uma inovação ou os processos de inovação e reformulação são executados em paralelo? Não há apenas uma resposta para essa pergunta. Tudo depende da complexidade do aplicativo em questão e da relevância dele para os negócios.

A Tailwind Traders foi confrontada com essa pergunta ao examinar a introdução da inovação na plataforma de comércio eletrônico. A empresa decidiu iniciar um projeto para reprojetar o aplicativo de comércio eletrônico com uma arquitetura de microsserviços, pois a importância comercial do aplicativo justificava esse esforço. A falta de modularidade do aplicativo prejudicaria muito a capacidade futura da Tailwind Traders de responder a mudanças de tendências no mercado online.

No entanto, a Tailwind Traders decidiu solucionar algumas das principais lacunas da plataforma ao mesmo tempo. Aguardar a conclusão do projeto de reformulação do aplicativo significaria perder uma fatia significativa de mercado para as novas startups que estão mudando o mercado do comércio eletrônico.

Os projetos devem interagir entre si, direcionados pelo valor comercial das inovações. Os esforços de reformulação devem se concentrar nas áreas mais críticas do aplicativo, em que a necessidade de modificação para aprimorar a experiência do cliente é a mais alta.

Contêineres

A tecnologia de conteinerização não é exclusiva das arquiteturas de microsserviços, mas os conceitos trabalham juntos. Os contêineres são uma forma de encapsular o código do aplicativo e as respectivas dependências, de modo que ele possa ser implantado com facilidade em qualquer plataforma.

Implantações de aplicativos tradicionais exigem que a organização instale software primeiro, como o runtime, as bibliotecas de programação ou os componentes externos do aplicativo. Essa abordagem costuma resultar no problema "funciona no meu computador": é difícil replicar o mesmo ambiente nas fases de desenvolvimento, teste, preparo e produção. Pequenas diferenças no modo como as dependências do aplicativo são instaladas podem fazer com que o aplicativo funcione bem durante os testes, mas falhe quando implantado na produção.

Os contêineres mudam as regras do jogo. As dependências do aplicativo são empacotadas com o código do aplicativo em uma unidade de implantação autônoma chamada de imagem de contêiner. Esteja o contêiner do aplicativo implantado no laptop de um desenvolvedor ou em um cluster de produção com centenas de nós, o tratamento das dependências será o mesmo. O contêiner funciona exatamente da mesma maneira, ou seja, o teste do aplicativo é mais confiável.

Os contêineres vêm fazendo muito sucesso desde que o Docker liberou o código deles como software livre em 2013. Agora, os contêineres dão suporte ao Linux e ao Windows e a diferentes arquiteturas de CPU. Há muitas ofertas no Azure que permitem a execução de cargas de trabalho baseadas em contêiner. Nesta unidade, você aprenderá mais sobre algumas delas.

Kubernetes e Red Hat OpenShift

Um runtime de contêiner é a tecnologia que inicia os contêineres em um computador, mas é necessária mais lógica em um ambiente de produção. Quem implanta mais contêineres se é necessário aumentar o desempenho? Quem reinicia os contêineres em caso de problemas? Se há vários computadores disponíveis, quem decide sobre qual deles determinado contêiner deve ser iniciado? Essas e outras tarefas são de responsabilidade de uma plataforma de orquestração de contêineres.

A primeira versão do Kubernetes foi lançada em 2015 e logo se tornou o padrão de fato para a orquestração de contêineres. Os clusters do Kubernetes são compostos por vários nós de trabalho. Cada nó de trabalho tem um runtime de contêiner, de modo que ele pode executar contêineres em que o painel de controle do Kubernetes agenda a implantação de aplicativos conteinerizados. Normalmente, esse painel de controle é executado em um conjunto de nós básicos. Ele é responsável por manter o aplicativo em execução corretamente, escalar ou reduzir o aplicativo verticalmente e realizar as atualizações necessárias.

Um dos principais motivos da popularidade do Kubernetes é a independência de hardware que os contêineres oferecem. Como aplicativos baseados em contêiner podem ser implantados de maneira confiável em qualquer runtime de contêiner, você pode executar o Kubernetes em nuvens que usam vários hipervisores. Os aplicativos implantados devem se comportar de maneira semelhante (supondo que os recursos de hardware subjacentes também sejam semelhantes). Muitas organizações adotaram o Kubernetes como uma camada de abstração que permite processos de implantação de aplicativos consistentes no local e em nuvens públicas.

Executar o Kubernetes no Azure é fácil. O Serviço de Kubernetes do Azure é simples de ser implantado e econômico, pois o cliente só paga o custo dos nós de trabalho. A Microsoft é responsável pelo custo e pela operação do painel de controle que contém os componentes principais. A Microsoft aplica patches ao sistema operacional dos nós de trabalho e o atualiza, reduzindo ainda mais a complexidade operacional do gerenciamento de um cluster do Kubernetes para executar contêineres do Linux e do Windows.

O OpenShift é uma plataforma de implantação de aplicativos baseada em Kubernetes, desenvolvida e mantida pela Red Hat. Ele incorpora muitas outras funcionalidades. Algumas das organizações que optam por executar aplicativos no OpenShift o fazem devido a esses recursos extras e pelo suporte fornecido pela Red Hat. Executar o OpenShift no Azure também é simples. O Red Hat OpenShift no Azure é composto por um cluster do OpenShift, cujos vários aspectos são gerenciados pela Microsoft, incluindo todo o ciclo de vida do cluster.

Serviço de aplicativo do Azure

O Serviço de Aplicativo do Azure é uma plataforma em que as organizações podem executar cargas de trabalho baseadas na Web sem precisar gerenciar nenhum orquestrador ou sistema operacional subjacente. O único requisito é carregar o código do aplicativo para o serviço por meio de um dos muitos métodos de implantação disponíveis. O Azure cuida do resto: reduzir ou escalar o aplicativo horizontalmente, aplicar patches e fazer a manutenção das máquinas virtuais subjacentes, entre outros, sem exigir a curva de aprendizado do Kubernetes.

O Serviço de Aplicativo do Azure dá suporte a cargas de trabalho baseadas em contêiner, de modo que você pode carregar a imagem de contêiner em vez do código do aplicativo. Ele também dá suporte a cargas de trabalho Linux e Windows e a vários runtimes de aplicativo diferentes.

O Serviço de Aplicativo do Azure dá suporte a vários modelos de preços, incluindo uma opção sem servidor chamada Azure Functions. No Azure Functions, somente o uso do aplicativo é cobrado. Não há custos fixos.

O modelo sem servidor é interessante para inovação, pois permite implantar novos microsserviços sem gerar faturas mensais altas caso o mercado não os aceite. Esse modelo é outro exemplo da estratégia de fail-fast, na qual a inovação não significa necessariamente despesas altas.

O Serviço de Aplicativo do Azure também oferece recursos que dão suporte a implantações orientadas a DevOps, como slots de aplicativos Web. Slots são áreas de preparo nas quais você pode implantar novos recursos sem afetar o ambiente de produção. Os slots são ótimos da perspectiva da inovação, pois você pode redirecionar uma pequena seleção de clientes para essa nova versão do aplicativo. Em seguida, você pode validar se a sua hipótese de inovação está correta. Por fim, se quiser promover o novo código para produção, você poderá "trocar" os slots de modo que o ambiente de preparo passe a ser a versão de produção.

Resumo

Nesta unidade, você aprendeu como a tecnologia pode dar suporte à inovação:

• Os processos e as ferramentas de DevOps dão às suas equipes de desenvolvimento e operações o superpoder de entregar novos recursos de maneira rápida e confiável.
• Os aplicativos podem ser rearquitetados em microsserviços para permitir a inovação nos respectivos componentes individualmente, sem afetar o restante.
• Os contêineres habilitam a implantação confiável de aplicativos em várias plataformas e ambientes.
• O Kubernetes é uma plataforma de orquestração independente de nuvem para execução de aplicativos conteinerizados.
• O Serviço de Aplicativo do Azure pode executar cargas de trabalho baseadas na Web com sobrecarga de gerenciamento mínima. Ele oferece muitos recursos, como computação sem servidor e slots de aplicativos, destinados a acelerar o ciclo de inovação.

A Tailwind Traders decidiu iniciar a reformulação do aplicativo de comércio eletrônico em uma arquitetura de microsserviços. O primeiro subsistema de aplicativos que ela separa do "monólito" é o serviço de pagamento, pois você o identificou como uma área crítica em que a concorrência oferece mais valor aos clientes.

Após o subsistema de pagamento, outros componentes de aplicativo serão convertidos em microsserviços independentes. Os microsserviços podem se comunicar por meio das APIs REST. O código do aplicativo de cada microsserviço deve ser conteinerizado, e as organizações de desenvolvimento e de operações devem adotar as melhores práticas de DevOps.

Como a Tailwind Traders não quer depender de nenhuma nuvem pública específica, a empresa decidiu desenvolver conhecimento interno sobre o Kubernetes e implantar o aplicativo em clusters do Serviço de Kubernetes do Azure. Caso novos microsserviços precisem ser desenvolvidos, a empresa optou por considerar o Azure Functions como uma plataforma para a implantação do MVP a fim de reduzir os custos de desenvolvimento.

O que procurar em seguida

Muitos dos conceitos nesta unidade são articulados mais detalhadamente nos artigos sobre o Cloud Adoption Framework Capacitar a adoção com a invenção digital e Kubernetes no Cloud Adoption Framework.