A surpreendente verdade sobre a transformação digital: Caos na Nuvem
Este é o segundo blog de uma série sobre os desafios decorrentes da transformação digital.
Caos nas nuvens.
Algum engenheiro inteligente está comentando agora mesmo que essa frase é redundante. Afinal, a nuvem é um caos, com sua falta de governança e abordagem laissez-faire para proteger aplicativos jogados em suas profundezas brancas e fofas sem um cronograma bem definido.
Vamos fazer uma pausa aqui para observar que o caos associado à nuvem é, na maioria das vezes, um problema de pessoas e processos , não técnico.
Isso não quer dizer que não existam desafios técnicos – ou pelo menos arquitetônicos – associados à nuvem. Algumas delas estão relacionadas às complexidades das redes virtuais. Mas a maioria é arquitetônica. Um desses desafios arquitetônicos está relacionado à própria natureza da nuvem, com seu foco por aplicação.
Se você pensar bem, a nuvem pública e seu modelo de implantação são considerados a forma ideal (a "forma de nuvem", como os platônicos podem chamá-la) de nuvem. Isso significa que a nuvem privada também deve seguir seus preceitos e exibir as mesmas características.
Isso significa APIs e provisionamento de autoatendimento. Painéis e consoles baseados na web. Mas também significa uma mudança arquitetônica para uma implantação que é puramente focada em um único aplicativo.
Arquiteturas por aplicativo são a norma na nuvem. Os serviços são implantados e configurados para oferecer suporte a um aplicativo por vez e criar um caminho de dados único do usuário até o ponto de extremidade que atravessa esses serviços. Isso contrasta fortemente com o design de rede de data center tradicional, no qual um número significativo de infraestrutura de serviços de rede e aplicativos é compartilhado.
É a noção de "infraestrutura compartilhada" que se torna desafiadora em um mundo de desenvolvimento DevOps e Agile que é tão focado em aplicativos quanto a nuvem pública.
Infraestrutura tradicional e compartilhada, as redes resultam em “um caminho verdadeiro da porta até o aplicativo”. Os desafios decorrentes desta abordagem no mundo digital acelerado de hoje são:
- Alinhamento de versão de infraestrutura. Um aplicativo pode exigir recursos fornecidos por uma atualização ou patch, enquanto outro depende da versão existente. A infraestrutura compartilhada geralmente não permite diversidade de versões no mesmo sistema e, portanto, pode impedir uma aplicação em favor de outra.
- Cronogramas de implantação conflitantes. Quando recursos compartilhados são afetados, as empresas iniciam uma fase de negociação na qual as partes interessadas no aplicativo tentam resolver conflitos nos cronogramas de implantação. O processo pode ser longo (e sempre doloroso) e ninguém ganha quando um novo aplicativo ou atualização é retido devido a conflitos de agendamento.
- Raio de explosão. Nem é preciso dizer que se meu aplicativo causar falha em um sistema compartilhado, todos os aplicativos que dependem desse sistema falharão. O raio de alcance da infraestrutura compartilhada é enorme e é um fator significativo na relutância em fornecer maior acesso ao pipeline de implantação para aqueles fora da TI.
- Solução de problemas. Tentar vasculhar logs agregados é doloroso. Empresas muito bem-sucedidas foram construídas com base apenas na capacidade de minerar grandes volumes de registros e desagregar os dados novamente em fluxos por aplicativo. A solução de problemas em sistemas compartilhados é complicada e demorada, além de ter um impacto negativo no tempo médio de resolução, um KPI essencial para a TI moderna.
Na nuvem, nada disso costuma ser um problema. Há um caminho por aplicativo, porque os aplicativos geralmente são implantados em seu próprio cronograma, em seu próprio ambiente, geralmente por equipes diferentes.
Para salvar nossa sanidade (e nosso data center), precisamos adotar essa abordagem no local, seja em uma nuvem privada ou não.
Você ainda terá serviços de rede compartilhados. Firewalls, IPS/IDS, DDoS e inspeção de usuários são bastante neutros em relação aos aplicativos e podem (e devem) ser aplicados em toda a empresa. Para todo o resto, há serviços e infraestrutura por aplicativo (específicos do aplicativo, se preferir). Essa separação lógica preserva a estabilidade e a segurança do negócio, ao mesmo tempo em que permite um ambiente mais volátil e talvez instável mais próximo dos aplicativos. Ele também preserva um caminho de dados para aplicativos tradicionais (legados e de herança) que não exigem o tipo de velocidade e suporte necessários para aplicativos mais novos. A rede por aplicativo pode ser uma nuvem privada, vários clusters de contêineres ou alguma combinação deles.
O casamento dos dois resultará em uma rede mais estável e resiliente, além de flexível e rápida.
Uma abordagem por aplicativo para a rede tem uma variedade de benefícios, além de mitigar os problemas decorrentes de uma abordagem compartilhada juntamente com arquiteturas de aplicativos e modelos de entrega modernos:
- Pipelines e cronogramas individuais. Posso agendar minhas próprias implantações quando estiverem prontas porque elas não impactam nenhum aplicativo ou infraestrutura além da minha. Isso oferece flexibilidade para dar suporte aos diversos cronogramas que você precisa manter em um data center moderno.
- Raio de explosão restrito. Se minha implantação causar uma falha em meus sistemas dedicados, a responsabilidade é toda minha. Não afeta nenhum outro aplicativo. Essa abordagem de caminho de dados dedicado por aplicativo facilita ainda mais a solução de problemas, pois posso ter certeza de que os logs e mensagens de erro em todos os sistemas pertencem a mim e ao meu aplicativo.
- A escala não se restringe aos recursos da plataforma. Em um mundo altamente volátil e dinâmico, é quase impossível saber quando o próximo fluxo de visitantes chegará ou se algum conteúdo se tornará viral ou, Deus nos livre, se você está sendo atacado. Seja qual for a causa, quando a demanda por aplicativos em sistemas compartilhados (hardware ou software) aumenta, a escala fica restrita aos recursos disponíveis na plataforma. Usar uma arquitetura por aplicativo atenua essa restrição e permite que componentes individuais sejam dimensionados conforme necessário para atender à demanda.
- Oferece suporte à verdadeira infraestrutura como modelo de código. Sistemas compartilhados usam configurações compartilhadas, mesmo que seja apenas uma configuração base com políticas por aplicativo. Esse modelo pode causar caos ao tentar implementar um modelo de infraestrutura como código , especialmente quando vários aplicativos estão tentando ser atualizados ao mesmo tempo. As alterações podem afetar outros aplicativos sem aviso, ou as ações de confirmação e clonagem podem falhar porque outros bloqueiam recursos quando você precisa deles. Uma arquitetura por aplicativo garante que os artefatos de implantação pertençam a apenas um aplicativo e possam ser gerenciados adequadamente pelos proprietários do aplicativo (sejam eles dev, DevOps, NetOps ou ).
Embora uma arquitetura por aplicativo não resolva todos os problemas que surgem da transformação digital, ela pode ajudar muito a domar o caos decorrente da nuvem. Ela oferece maiores oportunidades para padronizar a segurança , além de dar suporte aos ambientes multinuvem nos quais a maioria das empresas está se tornando.
Fique ligado na próxima postagem desta série, na qual veremos como você pode lidar com aqueles que estão pulando a segurança devido às pressões de entrada no mercado decorrentes da transformação digital.