O pilar de sustentabilidade é novo, mas promete uma verdadeira revolução no Well Architected Framework. Confira o artigo de Thiago Marques

08/07/2022
Por Thiago Marques
O pai ta on!!
Anunciado em 02 de dezembro de 2021, e lançado em abril de 2022, o novo pilar do Well Architected vem como uma forma de respostas a um dos temas mais discutidos no mundo nos últimos anos: proteção ambiental.
Nesse post vou mostrar os princípios do pilar, e passar por algumas das principais boas práticas.


Fonte

Well Architected Framework – Pilar Sustentabilidade

Em 2019 a Amazon já havia demostrado o tom de importância no assunto, quando anunciou a participação no the climate pledge, onde fechou um compromisso de impacto líquido zero em carbono, que previa:
• Adiantamento de 10 anos em relação ao acordo de Paris;
• 100% de uso em energia renovável até 2025;
• 50% de entregas com impacto líquido zero até 2030;

Atualmente mais de 50 galpões (CDs) da Amazon tem energia solar, e já encomendaram mais de 10mil veículos elétricos para entregas para o Amazon Prime.

Possivelmente para garantir a sustentabilidade de fim-a-fim, a Amazon decide então padronizar como um pilar de boas práticas, a fim de disseminar o mesmo grau de comprometimento para as empresas dentro da nuvem.

O novo pilar

Junto com o pilar de sustentabilidade foi criado também um modelo de responsabilidade para o mesmo (bem similar ao modelo de responsabilidade compartilhada da AWS), onde a AWS é responsável pela sustentabilidade DA nuvem o do cliente NA nuvem.


Fonte

Nesse contexto o objetivo principal da AWS é provocar o pensamento e a análise dos clientes quando ao impacto ambiental que seu workload tem no mundo, analisando métricas que vão desde o tipo de mídia que você deixa armazenado seus dados de long term, até a retro compatibilidade que seu workload possui com dispositivos mais antigos.

Além disso a própria AWS já disponibiliza no Cost and Usage Reports, métricas de emissão de carbono que a sua conta gera.

Para garantir e/ou ajudar os clientes a terem essa consciência, temos os 6 (seis) princípios do pilar:
1. Compreenda seu impacto: Que tem o objetivo de você começar a analisar os dados do seu workload no que tange a sustentabilidade. Isso pode incluir desde o impacto energético até mesmo o descarte de produtos e matérias que ele tem. Assim o principal ponto nesse princípio é criar KPIs para avaliar o impacto, e assim conseguir estabelecer planos para mitigá-lo.
2. Estabeleça metas de sustentabilidade: Se o primeiro princípio visa você TER o dado, esse ajuda a dar mais um passo, provocando agora a estabelecer metas de longo prazo. Isso envolve muitas vezes mudanças de arquitetura tecnológica que estão diretamente ligadas a outros pilares. Alteração de uma arquitetura monolítica para microserviços é um planejamento de médio/longo prazo que encaixa bem nesse princípio.
3. Maximize a utilização: Princípio totalmente prático, que assim como o anterior faz um ‘cross-over’ com outros pilares como performance, custos e excelência operacional. Nesse ponto o principal objetivo é atender o ‘stop guesting’, ou seja, se utilizar aquilo que precisa. Usar um ASG que escale com 70 ou 80%, ou até mesmo utilizar o Compute Optimizer para avaliar se tem instancias subutilizadas;
4. Antecipe e adote ofertas de hardware e software mais eficientes: Princípio interessante, a AWS investe sempre na atualização de hardwares que suportam a nuvem, e muitas vezes oferece tradeoffs muito valiosos para realizar o upgrade. O ponto aqui é garantir que seu workload, está utilizando máquinas e aplicações atualizados, pois em teoria eles são mais otimizados, e assim agridem menos o meio ambiente;
5. Use serviços gerenciados: Outro cross-over. Usar serviços gerenciados garante ‘menos’ responsabilidade no modelo de sustentabilidade, pois toda a administração passa a ser também da AWS. Assim utilizar o lifecycle do S3, ASG, Fargate e RDS são pontos principais aqui.
6. Reduza o impacto de seus workloads em nuvem: No último (mas não menos importante princípio), temos um dos que mais gosto que é de fato reduzir o impacto do workload, e nesse ponto a AWS cobra o cliente a fazer o mesmo que ela, ou seja: se preocupar com o ciclo completo do workload. Aqui o princípio provoca o cliente a fazer testes com farms de dispositivos e ver o impacto (em caso de um workload com uma aplicação), ou mesmo cobrar seus fornecedores que sigam princípios de sustentabilidade.

