Cinco técnicas para construir uma nuvem privada de sucesso

A Amazon Web Services foi, claramente, a líder mundial no Quadrante Mágico do Gartner de 2017 para Infraestrutura de Cloud como Serviço. Entretanto, isso não é o suficiente para se tornar o fator de decisão para todos as empresas. Recentemente, a Target anunciou que está saindo, pelo menos parcialmente, da AWS devido a concorrência com a oferta de varejo da Amazon.

O Walmart, por sua vez, construiu sua própria solução de cloud privada, e recentemente pediu a seus fornecedores técnicos que saíssem da Amazon, ao mesmo tempo em que formou acordos mais próximos com Google e Microsoft. Adicione a isso o fato de que todos os principais fornecedores de cloud pública se juntaram a Cloud Native Computing Foundation (CNCF) pressionados pelo Kubernetes e direcionando a indústria para um mundo de microservice baseado em containers nas nuvens públicas e privadas.

Já a VMWare, realizou acordos impressionantes com os quatro maiores provedores de cloud (Amazon, Microsoft, IBM e Google). A Microsoft liberou o Azure Stack, uma versão light da Azure para on-premises. Outro importante marco para a indústria é a evolução das regulações locais (China, Rússia, Europa) sobre privacidade de dados e segurança. Por exemplo, note a importância da implementação da European General Data Protection Regulation (GDPR) em maio de 2018.

Está se tornando crítico para as empresas refinar suas estratégias de nuvem para adotar soluções multi-cloud e considerar a necessidade de uma governança de dados forte. Comumente, isso significa suportar uma solução de nuvem privada.

Abaixo existem cinco pontos para considerar ao implementar uma estratégia de nuvem privada.

Quadrante Mágico para Infraestrutura de Cloud como Serviço, Mundial

Fonte: Gartner (June 2017)

1. Tenha uma visão e construa um plano estratégico e tático

Muitas implantações de nuvem privada falham em prover resultados significativos. Como sempre acontece com projetos de tecnologia, as expectativas não são setadas corretamente e os objetivos criados não são realistas, levando a resultados ruins. Não precisa ser dessa forma. Uma vez claro o entendimento de quais problemas você precisa resolver para os stakeholders, é necessário se definir requisitos e objetivos de forma muito clara. Por exemplo, olhe para os pontos de problemas com os desenvolvedores e como uma solução de nuvem privada irá ajudar a resolver, ou mitigar, esses problemas. Melhore a experiência dos desenvolvedores para garantir uma adoção rápida e sucesso a longo prazo.

Mudar para nuvem privada requer foco, perseverança, motivação, responsabilidade e comunicação. É preciso entendimento dos custos do serviço existente, realizando uma análise de TCO (Total Cost of Ownership).

Como o dia a dia da área de operações se comportam para passarem a suportar uma infraestrutura privada? É necessário definir um modelo de chargeback para os stakeholders e onde estão modelos de sucesso de chargeback? Quais os tipos de workloads você planeja mover para a nuvem privada, e como é possível simplificar o capacity planning? Qual será o mínimo footprint (armazenamento), e até mesmo o máximo footprint? As soluções atuais irão se integrar facilmente com os pipelines de CI/CD existentes e o fluxo de trabalho dos desenvolvedores? A atual infraestrutura já provê containers para os desenvolvedores ou ainda é preciso criar um plano para a adoção de containers em produção no ambiente multi-cloud?

Se algum componente precisar ser redesenhado ou recriado, todos os esforços precisam ser considerados. O processo de deployment de aplicações e abstrações talvez precise ser alterado para prover uma integração imperceptível para os times de desenvolvimento. Os SLAs precisam ser definidos e a forma de como monitor o KPI para os seus stakeholders. Uma vez que a estratégia esteja definida, fique mais tático e refine o seu plano.

Tenha em mente que com muito planejamento, nada será feito. No entanto, sem metas ambiciosas, você não criará o impulso necessário. Um equilíbrio adequado entre o conjunto de recursos necessários e a realidade da tecnologia é necessário para oferecer valor ao negócio.

Curiosidades

