Houve um tempo em que os desenvolvedores escreviam código muito próximo da infraestrutura em que seria executado. A infraestrutura era simples o suficiente para que os engenheiros lidassem com toda a pilha. Isso significava que eles poderiam gerenciar UX, lógica de negócios e servidores de uma só vez. Mas o software empresarial mudou drasticamente: os múltiplos ambientes, a ascensão da nuvem e os aumentos maciços na procura em torno da escalabilidade, monitorização e testes tornam muito mais difícil para os engenheiros de produto criar, aceder e gerir infraestruturas conforme necessário.
Na verdade, à medida que um produto é expandido, a sua infraestrutura cresce tanto em largura como em profundidade (mais serviços e módulos, e mais complexidade por serviço e módulo), o que dificulta a gestão de ambientes locais. Um produto normalmente consiste em um ou dois serviços quando está no nível inicial de financiamento ou na Série A. Alguns serviços podem ser facilmente executados localmente ou implantados para testar instâncias na nuvem. No entanto, um produto mais maduro que gere mais de US$ 2 milhões em receitas provavelmente consistirá em mais de cinco serviços em múltiplos ambientes, acessados por muitos desenvolvedores que fizeram fila para usá-los.
Entre na automação do fluxo de trabalho de infraestrutura. Com ele, os engenheiros de produto sem tempo ou experiência para desenvolver uma infraestrutura em nuvem que corresponda perfeitamente ao seu ambiente de produção podem usar a automação para fazer o trabalho. Se um desenvolvedor precisar de algo em tempo de execução, ele não precisará mais esperar por um ticket de suporte ou pela intervenção de um profissional de DevOps — ou, pior ainda, configurá-lo sozinho. Eles podem ignorar essa etapa e automatizar o processo, obtendo acesso imediato a uma opção de autoatendimento.
A infraestrutura como código (IaC) desempenha um papel aqui, permitindo que os desenvolvedores definam, provisionem e gerenciem a infraestrutura em nuvem de forma declarativa em arquivos de código. Isso requer muito menos tempo e é menos sujeito a erros do que navegar manualmente nas interfaces de usuário da nuvem para configuração. No entanto, o IaC ainda exige um esforço significativo da equipe de desenvolvimento.
Projetar um aplicativo com IaC exige planejamento proativo de infraestrutura e alinhamento de código. Apesar de um design proativo, o relacionamento forte, porém pouco unificado, entre aplicação e infraestrutura apresenta desafios de replicação. A engenharia de plataformas assume a responsabilidade de preencher esta lacuna, mas os conceitos prevalecentes de infraestrutura de autoatendimento tendem a enfraquecer essas conexões. A integração de primitivos de nuvem na camada de aplicação, em vez de gerenciar entidades separadas, facilita aplicações inerentemente conscientes da nuvem, simplificando a implantação de soluções de nuvem otimizadas. Em vez disso, a automação do fluxo de trabalho da infraestrutura permite que o código real seja usado para IaC.
Extraindo um padrão para uma biblioteca reutilizável usando a estrutura Nitric.
Para startups ou empresas menores que não possuem equipes de plataforma robustas, cada minuto que seus engenheiros de produto gastam tentando desenvolver a infraestrutura é tempo que poderia ter sido gasto na construção de recursos que geram receita. A automação forte pode permitir que seus engenheiros de produto desenvolvam o produto sem precisar se preocupar em como provisionar a infraestrutura necessária. O desenvolvedor pode — e deve ser capaz de — invocar ferramentas automatizadas que provisionem infraestrutura conforme definido no código.
Use código real para IaC.
Como exemplo de caso, quando os produtos de software como serviço (SaaS) são novos, sua plataforma, infraestrutura e sistema de construção ficam um pouco instáveis. Os desenvolvedores neste estágio precisam de flexibilidade para experimentar e decidir qual pilha de tecnologia melhor atende às necessidades de seus produtos. Navegar por processos complexos de nuvem, como a criação de nuvens privadas virtuais (VPCs) e clusters do Amazon Elastic Container Service (ECS), o gerenciamento manual de regras de privacidade e controle de acesso e a garantia de dimensionamento adequado de recursos prejudicam a capacidade de inovação dos desenvolvedores.
A automação da infraestrutura orientada por código pode gerenciá-los desde o início, permitindo que os engenheiros de produto façam o que fazem de melhor: aumentem a receita criando recursos que os clientes desejam.
Com plataformas inteligentes baseadas em código, como a estrutura de código aberto Nitric, os engenheiros de produto podem ser rápidos e fragmentados e configurar declarativamente a infraestrutura crítica simplesmente referenciando-a em seu código. Isso se mostrou um processo muito mais rápido e simples do que lidar com interfaces pesadas da AWS ou do Microsoft Azure, que poucos têm experiência para gerenciar corretamente. Com a plataforma, o cliente da Nitric, Drop Bio Health – uma empresa australiana de tecnologia de saúde – relatou uma redução de 60% em sua conta de nuvem AWS, um aumento de 12 vezes nas cadências de implantação e outras melhorias de eficiência.
A automação da infraestrutura também melhora a segurança e a postura de risco para startups com equipes enxutas e focadas no produto. A configuração inadequada da infraestrutura pode criar enormes riscos de segurança. Em 2001, o Gartner descobriu que a maioria dos problemas de segurança de TI se deviam à configuração incorreta manual do software. Mais de 20 anos depois, essa ameaça não mudou.
Muitas startups com poucos funcionários são forçadas a aceitar os riscos de ignorar as melhores práticas de segurança até construírem uma equipe de plataforma capaz de provisionar e gerenciar sua infraestrutura com segurança. Isto leva a um perfil de risco mais elevado, evidenciado pelo número de empresas que sofreram violações de privacidade. Mas sacrificar a segurança para uma entrada no mercado mais rápida nem sempre é uma opção.
Empresas em setores altamente regulamentados, como tecnologia financeira, seguros e saúde ter dedicar esforços para gerenciar cuidadosamente seus recursos de nuvem. E para startups enxutas, isso pode reduzir drasticamente a quantidade de tempo que seus engenheiros podem dedicar à construção do produto.
Em vez disso, o provisionamento automatizado pode preencher essa lacuna aplicando regras de segurança à infraestrutura até que a organização possa investir no talento de engenharia de plataforma necessário para gerenciar com segurança uma infraestrutura maior e mais profunda.
Empresas maiores que já possuem equipes de plataforma ainda veem benefícios significativos com a automação porque ela libera os engenheiros de confiabilidade de site (SREs) para trabalharem em suas próprias prioridades, em vez de atenderem constantemente às necessidades dos engenheiros de produto. Assim, para as empresas que possuem equipes de engenharia de plataforma, investir na automação da infraestrutura pode permitir que suas equipes de plataforma trabalhem em suas próprias prioridades, como conteinerização, migração para nuvem e IaC, sem perder tempo provisionando novos microsserviços.
A adoção da IaC, em particular, produz benefícios substanciais. Mas tem uma alta inércia de adoção, principalmente para empresas com arquiteturas grandes ou distribuídas. Apesar da adoção da IaC estar no topo da lista de prioridades dos líderes de engenharia de plataforma, as organizações muitas vezes lutam para cumprir as metas. As equipes de SRE geralmente estão ocupadas demais criando e desmontando recursos para que os engenheiros de produto possam mudar a forma como o provisionamento funciona.
O problema só piora à medida que o produto aumenta. Em vez de constituir uma única instância de computação para um produto pequeno, uma arquitetura maior envolve elementos mais complexos, como computação sem servidor, armazenamento elástico e gerenciamento de permissões. Isso significa que os engenheiros de plataforma precisam gastar cada vez mais tempo criando, protegendo e limpando manualmente a infraestrutura para as equipes de engenharia de produto, em detrimento do progresso em suas próprias iniciativas. O efeito cumulativo desses requisitos constantes faz com que os líderes de engenharia se voltem cada vez mais para a automação da infraestrutura.
A automação da infraestrutura também pode trazer benefícios não técnicos para organizações de tecnologia. Para os líderes de engenharia de plataforma, a redução do trabalho facilita a atração e a retenção dos melhores talentos. Encontrar SREs qualificados já é difícil, e mantê-los torna-se ainda mais difícil se eles passarem a maior parte do tempo em tarefas domésticas repetitivas. Eles deveriam trabalhar em iniciativas desafiadoras, como observabilidade ou conteinerização, que impulsionam a empresa e suas carreiras.
Os líderes tecnológicos são muitas vezes avessos à introdução de novas tecnologias se não sentirem que há uma crise. Mas a adoção de um conjunto de automação de infraestrutura envolve tanto prevenção quanto tratamento. Não precisa ser prejudicial ao roteiro. As empresas jovens têm a vantagem de poder construir seus produtos com automação incluída.
Mas mesmo escalonamentos e startups em estágio intermediário podem automatizar fluxos de trabalho de provisionamento sem muitos problemas, à medida que suas escalas de produtos e sistemas legados precisam ser substituídos ou refatorados. A introdução da automação da infraestrutura baseada em código nesta fase, como parte de uma revisão gradual da pilha de tecnologia SRE, irá lubrificar as rodas para o desenvolvimento futuro. Até mesmo restringir a automação a serviços recém-criados é melhor do que nada: proporciona aos engenheiros experiência com o conjunto de ferramentas e aumenta a confiança da liderança na eficácia da abordagem.
Independentemente de quando for introduzido, investir em automação robusta de fluxo de trabalho para infraestrutura pode reduzir o arrasto para organizações de tecnologia de todos os tamanhos. Isso facilita a vida dos engenheiros de plataforma e de produto. Acima de tudo, permite que a empresa se dedique à sua missão principal: construir um produto escalável.
YOUTUBE.COM/THENEWSTACK
A tecnologia avança rápido, não perca um episódio. Inscreva-se em nosso canal no YouTube para transmitir todos os nossos podcasts, entrevistas, demonstrações e muito mais.
SE INSCREVER