That’s all folks! Be Happy!!!

foto-thiago-marques

Thiago Marques
Technical Account Manager
thiago.marques@darede.com.br

Technical Account Manager da Darede, formato em Rede de Computadores, e pós graduado em Segurança da Informação. Possui ampla experiência em Datacenters e Service Providers, além de ser um entusiasta em DevOps e mercado financeiro.

OUTRAS PUBLICAÇÕES

Novidades da Semana 08 a 12 de março

Todos os dias a AWS lança uma série novidades e atualizações em seus produtos que visam melhorar a vida de seus usuários. Reunimos algumas delas que fazem mais sentido para nosso mercado e que certamente aplicaremos em nosso dia a dia. Confira as novidades da última semana. Segurança AWS Shield Advanced – Suporte a tags O AWS Shield Advanced agora protege recursos ou grupo de recursos baseados em sua tag. São suportados os seguintes recursos: EC2, ELB, CloudFront, Global Accelerator e Route53. AWS Security Hub – adição de 25 novos controles de boas práticas AWS Security Hub adicionou 25 novos controles de boas práticas. Agora o Security Hub possui 115 controles básicos de segurança. AWS IAM – Novo recurso no Access Analyzer O AWS Identity and Access Management (IAM) Access Analyzer agora permite que você valide o acesso de usuários antes de implantar as alterações de permissões. Storage & Analytics AWS Glue – DataBrew adiciona novas transformações visuais O AWS Glue DataBrew adiciona quatro novas transformações visuais – Binning, Skewness, Binarization e Transpose, ajudando analistas e cientistas de dados a aproveitar essas transformações sem escrever nenhum código. AWS Glue – DataBrew novas funções no painel de qualidade Ao gerar perfis de qualidade de dados em seus conjuntos de dados, o DataBrew agora publica um painel visual no console AWS Glue DataBrew com mais de 40 estatísticas e visualizações listadas em um formato tabular para fácil comparação. Amazon Redshift – Anúncio da ferramenta Amazon Redshift Cross-database queries As consultas entre bancos de dados do Amazon Redshift fornecem a capacidade de consultar bancos de dados em um cluster Redshift. Esse recurso agora está disponível em todas as regiões onde os tipos de nodes do Amazon Redshift RA3 estão disponíveis. Com as consultas entre bancos de dados, você pode realizar consultas de qualquer cluster, independentemente de qual você está conectado. Amazon Redshift – Anúncio da ferramenta Amazon Redshift Data Sharing O Amazon Redshift Data Sharing, uma maneira fácil e segura de compartilhar dados ao vivo entre clusters Redshift, agora está disponível para todos. Amazon RDS for PostgreSQL – Suporte a disaster recovery (DR) gerenciado O Amazon RDS para PostgreSQL agora oferece suporte a backups automatizados entre regiões. Este recurso estende a funcionalidade de backup existente do Amazon RDS, oferecendo a capacidade de configurar a replicação automática de snapshots do sistema e transaction log de uma região primária para uma região secundária. Amazon RDS for PostgreSQL – Instâncias M6g and R6g disponíveis em diversas regiões Agora as instâncias m6g e r6g estão disponíveis nas regiões de N. California, Canadá, São Paulo, e Londres. Amazon Aurora – Global Database expande a disponibilidade para São Paulo e Estocolmo Agora o Amazon Aurora Global Database está disponível nas regiões de São Paulo e Estocolmo (Suécia). Amazon Aurora PostgreSQL – suporte a autenticação simultânea com Active Directory e IAM Os clientes agora podem ativar vários protocolos de autenticação ao mesmo tempo para um cluster Amazon Aurora PostgreSQL. O Amazon Aurora PostgreSQL oferece suporte à autenticação Kerberos com Microsoft Active Directory (AD) e autenticação de banco de dados IAM, no passado você podia escolher apenas um para um determinado cluster. Amazon RDS for Oracle – suporte a versão 13.4 do Oracle Management Agent (OMA) for Oracle Enterprise Manager Cloud Control 13cR4 O Amazon RDS para Oracle agora oferece suporte ao Oracle Management Agent (OMA) versão 13.4 para Oracle Enterprise Manager (OEM) Cloud Control 13c versão 4, atualização 9. AWS Backup – adiciona recursos de backup contínuo e point-time-recovery de instâncias do Amazon RDS O AWS Backup adiciona suporte para backups contínuos e point-time-recovery (PITR) de instâncias do Amazon RDS. Você não precisa mais coordenar janelas de backup, períodos de retenção ou controles de acesso entre o Amazon RDS e o AWS Backup. Você pode realizar a recuperação pontual de suas instâncias do Amazon RDS diretamente com AWS Backup. Amazon Elastic File System – suporte a classe de armazenamento de baixo custo O Amazon EFS agora oferece suporte a classe de armazenamento Single Availability Zone (AZ) (One Zone), reduzindo os custos de armazenamento em 47% em comparação com as classes Amazon EFS Standard. Amazon Elasticsearch Service – agora publica eventos no Amazon CloudWatch e no Amazon EventBridge O Amazon Elasticsearch Service agora publica eventos para Amazon CloudWatch e Amazon EventBridge para fornecer melhor visibilidade do serviço. Eventos para indicar a disponibilidade de uma atualização de software de serviço para um domínio, o início de uma atualização e a conclusão de uma atualização serão incluídos na versão inicial. Compute Amazon EKS – suporte à criação e gerenciamento de add-ons no AWS CloudFormation O Amazon EKS agora permite que você crie e gerencie add-ons EKS usando o AWS CloudFormation. AWS Lambda – adiciona quatro verificações do Trusted Advisor O AWS Lambda agora oferece suporte a quatro novas verificações do Trusted Advisor, sao elas: Taxa de Erro, Timeouts, Runtime depreciado e Alta disponibilidade. Outros Amazon Connect – nova interface de usuário de chat O Amazon Connect Chat adiciona um widget de bate-papo pronto para usar, tornando mais fácil começar a atender seus clientes por meio do bate-papo com apenas alguns cliques. AWS Amplify – Versão Android com suporte ao Kotlin Agora o Amplify Android suporta Kotlin. O novo módulo oferece suporte a todas as categorias de recursos do Amplify Android, incluindo autenticação e armazenamento de dados. https://aws.amazon.com/pt/about-aws/whats-new/2021/03/announcing-kotlin-centric-developer-experience-in-amplify-android/ Quer saber as novidades da AWS das últimas semanas? Leia nosso blog! E acompanhe toda sexta-feira em nosso canal do Youtube nossa live sobre as Novidades da Semana.