#1 A Adobe Advertising Cloud DSP construiu sua solução multi-cloud através da perspectiva do crescimento rápido da TubeMogul. A visão? Simplificar a resolução de problemas de baixa latência e grandes requisitos de armazenamento, oferecendo aos nossos stakeholders a capacidade de atender o seu workload através de uma infraestrutura totalmente automatizada on-premises. A Estratégia? Entregar a flexibilidade de performance e provisionamento através de uma mistura de instâncias virtuais e físicas com um workflow CI/CD simples que funcione em ambientes multi-cloud. A tática? Aproveitar o projeto open source Platform OpenStack para a orquestração e automação da infraestrutura. Desenvolver uma equipe dedicada e enxuta, que possa manter P/D e manter o ciclo de vida da nuvem privada. Garantir um workflow constante de CI/CD para desenvolvedores em ambientes de nuvem privados e públicos.

# 2 Enquanto meditamos sobre os nossos planos em uma nuvem privada, confrontamos nossas descobertas diretamente com o nosso fornecedor de nuvem pública (AWS). Questionamos tudo, desde nossa análise de TCO até os desafios técnicos que enfrentamos. Em qualquer momento durante os primeiros três anos, estávamos prontos para retirar nossos planos de nuvem privada, mesmo depois de uma primeira localização implantada. No entanto, durante muito tempo, nosso plano de nuvem privada tem sido o nosso BATNA [1] para negociar preços baixos com nosso provedor de nuvem pública.

2. Faça o design pensando em flexibilidade

Depois de saber quais serviços serão entregues e qual seria o modelo operacional, é fundamental manter flexibilidade suficiente no design da sua solução. A fase de P/D não deve ser uma parte negligenciada de esforços. Serão necessárias múltiplas iterações. Planeje de acordo com o espaço para falhas desconhecidas ou complexas. Buscar uma tecnologia sempre leva a debates carregados de paixão.

Em seguida, pense em como definir a sua rede e as especificações dos servidores. Não cometa o erro de construir um canil para animais de estimação, você quer uma fazenda com gado grande. Em um modelo de nuvem privada, a tecnologia escolhida ficará por alguns anos. Você precisará estar de acordo com isso, ser um defensor, demonstrar valor agregado, construir uma comunidade, apoiá-la e explicar aos arquitetos mal-humorados porque este é o caminho. Bote no plano qual seria seu caminho de atualização e como é possível que a infraestrutura evolua da da versão v1 para a v2. A evolução da tecnologia será fundamental para suportar novos requisitos. Siga as novas tendências e mantenha seus talentos.

Primeiro, entregue um MVP sólido, que traga valor comercial crítico e que irá definir o seu sucesso. A melhoria do desempenho com sinos e assobios vem em segundo lugar. Certifique-se que você poderá avalancar a sua infraestrutura física, tanto quanto sua camada virtualizada ou conteinerizada. Não faça sua solução de nuvem privada apenas um "projeto de TI". Não pretenda construir uma nova nuvem pública internamente. Esta abordagem não terá sucesso! É preciso projetar a solução com flexibilidade suficiente para suportar todos os desenvolvedores de forma significativa. É preciso construir e desenvolver novas soluções, APIs e serviços para proporcionar uma experiência perfeita às partes interessadas na tecnologia. Garanta que os serviços de nuvem privada seguem padrões e convenções de nuvens já existentes para ajudar a impulsionar a adoção dos desenvolvedores e permitir que as funcionalidades sejam reutilizadas em outros ambientes. Dependendo do tamanho dos workloads e casos de uso, poderá ser preciso projetar uma SDN e desenvolver algumas sobreposições de serviço, ou ser capaz de mantê-los simples.

É importante tentar suavizar a curva de aprendizado e ser fortemente ágil. Comece pequeno, padronize os workflows dos desenvolvedores, aproveite as VLANs, limite o deployment para os serviços principais (por exemplo, gerenciamento de identidade, rede, computação, armazenamento) e tenha um procedimento claro para atualizações. Mantenha os serviços avançados para mais tarde, depois de demonstrar a viabilidade dos serviços básicos.

Curiosidades

