Os quatro estágios da sua jornada para a Nuvem Pública

Dependendo de quem você acredita, o hype em torno da nuvem está chegando ao "Pico das Expectativas Infladas" (onde as histórias de sucesso precoces capturam muita atenção da mídia e da indústria), ou já está escorregando rapidamente para o "Trough of Disillusionment" (onde implantações precoces não cumprem as expectativas e a indústria começa a reavaliar sua abordagem). Para complicar ainda mais as questões, o Gartner atualmente coloca serviços em nuvem avançados como PaaS sem servidor na inclinação para cima do ciclo de hype. Independentemente do que for correto, as empresas estão revisando suas estratégias de "cloud first".

O Gartner prevê que no decorrer do próximo ano,

"90% das organizações não terão uma estratégia pós-moderna de integração de aplicativos e capacidade de execução, resultando em desordem de integração, maior complexidade e custo".

A experiência parece confirmar a conclusão de Gartner também, principalmente porque parece haver uma séria confusão sobre o que o "cloud first" realmente significa em termos de estratégia.

À medida que eles entram pela primeira vez na computação em nuvem, a maioria das empresas assume que simplesmente replicar sua infra-estrutura existente na nuvem é o cumprimento de sua estratégia, mas essas empresas ainda estão longe de perceber os benefícios operacionais e financeiros da nuvem.