Entendendo Docker

O Docker é uma das melhores plataformas para o deploy de uma aplicação. Para entender sua funcionalidade, confira esse artigo em nosso blog!

DNS e as dúvidas quando precisa hospedar uma aplicação – Parte 1

Será que agora vou saber o que estou fazendo quando crio aquela entrada TXT, ou CNAME quando sigo um procedimento? Se você está lendo esse nosso primeiro artigo, deve estar com aquela pulga atrás da orelha, aquele sentimento de: “Será que agora vou saber o que estou fazendo quando crio aquela entrada TXT, ou CNAME quando sigo um procedimento?”. Fique tranquilo, após a leitura, terá todos os conceitos práticos necessários para saber exatamente o que está fazendo quando tiver que realizar qualquer mudança no DNS. E provavelmente você deve ter tido aula (ou apenas passou na prova) em seu curso técnico ou universitário, mas na hora de pôr a mão na massa no DNS, prefere pedir para alguém ou seguir aquela ‘receitinha’. Vamos acabar com isso hoje! Todos que estão lendo devem saber para que serve DNS: traduzir nome para IP, para que usemos nomes e não IP em uma aplicação como browser, shell, cliente de e-mail ou qualquer outro software. Você verá que é muito mais que isso. E muitos devem ter visto (na apresentação do professor) o desenho abaixo: Esqueça ele, por enquanto. Provavelmente você nunca terá que se preocupar com esse conceito, para 99% dos profissionais de TI são dispensáveis, mesmo sendo o único que todo professor ensina =D! Primeiro, é importante entender a realidade em que o DNS foi feito e quais problemas ele tenta resolver. Abaixo uma lista de verdades que explicam muita coisa: DNS foi criado na década de 1980, quando os recursos computacionais eram muito mais limitados que hoje; Foi criado para o controle ser centralizado; E a carga maior ser descentralizada. O segundo conceito, importante, é: Existem dois tipos de servidores DNS: O que todos usam sempre, o DNS ‘Resolver’ e O que temos medo de mexer, o ‘SOA’. O Servidor Resolver (do inglês “Resolvedor”) é aquele que configuramos em nossa placa de rede (ou recebemos via DHCP). Usamos para resolver/consultar nomes DNS de qualquer domínio, para que possamos navegar na Internet ou fazer uso das nossas aplicações. Subir um servidor DNS é muito simples, o roteador WIFI que temos em casa quase sempre faz essa função de servidor DNS para nós. A nossa operadora sempre nos oferece ao menos 2 servidores DNS de consulta, para nosso uso da Internet contratada. Quando configuramos um Servidor Resolver? No roteador da nossa casa; Quando vamos compartilhar Internet em nossas impressoras (isso pode inclusive ajudar no desempenho quando fazemos cache, pois evita consulta na Internet de requisições repetidas). Já os servidores SOA são os servidores responsáveis por responder para Internet (para os servidores de Resolver) cada nome de nosso domínio para IPs. Por exemplo, o domínio darede.com.br que temos registrado para nosso uso, precisa de servidores SOA, também ao menos dois, para que possamos apontar entradas DNS como www, mail, smtp, etc, para os IPs onde essas aplicações rodam. Mas por que sempre ao menos dois? Nem vou responder Nosso servidor DNS de consulta pode verificar algum outro DNS de consulta, como os do provedor, ou resolver diretamente usando o protocolo WHOIS. Esse ai (WHOIS) foi outro que dá aquela dor no estômago quando vê né? Saaaabe o que é…. mas não sabe explicar? 😉 WHOIS é um protocolo utilizado principalmente para: “Informar aos servidores DNS Resolvers quem são os SOA de determinado domínio”. Aqui vem a sacada do DNS. Existem bilhares de entradas nos milhares de SOA, a IANA que controla a internet precisa apenas ter o controle de qual SOA reponde por cada domínio, enquanto nós ficamos responsáveis pelo SOA e suas centenas de entradas. Muitos devem conhecer, mas usando serviços como os abaixo, conseguimos saber quem (who is) o servidor SOA do domínio xpto.com.br, além de outras informações do mantenedor do domínio: registro.br who.is Comando Whois que pode ser instalado no Linux e Windows: Uma vez que o Servidor Resolver sabe quem manda no domínio (xpto.com.br), ele faz a consulta diretamente para o SOA. E agora a pergunta é: “Eu sei que você manda no domínio xpto.com.br. Quem é o www?” Então, o fluxo de uma consulta DNS no dia a dia da Internet fica o seguinte: Cliente pergunta a seu servidor DNS Resolver: “Qual IP de www.darede.com.br?” Servidor DNS Resolver 1, que tem encaminhamento para outro Servidor DNS Resolver (2), pergunta: “Qual IP de www.darede.com.br?” Servidor DNS Resolver 2, que não faz encaminhamento, utiliza o protocolo WHOIS para questionar: “Quem é o SOA de darede.com.br?” Com os IPs do SOA, o Servidor DNS Resolver 2 pergunta à um dos SOAs: Eu sei que você é SOA de darede.com.br, qual o IP de www?” Agora que o Servidor DNS Resolver 2 sabe o IP de www.darede.com.br, ele informa o cliente (ou ao Servidor DNS Resolver 1) qual é o IP e pode ou não configurar para cachear esse nome” Registrar: O Registrar é o órgão responsável por manter a concessão dos domínios usados na Internet. É ele quem configura o WHOIS Server de modo que os servidores DNS Resolvers possam ‘descobrir’ os SOAs de cada domínio. No Brasil, possuímos apenas um registrar, o registro.br, é nele que registramos o domínio para podermos usá-lo. Em outros países podem existir diversos Registrars, nos EUA, por exemplo, os provedores de hospedagem de sites são os próprios registrar. Já por aqui, no Brasil, os provedores de hospedagem de site fazem apenas o papel de SOA, servidor de e-mail, servidor de páginas web, etc. Agora que entendemos o fluxo das consultas DNS na Internet, sabemos que funciona assim, como abaixo: Os clientes consultam seu DNS Resolver procurando pelo IP de www.xpto.com.br; O WHOIS mantém os SOAs que respondem para cada domínio; O SOA mantém a tabela de nomes e IPs do domínio xpto.com.br; Os Servidores DNS Resolvers consultam WHOIS (Quem é) SOA de xpto.com.br; Os Servidores DNS Resolvers consultam ao SOA qual o IP de www.xpto.com.br; Cliente faz a requisição (HTTP, POP, SMTP, etc) ao IP de www.xpto.com.br Até então, falamos apenas de solução de nomes para IP, mas não existe apenas esse tipo de resposta.

Nós usamos cookies para garantir e oferecer a melhor experiência de navegação em nosso site! Mais informações