Tecnologias do Azure para o processo de compilação

Concluído

Nesta unidade, você aprende a relação entre o processo de inovação e algumas das tecnologias da indústria que podem ajudá-lo a construir novas funcionalidades em aplicativos.

DevOps

Depois de iniciar a fase de compilação para validar sua hipótese de inovação, os ciclos de desenvolvimento, integração e implantação necessários devem ser o mais simplificados possível. É nesta fase que entra o DevOps. Você pode definir DevOps como "processos e ferramentas para fornecer recursos de software de forma rápida e confiável". Aqui estão detalhes sobre essa definição:

• Processos e ferramentas: o DevOps, e o processo de inovação como um todo, é baseado em padrões de cultura que incentivam a mudança. O Azure e o GitHub oferecem ótimas ferramentas em torno do DevOps, mas comprar uma licença não é suficiente. Seus processos e cultura organizacional precisam evoluir para abraçar a mudança e a inovação.

• Entrega rápida de recursos de software: os processos e ferramentas de DevOps adotam o conceito de falhar rapidamente. Criar MVPs ou protótipos para validar rapidamente se o recurso no qual você está trabalhando vai na direção certa é essencial para o conceito de DevOps.

• Fornecimento confiável de recursos de software: as organizações avessas à mudança geralmente associam mudanças rápidas ao tempo de inatividade. No entanto, o DevOps promete exatamente o oposto: uma taxa de mudança rápida e um alto nível de confiabilidade. Essa confiabilidade é possível através da integração de testes nos estágios iniciais do ciclo de desenvolvimento, em um processo chamado "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 legado executaria a validação do usuário e o controle de qualidade no final do ciclo de desenvolvimento. No extremo "direito" dessa linha. O DevOps aconselha você a testar e validar o mais cedo possível, à "esquerda" dessa linha do tempo.

O DevOps incorpora os mesmos conceitos centrais de uma cultura de inovação saudável. Adotar sua metodologia é fundamental para chegar a 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 é uma interação complexa de muitas partes que não podem ser desmontadas (muitas vezes chamado de "monólito"), interdependências estreitas de componentes dificultam as melhorias do sistema. Cada alteração precisa ser validada com o resto do sistema, portanto, o processo de teste é complexo.

Se o sistema for modular, você pode separá-lo em subsistemas menores que interagem entre si por meio de interfaces bem definidas. Introduzir alterações em um desses subsistemas é mais fácil, porque enquanto sua interface com os outros módulos permanece constante, o sistema geral continua funcionando.

As arquiteturas de microsserviços são padrões de aplicativos que exploram a modularidade. As aplicações são subdivididas em pequenos componentes separados que podem ser desenvolvidos independentemente uns dos outros, potencialmente até usando diferentes linguagens de programação. Cada componente, ou microsserviço, pode operar por conta própria. Você pode dimensioná-lo conforme necessário, pode solucioná-lo como uma única unidade, pode modificá-lo independentemente dos outros microsserviços.

Uma pergunta que as organizações costumam fazer é o que fazer se um aplicativo for monolítico. A organização deve redesenhar o aplicativo em uma arquitetura de microsserviços antes de introduzir inovação, ou os processos de inovação e redesign podem ser executados em paralelo? Não há uma resposta única para esta pergunta. Depende da complexidade e da relevância comercial da aplicação em consideração.

A Tailwind Traders confrontou-se com esta questão quando olhou para a introdução de inovação na sua plataforma de comércio eletrónico. A empresa decidiu iniciar um projeto para redesenhar o aplicativo de comércio eletrônico em uma arquitetura de microsserviços, porque a criticidade de negócios do aplicativo justificava esse esforço. Não ter uma aplicação modular prejudicaria gravemente a capacidade da Tailwind Traders de reagir às tendências em mudança no mercado online.

No entanto, a Tailwind Traders tomou a decisão de resolver algumas das principais lacunas em sua plataforma ao mesmo tempo. Esperar que o projeto de redesenho do aplicativo termine significaria perder participação de mercado significativa para as novas startups que estão revolucionando o mercado de comércio eletrônico agora.

Os projetos devem interagir uns com os outros, guiados pelo valor comercial das inovações. Os esforços de redesenho são para se concentrar nas áreas de aplicação mais críticas, onde a necessidade de modificação para melhorar a experiência do cliente é maior.

Contentores

A tecnologia de conteinerização não é exclusiva das arquiteturas de microsserviços, mas os conceitos trabalham juntos. Os contêineres são uma maneira de encapsular o código do aplicativo e suas dependências para que possam ser implantados sem esforço em qualquer plataforma.

As implantações de aplicativos tradicionais exigem que a organização instale o software primeiro, como o tempo de execução do aplicativo, bibliotecas de programação ou componentes externos. Essa abordagem geralmente resulta no problema "funciona na minha máquina": é difícil replicar o mesmo ambiente no desenvolvimento, teste, preparação e produção. Pequenas diferenças na maneira como as dependências do aplicativo são instaladas podem fazer com que o aplicativo funcione bem durante o teste, mas falhe quando é implantado na produção.

Os contentores mudam as regras do jogo. As dependências do aplicativo são compactadas junto com o código do aplicativo em uma unidade de implantação autônoma chamada imagem de contêiner. Quer o contêiner de aplicativo seja implantado no laptop de um desenvolvedor ou em um cluster de produção com centenas de nós, a manipulação de dependência é a mesma. O contêiner funciona exatamente da mesma maneira, portanto, o teste de aplicativos é mais confiável e confiável.

