Nossas soluções transformam os negócios e a sociedade por meio da tecnologia.
Um dos provedores de cloud mais conhecidos do mercado é a AWS, não é mesmo? Mas além da qualidade e latência que ela oferece, ela também tem recursos de automação que podem ser muito importantes para o seu negócio. O que acha, então, de entender um pouco mais sobre as características desses serviços e quais são as aplicações práticas dentro da estrutura de nuvem da sua empresa?
Continue a leitura deste artigo para entender mais sobre os serviços de automação em nuvem AWS. Confira!
Quais são os serviços de automação em nuvem AWS que a sua empresa pode utilizar? Listamos os principais deles para que você identifique aquele que melhor se encaixa aos objetivos e estratégias da sua equipe. Confira!
Já sabemos que é possível a criação de um ambiente completo (stack) por meio de um único template, não é mesmo? O CloudFormation também nos auxilia no gerenciamento de recursos em múltiplas contas e múltiplas regiões. É o chamado stackset ou conjunto de stacks.
O mesmo template que você utiliza para a criação de um stack pode ser utilizado para o desenvolvimento de um stackset, basta informar as contas e regiões, e o stack é criado em todas elas.
O que parece bom, fica ainda melhor. Utilizando o AWS Organizations para organizar a sua estrutura de contas AWS você pode associar um stackset a uma Organization Unit e qualquer conta que entre nessa OU terá o stack criado automaticamente. Além disso, ao ser removida da OU, o stack será removido prontamente também.
As suas OUs podem ser segregadas como preferir, por tipo de ambiente (desenvolvimento, qualidade e produção), por produto, por área ou da maneira que fizer mais sentido para a sua organização.
Você associa os stacksets às OUs correspondentes, e sempre que for criada uma conta naquela OU, o stack será criado como planejado. Para completar, é possível definir templates para configurações de segurança, implantação de serviços core ou o que mais for necessário.
Quando você passa a criar sua infraestrutura como código, espera-se que seu ambiente reflita exatamente o código desenvolvido. Mesmo revisando seus processos e treinando sua equipe podem ocorrer intervenções manuais que gerarão conflitos.
Se na sua configuração você definiu, por exemplo, que seu Auto Scaling Group teria 5 instâncias definidas e poderia escalar até 10, mas, manualmente, alguém alterou esse valor máximo para 6, você provavelmente perceberia somente quando tivesse uma contenção na sua aplicação.
Não podemos “achar” que o ambiente reflete o nosso código, precisamos ter certeza disso. Portanto, você pode contar com o CloudFormation Drift Detection. Com ele, podemos validar que o nosso ambiente reflete o template CloudFormation aplicado.
Se for detectada uma alteração de recurso fora do CloudFormation, somos apresentados a um diferencial de como deveria estar o ambiente de acordo com o template e como ele está no momento.
Isso facilita a avaliação sobre se o template deve ser atualizado para refletir a infraestrutura criada manualmente ou se essa alteração manual deverá ser removida para voltarmos à configuração original.
O CloudFormation StackSet também suporta Drift Detection. Portanto, podemos validar o estado da nossa infraestrutura em múltiplas contas e múltiplas regiões com apenas poucos cliques (ou poucos comandos).
Se você quer auditar e avaliar constantemente se há Drift no seu ambiente, pode utilizar a regra cloudformation-stack-drift-detection-check do AWS Config e, a partir do AWS CloudWatch Events, relacionar essa config rule para receber notificações por e-mail ou abertura de chamados.
Se você não quer intervenções manuais ou o seu ambiente de missão crítica exija aderência entre o código e a infraestrutura, é possível relacionar a config rule do AWS CloudWatch Events a uma função Lambda que faz a reversão automática ao estado correto da infraestrutura. Com essa automação, você elimina os stack drifts de uma vez por todas, sem a necessidade de avaliação e correção manual.
Esse recurso é muito importante para separar a responsabilidade de gerenciamento dos templates e manter a associação dos diferentes recursos.
Para ser mais prático, em uma empresa na qual o administrador de redes cria e gerencia os templates CloudFormation relacionados à comunicação de rede são configurados os VPCs, Networks, Subnets, Elastic IPs, NACLs e outros dentro desse template de Redes.
O especialista em database cria e mantém os templates de RDS e DynamoDB. Na configuração desses recursos, o DBA precisa especificar em quais redes seu banco de dados rodará, entre outras informações. Caso o DBA faça uma associação diretamente ao recurso criado, como, por exemplo, a uma faixa de endereçamento IP, terá problemas sempre que o analista de redes atualizar essas informações.
Para isso, o CloudFormation conta com o Cross-Stack Reference, de um lado o analista de redes usa a opção Export na seção Output para exportar os recursos que desejar, nesse caso, uma Subnet, e o analista de banco de dados usa a função ImportValue para importar o valor que deseja.
Dessa forma, os dois templates são gerenciados por equipes diferentes, mas de maneira totalmente integrada.
É possível formular stacks dentro de outros stacks. Dessa forma, você consegue modularizar os seus templates e trabalhar com programação orientada a objetos. Imagine que precisa criar um bucket S3 em vários projetos. Basta definir a configuração do recurso e, a cada novo template, inserir essa configuração.
Depois de dezenas ou centenas de stacks criados há a necessidade de atualizar a configuração do bucket S3. Você precisaria realizar essa etapa em cada stack criado. Porém, utilizando o Nested Stack, o código do bucket S3 é único, e, nos templates principais, você define a criação do bucket a partir desse template específico.
Dessa forma, quando existir a necessidade de atualizar a configuração do bucket S3, você pode fazer isso em apenas um lugar. Sempre que houver algum componente a ser criado da mesma maneira em vários templates, use o Nested Stack para ganhar tempo.
Durante a criação ou atualização de um stack, você pode definir os CloudWatch Alarms a serem monitorados. Se o alarme entrar em estado de ALARM, o CloudFormation volta o stack ao estado anterior. Você pode definir o período de monitoração de 0 a 180 minutos. Se definido com valor 0, o rollback só será disparado se o alarme for acionado durante o desenvolvimento ou atualização do stack.
Imagine que você tem um CloudWatch alarm para acompanhar o desempenho da sua aplicação e, ao atualizar o stack com novas configurações, define o Rollback trigger para esse alarme. O stack é atualizado, a nova configuração é aplicada corretamente, mas, com isso, a aplicação passa a apresentar problemas, o alarme é acionado e, então, o CloudFormation volta o stack automaticamente ao estado anterior.
Essa função é extremamente importante porque diminui o tempo de indisponibilidade de uma alteração que não apresenta o resultado esperado.
Com tantas opções no mercado, nem sempre é simples identificar aquilo que é melhor para a sua empresa, não é mesmo? Mas você não precisa se preocupar com isso: a TIVIT Cloud Solutions consegue identificar o melhor de cada nuvem para disponibilizar para a sua empresa. Dessa forma, é possível integrar diferentes ambientes e aplicações com máxima disponibilidade e segurança de dados.
A TIVIT é referência na América Latina em soluções completas de nuvem, e disponibiliza toda sua expertise para que sua empresa obtenha todos os benefícios que a computação em nuvem pode oferecer.
Viu? Os serviços de automação em nuvem AWS são os mais variados e podem ajudar a sua empresa de diferentes maneiras. Agora é só entender quais são as suas necessidades e identificar como elas podem ser resolvidas com essas soluções.
O que acha, então, de dar o próximo passo? Fale com um de nossos especialistas e entenda como podemos ajudar!
.jpg)
