Definindo o que é um Software Cloud-Native

Descreva o que significa ser cloud-native? Isso exige que suas aplicações e infraestrutura nasçam na nuvem? Qual é o equilíbrio entre tecnologia e métodos? Neste painel, o InfoQ conversou com três especialistas da indústria para saber mais sobre os motivos para se tornar cloud-native, e a abordagem a ser seguida. Nossos entrevistados incluem:

• Christian Posta - Arquiteto Chefe da Red Hat e autor do livro 'Microservices for Java Developers'.
• Kevin Hoffman - Engenheiro da Capital One e autor do livro 'Building Microservices with ASP.NET Core'.
• Matt Stine - CTO da Global, arquiteto da Pivotal e apresentador do 'Software Architecture Radio podcast'.

InfoQ: Como vocês definem cloud-native, e por que alguém deveria se preocupar em criar aplicativos desta forma em vez de continuar criando software da forma que vinham fazendo isso até agora?

Stine: Estamos tentando equilibrar o conflito percebido: agilidade comercial baseada em software versus software resiliente. Queremos avançar rápido e ainda assim, não quebrar coisas. Para fazer isso, vamos mudar a forma como construímos software, não necessariamente onde construímos software. As mudanças chaves de como fazê-lo estão no DevOps e Continuous Delivery, que eu defini especificamente no meu livro.

DevOps representa a ideia de destruir silos organizacionais e construir conjuntos de ferramentas, vocabulários e estruturas de comunicação compartilhados a serviço de uma cultura focada em um único objetivo: entregar valor de forma rápida e segura. Este é o aspecto cultural de se mover rápido e não quebrar as coisas.

Continuous Delivery representa a ideia de apoiar tecnicamente o conceito para monetizar o ciclo de vida, fazendo com que todo commit de código seja implantado direto em produção, de forma automatizada. Esta é a prática de engenharia de apoio de se mover rápido e não quebrar coisas.

Assim, criando uma cultura DevOps e empregando práticas de Continuous Delivery, trazemos equilíbrio para agilidade e resiliência. Mas, obviamente, precisamos de um lugar para fazer isso: na nuvem (cloud).

Eu defino cloud como qualquer ambiente de computação em que os recursos de computação, rede, e armazenamento podem ser provisionados e lançados elasticamente de acordo com a demanda, e de forma self-service.

O ecossistema da Pivotal, da Pivotal Cloud Foundry, e o seu ecossistema de serviços (como o Spring Cloud Services e Pivotal Cloud Cache) tornam-se o substrato no qual praticamos engenharia de software. Seus recursos orientados à API, que conduzem a orquestração rápida e elástica das cargas de trabalho, são o kit técnico que permite o DevOps e Continuous Delivery.

Isso nos leva à arquitetura. A arquitetura é o processo pelo qual fazemos decisões de engenharia de software que têm impacto no sistema e muitas vezes são caras de reverter. Nossa arquitetura de tomada de decisões afeta diretamente nosso sucesso ou fracasso. Podemos expressar esse impacto de três maneiras:

• A tomada de decisões de arquitetura pode melhorar ou prejudicar a nossa capacidade de praticar DevOps.
• A tomada de decisões de arquitetura pode melhorar ou prejudicar a nossa capacidade de praticar Continuous Delivery.
• A tomada de decisões de arquietura pode explorar ou desperdiçar as características da Cloud Infrastructure.

Arquiteturas cloud-native aprimoram nossa capacidade de praticar DevOps e Continuous Delivery, e elas exploram as características da infraestrutura na nuvem. Eu defino arquiteturas cloud-native como tendo as seguintes seis qualidades:

1. Modularidade (através de Microservices).
2. Capacidade de observação.
3. Implementabilidade.
4. Testabilidade.
5. Descartabilidade.
6. Substituível.

Obviamente, eu poderia continuar daqui, mas acho que provavelmente já ultrapassou seu limite de palavras. ;-)

Posta: Antes de responder o que é cloud-native, deixe-me explicar porque alguém deveria se preocupar em criar aplicativos "dessa forma" versus "abordagens passadas", definindo algum contexto.