Na nossa opinião, existem quatro etapas na jornada típica para a construção de uma infra-estrutura de TI verdadeiramente sustentável em nuvem pública. Qual etapa alcançou o seu negócio?

  • Etapa 1: Replicando TI na nuvem

    Conforme mencionado anteriormente, as implementações iniciais da nuvem se concentram em tentar replicar sua infraestrutura no local em uma plataforma da nuvem. Compreensivelmente, muitos pensam que este é também o fim do processo; não só eles agora são orgulhosos "proprietários" de uma plataforma extremamente familiar que eles entendem por dentro e por fora, mas também resolvem um de seus problemas mais urgentes - restrições de capacidade.

    As empresas podem passar anos na primeira fase, simplesmente expandindo para fora à medida que a demanda por processamento e armazenamento aumenta. E porque tudo é tão familiar, o modelo DevOps permite que as empresas continuem como normais, mantendo o mesmo nível de produtividade e eficiência que sempre gostaram.

    Mas se um negócio permanecer neste estágio inicial de sua primeira estratégia em nuvem, eles podem achar que os primeiros sucessos não serão levados adiante para o futuro.

  • Etapa 2: reconstruir e automatizar

    Também conhecido como a fase: "O que aconteceu com as economias de custos que prometeu?", o estágio 2 só é iniciado quando o CFO começa a fazer perguntas difíceis. Embora a organização tenha reduzido o gasto de capital no hardware, os custos da nuvem continuam em espiral - e ninguém está inteiramente certo por que.

    O problema é que a escalabilidade ilimitada da nuvem pode causar problemas imprevistos para desenvolvedores de nuvem e engenheiros de sistemas sem experiência. Os desenvolvedores podem fazer uso de tantos serviços de fornecedores de nuvem como eles gostem, mas todos são cobrados de acordo. O que significa que muitos alocam muitos recursos de forma ineficiente ou desnecessária.

    Não é coincidência que o "Trough of Disillusionment" do Gartner coincida com as empresas que enfrentam problemas no estágio 1, forçando uma reavaliação de implantações e estratégia da nuvem. Como David Stanley, chefe da entrega da plataforma em Trainline, disse sobre as experiências de nuvem pública de sua empresa:

    "A maior mudança cultural para passar depois de ter feito todas as suas alterações do DevOps é se concentrar nos custos".

    Chestened por uma repreensão severa do CFO, o departamento de TI começa sistemas de reengenharia para alinhá-los com as várias regras pelas quais os custos da nuvem pública são calculados. Por exemplo, criando usuários e grupos, as empresas podem controlar quem tem permissão para solicitar recursos públicos de nuvem. Imediatamente, os sistemas se tornam mais eficientes em termos de operações e custos.

    À medida que sua experiência com as tecnologias da nuvem se aprofunda, os desenvolvedores também aumentam o nível de automação usado para seus sistemas hospedados. Como exemplo, em um retorno aos princípios de processamento em lote de antigas, as máquinas virtuais serão giradas durante as horas fora de horário para reduzir os custos operacionais. O recurso AWS Auto Scaling, por exemplo, permite aos desenvolvedores limitar a escala de recursos com base em um cronograma pré-definido, garantindo que os recursos estejam disponíveis de acordo com a demanda previsível e liberados fora dessas horas para que o gasto esteja alinhado com o uso.

    Com sistemas redesenhados para a nuvem e automação usada para agilizar as operações, o CFO será muito mais feliz quando as contas voltarem sob controle. O gasto ainda pode aumentar, mas esse processo de racionalização garante que os custos estejam melhor contidos e plenamente justificáveis.

  • Etapa 3: Containerização

    Embora os custos estejam agora sob controle, a infra-estrutura hospedada ainda é relativamente intensiva em recursos quando se trata de gerenciamento. No final do segundo estágio, os aplicativos ainda residem em máquinas virtuais instaladas em um hypervisor, o que, em si, fica em cima da camada da nuvem.

    Muitos desses sistemas virtualizados serão definidos e esquecidos, mas isso é minimizar o trabalho envolvido na configuração deles no momento da implantação. Há também a realidade de que as mudanças de configuração em larga escala serão necessárias - e a equipe de TI precisará realizar o trabalho para garantir que os sistemas continuem a funcionar como esperado.

    Com aplicativos, binários e bibliotecas, sistema operacional convidados e um hypervisor instalado no topo do sistema operacional host, existem vários níveis que precisam ser gerenciados. É aqui que a terceira fase começa, com o objetivo de simplificar a arquitetura de aplicativos, reduzindo as despesas gerais de gerenciamento e o uso de recursos em nuvem.

    Usando um mecanismo de contêiner como Kubernetes ou Docker instalado diretamente em cima de um sistema operacional convidado, os desenvolvedores podem fazer a reengenharia de aplicativos sem a necessidade de um hypervisor ou máquina virtual. O código é compilado e executado em um "contêiner", contendo nada mais do que as dependências necessárias para o aplicativo. Isso oferece várias vantagens:

    • A aplicação em contentor é mais leve, ajudando a reduzir as demandas sobre os recursos do servidor e os custos de funcionamento,
    • O aplicativo torna-se mais portátil, permitindo que ele seja redistribuído em outro serviço da nuvem com o mínimo esforço,
    • Os desenvolvedores podem se concentrar inteiramente na construção de um aplicativo ou serviço, sem se preocupar com o sistema operacional ou outros fatores secundários que complicam o processo,
    • Com menos camadas para gerenciar, administradores e engenheiros são liberados para se concentrar em outros projetos estratégicos,

    Como um bônus, uma redução adicional na demanda em recursos do servidor também ajuda a reduzir os custos ainda mais, o que significa muito menos aborrecimento do CFO.

    Com menos camadas para gerenciar, administradores e engenheiros são liberados para se concentrar em outros projetos estratégicos.

  • Etapa 4: Computação verdadeiramente sem servidor (Serverless)

    No final da terceira fase, os recursos computacionais foram dramaticamente simplificados, compactando as aplicações e os custos operacionais e aumentando a portabilidade do código. Mais uma vez, a tentação é assumir que o processo de migração da nuvem está completo, mas ainda há mais melhorias a serem feitas.

    Neste ponto, os aplicativos são incorporados em contêineres autônomos, mas a plataforma Docker na qual eles são construídos ainda consomem recursos do servidor dentro do data center do fornecedor da nuvem. Em muitos casos, os desenvolvedores estão executando máquinas virtuais completas dentro de seus contêineres. Isso não é necessariamente uma coisa ruim, mas as aplicações podem ser mais racionalizadas, o que, por sua vez, reduz o esforço e o custo de desenvolvimento.

    Mais importante é que ao reter um sistema operacional dentro do contêiner, o ambiente mantém as mesmas despesas gerais e administrativas. Os esforços iniciais podem proporcionar uma maior densidade de máquinas virtuais, mas incluir o sistema operacional em um recipiente faz pouco para reduzir a complexidade de manutenção - e as despesas gerais de operação.

    O estágio final da migração da primeira nuvem é desenvolver e implantar aplicativos "sem servidor". Como o nome indica, esses aplicativos são projetados para reduzir a confiança nos servidores Kubernetes, Docker e na nuvem, na medida do possível. Em vez de recorrer a aplicativos e máquinas virtuais totalmente compilados, aplicativos sem servidor são criados usando bibliotecas em contêineres e plataformas de nuvem hospedadas em binários e vinculados com API fornecidos por serviços públicos em nuvem.

    Simplificando, as aplicações sem servidor levam os blocos de construção fornecidos por vários serviços on-line e os "colam" juntos. Essencialmente, os aplicativos da Etapa 4 aproveitam a "Função como Serviço" para reduzir custos e despesas gerais.

    Essas aplicações ainda são infinitamente escaláveis, aproveitando recursos de terceiros quando necessário, mas com uso mínimo dos recursos locais. Conectando esses serviços deste modo, aumentam ainda mais a velocidade do desenvolvimento e reduzem o nível de manutenção necessário para lidar com as atualizações dos serviços que estão sendo usados.

    E porque suas novas aplicações dependem dos serviços de nível SaaS fornecidos por terceiros, não há necessidade (ou mesmo função) de ajustar a configuração de componentes como 'httpd' ou MongoDB - essas funções são tratadas pelo provedor de terceiros. Sempre haverá uma sobrecarga operacional para aplicativos baseados em nuvem, mas, ao terceirizar as responsabilidades de infraestrutura e SO para provedores de serviços externos, o custo de funcionamento interno ainda é reduzido.

Tempo para avaliar o seu progresso

Com a primeira viagem para a nuvem planejada, torna-se muito mais fácil avaliar aonde sua empresa chegou. Muitos adotadores tardios ainda estarão em torno do primeiro estágio, o que significa que eles ainda têm algum caminho a trilhar. A maioria das organizações alcançou o estágio dois, no entanto, estão investigando como usar melhor a infraestrutura da nuvem para melhorar suas operações.

A computação em nuvem é uma mudança dramática na TI corporativa, e muitos ainda estão aprendendo a aproveitar ao máximo os benefícios fornecidos pela nuvem pública. A escassez de competências é agravada pelo ritmo acelerado de desenvolvimento de plataformas da AWS, Azure e Google Cloud Platform, por isso é uma pequena surpresa que as empresas estão lutando para alcançar seus objetivos de 'cloud first'. Especialmente quando a verdadeira estratégia de nuvem continua a ser mal compreendida.

A Claranet é o fornecedor credenciado multi-cloud - um membro ativo da Amazon Partner Network, tendo alcançado o status de Premier Consulting Partner e Managed Service Provider; Google Cloud Partner Program e alcançou o status de Premier e a Especialização de Parceiros em Infraestrutura; Microsoft Gold Partner; e o Prestador de Serviços Certificado Kubernetes.

Descubra mais...