#1 Na TubeMogul, passamos por vários ciclos de tentativa e erro para escolher nossas tecnologias ou fornecedores. Algumas dessas tecnologias quase não existem mais (CloudStack, Eucalyptus, etc.) e nós acabamos estabelecendo o OpenStack com uma mistura de bare-metal. Algumas das bases fundamentais do nosso primeiro design assumiram hardware como uma commodity barata, mas poderosa, com design simples de rede e falha. Nós avançamos apenas com os serviços principais do OpenStack e um workflow CI/CD básico com Jenkins e PXE para provisionamento em bare-metal. O mesmo pipeline CI/CD é usado por desenvolvedores para gerenciar os aplicativos e lançamentos em produção em ambientes de nuvem públicos e privados, ou enquanto faz mudança de um ambiente de nuvem para outro. Isso exigiu a convenção de nomenclatura padrão e o alinhamento entre ambientes para nos permitir reutilizar ferramentas e serviços existentes de forma transparente, o que foi fundamental para criar algum impulso.

3. Automação de Infraestrutura

Uma parte crítica de uma implantação de nuvem privada é a forma como o data center é gerenciado, a rede e a parte de aquisição. Isso inclui o processo de gerenciamento de ativos, o processo de RMA e todo o ciclo de vida de ativos. Isso pode tornar-se facilmente um ponto crítico de dor que desaceleraria todas as operações e pode ameaçar o valor comercial da implantação. Pense nisso, ache o que você é bom e o que você não é bom. Dependendo do investimento, expertise da equipe e objetivo, você pode assumir mais, mas não subutilize seus fornecedores.

Como eu continuo lembrando meus times, o VAR representa revendedores de valor agregado, não perca o valor agregado senão você é roubado. Dependendo do seu modelo de engajamento, você precisará definir elevação de rack, matriz de cabo, mapeamento de portas, power draw, etc. Em última análise, você quer se afastar do modelo de servidor a tempo para chegar a um rack-at-a-time-model e fazer a entrega dos seus racks do data center que estão totalmente carregados e cabeado. Ou seja, faça um Rack-And-Roll. Você apenas conecta o rack à sua rede principal e fica pronto imediatamente. Você não quer estar no negócio de montagem, rack e cabeamento, a menos que você tenha pessoal profissional para isso e obtenha um verdadeiro valor agregado dele. A maioria das empresas não usa um VAR.

Como parte desta "automação de hardware", assegure-se de ter um design que se encaixe na localização do datacenter. Qual o design Top-Of-Rack para o qual você está indo? Você provavelmente não quer saber sobre TIA 942-A, então aproveite seu fornecedor de data center para fornecer informações e revisões de design. Isso pode afetar as opções de hardware dependendo da escolha de ventiladores na parte traseira ou frontal e onde é o seu corredor frio no seu data center. São muitos os detalhes a serem pensados! Certifique-se de que seu plano se encaixa em consideração a sua alocação de espaço e energia, bem como você pode alavancar o pessoal no local para lidar com o seu RMA. Esses são elementos críticos para entender, racionalizar e controlar, a fim de criar as bases de uma nuvem privada bem-sucedida que pode ser totalmente automatizada através do código.

Curiosidades

#1 O espaço mínimo de implantação do Adobe Advertising Cloud DSP para qualquer data center é de dois racks. Todos os racks são construídos a partir do nosso VAR e são entregues nas instalações Equinix, prontos para funcionar. Todo o provisionamento é então automatizado para implantar nossa imagem base e componentes básicos, com base em cada função atribuída. O Puppet irá garantir o nosso gerenciamento de configuração. Se um recurso entrar em um estado indesejado ou, foi RMA e precisa ser redistribuído, é apenas uma questão de marcar o recurso para um novo provisionamento para iniciar um rebuild.

4. Seja usuário da sua própria solução e seja transparente

À medida que você passar pelos esforços necessários, não se deixe enganar. Você precisa testar o que você constrói! Você precisará testar novamente e novamente. Você quer quebrar sua implantação, reconstruí-la, uma e outra vez. Isso é fundamental para dedicar a quantidade certa de recursos à sua equipe de engenharia para poder iterar, separar as coisas, quebrar coisas, enxaguar e repetir. Você quer um laboratório realista para testar e experimentar. Você precisa usar sua própria nuvem privada para sentir a dor e abordar lacunas críticas.