Eu acho que as "abordagens passadas" (eu sei que isso é vago) podem ser resumidas como "ser realmente muito bom em prever o futuro". Este é o cerne da discussão. No passado, dedicamos um tempo incrível, energia e dinheiro tentando "prever o futuro":

• prever futuros modelos de negócios
• preveja o que os clientes querem
• prever a "melhor maneira" de projetar/arquitetar um sistema
• prever como evitar que as aplicações falhem, etc, etc.

Em vez de tentar "melhorar a previsão do futuro", queremos construir um sistema que "melhore a resposta à mudança e à imprevisibilidade". Este sistema é construído por pessoas e é entregue através da tecnologia.

Como podemos prever o que os clientes desejam? Não podemos. Nós executamos experimentos baratos o mais rápido possível, colocando ideias, produtos e/ou serviços na frente dos clientes e medindo o impacto.

Como podemos prever a melhor maneira de arquitetar um sistema? Não podemos. Nós experimentamos dentro de nossa empresa, e determinamos o que se encaixa melhor para os funcionários, capacidades, e expectativas por observação.

Como podemos prever evitar que os aplicativos falhem? Não podemos. Nós esperamos a falha e arquitetamos por observabilidade, então podemos classificar o nível das falhas rapidamente, restaurar o serviço e alavancar os testes de caos para provar isso continuamente, e assim por diante.

"Cloud-native" é um adjetivo que descreve as aplicações, arquiteturas, plataformas / infraestrutura, e processos que, em conjunto, tornam "econômico" trabalhar de forma a melhorar nossa capacidade de responder rapidamente às mudanças e reduzir a imprevisibilidade.

Isso inclui coisas como arquiteturas de serviços, infraestrutura de autoatendimento, automação, pipelines de integração / entrega contínua, ferramentas de observabilidade, liberdade e responsabilidade para experimentar, equipes motivadas por resultados, não por produção, etc.

Hoffman: Eu realmente não acho que eu poderia ter dito isso melhor do que Christian. Essa é uma resposta fantástica.

InfoQ: Os containers são parte essencial de uma abordagem cloud-native? Por quê?

Posta: Não tenho certeza de que concordo com o enquadramento da pergunta, para ser honesto. Eu preferiria pensar sobre "o que é essencial" em termos de capacidades e práticas em uma "abordagem cloud-native".

Por exemplo, quais são as capacidades e práticas necessárias para tornar o trabalho em pequenos lotes, teste de hipóteses, e aprendizado economicamente viáveis? Capacidades como compiladores de aplicações baratos, implantações seguras, gerenciamento automatizado de implantações (iniciar, parar, medição, health checking, etc.), segurança, configuração distribuída, roteamento de tráfego e outros.

Os containers desempenham um papel fundamental na implementação dessas capacidades, e são a base de tecnologia / plataformas que fornecem esses recursos, mas as capacidades é que são importante.

Stine: Eu vou pegar carona na resposta do Christian pois acho que ele está indo exatamente no caminho certo. Se você olhar para a forma como nós dois abordamos a noção de cloud-native, nenhum de nós focou tanto na tecnologia quanto focamos em possibilitar modelos de negócios orientados a hipóteses e ciclos de feedback rápidos. O que precisamos é do nível apropriado de abstração da plataforma para fazer isso economicamente.

Com a transição do hardware físico para as máquinas virtuais, e para os containers, reduzimos o custo por unidade de valor das implantações, e isso nos possibilitou criar plataformas de software com capacidade crescente para garantir a rápida evolução do software. Os containers certamente desempenharam um papel importante na evolução atual da construção da plataforma. Mas, em muitos aspectos, eles devem ser um detalhe de implementação da plataforma de software

Como desenvolvedor, meu foco deve ser o máximo possível no atendimento das necessidades de negócios de forma flexível e resiliente. Os containers não têm nada a ver com isso. Os desenvolvedores têm todo direito de serem desconhecidos deles, mesmo que cada programa que eles escrevam seja executado dentro de um container.

E continuaremos a escalar esta escada de abstração.