Os contêineres percorreram um longo caminho desde que o Docker lançou seu código como código aberto em 2013. Os contêineres agora suportam Linux e Windows e 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ê aprende sobre alguns deles.

Kubernetes e Red Hat OpenShift

Um tempo de execução de contêiner é a tecnologia que inicia contêineres em um computador, mas mais lógica é necessária em um ambiente de produção. Quem implanta mais contêineres se for necessário mais desempenho? Quem reinicia os contentores se tiverem um problema? Se vários computadores estiverem disponíveis, quem decide em qual deles um determinado contêiner deve ser iniciado? Estas e outras tarefas são da responsabilidade de uma plataforma de orquestração de contentores.

A primeira versão do Kubernetes foi lançada em 2015, e logo se tornou o padrão de fato para orquestração de contêineres. Os clusters do Kubernetes consistem em vários nós de trabalho. Cada nó de trabalho tem um tempo de execução de contêiner, portanto, pode executar contêineres onde o plano de controle do Kubernetes agenda a implantação de aplicativos em contêineres. Esse plano de controle normalmente é executado em um conjunto de nós principais. Ele é responsável por manter o aplicativo funcionando corretamente, dimensioná-lo para cima ou para baixo e realizar as atualizações necessárias.

Uma das principais razões para a popularidade do Kubernetes é a independência de hardware que os contêineres oferecem. Como os aplicativos baseados em contêiner podem ser implantados de forma confiável em qualquer tempo de execução 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 consistentes de implantação de aplicativos no local e em nuvens públicas.

Executar o Kubernetes no Azure é fácil. O Serviço Kubernetes do Azure é simples de implantar e econômico, porque o cliente é cobrado apenas pelo custo dos nós de trabalho. A Microsoft carrega o custo e a operação do plano de controle que contém os componentes principais. A Microsoft corrige e atualiza o sistema operacional dos nós de trabalho, reduzindo ainda mais a complexidade operacional do gerenciamento de um cluster Kubernetes para executar contêineres Linux e Windows.

OpenShift é uma plataforma de implementação de aplicações baseada no Kubernetes, desenvolvida e suportada pela Red Hat. Incorpora muitas outras funcionalidades. Algumas das organizações que optam por executar seus aplicativos no OpenShift o fazem por causa desses recursos extras e do suporte que a Red Hat oferece. Executar o OpenShift no Azure é novamente simples. O Azure Red Hat OpenShift consiste em um cluster OpenShift onde a Microsoft gerencia muitos de seus aspetos, incluindo todo o ciclo de vida do cluster.

Serviço de Aplicações do Azure

O Serviço de Aplicativo do Azure é uma plataforma onde as organizações podem executar suas 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 faz o resto: dimensionar o aplicativo para dentro e para fora, aplicar patches e manter as máquinas virtuais subjacentes e muito mais, 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, para que você possa carregar sua imagem de contêiner em vez do código do aplicativo. Ele também suporta cargas de trabalho Linux e Windows e muitos tempos de execução de aplicativos 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, apenas o uso do aplicativo é cobrado. Não há custos fixos.

O modelo serverless é interessante para inovar, pois permite implantar novos microsserviços sem incorrer em altas faturas mensais se o mercado não as aceitar. Este modelo é outro exemplo da estratégia fail-fast, onde a inovação não significa necessariamente despesas elevadas.

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. Os slots são áreas de preparação onde você pode implantar novos recursos sem afetar o ambiente de produção. Os slots são ótimos do ponto de vista da inovação, porque você pode redirecionar uma pequena seleção de seus clientes para esta nova versão do aplicativo. Em seguida, você pode validar se sua hipótese de inovação está correta. Eventualmente, se você quiser promover o novo código para a produção, você pode "trocar" slots para que o ambiente de preparação se torne a versão de produção.

Resumo

Nesta unidade, você aprendeu como a tecnologia pode apoiar a inovação:

• Os processos e ferramentas de DevOps dão às suas equipes de desenvolvimento e operações o superpoder de fornecer novos recursos de forma rápida e confiável.
• Você pode rearquitetar aplicativos em microsserviços para permitir a inovação em seus componentes individualmente, sem afetar o resto.
• Os contêineres permitem a implantação confiável de aplicativos em várias plataformas e ambientes.
• O Kubernetes é uma plataforma de orquestração independente da nuvem para executar aplicativos em contêineres.
• O Serviço de Aplicativo do Azure pode executar cargas de trabalho baseadas na Web com sobrecarga mínima de gerenciamento. Ele oferece muitos recursos, como slots sem servidor ou aplicativos, para acelerar o ciclo de inovação.

A Tailwind Traders decidiu iniciar o redesenho de seu aplicativo de comércio eletrônico em uma arquitetura de microsserviços. O primeiro subsistema de aplicação que separa do "monólito" é o serviço de pagamento, porque o identificou como uma área crítica onde a concorrência está a oferecer um melhor valor aos clientes.

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

Como o Tailwind Traders não quer depender de nenhuma nuvem pública específica, decidiu criar a experiência do Kubernetes internamente e implantar o aplicativo nos clusters do Serviço Kubernetes do Azure. Se novos microsserviços precisarem ser desenvolvidos, a empresa optou por considerar o Azure Functions como uma plataforma para implantação de MVP para reduzir os custos de desenvolvimento.

Onde olhar a seguir

Muitos dos conceitos nesta unidade são ainda mais articulados nos artigos do Cloud Adoption Framework Empower adoption with digital invention e Kubernetes in the Cloud Adoption Framework.