À medida que você entra em produção com a sua nuvem, é preciso certificar-se de fornecer informações suficientes para que os stakeholders entendam o progresso. Não tenha medo de mostrar riscos e o estado geral da sua nuvem. Você fornece atualizações claras de planejamento de capacidade, e quantos recursos de computação estão disponíveis? Seus stakeholders entendem a limitação de rede do projeto atual e como isso afeta o uso de sua aplicação? Como você fornece visibilidade na sua stack de rede para criar confiança? Você tem sobrecarregado recursos de computação e está abusando de taxas de subscrição? Todas essas questões precisam ser respondidas para fornecer confiança e suporte aos seus stakeholders a cada iteração e enquanto o ambiente de produção cresce.

Curiosidades

#1 O primeiro ambiente de desenvolvimento OpenStack da TubeMogul foi um sucesso, até uma semana depois, quando enfrentamos nossos primeiros problemas com o Ceph e reduzindo o ambiente completo. As más notícias? Tornou-se um ambiente de desenvolvimento ativo e compartilhado para experimentar o futuro da nuvem privada, bem como um ambiente de desenvolvimento ativo para os stakeholders de engenharia trabalharem em desenvolvimentos de recursos e validação pré-lançamento. Semana ruim, lição aprendida. Não misture seu ambiente de desenvolvimento com o ambiente dos seus stakeholders. Uma vez que alguém dependa da sua stack, é sua responsabilidade sua entregar um serviço de qualidade.

#2 O planejamento de capacidade é sempre difícil; em ambientes de nuvem, é preciso entender os casos de uso do negócio, mas não é desejado que o negócio dependa exclusivamente do crescimento da nuvem privada. É importante ter um contrato que permita adicionar capacidade antes do tempo. Nossa expansão mínima é baseada em dois racks. Se estamos ficando com poucos recursos disponíveis em uma localização, nós vamos adicionar dois racks no nosso tempo. Aqui é onde o nosso desenho flexível entra em ação, nos permite acelerar rapidamente voltando para uma nuvem pública se necessário.

Conclusão

É uma jornada. Construir uma nuvem privada não é trivial e a maioria das empresas pode não ter um verdadeiro caso de uso para isso. Use a nuvem pública onde quer que faça sentido. Para construir uma nuvem privada, é preciso ter muito claro o que se deseja alcançar e como isso se encaixa na sua estratégia multi-cloud. Sua governança de dados ou decisões comerciais e estratégicas podem dirigi-lo de uma maneira ou de outra. Uma nuvem privada não é um simples projeto de tecnologia; deve ser uma decisão estratégica. Compreenda o quadro geral, tenha o apoio de seus stakeholders e, em seguida, crie um plano ágil que permita que você construa, falhando e corrigindo rapidamente. A Adobe Private Cloud DSP passou por várias fases que requerem software sólido e tecnologia operacional para automatizar nossa infraestrutura. Agora oferecemos uma infraestrutura central que nos permite reduzir nossa pegada, reduzir nossa latência, lidar com mais tráfego e superar as performances da rede real AWS por três vezes.

Referências

[1] BATNA é um termo criado por Roger Fisher e William Ury no best seller deles em 1981, Como Chegar ao Sim: A negociação de acordos sem concessões.[1] Significa "Melhor Alternativa para se negociar um acordo."

[2] Cisco Data Center Top-of-Rack Architecture Design

Sobre o Autor

Nicolas Brousse Líder em Tecnologia de Cloud, tornou-se Diretor de Engenharia de Operações da Adobe (NASDAQ: ADBE) após a aquisição da TubeMogul (NASDAQ: TUBE). Com adaptação rápida às mudanças às necessidades e restrições comerciais atuais, Nicolas lidera uma equipe global de engenheiros de confiabilidade de sites, engenheiros de cloud, engenheiros de segurança e arquitetos de banco de dados que criam, gerenciam e monitoram a infraestrutura do Adobe Advertising Cloud 24/7 e aderem a "DevOps" metodologia. Nicolas é um orador freqüente nas principais conferências de tecnologia dos EUA e regularmente dá conselhos a outros engenheiros de operações. Antes de se mudar para os Estados Unidos para se juntar ao TubeMogul, Nicolas trabalhou em tecnologia há mais de 15 anos, gerenciando tráfego pesado e bancos de dados de usuários grandes para empresas como a MultiMania, Lycos e Kewego.