O ecossistema serverless (sem servidor) desvia nossa atenção para as funções individuais como uma unidade de implantação. Você precisa saber, basicamente, qual é o runtime necessário para execução da sua função, não sendo necessária qualquer preocupação com relação a como vai ser a máquina que executará essa função. Questões que você "não precisa saber", devem ser ignoradas. E, portanto, parte da nossa responsabilidade é negociar restrições versus as promessas de viver em níveis de abstração potencialmente múltiplos: infraestrutura, containers, aplicativos, e funções.

Hoffman: Me fazem esta pergunta o tempo todo, e minha resposta geralmente começa com "você está fazendo as perguntas erradas". Quando olhamos para alguns dos requisitos independentes da tecnologia para obter os benefícios geralmente associados à natividade da nuvem (cloud-native), vemos coisas como: implantação rápida e automática, capacidade de escalar horizontalmente, tolerância a falhas, tempos de inicialização e desligamento rápidos, e paridade de ambientes.

Indo mais fundo nessa lista de requisitos, vemos que muitos deles dependem de um requisito de nível inferior - o uso de um artefato de lançamento imutável. É esse artefato único, portátil, e imutável que pode ser transferido entre VMs de forma dinâmica e pode ser executado em todos os nossos ambientes sem mudanças; que pode ser programado e lançado automaticamente onde quisermos, sempre que quisermos. Isso facilita muitos dos nossos requisitos cloud-native.

Então, eu diria que a dependência de artefatos de lançamento imutáveis constitui a base para os blocos de construção que oferecem suporte à cloud-native como pensamos nisso hoje. O fato de que os containers (Docker ou outros) são o que usamos para nossos artefatos de lançamento imutáveis é um detalhe de implementação e apenas um meio para um fim, e não o objetivo final em si.

InfoQ: Quais são alguns exemplos claros de antipadrões se você estiver tentando desenvolver de maneira cloud-native? Ou, o que podem não ser antipadrões, mas algo para se desconfiar?

Posta: Então, esta é uma área que eu posso discutir e divagar por páginas, mas eu vou ficar com o que apareceu na minha cabeça neste momento. Não tenho certeza do que contam como antipadrões, mas todos são definitivamente coisas para se desconfiar.

Primeiro é o desejo de "construir uma plataforma". Estamos entusiasmados com tecnologias como Docker e Kubernetes, etc., e queremos ser os rockstars da infraestrutura (eu acho).

Mas tomar tecnologias como Docker e Kubernetes, e passar meses operacionalizando-os para construir uma plataforma é trabalho pesado.

Mesmo que você operacionalize uma plataforma, as comunidades e as tecnologias subjacentes estão mudando tão rápido que você precisa se perguntar: "Sou eu uma empresa de plataforma de infraestrutura? Ou sou uma empresa de varejo, finanças, seguro, etc.? Estou disposto a investir múltiplas cabeças em cada comunidade open-source, equipes de engenharia para integrar essas coisas, equipes de controle de qualidade para testar, e gerenciamento de produtos, recursos de arquitetura para fazer isso?"

Ou, você pode contar com empresas que se especializam em trazer essa infraestrutura cloud-native para a empresa (como Red Hat, Pivotal, etc.) e usar esse relacionamento para acelerar sua estratégia cloud-native? Eu conheci algumas equipes que passaram pela abordagem DIY (Faça você mesmo), queimaram toneladas de dinheiro e recursos para acabar em um caminho completamente insustentável se continuassem, e nada mais perto de seus objetivos estratégicos, de negócios.

Segundo, é o desejo de adotar novas tecnologias, mas não mudar nada sobre como elas funcionam.

Uma abordagem cloud-native combina capacidades tecnológicas com mudanças na forma como suas equipes trabalham umas com as outras.

Por exemplo: se você apenas adotar uma plataforma cloud-native mas continuar a trabalhar no modo tradicional (desenvolvedores mandam o código para a equipe de operações) em vez de trabalhar no modo DevOps (equipes trabalhando colaborativamente, com continuous deployment e fast feedback), o que você realmente mudou sobre suas capacidades para escalar e ir mais rápido?

