O Amazon Web Services criou um conjunto de práticas recomendadas para a execução de sistemas na nuvem, chamada de AWS Well-Architected Framework.

O objetivo é uma revisão das arquiteturas e processos que estão em produção. A aplicação da metodologia (Framework) é realizada por engenheiros certificados da Sky.One que trabalham com um conjunto com o cliente revisando a arquitetura através de perguntas estruturadas e avaliações do ambiente para estabelecer o alinhamento com as melhores práticas recomendadas pela AWS

A AWS é uma plataforma em rápida evolução: novos recursos são frequentemente lançados para melhorar fatores críticos como segurança, custos e eficiência. Com o tempo, qualquer ambiente computacional necessita sofrer revisões frequentes, não aplicar correções ou melhorias implica em correr riscos, custar mais caros, comprometer o desempenho, a eficiência e principalmente ter vulnerabilidades.

Avaliar seus sistemas em relação às melhores práticas comprovadas é uma maneira eficaz de resolver essas questões. As revisões oferecem clareza e foco em um ambiente em constante mudança, permitindo problemas e melhorias sejam identificadas, priorizadas e implementadas.

Otimizar cargas de trabalho – Identificar oportunidades para otimizar os custos e re-arquitetar o ambiente para executar de maneira mais eficiente, confiável e econômica;

Mitigar riscos – Reduzir ou atenuar os riscos por meio de um melhor entendimento à medida que você constrói ou otimiza suas arquiteturas atuais;

Acelerar e inventar – Descobrir novos serviços que ajudam a melhorar os serviços contratados e responder mais rapidamente às necessidades do negócio.

A revisão do ambiente precisa ser realizada de maneira consistente, que incentive aprofundamento nas cinco dimensões (pilares) estratégicos: excelência operacional, segurança, confiabilidade, eficiência de performance e otimização de custos. Deve ser um processo leve, de horas, e que seja uma conversa e não uma auditoria. O objetivo de revisar o ambiente é identificar quaisquer problemas críticos que necessitam ser abordados ou áreas que possam ser melhoradas. O resultado é um conjunto de ações que devem melhorar a totalidade do ambiente.

Uma abordagem contínua permite responder às necessidades à medida que o ambiente evolui e novos serviços são lançados.

Sim, o AWS Well-Architected tem como premissa um conjunto de princípios de design que influencia a abordagem arquitetural e perguntas que garantem que as pessoas não negligencie áreas que geralmente são apresentadas na Análise de Causa Raiz. Sempre que houver um problema significativo com um sistema interno, serviço da AWS ou cliente, examinamos o Análise de Causa Raiz para ver se poderíamos melhorar os processos de revisão que usamos.

O assessment inicial normalmente é executada em três ou quatro horas. Em ambientes complexos, que necessitam um aprofundamento maior, estimamos três dias. Deve-se reservar mais duas horas para discutir os resultados e as recomendações.

Estimamos o custo total em função da densidade e complexidade do ambiente. Comumente os projetos variam em torno de R$ 15.000,00 a R$ 45.000,00. Se sua empresa contratar nosso serviço de sustentação de ambientes em nuvem, a aplicação da metodologia é gratuita.

É importante a participação dos principais envolvidos com as aplicações e que suportam o ambiente. Recomendamos a presença de pelo menos uma pessoa de cada área. Para uma carga de trabalho típica, isso normalmente envolve as seguintes funções: Engenheiro de Infraestrutura, DBA, DevOps, Desenvolvedor, Equipe de Suporte e Equipe de Segurança.

1. Assinatura do NDA para garantir a relação entre as partes;
2. Liberação de um usuário com propriedades somente de leitura no IAM para acesso ao console da AWS;
3. Kickoff inicial de 30 minutos para confirmar o escopo do trabalho e discutir a necessidade dos pré-requisitos;
4. A documentação existente sobre o design do ambiente, incluindo diagramas de arquitetura;
5. Informações ou acesso a ferramentas de monitoramento que existirem e não estão liberadas no console da AWS.

Porque iremos acessar o Well Architected Tool com seu ID e criar todo o relatório para notificar a AWS que o processo está sendo feito.

Nossa experiência tem demonstrado que os cinco pilares estratégicos (excelência operacional, segurança, confiabilidade, eficiência de performance e otimização de custos) são dinâmicos e devem ser revistos com frequência.

A Sky.One preparou um serviço específico, que chamamos de “sustentação de ambientes em nuvem”, que atende os cinco pilares.

Durante a fase de entendimento e análise procuramos conhecer o ambiente, os processos, a segurança e quais regulatórios a empresa deve cumprir, aplicando as melhores práticas da AWS. Neste momento, podemos encontrar a necessidade de uma “remediação” imediata em função de situações de exposição de riscos. Neste caso, geramos um documento extra de riscos com as recomendações de remediação imediata.

Recomendamos a execução de uma revisão bem arquitetada de três a seis meses para cada carga de trabalho distinta. Isso permitirá que você veja as melhorias, compare os novos resultados da revisão com a primeira e avalie o status atual da carga de trabalho em relação às melhores práticas em evolução

Embora o valor da aplicação da metodologia seja bastante claro para a maioria dos envolvidos, após iniciarmos, você pode descobrir que uma parte da sua equipe pode ser resistente no primeiro momento, mas que pode ser resolvido por meio de esclarecimento sobre os benefícios e uma determinação clara dos objetivos que buscamos alcançar.

Aqui estão as três objeções mais comuns:

• Objeção: “Estamos muito atarefados”

Argumentação: Se você está se preparando para um grande lançamento, deseja que ele corra bem. A revisão permitirá que você entenda os problemas que você pode ter no futuro.

• Objeção: “Não temos tempo para fazer melhorias agora, estamos sobrecarregados e temos muitas implementação pendentes”

Argumentação: Os projetos não vão parar. Entregar novas funcionalidades ou cargas de trabalho sem avaliar os riscos é muito crítico. Mesmo se você não implementar todas as recomendações listadas na metodologia, saber quais são, priorizar e executar em fases é a melhor forma de mitigar riscos. O pior risco é o que não conhecemos!

• Objeção: “Não queremos que outras pessoas saibam os segredos da implementação da nossa solução”

Argumentação: Primeiro, estabelecemos um NDA para garantir ambos os lados, segundo, as perguntas e a avaliação não buscam por segredos de negócios ou qualquer profundidade nos códigos das aplicações envolvidas. Não temos acesso a nenhum código fonte e não buscamos informações que violem propriedade comercial ou técnica.