O que você realmente mudou sobre sua capacidade de aprender e experimentar? Na verdade, se você não fez com que ele fosse econômico para trabalhar em pequenos lotes, obter feedback, etc., você provavelmente aumentou seu custo de fazer mudanças.

Precisamos evoluir nossas práticas para um ambiente de alta confiança e alto grau de responsabilidade onde esperamos que falhas ocorram, e aprendemos com elas. Isso começa no topo.

Outra coisa que eu estou vendo é um completo e absoluto medo da adoção estilo big-bang nas abordagens cloud-native: "containers, Kubernetes, PaaS, Spring Boot, ci/cd, transações / compensações / sagas, Domain Driven Design, replicação de dados, arquitetura baseada em eventos, Kafka, rolling deployment, técnica de deploy blue/green, messaging, integração, APIs, padrões circuit breaker, monitoramento, rastreamento, registro, métricas, observabilidade, ferramentas antigas e ferramentas novas, e porcarias! Eu tenho que estar em produção em 4 meses! Aaaaaaaaahhhhh". Ah! Vamos parar com isso. Esta coisa de cloud-native NÃO é uma abordagem big-bang, e tentar fazê-la assim vai resultar em uma dificuldade imensa.

Outros padrões para se ter cuidado: coisas como modelos de dados canônicos!? Eu pensei que aprendemos nossa lição sobre isso, ou coisas como esperar a nossa infraestrutura sob medida para fornecer coisas como transações distribuídas através dos limites, exatamente após a entrega, etc. Dá uma olhada no [documento] 'Princípio ponta a ponta' (End-to-end principle) e de manhã a gente conversa.

E outra essa coisa de "com certeza, vamos ter cadeias longas de estruturas de chamada de gráfico cíclico não direcionadas entre nossos serviços por causa dos microservices" - isso é só tristeza. E por último, não querer remover meticulosamente todas as etapas manuais quando se trata de nossa pipeline de implantação.

Stine: Ok, eu vou jogar. O Christian falou de alguns dos mais óbvios. Adoro quando ele fala sobre o que eu gosto de chamar de "construção de nave espacial". E uma consideração profunda das mudanças no sistema ou no trabalho de uma empresa também é crucial.

Vou citar alguns dos meus antipadrões mais frequentes, ou talvez contos cautelosos, na mistura.

A primeira é a falta de consideração das estratégias de decomposição. Eu escrevi sobre este tópico. Uma vez que uma empresa concorda com a proposta de valor por trás da arquitetura microservices, e eles começam com isso, muitas vezes o fazem com uma estratégia confusa ou sem uma clara estratégia.

Provavelmente, a pior estratégia de adoção que eu já vi é sobre a decomposição dentro de equipes ou aplicativos únicos. Isso se manifesta como uma equipe única, muitas vezes grande, que pega o que seria originalmente um aplicativo monolítico e o desenvolve como um monólito distribuído.

A equipe cria dez ou mais microservices e, em seguida, procede para orquestrar o teste e a implantação de toda a frota sempre que um único microservice muda. Esta equipe está pagando o que eu chamo de "imposto do sistema distribuído", sem colher nada do valor.

Perguntei a essas equipes que valor elas obtêm da adoção da arquitetura de microservices, e raramente elas dão uma resposta concreta. Quando eu continuo com: "Então, por que você está fazendo isso?", a resposta mais comum é: "Bem, disseram que precisávamos escrever microservices!"

Eu escrevi sobre esse problema depois do meu tweet viral. É um problema muito real, e pode rapidamente sair do controle. Uma vez eu estava falando no simpósio de desenvolvedor interno de uma grande empresa. Durante a sessão de perguntas/respostas, fizeram esta pergunta: "Temos cerca de 50 microservices dentro de nossa aplicação, e novos estão aparecendo todos os dias. Está ficando realmente difícil de gerenciar. O que você acha que devemos fazer?"

Minha resposta foi: "Bem, a primeira coisa é que você provavelmente deveria escrever menos microservices!" Após o encerramento do simpósio, um dos patrocinadores do evento me deu mais contexto da história: "Acontece que a empresa daquela pessoa foi incentivada a criar tantos microservices quanto possível para que seu líder possa demonstrar o quanto ele estão engajados com nossa iniciativa de modernização! "

O melhor conselho que posso oferecer aqui é que primeiramente você considere o motivo de estar adotando microservices.

Como Christian falou, é tudo uma questão da sua capacidade de ir mais rápido, inovar, e experimentar. A adoção de microservices da maneira que descrevi vai resultar, em geral, em uma experiência oposta. Uma forma de ver isso é que as organizações criam microservices, enquanto as equipes criam monólitos bem-intencionados. A principal razão pela qual queremos se decompor em microservices é apoiar equipes individuais, empresários, e fluxos de valores evoluindo de forma autônoma. Embora isso não signifique necessariamente uma equipe por microservice, os números não devem ser radicalmente desproporcionais.

Mais uma coisa que eu gostaria de falar, e que é uma consideração adequada dos requisitos de qualidade, é que eu vejo muitos times cuja maior preocupação é a disponibilidade.

Muitas vezes, uma empresa que teve desafios de disponibilidade no passado irá superá-los.

Elas vão sobrecarregar arquiteturas, incluindo muito redundância e distribuição geográfica, e muitos padrões de tolerância a falhas. Vou descrever isso como "disponibilidade por marreta". Na outra extremidade do espectro, você verá equipes que acham fácil trabalhar com camada em circuit breaker com Spring Cloud, e eles vão pensar que adicionar a annotation @HystrixCommand torna [o código] imediatamente tolerantes a falhas.

Em ambas as situações, você tende a se concentrar em soluções sem uma compreensão clara do problema.

Quando pergunto a essas equipes quais são os requisitos de disponibilidade deles, recebo respostas vagas como "o sistema nunca pode cair", ou "todos os nossos serviços exigem altÍssima disponibilidade". O que eles não conseguiram entender é que alcançar este tipo de disponibilidade é incrivelmente difícil e dispendioso, e quase certamente não o fizeram. E o que é pior, eles quase certamente não precisam disso.

Na Pivotal, falamos muito sobre a criação da disciplina de gerenciamento de produtos no negócio, e parte disso é uma consideração adequada das necessidades e da prioridade do negócio. Parte dessa consideração são os requisitos de qualidade.

Enquanto trabalhamos com a área de negócio para escrever coisas como user stories, também deveríamos escrever histórias sobre coisas como disponibilidade, escalabilidade, segurança, e desempenho.

Devíamos perguntar a área de negócio: "Qual deve ser o comportamento quando o componente do processo empresarial X sofrer uma falha?"

Deveríamos então dar prioridade adequada a todas essas histórias em contexto com as histórias de lógica de negócios. Nesse ponto, começamos a entender como arquitetar o sistema com os compromissos apropriados considerados.

Hoffman: Eu concordo com todos os antipadrões discutidos até agora. Um dos que eu vejo com mais frequência é o que eu chamo de "buzzword shopping". A falácia no núcleo disto é a ideia de que uma determinada tecnologia é cloud-native ou não.

Não é a tecnologia que é cloud-native, é como você a usa.

Arquitetos, desenvolvedores, e até mesmo executivos da alta gestão levarão seu carrinho de compras para a mercearia da tecnologia e jogar dentro dele tudo o que se afirma ser cloud-native. Quando eles chegarem à casa, eles vão jogar tudo em um liquidificador e esperar que se transforme em um lindo soufflé cloud-native. Mas, não é assim que funciona. Não é assim que nada disso funciona.

O objetivo é começar olhando para o que você está fazendo, porque você está fazendo isso, e o que você espera ganhar com isso. Sem saber isso como sua base, você não tem como acabar com uma solução verdadeiramente cloud-native. Na melhor das hipóteses você acabará apenas hospedando um "ensopado tecnológico" mal feito na nuvem.

InfoQ: As aplicações cloud-native mudam a natureza das operações e o gerenciamento de sistemas? Em caso afirmativo, como?

Stine: Claro que sim. Todos nós chamamos de antipadrão a abordagem "joga pra frente" do desenvolvimento e operações. A abordagem cloud-native é muito mais sobre "como" do que sobre "onde". Uma parte fundamental do novo "como" é como abordamos operações e gerenciamento de sistemas.

Eu gosto de ver isto de algumas formas diferentes. Uma delas é um espectro horizontal de abordagens operacionais. Em uma extremidade desse espectro há o que eu chamarei de operações tradicionais, o que é mais próximo da ideia de mandar o código para a equipe de operações. Na outra extremidade desse espectro está a abordagem: "você o codifica, você roda o código".

Já há alguns anos o meu conselho é: se você escreve, você executa; seja qual for o motivo, isso força a equipe de desenvolvimento a se concentrar na realidade operacional.

Você vai escrever um código diferente (e espero que melhor!) se você tiver que almoçar em frente à pessoa que foi chamada às 3 da manhã [por problemas no seu código]! Mas, mais importante ainda, se você é responsável pelo ciclo de vida operacional da sua aplicação, a capacidade de se mover mais rápido e realizar experiências está inteiramente em suas mãos.

No ano passado, fiquei muito interessado em uma abordagem que se inclina para o centro desse espectro, que é o que o Google chama de Site Reliability Engineering (SRE) (Engenharia de Confiabilidade do Site). Eles publicaram recentemente um livro com o mesmo nome que está disponível gratuitamente na web. No mundo SRE, existe uma equipe separada de engenheiros de software que também possuem fortes habilidades operacionais.

Esses SRE se encarregam de operar as aplicações, desde que atinjam um conjunto contínuo de requisitos de qualidade, incluindo um limite de tempo de 50% em atividades (Toil) operacionais. Toil é definido como trabalho manual, repetitivo, automatizável, e tático que não tem valor duradouro e escala linearmente com o crescimento do serviço. O trabalho contínuo de engenharia deve sempre ser dedicado a reduzir a porcentagem de toil. Ao reduzir o toil, os SRE são capazes de concentrar pelo menos 50% do seu tempo no trabalho de engenharia principalmente relacionado aos requisitos de qualidade.

Há também uma abordagem vertical em camadas das operações. Falamos extensivamente sobre a necessidade de desenvolver e operar aplicativos em uma plataforma. Essa plataforma é devidamente consumida por desenvolvedores de aplicações e operadores por meio de um contrato explícito, geralmente exposto como API e objetivos de nível de serviço (service level objectives - SLOs).

Esses desenvolvedores de aplicações e operadores não devem ter que estar cientes ou se preocupar com qualquer coisa que aconteça abaixo daquela API e do conjunto de SLO, desde que o contrato continue a ser cumprido.

Dito isto, o desenvolvimento e as operações definitivamente ocorrem abaixo dessa API, é simplesmente o limite dos desenvolvedores da plataforma e dos operadores da plataforma.

Estes quatro conjuntos de papéis diferentes:

• Desenvolvedor de aplicações.
• Operador de aplicações (ou SRE)
• Desenvolvedor de plataforma.
• Operador de plataforma (ou PRE)

Quando combinados com a responsabilidade pelo produto e o gerenciamento de cada camada vertical, compreendem o que começamos a chamar "a equipe de produtos da plataforma balanceada".

Posta: Sim. Para citar a maravilhosa Charity Majors, "o que te trouxe aqui não te levará até lá". Arquiteturas e aplicativos cloud-native mudam a natureza das operações e gerenciamento de sistemas. O Matt citou alguns bons pontos em sua resposta. O ponto que eu sempre reforço é a ideia de fazer mudanças rápidas e medir seu impacto.

Devemos ser capazes de implantar tão rapidamente quanto os desenvolvedores, as equipes de desenvolvimento desejam, e de ter alguma maneira controlada de liberar o software para nossos usuários.

Observe as diferenças explícitas entre deployment (implantação) e release (lançamento):

Deployment é colocar uma nova versão do código no ambiente de produção; release é levar tráfego ao vivo para o deployment.

O pessoal incrível do turbine labs tem um blog que fala mais sobre isso. Esse desacoplamento de implantação e lançamento é muito diferente do que a maioria dos times trabalham.

Tipicamente, implantação == lançamento, e isso se torna muito arriscado e, de fato, é por isso que provavelmente há muita burocracia, processo de aprovação, etc., quando se trata de colocar o código em produção.

Mas, mais importante ainda, como medimos o impacto da implantação ou do lançamento? Há um punhado de coisas que queremos medir: SLA/SLOs, como o Matt mencionou. Também queremos medir o efeito comercial pretendido de uma mudança. A adição de recomendações com base em nossos novos super algoritmos de previsão leva a mais produtos adicionados aos carrinhos de compras? Queremos posicionar nossas mudanças como hipótese e então poder fazer perguntas sobre seus efeitos.

Tão importante quanto os impactos no nível de negócios, queremos observar o que acontece com as interações dos sistemas distribuídos e com a saúde das experiências de nossos clientes. Essa nova versão aumentou a latência em nosso processo de pagamento? Os carrinhos de compras de alguns clientes não estão sendo exibidos corretamente enquanto outros os são? Um tópico específico no nosso cluster Kafka não envia mensagens com rapidez suficiente? Devemos poder fazer perguntas sobre nossa infraestrutura, serviços, e experiência do usuário para obter uma compreensão mais profunda disso e comparar o que estamos esperando.

No passado, tentamos prever quais valores de proxy "monitorar" e colar estes em um painel. Mas isso é, mais uma vez, parte da diferença entre a "maneira antiga" e a maneira "cloud-native": não podemos prever a certeza de qualquer uma dessas dimensões - precisamos melhorar na operação de nossos serviços e sistemas no ambiente inevitável de confusão, contradições, e incerteza.

InfoQ: É uma suposição razoável que a maioria das empresas possui centros de dados cheios de aplicações tradicionais não cloud-native? Vocês todos escreveram sobre estratégias de decomposição, mas o que vocês sugerem que as empresas façam se quiserem atualizar algumas dessas aplicações para cloud-native?

Posta: Cada empresa é diferente, e terá tolerâncias e apetites diferentes sobre como eles desejam abordar a modernização das aplicações. Apenas copiar o que vemos uma empresa fazer não nos levará ao que queremos ser.

A discussão deve envolver dar um passo atrás e classificar as iniciativas em buckets (compartimentos) que se alinham com a estratégia de portfólio de TI. Os três buckets que utilizo são as aplicações MVP/Inovação/Exploração, as aplicações/serviços com altas expectativas de crescimento e, finalmente, as aplicações/serviços flagship, que estão crescendo lentamente.

Cada bucket requer diferentes soluções, diferentes medições heurísticas, e diferentes abordagens de gerenciamento. Na corrida para tornar tudo "cloud-native" ou "microservices", devemos seguir uma abordagem estratégica. Eu escrevo mais sobre isso com mais detalhes em uma postagem no blog "Sobre quando não fazer microservices".

Depois de ter uma estratégia, uma compreensão compartilhada sobre as iniciativas, precisamos explorar o fluxo de valor que faz parte da capacidade de cada iniciativa de entregar. Normalmente, ter uma ideia geral e mapeada do fluxo de valor (as etapas necessárias para entregar uma iniciativa) pode destacar áreas que precisam ser melhoradas (ou se uma iniciativa específica é mesmo aplicável para melhoria, modernização). Por exemplo, em nosso fluxo de valor, se nossa arquitetura de aplicações não for o gargalo para ir mais rápido (entregar iterações mais rápidas), então, não importa o quanto otimizemos isto (microservices, cloud-native, etc.), não vai melhorar a nossa capacidade entregar.

Da mesma forma, se classificarmos o fluxo de valor para uma iniciativa específica, podemos descobrir que certos esforços de modernização talvez não tenham um impacto tão grande como, digamos, uma melhoria de processo, etc. Isso é crucial na minha opinião - porque, de outra forma,

Como desenvolvedores e arquitetos entusiasmados e armados com novas tecnologias, queremos reescrever e re-arquitetar o mundo, e essa pode não ser a abordagem mais eficaz.

Por fim, dependendo em qual bucket a aplicação/iniciativa cai, talvez desejemos:

1) explorar melhorias na arquitetura existente,

2) adicionar/complementar a arquitetura existente, ou

3) re-escrever completa ou parcialmente para ter uma arquitetura ainda melhor.

Aqui é onde uma combinação de metodologias como Improvement Kata, Impact Mapping, Event Storming, Domain Driven Design, etc., entram para jogar. Assim como Kevin falou ao final de sua resposta, tão importante (senão mais?) quanto a metodologia é a medida desses impactos.

Douglas Hubbard escreveu um livro incrível, "How to Measure Anything" (Como medir qualquer coisa), cujas estratégias devem estar na vanguarda da mente de todos enquanto embarcamos nesta dança cloud-native.

Hoffman: No meu tempo com a Pivotal, bem como com várias outras empresas, eu costumava encontrar esse cenário. Mais uma vez, precisamos dar um passo atrás e perguntar qual é a razão por trás da migração. Algumas empresas têm aplicações legadas que simplesmente precisam sair de um data center e migrar para a cloud por razões financeiras. Estas aplicações podem ser caracterizadas como congeladas, e estão apenas no "suporte vital". Em casos como este, talvez não faça sentido torná-las cloud-native quando simplesmente executá-las em um conjunto de containers pode ser suficiente para fazer o trabalho. Isso é muitas vezes referido como "lift and shift" (levantar e deslocar).

Existe um meio termo entre "lift and shift" e a verdadeira cloud-native. Aqui, as empresas começaram com a ideia de que simplesmente vão levantar e deslocar, e executar na nuvem. Mas, no processo de enfiar tudo numa pilha de containers, nós sempre descobrimos algumas coisas que simplesmente não funcionam corretamente na nuvem .

Quanto mais antigo o software é (e quanto mais requisitos do sistema principal ele assume), mais provável é que ele caia nessa categoria. Em situações como essa, muitas vezes temos que decompor as partes vulneráveis do monólito apenas para que o aplicativo seja executado na nuvem. As empresas precisam fazer um julgamento de valor para determinar se é do seu interesse ir totalmente cloud-native, ou "fazê-lo funcionar" e definir um plano de migração para continuar a decomposição ao longo do tempo.

Quanto a estratégias específicas para migrar uma aplicação, existem várias, e não existe uma única estratégia para governá-las todas. Algumas que as pessoas têm muito sucesso incluem técnicas como event storming e a identificação de contextos limitados para se decompor em microservices. Mas, as questões reais que precisam ser respondidas são:

O que você espera obter migrando para cloud-native? Como você medirá esses ganhos? Quais recursos você acha que pode adicionar à sua aplicação, uma vez que ele seja cloud-native, que não poderia antes?

Concentrar-se em marcos específicos em sua jornada iterativa para cloud-native ajudará a manter as coisas ágeis e garantir que você não esteja bloqueando todos os seus recursos de desenvolvimento por anos a fio, prejudicando a sua capacidade de continuar a criar novos produtos enquanto migra os legados.

Sobre os entrevistados

Christian Posta (@christianposta) é arquiteto-chefe da Red Hat, com mais de 15 anos de experiência construindo e projetando sistemas altamente escaláveis, resilientes e distribuídos. Ele recentemente lançou o livro "Microservices for Java Developers" para O'Reilly e Red Hat

Matt Stine é um veterano com 17 anos na indústria de TI, sendo oito destes anos passados como arquiteto de soluções de consultoria para várias empresas da Fortune 500, bem como do Hospital de Pesquisa St. Jude Children's Research, sem fins lucrativos. Ele é o autor do Migrating to Cloud-Native Application Architectures, da O'Reilly, e anfitrião do podcast Software Architecture Radio

Kevin Hoffman é um engenheiro líder de inovação digital para a 'Capital One', onde é responsável por projetar, implementar e socializar sistemas cloud-native modernos. Isso inclui tudo, desde a escolha da linguagem de programação até padrões de alto nível e práticas CI/CD. Antes disso, ele trabalhou para a Pivotal onde ele se incorporaria aos clientes, ensinando através do emparelhamento e implementação a migrar monólitos legados para a nuvem. Ele é autor de livros de fantasia, e construtor de mundos de videogames.