ADD ANYTHING HERE OR JUST REMOVE IT…

Blog

Protegendo sistemas de energia renovável usando AWS IoT

A Internet das Coisas (IoT) tornou-se cada vez mais prevalente em uma variedade de setores. Além disso, com o número crescente de dispositivos conectados e a quantidade de informações confidenciais transmitidas, a segurança da IoT tornou-se uma das principais preocupações. À medida que a população global continua a aumentar, a procura de energia aumentou para níveis sem precedentes. Em resposta a este desafio premente, as fontes de energia renováveis ​​ganharam imensa importância, aproveitando o poder da tecnologia IoT para impulsionar esta transição transformadora. Moinhos eólicos, instalações hidroelétricas e sistemas fotovoltaicos (PV) emergiram como catalisadores vitais, permitindo a geração e utilização eficiente de energia limpa e sustentável. O AWS IoT oferece um meio seguro e criptografado de conexão de dispositivos e sistemas, garantindo a integridade e a segurança dos dados transmitidos.

Visão geral da solução

Na arquitetura proposta, um sistema de energia renovável é integrado a um dispositivo certificado AWS IoT que utiliza a interface Modbus. Este dispositivo executa o AWS IoT Greengrass e oferece conectividade perfeita. O dispositivo se comunica com o AWS IoT Core por meio dos protocolos MQTT e HTTPS . Os dados são então transmitidos por meio do Amazon Kinesis Data Firehose para entrega eficiente e armazenados no Amazon Simple Storage Service . Para visualizar os dados e obter insights, o Amazon QuickSight é utilizado para criar painéis interativos e visualmente atraentes. O monitoramento e alertas em tempo real podem então ser implementados usandoAWS IoT Device Management , Amazon CloudWatch ou Amazon Simple Notification Service. Além disso, os dados podem ser aproveitados para aplicações de IA/ML para permitir análises avançadas e recursos preditivos.

Figura 1: Solução certificada de Energia Renovável – Power AWS IoT

Segurança na nuvem com AWS IoT

O setor das energias renováveis ​​enfrenta vários desafios no que diz respeito à segurança da IoT. Alguns dos principais desafios e suas soluções AWS IoT correspondentes incluem:

  1. Segurança dos dispositivos: Os dispositivos IoT utilizados em sistemas de energia renovável podem ter vulnerabilidades que podem ser exploradas por agentes mal-intencionados. Essas vulnerabilidades podem resultar de firmware inseguro, falta de patches de segurança ou mecanismos de autenticação fracos. Melhorar a segurança destes dispositivos é crucial para evitar acessos não autorizados ou adulterações. O AWS IoT oferece serviços de segurança de dispositivos que permitem integração segura de dispositivos , gerenciamento de certificados e controle de acesso baseado em políticas . Ele fornece mecanismos de autenticação robustos , atualizações seguras Over-the-air (OTA) e serviços de gerenciamento de vulnerabilidades, como o AWS IoT Device Defender , para solucionar vulnerabilidades de dispositivos.
  1. Interoperabilidade: Os sistemas de energias renováveis ​​consistem frequentemente numa combinação de dispositivos legados e modernos de diferentes fabricantes. Implementar integração e interoperabilidade perfeitas entre esses dispositivos e, ao mesmo tempo, manter a segurança pode ser um desafio. Os dispositivos legados podem não ter recursos de segurança robustos, o que os torna potenciais pontos fracos no sistema. O AWS IoT facilita a integração e a interoperabilidade perfeitas entre dispositivos de diferentes fabricantes por meio de protocolos e APIs padronizados. O AWS IoT Core e o AWS IoT Greengrass fornecem protocolos MQTT , HTTPs e Modbus para comunicação segura, garantindo compatibilidade entre dispositivos legados e modernos, mantendo a segurança.
  1. Segurança de dados : Os sistemas IoT geram grandes quantidades de dados, incluindo informações confidenciais sobre produção de energia, consumo e comportamento do usuário. Proteger a privacidade e a confidencialidade desses dados é fundamental. As organizações devem implementar mecanismos seguros de transmissão, armazenamento e controle de acesso de dados para proteger contra acesso não autorizado ou violações de dados. O AWS IoT fornece segurança de dados completa por meio de criptografia, protocolos seguros de transmissão de dados (como TLS) e mecanismos de controle de acesso.
  1. Segurança de acesso remoto: Muitos sistemas de energias renováveis ​​são monitorizados e geridos remotamente, o que introduz riscos de segurança adicionais. O acesso remoto aos sistemas de controlo e plataformas de monitorização deve ser devidamente protegido para evitar acesso não autorizado ou adulteração. A implementação de protocolos de acesso remoto seguros e autenticação multifatorial pode ajudar a mitigar esses riscos. O AWS IoT oferece acesso remoto seguro a sistemas IoT por meio do uso do AWS Identity and Access Management (IAM) , AWS IoT Core e túnel seguro do AWS IoT .
  1. Melhores práticas de segurança padronizadas . A natureza em rápida evolução da tecnologia IoT resultou na falta de práticas e regulamentações de segurança padronizadas. Isto representa um desafio para as organizações implementarem medidas de segurança consistentes e robustas em todos os seus sistemas de energia renovável. O desenvolvimento de padrões de segurança para todo o setor e o cumprimento das regulamentações relevantes são essenciais para melhorar a segurança da IoT. O AWS IoT segue as práticas recomendadas do setor em termos de segurança e conformidade . Ele fornece diretrizes, estruturas e documentação para ajudar as organizações a implementar medidas de segurança robustas em suas implantações de IoT.
  1. Gerenciamento de dispositivos : os dispositivos IoT em sistemas de energia renovável exigem atualizações de manutenção frequentes durante todo o seu ciclo de vida. Manter os dispositivos atualizados com patches e atualizações de segurança pode ser um desafio para implementar em implantações em grande escala. As organizações devem estabelecer processos eficientes para gerenciar atualizações de dispositivos e patches de segurança para reduzir vulnerabilidades. O AWS IoT fornece serviços de gerenciamento de dispositivos que simplificam o processo de atualização e gerenciamento de dispositivos em grande escala. O AWS IoT Device Management oferece AWS IoT Jobs , que permite que as organizações implantem com eficiência patches de segurança e atualizações de firmware em seus dispositivos IoT.

Ao aproveitar os recursos e serviços de segurança abrangentes fornecidos pela AWS, as organizações podem fortalecer sua postura de segurança e mitigar os riscos associados a vulnerabilidades de firmware e sistema operacional, interoperabilidade, privacidade de dados, acesso remoto e gerenciamento de dispositivos.

Artigo originalmente publicado por Blog AWS

DNX Brasil – Soluções cloud-native

O que é Flux CD?

Desenvolvido pela Weaveworks em 2016,  o Flux CD  é uma ferramenta de entrega contínua GitOps usada para agilizar e automatizar implantações de aplicativos. Tudo começou como um pequeno projeto interno; agora é um  projeto graduado pela CNCF  com uma grande e ativa comunidade de colaboradores e usuários.

Em julho de 2023, o  projeto anunciou  a disponibilidade geral (GA) do Flux CD v2. Este marco indica que as APIs marcadas como GA agora são estáveis ​​e confiáveis ​​para uso em ambientes de produção. Os usuários podem utilizar essas APIs com segurança, sabendo que elas fornecem compatibilidade com versões anteriores, garantindo que as implementações existentes funcionarão perfeitamente como antes. Embora o Flux inclua várias APIs, nem todas alcançaram o status GA no momento. Ele é usado por muitas organizações, incluindo  GitLab , Orange, Ring Central, MediaMarktSaturn e  muitas outras .

O que é FluxCD?

Flux CD é uma ferramenta GitOps e entrega contínua de código aberto projetada para simplificar e automatizar a implantação e o gerenciamento do ciclo de vida de aplicativos e infraestrutura no Kubernetes. Com a tecnologia, desenvolvedores e operadores podem definir declarativamente o estado desejado de seus aplicativos e configurações como código armazenado em um repositório Git.

O Flux CD monitora continuamente o repositório em busca de alterações e aplica atualizações automaticamente ao cluster Kubernetes, garantindo que o estado real corresponda ao estado desejado. Ao adotar a abordagem GitOps, o Flux CD permite que as equipes obtenham um processo de implantação confiável e auditável, ao mesmo tempo que promove a colaboração e a rastreabilidade em diferentes ambientes. Com sua arquitetura flexível e conjunto robusto de recursos, a tecnologia ganhou popularidade como uma ferramenta poderosa para implementar fluxos de trabalho GitOps e obter entrega perfeita de aplicativos em ambientes Kubernetes.

Recursos e capacidades do Flux CD

O Flux CD aproveita o poder dos princípios do GitOps para gerenciar recursos do Kubernetes de maneira eficaz, garantindo implantações contínuas de aplicativos e gerenciamento robusto de configuração. Aqui estão alguns recursos notáveis ​​do Flux CD:

  • Implantações automatizadas:  O programa automatiza as implantações de aplicativos monitorando continuamente o repositório Git em busca de alterações e aplicando atualizações automaticamente ao cluster. Isso elimina a intervenção manual, reduz o erro humano e garante implantações consistentes.
  • Fluxo de trabalho GitOps:  Seguindo a abordagem GitOps, o Flux CD permite que os desenvolvedores definam o estado desejado e as alterações de configuração no Git. Isso promove o controle de versão, a colaboração e a auditabilidade, simplificando o gerenciamento e o rastreamento de alterações.
  • Entrega progressiva:  aproveitando o Flagger, ele permite que as equipes implementem estratégias de entrega progressiva, como implantações canário, lançamentos azul/verde e testes A/B. Isso facilita atualizações seguras e controladas de aplicativos em produção, minimizando riscos.
  • Seguro desde o design:  Desenvolvido com a segurança em mente, incorporando operações baseadas em pull, o princípio de privilégio mínimo e integração perfeita com ferramentas de segurança. Esses recursos ajudam a manter um pipeline de implantação seguro e a proteger recursos confidenciais.
  • Compatível com todas as ferramentas comuns:  o Flux CD integra-se perfeitamente com uma ampla gama de ferramentas populares do Kubernetes, incluindo Kustomize, Helm, GitHub, GitLab, Harbor, webhooks personalizados e validações orientadas por políticas, como OPA e Kyverno. Essa flexibilidade permite que as equipes aproveitem suas ferramentas preferidas e incorporem facilmente o Flux CD em seus fluxos de trabalho existentes.

O Flux CD capacita as equipes a adotar um fluxo de trabalho de CD robusto e escalonável, automatizando implantações, garantindo configurações consistentes, oferecendo suporte à entrega progressiva, priorizando a segurança e fornecendo compatibilidade com várias ferramentas do Kubernetes.

Artigo originalmente publicado por CNCF.IO

DNX Brasil – Soluções cloud-native

Migração

Como gerencio os custos em migração de grande escala?

Ao longo de nossos projetos apoiando organizações diversas em suas jornadas de sucesso para a nuvem, identificamos como a falta de mecanismos de gerenciamento de custos pode afetar a velocidade dos projetos, podendo atrasar ou até parar uma migração. Essa desaceleração prejudica o retorno de investimento (ROI) uma vez que se faz necessário manter dois ambientes simultaneamente por um período mais longo que o previsto. Para evitar que isso aconteça, o projeto de migração deve incorporar os princípios de Gerenciamento Financeiro em Nuvem (CFM do inglês Cloud Financial Management) durante a jornada de migração. Este artigo fornecerá três melhores práticas que observamos que empresas bem-sucedidas adotam ao executar uma iniciativa de migração e modernização em grande escala.

Começando com sua migração

Existem vários motivadores de negócios para as empresas migrarem cargas de trabalho para a AWS. Reduzir os custos ao pagar apenas pelo que utiliza é uma justificativa popular, assim como a melhoria na agilidade do negócio e na produtividade da equipe, uma vez que a migração permite a adoção de novas tecnologias e novos modelos de trabalho. Outros exemplos são a velocidade de lançamento de novas funcionalidades, a oportunidade de modernizar as aplicações corporativas, e a facilidade de expansão para novas regiões.

Na AWS, dividimos a jornada de migração e modernização em três fases:

  1. Avaliação. É aqui que sua empresa construirá o argumento para a mudança. A fase de avaliação é onde a prontidão atual de sua organização para operar na nuvem é avaliada por meio da análise dos seis pilares do AWS Cloud Adoption Framework (CAF): negócios, processos, pessoas, plataforma, operações e segurança. As organizações devem ser capazes de identificar os resultados comerciais desejados e desenvolver um caso comercial de migração durante essa fase.
  2. Mobilização. É aqui que sua empresa irá mapear os benefícios que serão ganhos com a migração. Como parte dessa fase, sua empresa criará um plano de migração e refinará o caso comercial inicial. Também abordará as lacunas na prontidão da organização que foram descobertas na fase de avaliação, com foco na criação de um ambiente básico (Landing Zone), na promoção da prontidão operacional e no desenvolvimento de habilidades em nuvem.
  3. Migração e modernização. É aqui que sua empresa acelerará a transformação em grande escala. Durante essa fase, cada aplicação é projetada, migrada e validada. Para muitas aplicações, a melhor abordagem é migrar rapidamente para a nuvem e depois rearquitetar na AWS. Você pode usar o AWS Application Migration Service (MGN)para transferir rapidamente (re-hospedar) um grande número de servidores da infraestrutura física, virtual ou de nuvem para a AWS.

Os problemas mais comuns que observamos durante as migrações que resultam em aumento de custos são: patrocínio executivo ausente ou ineficaz do lado dos clientes, falta de métricas de sucesso da migração e, finalmente, indefinição dos responsáveis pelo gerenciamento de custos da nuvem.

Como começar a gerenciar custos durante migrações de grande escala

1. Definir métricas de migração | Fase de avaliação

Definir métricas de sucesso dá à sua empresa uma maior capacidade de controlar os custos à medida que a migração progride. Também permite que sua organização discuta essas métricas entre diferentes equipes e perspectivas, resultando em objetivos mais alinhados. Alguns exemplos de métricas de sucesso incluem:

  • Custo e produtividade—porcentagem de gastos com infraestrutura de TI da receita anual, custo por usuário/transações, número de VMs/TBs gerenciadas por administrador
  • Desempenho geral—porcentagem dos programas que alcançam o ROI estimado, número de horas para preparar recursos de TI, satisfação média de clientes/funcionários
  • Resiliência e segurança—porcentagem de disponibilidade crítica de aplicações, número de horas de inatividade não planejada, tempo médio de detecção e resolução
  • Agilidade nos negócios— Tempo médio de lançamento no mercado, número de lançamentos de produção sem problemas, número médio de novas implantações

Como definir métricas de sucesso?

  1. Quais métricas sua organização acompanha atualmente? Essa é uma pergunta essencial a ser respondida se sua organização quiser comparar custo e desempenho antes e depois da migração.
  2. Quais pilares de valor são mais relevantes para sua empresa? O AWS Cloud Value Framework (CVF)recomenda quatro áreas: redução de custos, produtividade da equipe, resiliência operacional e agilidade nos negócios.
  3. Quem são os patrocinadores executivos? Identifique os líderes que serão mais afetados com essa migração. Se ocorrerem imprevistos, identifique quem garantirá recursos e financiamento para manter o projeto em andamento.
  4. Qual é o esforço e o custo necessários para monitorar essas métricas? Avalie as opções de ferramentas e os formatos de visualização. Defina a granularidade e a frequência desejadas para análise dessas métricas.

2. Melhore a visibilidade e a previsibilidade dos custos de migração | Fase de mobilização

Uma migração de larga escala é composta por diversas etapas e uma importante é a criação de um ambiente de gerenciamento de custos. O AWS Migration Acceleration Program (MAP) oferece financiamento para clientes que estão migrando para a AWS e exige que eles identifiquem suas cargas de trabalho adequadamente. Essa é uma boa oportunidade para também definir uma estratégia mais ampla de alocação de custos e monitorar como as equipes estão migrando suas aplicações.

Trabalhe com as equipes financeiras para transformar o caso de negócios de migração em um plano de orçamento de migração aproveitando o AWS Budgets; recomendamos documentar as suposições e atualizá-las ao longo da jornada. Certifique-se de que esses números estejam visíveis em toda a sua empresa criando painéis personalizados (por exemplo, Cloud Intelligence KPI Dashboard), especialmente entre líderes de equipe e patrocinadores executivos. Quando as primeiras ondas de migração começarem, documente as variações de custo e experimente criar uma previsão baseada nos motivadores usando as ondas de migração restantes. Alguns clientes acham útil classificar as aplicações com base no seu tamanho, por exemplo, pequenas, médias e grandes para facilitar a operacionalização do processo de previsão de custos na nuvem. Também recomendamos ativar o AWS Cost Anomaly Detection para evitar surpresas de custo e aprimorar o controle sem atrasar sua migração.

3. Otimize mais cedo para maximizar o ROI e economizar tempo | Fase de migração e modernização

As migrações são um ótimo exercício para avaliar o quão bem sua empresa está utilizando seus recursos. Durante o caso comercial de descoberta e migração de aplicações (fase de avaliação), sua organização compilou informações críticas sobre a utilização da CPU e da memória de várias aplicações durante um período de tempo definido — recomendamos pelo menos 2 semanas de dados para capturar picos e baixas de desempenho.

Certifique-se de que sua empresa esteja aproveitando esses dados para dimensionar corretamente os recursos na nuvem desde o começo. Para computação, recomendamos explorar as instâncias Graviton e Burstable para maximizar a economia e o desempenho. Para armazenamento, verifique se a classe de armazenamento mais recente para EBS (GP3) está sendo utilizada, pois ela fornece uma melhor relação custo/desempenho, e implemente políticas de ciclo de vida de armazenamento em seus buckets do S3.

Para aproveitar ao máximo os benefícios da AWS, sua organização precisará modernizar suas aplicações. Considere as opções de banco de dados gerenciados pela AWS, como RDS, Aurora, Redshift e DynamoDB, e maximize seu retorno. Se for muito complexo ou houver restrições de tempo, migre como está (lift-and-shift) primeiro, mas defina um caminho claro com a empresa para se modernizar depois. Programas como o AWS Database Freedom podem ajudar sua empresa durante esse exercício fornecendo consultoria técnica, suporte à migração e assistência financeira.

Depois que as cargas de trabalho forem migradas e os testes de desempenho concluídos, comunique-se com o responsável pelas finanças da nuvem da sua empresa para adquirir Savings Plans ou Instâncias Reservadas para pagar menos por cargas de trabalho sempre ativas.

AWS: Práticas comprovadas para desenvolver uma estratégia multi-nuvem

 Tópicos sobre multi-nuvem surgem em muitas discussões repletas de confusão, falsa certeza e hesitação. As empresas são bombardeadas com mensagens conflitantes, dizendo-lhes que nunca adotem uma abordagem multi-nuvem ou que não percam a oportunidade porque “todo mundo está migrando para multi-nuvem”.

Há boas razões para seguir ou evitar estratégias multi-nuvem. Este blog se concentra em oito práticas comprovadas para o sucesso com multi-nuvem, incluindo quando e onde faz sentido e como a AWS está posicionada para ajudar as empresas a ter sucesso com suas estratégias multi-nuvem.

Multi-nuvem se refere ao uso simultâneo de mais de um provedor de serviços de nuvem (CSP, do Inglês “Cloud Service Provider”) em uma organização. Mas primeiro, vamos esclarecer algumas terminologias. Usar produtos SaaS, como e-mail ou software de gerenciamento de projetos, junto com um CSP não constitui um ambiente multi-nuvem puro. É uma boa estratégia e pode permitir que você aproveite várias nuvens, mas, no contexto deste blog, não é multi-nuvem para nuvens públicas.

1.Busque multi-nuvem somente para atender às necessidades de negócio legítimas

Embora recomendemos os clientes da AWS a aproveitar ao máximo os benefícios da nuvem escolhendo um provedor de nuvem principal, em que a maioria de suas cargas de trabalho estejam em um único CSP, há motivos válidos pelos quais uma abordagem multi-nuvem pode ser adequada para sua organização. Situações que podem exigir a complexidade de uma infraestrutura multi-nuvem incluem:

Fusões e aquisições

Um ambiente multi-nuvem pode ser criado durante uma transação de fusão e aquisição, quando a empresa adquirente está em um CSP principal e a empresa adquirida está em outro. Bem-vindo a multi-nuvem! O que vem a seguir não é fácil. O engenheiro em mim quer dizer consolide — menos é mais. Entretanto, pode não fazer sentido consolidar imediatamente. Sua estratégia geral de integração de tecnologia e abordagem de avaliação devem ser refletidas nesse processo; torne-as parte de seu manual de fusões e aquisições. O que você transfere de um provedor para outro, quando você o move e o que você mantém podem variar. Mas estabelecer uma estratégia de integração é tão importante quanto impedir que várias instâncias do ERP funcionem para sempre.

Desejo de aproveitar as capacidades diferenciadas de longo prazo de outro CSP

O medo de ficar de fora faz com que algumas empresas queiram um pouco de cada nuvem. Acreditamos que as empresas são melhor atendidas selecionando um CSP que possa resolver a maioria dos desafios de sua organização, em vez de adotar uma estratégia mais difusa. Uma estratégia 80/20 é uma boa maneira de pensar sobre isso. Focar nos 80% (e não nos 20%) pode resultar em melhor eficiência, retenção de talentos e valor. Embora possa haver cargas de trabalho especializadas que exijam uma determinada tecnologia, essas situações devem ser tratadas caso a caso, onde benefícios e compensações possam ser considerados.

As empresas podem pensar na “carga de trabalho certa para a nuvem certa”. Certifique-se de que a análise do que constitui a “nuvem certa” vá além das considerações para uma carga de trabalho específica. Pergunte como a distribuição dessa carga de trabalho em um CSP adicional afeta a complexidade geral. Eu recomendo que você faça uma análise cuidadosa de preço e desempenho de cada carga de trabalho em cada nuvem para garantir que o valor seja suficiente para justificar isso.

Multi-nuvem na holding e nuvem primária na empresa operacional/linha de negócios

Para organizações de Private Equity ou grandes holdings com várias empresas no portfólio, pode fazer sentido que cada empresa do portfólio tenha sua própria estratégia de CSP (frequentemente impulsionada por fusões e aquisições). A concentração de seus gastos em um único provedor de nuvem pode permitir que você aproveite descontos por volume e incentivos para reservar instâncias. Mas as outras deficiências relacionadas a talentos, cargas de trabalho fragmentadas e maiores riscos são amplamente contornadas, pois cada organização opera de forma independente.

2. Esteja atento aos mitos da multi-nuvem

Mito 1: Todos estão adotando estratégias multi-nuvem

Empresas de consultoria e empresas de mídia divulgaram resultados mistos sobre até que ponto as empresas colocam suas cargas de trabalho em várias nuvens. Nossa recomendação é fazer a coisa certa para sua empresa e tomar decisões com base em custos e riscos, independentemente de quão predominante essa prática possa parecer.

Mito 2: Multi-nuvem reduz o risco de dependência de fornecedores

Algumas empresas citam o medo da dependência de fornecedores (do ponto de vista contratual e tecnológico) como a principal razão para buscar estratégias multi-nuvem. Em ambientes de data centers locais, as empresas são motivadas a grandes investimentos de capital de longo prazo, geralmente regidos por contratos de serviço longos e complicados. Essas são grandes decisões de porta que abre para um lado (ou seja, difíceis e caras de reverter) para as empresas e exigem um forte foco na redução de riscos.

A nuvem é diferente. As empresas que executam a mesma carga de trabalho em vários provedores de nuvem geralmente se sentem pressionadas a usar o “menor denominador comum” — elas devem considerar as limitações. Em alguns casos, elas podem evitar esse problema executando cargas de trabalho diferentes com provedores diferentes.

Eu recomendo que as empresas trabalhem para entender completamente seus possíveis custos de mudança se precisarem sair do CSP existente e a probabilidade de isso ocorrer. A partir daí, é possível definir a melhor abordagem para reduzir a dependência avaliando o custo e a probabilidade de precisar alterar os CSPs versus os benefícios estratégicos de ter um provedor principal.

Também é importante observar que a nuvem é inerentemente mais aberta do que o modelo tradicional de TI, e não acreditamos que multi-nuvem seja necessária para evitar a dependência. Veja como a AWS cria serviços em tecnologias e padrões de código aberto, como SQL, Linux e contêineres. Os clientes têm a opção de usar serviços gerenciados de código aberto—como o Amazon Relational Database Service (RDS) para MySQL e o Amazon RDS para PostgreSQL, ou componentes básicos—e pagam conforme o uso; não há compromisso antecipado e de longo prazo. Nós nos empenhamos para criar serviços que os clientes queiram usar, mas se um cliente optar por se mudar, a AWS torna isso o mais simples possível. A AWS fornece várias ferramentas de migração não apenas para ajudar os clientes a mover recursos do data center local para a AWS com mais facilidade, mas também para movê-los de volta para o data center local ou para outras nuvens, se os clientes assim o desejarem.

Mito 3: Multi-nuvem melhora a disponibilidade

Reduzir o risco de interrupção do serviço se o CSP principal de uma empresa tiver uma indisponibilidade é um motivo cada vez mais raro para adotar uma estratégia multi-nuvem. Nesses casos, acredita-se que uma empresa pode mudar suas cargas de trabalho de forma simples e sem dificuldade para um CSP secundário.

O failover multi-nuvem presume que um aplicativo pode ser transferido para outra nuvem. Como muitas organizações descobriram, isso é extremamente desafiador. Conseguir isso exige que a empresa mantenha a portabilidade total entre dois CSPs, adicionando complexidade, risco e trabalho adicional com a crença de que o failover é possível.

A Distinguished Vice President e analista Lydia Leong, da Gartner, resumiu os problemas com o failover multi-nuvem em seu tweet: “O failover multi-nuvem é complexo e caro a ponto de ser quase sempre impraticável, e não é uma forma especialmente eficaz de lidar com os riscos de resiliência da nuvem”. O problema em fazer o failover funcionar são todos os diferenciais do CSP (por exemplo, as diferentes arquiteturas e recursos de rede, diferentes recursos de armazenamento, serviços proprietários de nível superior, camadas de banco de dados, serviços de aprendizado de máquina, além de diferentes recursos de segurança, etc.). Quando as cargas de trabalho estão espalhadas entre os CSPs, uma falha em qualquer um dos CSP pode causar uma interrupção. Nesse caso, a distribuição de cargas de trabalho entre os CSPs, na realidade, aumenta o risco.

Em vez disso, recomendo que as empresas reduzam os riscos “implementando e simplificando”. Escolha uma carga de trabalho ou aplicativo específico para uma única nuvem, migre-a, domine-a, elimine custos e riscos e repita. Incentive um aprendizado mais profundo dos recursos e capacidades específicos do CSP por meio de treinamento e aproveite os serviços e ferramentas de nível superior específicos do CSP que já estão integrados. Por fim, e talvez o mais importante, tire proveito das Regiões e Zonas de Disponibilidade da AWS. Os recursos da AWS nessa área já oferecem aos clientes da AWS excelentes recursos para garantir soluções altamente disponíveis e confiáveis.

Mito 4: Multi-nuvem oferece melhores preços

A competitividade de preços pode ser o argumento mais fraco de todos para a multi-nuvem. As experiências das organizações com contratos complicados e caros de software ou data center que as prendem por vários anos as tornaram cautelosas ao adquirir serviços de TI. As abordagens tradicionais de compras não se adaptaram às compras pagas conforme o uso, aos descontos por volume ou à realidade da concorrência de preços na nuvem. (A AWS reduziu os preços 129 vezes desde o seu lançamento.)

O maior fator isolado da redução de custos é o quão bem gerenciado e otimizado é o ambiente de nuvem de uma empresa. Uma empresa pode obter uma melhor otimização de custos trabalhando principalmente com um provedor cujos serviços oferecem vantagens de preço-desempenho (como instâncias de computação baseadas em chips personalizados, como o AWS Graviton) e têm soluções superiores de gerenciamento financeiro na nuvem. De acordo com um estudo de 2021 do Grupo Hackett com mais de 1.000 organizações, os gastos com infraestrutura como porcentagem dos gastos totais com TI foram 20% menores para os clientes da AWS do que para organizações multi-nuvem.

Nossa experiência mostrou que as empresas não preveem o custo e a complexidade adicionais de operar em várias nuvens, nem os comparam adequadamente com o ganho percebido em um contrato direto de fornecimento.

3. Tenha uma estratégia clara e governança para apoiá-la

A simples decisão de adotar uma estratégia multi-nuvem é insuficiente; você também deve estabelecer uma estratégia para cumprir seu objetivo de multi-nuvem, incluindo uma governança clara de quais cargas de trabalho irão para onde e por quê. Critérios de avaliação devem ser usados para otimizar as cargas de trabalho e suas dependências. Se deixada para os indivíduos, a dispersão descoordenada entre os CSPs provavelmente corroerá qualquer valor que a estratégia multi-nuvem buscava alcançar. Avalie o desempenho da carga de trabalho do CSP regularmente e use sua avaliação como um elemento chave para a seleção, os critérios e o uso futuro do CSP.

É crucial ter visibilidade abrangente do número total de serviços, aplicativos e componentes usados em toda a empresa como parte de uma estratégia geral de governança. Parte integrante disso é uma estratégia robusta de marcação (do Inglês “tagging”) que abrange todos os CSPs e estabelece claramente propriedade, uso e ambiente (por exemplo, desenvolvimento, controle de qualidade, pré-produção e produção) para 100% dos recursos implantados. Tudo deve ser marcado para um proprietário; se não estiver marcado ou um proprietário não puder ser identificado, deve ser removido. Isso codifica as regras de governança e automatiza a fiscalização em vez de criar obstáculos ao progresso (grades de proteção, não portões). O custo, as operações e a segurança devem ser rastreados, monitorados e aplicados da mesma maneira, com a mesma profundidade de dados e transparência entre os CSPs. É preferível uma única ferramenta para uma determinada necessidade que possa operar entre CSPs.

4. Não distribua cargas de trabalho contíguas entre CSPs

Na minha opinião, fluxos de trabalho que abrangem vários CSPs introduzem complexidade, risco e custo desnecessários, ao mesmo tempo em que complicam o suporte, a implantação e a arquitetura com pouco valor agregado. Cargas de trabalho contíguas geralmente envolvem grandes volumes de dados que precisam ser processados e analisados juntos. Quando os dados são distribuídos entre vários provedores de nuvem, eles podem criar desafios na movimentação, sincronização e também na manutenção de sua consistência. Além disso, gerenciar uma carga de trabalho contígua em vários CSPs pode ser complexo e demandante. Ela exige lidar com diferentes APIs, interfaces de gerenciamento, modelos de segurança e processos operacionais para cada CSP. Essa complexidade aumenta as chances de erros, aumenta a sobrecarga operacional e pode prejudicar a agilidade e a escalabilidade.

Critérios específicos e princípios orientadores devem ser estabelecidos ao avaliar esse tipo de design e necessidade de negócio.

5. Os aplicativos devem permanecer com seus dados transacionais

Deve-se tomar cuidado quando os desenvolvedores precisarem mover grandes volumes de dados entre aplicativos em diferentes nuvens, especialmente com computação/aplicativos implantados em um CSP e armazenamento de dados em outro. Essa situação pode adicionar complexidade e latência que podem anular os benefícios percebidos.

Os critérios de decisão para determinar um CSP para uma carga de trabalho devem incluir uma visão de longo prazo da integração dessa carga de trabalho com outras. Os dados serão necessários para análise avançada ou aprendizado de máquina além do escopo atual? Os serviços fornecidos serão amplamente consumidos em outros CSPs ou estarão isolados para as cargas de trabalho desse CSP? Para obter mais orientações e um modelo de decisão para considerações de implantação, confira o blog Multi-cloud: From Buzzword to Decision Model, do meu colega Gregor Hohpe.

6. Os contêineres podem ajudar, mas entenda que não resolvem todos os casos de uso

Usar contêineres geralmente é uma boa ideia para qualquer aplicativo moderno e eles ajudam com muitos elementos de portabilidade. Os contêineres são plataforma-agnósticos, o que significa que podem ser executados em qualquer plataforma de nuvem ou infraestrutura que ofereça suporte à conteinerização. Isso permite que você desenvolva e empacote seu aplicativo uma vez e o implante de forma consistente em vários provedores de nuvem ou data centers locais sem modificações significativas. Mas tenha cuidado, pois os contêineres não funcionam em todos os casos (por exemplo, grandes aplicativos monolíticos) nem resolvem todos os problemas (especialmente dados, políticas e segurança) relacionados à portabilidade entre CSPs.

 

7. Tenha um único Centro de Excelência em Nuvem (CCOE), mas especialize-se dentro dele

Como aconselhamos muitos clientes da AWS, você deve utilizar um CCOE (do Inglês “Cloud Center of Excellence”) em sua organização para fornecer liderança, padronização e aceleração de sua jornada na nuvem. Quando se trata de multi-nuvem, descobrimos que as empresas mais bem-sucedidas têm um único CCOE, mas especializam nesse CCOE as habilidades, as ferramentas e os mecanismos específicos para um CSP. Descobrimos que quando os clientes da AWS têm vários CCOEs para cada CSP, isso geralmente leva à divergência, reengenharia e desperdício, ao invés de uma abordagem mais coordenada por meio de um único CCOE.

 

8. Certifique-se de que a segurança seja sempre a principal prioridade

Multi-nuvem dificulta a segurança ao aumentar o risco de acesso não autorizado ou violação de dados. Multi-nuvem força as empresas a lidar com vários modelos de segurança através dos CSPs em áreas como gestão de identidade, segurança de rede, gestão de ativos e logs de auditoria.

Essa complexidade dificulta a transparência e aumenta a carga sobre as equipes de segurança, elevando o risco. Embora não sejam exclusivas de multi-nuvem, várias práticas básicas de segurança se tornam mais importantes: (1) transferir a segurança para o ciclo de desenvolvimento, automatizando-a e incorporando-a aos pipelines de entrega, ambientes de nuvem e prioridades da equipe; e (2) criptografar dados em repouso e em trânsito dentro ou entre CSPs.

Uma abordagem útil para a adoção de multi-nuvem é criar um único destino para os dados de segurança (ou seja, uma única visão). Amplie isso com ferramentas nativas da nuvem desenvolvidas por cada CSP para apresentar esses dados de forma que façam sentido nesse ambiente.

Conclusão

Para a maioria das organizações, uma estratégia de nuvem principal fornece o máximo valor por meio de simplicidade, foco e mitigação de riscos, ao mesmo tempo em que permite que as empresas aprofundem suas parcerias e conhecimentos práticos sobre seu principal CSP e serviços. Isso aumenta a capacidade da organização de aproveitar serviços mais sofisticados e atrair e reter melhor seus talentos, ao mesmo tempo em que agrega valor às empresas com mais rapidez.

Uma abordagem multi-nuvem pode fazer sentido, mas as empresas devem garantir que sua decisão de adotá-la seja orientada pelas necessidades de negócio e feita com uma compreensão clara das vantagens e desvantagens envolvidas. Nesses casos, recomendamos um modelo de nuvem focado em aplicativos e fluxos de trabalho de negócios que possam ser fornecidos de um único CSP, que provavelmente não compartilhem dados entre os CSPs e tenham uma governança clara de qual carga de trabalho vai para onde.

Artigo originalmente publicado por Blog AWS

DNX Brasil – Soluções cloud-native

Passos para Realizar uma Revisão de Well-Architected

Em um mundo cada vez mais digital e orientado por tecnologia, a arquitetura de nuvem desempenha um papel fundamental no sucesso das empresas. A AWS Well-Architected Framework oferece diretrizes valiosas para projetar, construir e manter aplicações na nuvem de maneira eficiente, segura e confiável. Realizar uma revisão de Well-Architected é uma etapa crucial para garantir que sua infraestrutura na nuvem esteja alinhada com as melhores práticas. Neste artigo, exploraremos os passos essenciais para conduzir uma revisão de Well-Architected de forma eficaz. 

Passo 1: Avaliar os Pilares da Arquitetura 

O Well-Architected Framework baseia-se em cinco pilares fundamentais: Excelência Operacional, Segurança, Confiabilidade, Eficiência de Performance e Otimização de Custo. Para iniciar a revisão, é essencial entender esses pilares e sua importância para as aplicações na nuvem. Avalie como sua arquitetura atual aborda cada pilar e identifique possíveis lacunas ou áreas de melhoria. 

Passo 2: Definir o Escopo da Revisão 

Antes de prosseguir, determine qual parte específica de sua infraestrutura na nuvem será revisada. Pode ser um aplicativo inteiro, um componente crítico ou até mesmo um projeto piloto. Definir o escopo da revisão ajudará a concentrar os esforços e a garantir que nenhum aspecto importante seja deixado de lado. 

Passo 3: Coletar Dados e Informações Relevantes 

Reúna informações detalhadas sobre a arquitetura, recursos, fluxos de trabalho e requisitos de desempenho de sua aplicação na nuvem. Isso inclui métricas de utilização, padrões de tráfego, estrutura de custos e outras métricas relevantes. Quanto mais dados você tiver, mais precisa será sua avaliação. 

Passo 4: Utilizar Ferramentas de Avaliação 

A AWS oferece ferramentas como o AWS Well-Architected Tool e o AWS Trusted Advisor, que podem automatizar partes do processo de revisão. Essas ferramentas analisam sua infraestrutura e fornecem recomendações específicas para melhorias com base nas melhores práticas do Well-Architected Framework. 

Passo 5: Identificar Melhorias e Definir Ações Corretivas 

Com base nas informações coletadas e nas análises das ferramentas, identifique áreas onde sua arquitetura pode ser aprimorada. Isso pode incluir otimizações de custo, melhorias de segurança, ajustes de desempenho ou aprimoramentos em qualquer um dos pilares da arquitetura. Defina ações corretivas claras e priorize-as de acordo com sua importância. 

Passo 6: Desenvolver um Plano de Implementação 

Após identificar as melhorias necessárias, crie um plano detalhado para implementá-las. Isso deve incluir os passos específicos a serem seguidos, os recursos necessários e um cronograma realista. Lembre-se de envolver as equipes relevantes, como desenvolvedores, engenheiros de operações e especialistas em segurança, para garantir uma implementação eficaz. 

Passo 7: Monitorar e Iterar 

A revisão de Well-Architected não é um processo único; é um ciclo contínuo de avaliação e melhoria. Uma vez que as melhorias sejam implementadas, monitore constantemente os resultados e ajuste sua arquitetura conforme necessário. À medida que sua aplicação evolui, novos desafios podem surgir, tornando a iteração uma parte vital do processo. 

Para quem é Well-Architected Review? 

A avaliação da Well-Architected Review pode ser executada em qualquer tipo de empresa, desde startups até empresas enterprises que buscam avaliar seu ambiente. O AWS Well-Architected Framework ajuda você a compreender os prós e contras das decisões que foram tomadas na arquitetura de seu ambiente cloud AWS. 

Na DNX Brasil, estamos comprometidos em oferecer a avaliação Well-Architected Review de maneira abrangente e adaptada às necessidades individuais de nossos clientes. Independentemente do tamanho ou do estágio de desenvolvimento de sua empresa, nossa equipe de arquitetos certificados pela AWS está pronta para auxiliar na análise detalhada de suas arquiteturas na nuvem. Através de nossa parceria, você terá acesso a uma avaliação criteriosa, seguida por recomendações precisas e um roteiro estratégico para aprimorar continuamente sua infraestrutura. Seja identificando áreas de otimização de custos, reforçando a segurança ou melhorando a confiabilidade, nossa abordagem visa capacitar sua organização a extrair o máximo valor de sua presença na AWS. 

 

Chegamos a um ponto sem retorno no gerenciamento de dependências de software?

Os problemas de segurança da cadeia de fornecimento de software  estão afetando fortemente todo o ecossistema OSS; não passa um dia sem que um incidente de segurança  aconteça, afetando usuários e empresas desatentos com software construído com os padrões modernos de  ultracombinabilidade  feitos de um denso número de dependências externas em múltiplas camadas.

De acordo com a pesquisa realizada pela Sonatype em seu relatório anual  State of Software Supply Chain , os ataques à cadeia de suprimentos têm um aumento médio de  742% ao ano.

Existem várias razões por trás disso, como a maior demanda do mercado por software em todos os setores e o tremendo crescimento do modelo de código aberto; estima-se que 90%  das empresas utilizam código aberto.

Outro aspecto que sustenta esta situação é a descoberta e a evolução de ataques cibernéticos especificamente concebidos para anexar a cadeia de abastecimento, como a Confusão de Dependência, o Typosquatting e o seu Primo-Brandjacking, as Injecções de Código Malicioso e o Protestware.

De acordo com  dados da indústria , o número médio de dependências transitivas (indiretas) para um projeto JavaScript no GitHub é  683.

As dependências continuam sendo um dos mecanismos preferidos para criar e distribuir pacotes maliciosos, e ainda é relativamente fácil forjá-los.

Em fevereiro de 2022, o GitHub  introduziu a autenticação obrigatória de dois fatores para os 100 principais mantenedores de npm  e  o PyPA está trabalhando para reduzir a dependência de setup.py , que é um elemento-chave para como esses ataques podem ser lançados ao mesmo tempo em que promovem  a adoção de 2FA usando um painel público  ( Fonte:  https://www.sonatype.com/state-of-the-software-supply-chain/open-source-supply-demand-security )

Para ver os números em ação, testaremos duas das linguagens mais utilizadas em 2022, que são Javascript e Python, e por fim um projeto baseado em Microsserviços composto por diversas linguagens.

JavaScript 

Indo inicializar uma  base de código Javascript NextJS simples   usando as configurações padrão fornecidas:

❯ npx create-next-app@latest
✔ What is your project named? … supply-chain
✔ Would you like to use TypeScript with this project? … No / Yes
✔ Would you like to use ESLint with this project? … No / Yes
✔ Would you like to use Tailwind CSS with this project? … No / Yes
✔ Would you like to use `src/` directory with this project? … No / Yes
✔ Use App Router (recommended)? … No / Yes
✔ Would you like to customize the default import alias? … No / Yes
Creating a new Next.js app in /Users/paolomainardi/temp/supply-chain.

Using npm.

Initializing project with template: app-tw

Installing dependencies:
- react
- react-dom
- next
- typescript
- @types/react
- @types/node
- @types/react-dom
- tailwindcss
- postcss
- autoprefixer
- eslint
- eslint-config-next

added 344 packages, and audited 345 packages in 4s

127 packages are looking for funding
  run `npm fund` for details

5 moderate severity vulnerabilities

To address all issues, run:
  npm audit fix

Run `npm audit` for details.
Initialized a git repository.

Success! Created supply-chain at /dev/supply-chain

Uma coisa a observar é que um aplicativo recém-instalado já possui  5 vulnerabilidades de gravidade moderada . Essa forma de entregar mensagens é arriscada porque inadvertidamente ensina nosso cérebro a ignorá-las, sejam elas úteis ou não. Na próxima vez que um aviso como esse aparecer, ele poderá passar despercebido. Deveríamos melhorar a forma como apresentamos estas mensagens.

Vamos agora contar as dependências:

❯ tree -d supply-chain/node_modules -L 1 | tail -n 1
298 directories

Para imprimir um Hello World com NextJS, precisamos trazer  298 dependências  com  5 vulnerabilidades conhecidas .

Empacotamos o aplicativo em um contêiner OCI, conforme  explicado aqui no documento oficial :

❯ curl -Lo Dockerfile https://raw.githubusercontent.com/vercel/next.js/canary/examples/with-docker/Dockerfile

❯ # Edit this file according to the documentation to produce a standalone build.
// next.config.js
module.exports = {
  // ... rest of the configuration.
  output: 'standalone',
}

❯ docker build -t supply-chain-next-docker .
[+] Building 33.0s (19/19) FINISHED
=> => naming to docker.io/library/supply-chain-next-docker                                  0.0s

❯ syft supply-chain-next-docker > deps
 ✔ Loaded image
 ✔ Parsed image
 ✔ Cataloged packages      [282 packages]

❯ grep apk deps | wc -l
17

❯ grep npm deps | wc -l
249

# Scan for known vulnerabilities.
❯ grype supply-chain-next-docker
 ✔ Loaded image
 ✔ Parsed image
 ✔ Cataloged packages      [282 packages]
 ✔ Scanning image...       [1 vulnerabilities]
   ├── 0 critical, 0 high, 1 medium, 0 low, 0 negligible
   └── 1 fixed
NAME    INSTALLED  FIXED-IN  TYPE  VULNERABILITY        SEVERITY
semver  7.3.8      7.5.2     npm   GHSA-c2qf-rxjj-qqgw  Medium

Nesse caso, a compilação produzida pelo  NextJS  é um pouco menor em termos de pacotes ( por causa do modo autônomo ), e a imagem base Alpine adiciona apenas 17 pacotes no momento sem nenhuma vulnerabilidade conhecida.

Esta é uma imagem pronta para ser enviada em produção, e conta com  282 pacotes (NPM + Alpine)  sem nenhuma modificação feita por nós; é apenas a estrutura básica.

Os grandes tamanhos de pacotes no NodeJS se devem principalmente à biblioteca padrão JavaScript relativamente pequena e à filosofia inspirada no Unix por trás do NodeJS, conforme explicado nesta  postagem do blog .

A filosofia mencionada às vezes pode levar a distorções, como no caso de pacotes como “left-pad” se tornarem parte de muitos pacotes (mesmo como uma dependência transitiva). Isso quase causou  o colapso da internet  quando o autor decidiu removê-lo devido a uma disputa de nome. Você pode ler mais sobre isso aqui.

Acho que este evento também inspirou este famoso   meme do xkcd :

Imagem mostrando a construção da infraestrutura.  Um pequeno pedaço foi adicionado por alguma pessoa aleatória em Nebraska e tem sido mantido ingratamente desde 2003 e contém toda a infraestrutura digital moderna

Pitão 

É a segunda linguagem mais usada e de crescimento mais rápido, com mais de 22% ano após ano (fonte:  https://github.blog/2023-03-02-why-python-keeps-growing-explained/ ).

Para comparar com Javascript, usarei Django como caso de teste.

❯ cat app/requirements.txt
Django==4.2.2

❯ cat app/Dockerfile
FROM python:3.10-alpine
EXPOSE 8000
WORKDIR /app
COPY requirements.txt /app
RUN pip3 install -r requirements.txt --no-cache-dir
COPY . /app
ENTRYPOINT ["python3"]
CMD ["manage.py", "runserver", "0.0.0.0:8000"]

❯ syft django-web
 ✔ Loaded image
 ✔ Parsed image
 ✔ Cataloged packages      [46 packages]

❯ grep apk deps | wc -l
 38
❯ grep python deps | wc -l
 8
❯ grep binary deps | wc -l
 2

# Scan for known vulnerabilities.
❯ grype django-web
 ✔ Vulnerability DB        [no update available]
 ✔ Loaded image
 ✔ Parsed image
 ✔ Cataloged packages      [46 packages]
 ✔ Scanning image...       [2 vulnerabilities]
   ├── 0 critical, 1 high, 1 medium, 0 low, 0 negligible
   └── 0 fixed

NAME    INSTALLED  FIXED-IN  TYPE    VULNERABILITY   SEVERITY
pip     23.1.2               python  CVE-2018-20225  High
python  3.11.4               binary  CVE-2007-4559   Medium

A situação aqui é melhor; Django tem apenas 8 dependências (pelo menos as descobertas por  Syft ).

Como Python é a melhor linguagem para IA, eu queria tentar adicionar  PyTorch  como uma dependência do projeto:

❯ cat app/requirements.txt
Django==4.2.2
--extra-index-url https://download.pytorch.org/whl/cpu
torch
torchvision
torchaudio

# We need a glibc base image to install pytorch.
❯ cat app/Dockerfile
FROM python:3.11.4
...

❯ grep binary deps | wc -l
 2
❯ grep python deps | wc -l
 35
❯ grep deb deps | wc -l
 429

❯ grype django-web
 ✔ Vulnerability DB        [no update available]
 ✔ Loaded image
 ✔ Parsed image
 ✔ Cataloged packages      [455 packages]
 ✔ Scanning image...       [678 vulnerabilities]
   ├── 1 critical, 41 high, 111 medium, 30 low, 464 negligible (31 unknown)
   └── 3 fixed

Mesmo com o PyTorch e suas dependências, o número de pacotes Python é relativamente pequeno, apenas 35; o que é muito maior agora é o número de pacotes transportados da imagem base do Debian (necessários para usar PyTorch em vez de Alpine), para ser mais preciso, 429  pacotes  com um  número absurdo de vulnerabilidades conhecidas , mesmo que esta imagem seja o  Python estável mais recente Versão 3.11 .

Arquitetura e dependências de microsserviços 

Para este teste, usarei um projeto muito interessante do GCP:  Online Boutique é um aplicativo de demonstração de microsserviços  que  prioriza a nuvem e tem como objetivo principal demonstrar o uso de tecnologias como Kubernetes, GKE, Istio, Stackdriver e gRPC e é composto por 11 microsserviços  em  5 linguagens diferentes  : Go, Node.js, Python, Java, C#

  • Outra suposição importante a ser feita aqui é que este projeto devido à sua natureza é mais otimizado nas partes da nuvem do que nos aspectos de desenvolvimento, como dependências
# Calculate packages and vulnerabilities for each microservice.

DOCKER_IMAGES="gcr.io/google-samples/microservices-demo/emailservice:v0.8.0,
gcr.io/google-samples/microservices-demo/checkoutservice:v0.8.0,
gcr.io/google-samples/microservices-demo/recommendationservice:v0.8.0,
gcr.io/google-samples/microservices-demo/frontend:v0.8.0,
gcr.io/google-samples/microservices-demo/paymentservice:v0.8.0,
gcr.io/google-samples/microservices-demo/productcatalogservice:v0.8.0,
gcr.io/google-samples/microservices-demo/cartservice:v0.8.0,
gcr.io/google-samples/microservices-demo/loadgenerator:v0.8.0,
gcr.io/google-samples/microservices-demo/currencyservice:v0.8.0,
gcr.io/google-samples/microservices-demo/shippingservice:v0.8.0,
gcr.io/google-samples/microservices-demo/adservice:v0.8.0"

for image in $(echo $DOCKER_IMAGES | sed "s/,/ /g")
do
  echo "Scanning image: $image"
  syft $image > /dev/null
  grype $image > /dev/null
done%

Vamos eliminar as vulnerabilidades abaixo das altas e formatar os dados em uma tabela:

Microsserviço Linguagem Pacotes ≥ Altas vulnerabilidades
serviço de e-mail Pitão 152 39
serviço de checkout Ir 52 2
serviço de recomendação Pitão 147 39
front-end Ir 71 8
serviço de pagamento Node.js 626 5
catálogo de produtosserviço Ir 51 5
serviço de carrinho C# 25 0
gerador de carga Python/Gafanhoto 137 33
serviço de moeda Node.js 649 5
serviço de entrega Ir 37 3
serviço de anúncios Java 112 19
TOTAL 2059 158

Aqui podemos ver toda a superfície deste aplicativo baseado em microsserviços, um aglomerado de linguagem de programação e dependências de sistema operacional, para  2.095 pacotes  com  158 vulnerabilidades conhecidas altas e críticas  , números enormes.

Node.js, novamente, é o que mais exige dependências. Em vez disso, o Python tem menos dependências, mas mais vulnerabilidades abertas; Java está muito próximo do Python com os números.

O vencedor claro neste cenário é o C#, apenas 25 bibliotecas agregadas e 0 vulnerabilidades.

Pensamentos finais 

Sonatype resume bem o crescimento ininterrupto do ecossistema OSS:

Gráfico de tabela mostrando estatísticas da cadeia de suprimentos de software, 2022

Os dados mostram que:

  1. O desenvolvimento de código aberto está mais florido do que nunca; OSS venceu .
  2. O crescimento está espalhado por todos os maiores ecossistemas, o que é muito bom para toda a indústria; não existe um ator monopolista.
  3. Um ecossistema médio possui  3,3 milhões de projetos , cada um com uma média de  14 versões lançadas  anualmente, o que é bom porque o projeto é mantido e ruim porque requer manutenção.

Hoje estamos expostos a uma grande complexidade escondida por ferramentas muito poderosas.

Obter uma nova dependência é uma tarefa que exige muito pouco esforço; com um gerenciador de pacotes moderno, podemos montar sistemas operacionais e aplicativos inteiros compostos por centenas de milhares de dependências externas, com apenas um ou poucos comandos fáceis, e isso é francamente poderoso e assustador

Em 1984, Edsger Wybe Dijkstra no artigo “ Sobre a natureza da Ciência da Computação ” disse que  “A simplicidade é uma grande virtude mas requer muito trabalho para alcançá-la e educação para apreciá-la. E para piorar: a complexidade vende melhor”.

Pela minha experiência pessoal, em muitos anos neste setor, um dos maiores inimigos desta indústria são as soluções de tamanho único que podem resolver e corrigir magicamente qualquer problema, em qualquer contexto, no que diz respeito à complexidade do problema, este nunca é o caso, é melhor focar na complexidade do problema.

Por exemplo, se eu precisar enviar um site estático com um monte de HTML e CSS, nunca terei a necessidade de implantá-lo em um cluster Kubernetes; em vez disso, tudo que preciso é de um servidor da web não tão sofisticado.

O mesmo se aplica aos microsserviços, nem sempre é o ajuste certo, mesmo quando o cenário pode sugerir o contrário, há casos importantes como  Istio  ou  Amazon Prime Video.

E agora, voltando à questão deste artigo.

A resposta é sim,  já ultrapassamos o ponto sem volta e isso não é necessariamente uma coisa ruim, pelo contrário, acho que estamos vivendo a era de ouro desta indústria e temos tantas oportunidades como profissionais ou cientistas como nunca antes. .

No entanto, isto também significa que a maioria dos projetos depende de grandes quantidades de código que podem ser vulneráveis ​​ou maliciosos. Isto causa estresse para os desenvolvedores e representa riscos significativos para todo o setor. Em alguns casos, pode até pôr em perigo a segurança nacional, como demonstrado pelo  caso Solarwinds .

Hoje, a criação de um novo produto de software deve levantar algumas questões fundamentais, tais como:

  • Como podemos confiar que alguém diferente de nós sempre poderá atuar como um bom ator?
  • Como podemos ter certeza de que todo o código do qual dependemos é feito exclusivamente para fazer o que afirma?
  • Como podemos ter certeza de que o software não foi adulterado em um dos pontos da  cadeia de abastecimento ?

Em 1984, Ken Thompson, no famoso artigo “ Reflexões sobre a confiança na confiança ”, basicamente fez as mesmas perguntas, e a moral, que considero ainda válida, diz que:

  • “Você não pode confiar em um código que você mesmo não criou totalmente. Nenhuma verificação ou escrutínio no nível da fonte protegerá o uso de código confiável. Até que ponto se deve confiar numa afirmação de que um programa está livre de cavalos de Tróia? Talvez seja mais importante confiar nas pessoas que escreveram o software.”

Embora tenha sido possível conhecer os desenvolvedores que criaram e utilizaram bibliotecas de terceiros no passado, hoje não é tão viável devido ao aumento do número de atores envolvidos. Além disso,  os ataques Protestware  podem representar uma forte ameaça que não pode ser facilmente combatida.

Aprendizado 

Então, aqui estão 8  tarefas práticas :

  1. Não caia na armadilha de usar muitas bibliotecas externas, pense duas vezes se realmente precisar delas, em caso de dúvida pense em um  desastre com o teclado esquerdo  .
  2. Microsserviços vs Monolith  não é escolher o bom ou o ruim, concentre-se no problema, mais simples é sempre melhor.
  3. Use a  estrutura SLSA  para compreender as ameaças modernas à cadeia de fornecimento de software e trabalhar para adotar níveis de segurança definidos, um passo de cada vez.
  4. Automatize o gerenciamento de dependências usando uma ferramenta OSS como  o RenovateBot , é agradável e fácil de integrar.
  5. Abrace a nova era de assinatura de artefatos usando  atestados Sigstore  e  SLSA  para produzir seus artefatos e como um guia para escolher software de terceiros que os adote.
  6. Sempre produza Lista de Materiais de Software (SBOM) para um artefato e finja que também o recebeu de seus fornecedores. (  Padrões SPDX  e  CycloneDX )
  7. Automatize e verifique vulnerabilidades conhecidas em todo o seu conjunto de dependências. É fácil fazer isso ao padronizar os artefatos para contêineres OCI. Usando uma ferramenta como  o Grype .
  8. Use imagens Docker menores, como  Distroless  ou  Chainguard,  quando possível

 

Artigo originalmente publicado por CNCF.IO

DNX Brasil – Soluções cloud-native

Anúncio de novas instâncias Hpc7a do Amazon EC2 otimizadas para computação de alta performance

Em janeiro de 2022, a AWS lançou instâncias Amazon EC2 Hpc6a para que os clientes executem com eficiência suas cargas de trabalho de computação de alto desempenho (HPC) vinculadas à computação na AWS com desempenho de preço até 65% melhor em relação a instâncias comparáveis ​​otimizadas para computação baseadas em x86.

À medida que seus trabalhos se tornam mais complexos, os clientes pedem mais núcleos com mais desempenho computacional e mais memória e desempenho de rede para reduzir o tempo de conclusão dos trabalhos. Além disso, à medida que os clientes buscam trazer mais cargas de trabalho de HPC para o EC2, eles perguntam como podemos facilitar a distribuição de processos para fazer o melhor uso da memória e da largura de banda da rede, para alinhar com seus requisitos de carga de trabalho.

Considerado umas das principais notícias AWS de agosto, a gigante Amazon anunciou a disponibilidade geral das instâncias Hpc7a do Amazon EC2 , a próxima geração de tipos de instância criados especificamente para cargas de trabalho de HPC fortemente acopladas. As instâncias Hpc7a equipadas com processadores AMD EPYC de 4ª geração (Gênova) oferecem desempenho até 2,5 vezes melhor em comparação com as instâncias Hpc6a. Essas instâncias oferecem largura de banda do Elastic Fabric Adapter (EFA) de 300 Gbps alimentada pelo AWS Nitro System, para comunicações entre nós rápidas e de baixa latência.

As instâncias Hpc7a apresentam memória Double Data Rate 5 (DDR5), que fornece largura de banda de memória 50% maior em comparação com a memória DDR4 para permitir acesso de alta velocidade aos dados na memória. Essas instâncias são ideais para cargas de trabalho com uso intensivo de computação e sensíveis à latência, como dinâmica de fluidos computacional (CFD) e previsão numérica do tempo (NWP).

Se você estiver executando no Hpc6a, poderá usar instâncias Hpc7a e aproveitar a densidade de núcleo 2 vezes maior, a largura de banda de memória efetiva 2,1 vezes maior e a largura de banda de rede 3 vezes maior para reduzir o tempo necessário para concluir tarefas em comparação com as instâncias Hpc6a.

Aqui está um infográfico rápido que mostra como as instâncias Hpc7a e o processador AMD EPYC de 4ª geração (Gênova) se comparam às instâncias e ao processador anteriores:

As instâncias Hpc7a apresentam tamanhos de até 192 núcleos das CPUs dos processadores AMD EPYC com 768 GiB de RAM. Aqui estão as especificações detalhadas:

Essas instâncias fornecem maior desempenho de computação, memória e rede para executar as cargas de trabalho com uso mais intensivo de computação, como CFD, previsão do tempo, dinâmica molecular e química computacional na AWS.

Semelhante às instâncias EC2 Hpc7g lançadas um mês antes, estamos oferecendo tamanhos de instância menores que tornam mais fácil para os clientes escolherem um número menor de núcleos de CPU para ativar, mantendo todos os outros recursos constantes com base nos requisitos de carga de trabalho. Para cargas de trabalho de HPC, os cenários comuns incluem o fornecimento de mais largura de banda de memória por núcleo para cargas de trabalho de CFD, a alocação de menos núcleos em cenários vinculados a licença e o suporte a mais memória por núcleo. 

Assim como acontece com as instâncias Hpc6a, você pode usar a instância Hpc7a para executar suas maiores e mais complexas simulações de HPC no EC2 e otimizar custo e desempenho. Você também pode usar as novas instâncias Hpc7a com AWS Batch e AWS ParallelCluster para simplificar o envio de cargas de trabalho e a criação de clusters. Você também pode usar o Amazon FSx for Lustre para latências inferiores a milissegundos e até centenas de gigabytes por segundo de taxa de transferência para armazenamento.

Para obter o melhor desempenho para cargas de trabalho de HPC, essas instâncias têm o Multithreading Simultâneo (SMT) desabilitado, estão disponíveis em uma única zona de disponibilidade e têm rede externa limitada e largura de banda do EBS.

Artigo originalmente publicado por Blog AWS

DNX Brasil – Soluções cloud-native

Introdução ao AWS Well-Architected Framework: Garantindo a Excelência na Arquitetura de Cloud

No cenário em constante evolução da computação em nuvem, garantir que suas aplicações sejam projetadas e executadas de forma eficiente, segura, confiável e de alto desempenho é essencial. É aqui que entra o AWS Well-Architected Framework (Estrutura de Arquitetura Bem-Projetada da AWS). O AWS Well-Architected Framework fornece um conjunto de práticas recomendadas para ajudar os arquitetos de nuvem a projetar, implantar e gerenciar cargas de trabalho na nuvem com mais eficiência, levando em consideração aspectos críticos como segurança, desempenho e custo. 

Entendendo o AWS Well-Architected Framework 

O AWS Well-Architected Framework baseia-se em seis pilares fundamentais: 

  • Excelência Operacional: Este pilar se concentra em garantir que você possa administrar e operar suas cargas de trabalho de forma eficiente. Isso inclui automação de processos, monitoramento, gerenciamento de incidentes e manutenção geral do ambiente. 
  • Segurança: A segurança é uma prioridade máxima em qualquer arquitetura. Este pilar se concentra em proteger suas informações, sistemas e ativos. Isso inclui o controle de acesso, a proteção de dados em trânsito e em repouso, bem como a implementação de práticas recomendadas de segurança. 
  • Confiabilidade: Cargas de trabalho na nuvem devem ser altamente confiáveis. Este pilar aborda a capacidade de recuperar-se automaticamente de falhas, a tolerância a falhas e a garantia de que sistemas estejam disponíveis e funcionando conforme o esperado. 
  • Eficiência de Desempenho: O desempenho é essencial para fornecer uma experiência positiva ao usuário. Este pilar trata da otimização de recursos para garantir que sua aplicação tenha a capacidade de lidar com a carga de trabalho sem sacrificar a qualidade. 
  • Otimização de Custos: A nuvem oferece flexibilidade, mas é importante otimizar os custos associados à execução de suas aplicações. Este pilar inclui estratégias para reduzir gastos excessivos, como dimensionamento adequado e uso eficiente de recursos. 
  • Sustentabilidade: Focaliza os impactos ambientais, especialmente a eficiência e o consumo de energia, que são fatores importantes para fundamentar ações diretas dos arquitetos visando reduzir o uso de recursos. 

 

Benefícios do AWS Well-Architected Framework 

A adoção do AWS Well-Architected Framework traz inúmeros benefícios para as organizações que utilizam serviços em nuvem da AWS: 

  • Melhoria da Qualidade da Arquitetura: Ao seguir as práticas recomendadas do framework, você estará projetando sistemas mais robustos, escaláveis e seguros. 
  • Redução de Riscos: As diretrizes de segurança e as melhores práticas de design ajudam a reduzir a exposição a ameaças e vulnerabilidades. 
  • Economia de Custos: O foco na otimização de custos auxilia na eliminação de gastos desnecessários, proporcionando um melhor retorno sobre o investimento. 
  • Maior Eficiência Operacional: A automação e a padronização proporcionam uma operação mais suave e eficaz das cargas de trabalho. 
  • Adaptação às Mudanças: A arquitetura bem projetada é mais flexível e capaz de se adaptar às mudanças nas demandas do negócio. 

Como Aplicar o AWS Well-Architected Framework 

  • Avaliação Atual: Avalie sua arquitetura atual em relação aos cinco pilares e identifique áreas de melhoria. 
  • Planejamento: Crie um plano para implementar as mudanças necessárias, priorizando as ações com maior impacto. 
  • Implementação: Realize as modificações conforme planejado, adotando as práticas recomendadas do framework. 
  • Avaliação Contínua: Mantenha um ciclo de avaliação contínua para garantir que sua arquitetura permaneça alinhada com os princípios do AWS Well-Architected Framework. 

Conclusão 

O AWS Well-Architected Framework é uma abordagem fundamental para projetar e operar cargas de trabalho em nuvem com excelência. Ao seguir suas diretrizes, as organizações podem criar sistemas mais seguros, eficientes e confiáveis, enquanto otimizam os custos e se adaptam às mudanças do mercado. Investir na arquitetura bem projetada não apenas traz benefícios imediatos, mas também prepara o terreno para um crescimento sustentável no mundo dinâmico da computação em nuvem. 

Não perca tempo! Entre em contato conosco agora mesmo para garantir que seu ambiente esteja totalmente alinhado com as práticas do WAR. A DNX Brasil é o parceiro ideal para transformar sua infraestrutura e garantir a segurança e eficiência que seu negócio merece. Não deixe para depois, tome a ação certa hoje e leve sua empresa ao próximo nível com a expertise da DNX Brasil. Estamos prontos para ajudar, entre em contato agora! 

Melhores Práticas AWS: DevOps

O DevOps revolucionou o desenvolvimento e as operações de software ao promover a colaboração, a automação e a melhoria contínua. Ao reunir equipes de desenvolvimento e operações, as organizações podem acelerar a entrega de software, aumentar a confiabilidade e atingir um tempo de lançamento no mercado mais rápido.

Nesta postagem do blog, exploraremos as melhores práticas e considerações arquitetônicas para implementar DevOps com Amazon Web Services (AWS), permitindo que você crie sistemas eficientes e escaláveis ​​que se alinhem aos princípios de DevOps. O Vamos Arquitetar! A equipe deseja compartilhar recursos úteis que ajudam você a otimizar o desenvolvimento e as operações de software.

Revolução DevOps

Os sistemas distribuídos são adotados pelas empresas com mais frequência agora. Quando uma organização deseja aproveitar as características dos sistemas distribuídos, é necessária uma mudança de mentalidade e abordagem, semelhante a um novo modelo para o ciclo de vida de desenvolvimento de software.

Neste vídeo re:Invent 2021, Emily Freeman, agora chefe de envolvimento com a comunidade na AWS, compartilha conosco os insights obtidos nas trincheiras ao adaptar um novo ciclo de vida de desenvolvimento de software que ajudará sua organização a prosperar usando sistemas distribuídos.

Leve-me para este vídeo re:Invent 2021!

Operacionalizando a revolução DevOps

Operacionalizando a revolução DevOps

Meu pipeline de CI/CD é meu capitão de lançamento

Projetar fluxos de trabalho DevOps eficazes é necessário para alcançar uma colaboração perfeita entre as equipes de desenvolvimento e operações. A Amazon Builders’ Library oferece diversas orientações sobre como projetar fluxos de trabalho de DevOps que promovem eficiência, escalabilidade e confiabilidade. Da integração contínua e estratégias de implantação ao gerenciamento de configuração e observabilidade, este recurso abrange vários aspectos do design do fluxo de trabalho DevOps. Seguindo as práticas recomendadas descritas na Builders’ Library, você pode criar fluxos de trabalho DevOps robustos e escalonáveis ​​que facilitam a entrega rápida de software e operações tranquilas.

Leve-me a este recurso!

Um pipeline coordena vários lançamentos em andamento e os promove em três estágios

Um pipeline coordena vários lançamentos em andamento e os promove em três estágios

Usando funções do Cloud Fitness para impulsionar a arquitetura evolutiva

As funções de fitness na nuvem fornecem um mecanismo poderoso para impulsionar a arquitetura evolutiva em suas práticas de DevOps. Ao definir e medir metas de adequação arquitetônica, você pode melhorar e evoluir continuamente seus sistemas ao longo do tempo.

Esta postagem do blog de arquitetura da AWS investiga como os serviços da AWS, como AWS Lambda , AWS Step Functions e Amazon CloudWatch podem ser aproveitados para implementar funções de fitness na nuvem de maneira eficaz. Ao integrar esses serviços em seus fluxos de trabalho DevOps, você pode estabelecer uma arquitetura que evolui em alinhamento com as mudanças nas necessidades de negócios: melhorando a resiliência, a escalabilidade e a capacidade de manutenção do sistema.

Leve-me para esta postagem do blog de arquitetura da AWS!

Funções de condicionamento físico fornecem feedback aos engenheiros por meio de métricas

Funções de condicionamento físico fornecem feedback aos engenheiros por meio de métricas

Implantações multirregionais do Terraform com AWS CodePipeline usando Terraform Built CI/CD

Conseguir implantações consistentes em diversas regiões é um desafio comum. Esta postagem do blog AWS DevOps demonstra como usar o Terraform, o AWS CodePipeline e os princípios de infraestrutura como código para automatizar implantações multirregionais de maneira eficaz. Ao adotar essa abordagem, você pode demonstrar implantações consistentes de infraestrutura e aplicativos, melhorando a escalabilidade, a confiabilidade e a disponibilidade de suas práticas de DevOps.

A postagem também fornece exemplos práticos e instruções passo a passo para implementar implantações multirregionais com serviços Terraform e AWS, permitindo que você aproveite o poder da infraestrutura como código para agilizar os fluxos de trabalho de DevOps.

Leve-me para esta postagem do blog AWS DevOps!

Implantação AWS multirregional com pipelines IaC e CI/CD

Artigo originalmente publicado por Blog AWS

DNX Brasil – Soluções cloud-native

Cloud based e cloud native: qual a diferença?

Conheça as diferenças entre aplicativos nativos da nuvem (cloud native) e aplicativos baseados na nuvem (cloud based) e seus benefícios 

O termo “nuvem” tornou-se uma palavra da moda na indústria de tecnologia, muitas vezes usado de forma intercambiável para descrever qualquer coisa, desde armazenamento online até serviços de computação complexos. Mas o que isso realmente significa? E o mais importante, o que isso significa para o seu negócio?

“A Nuvem” é um conceito que certamente revolucionou a forma como armazenamos, gerenciamos e interagimos com os dados. Mas, como acontece com qualquer avanço tecnológico, a nuvem vem com seu próprio conjunto de terminologias que muitas vezes podem ser confusas. Dois desses termos que muitas vezes causam confusão são “cloud native” e “cloud based”. Embora possam parecer semelhantes, representam abordagens diferentes para usar a nuvem. Compreender essas diferenças é crucial para as empresas que buscam aproveitar o poder da nuvem de forma eficaz.

Nesta postagem do blog, veremos as diferenças entre aplicativos nativos e baseados em nuvem, exploraremos seus prós e contras e ajudaremos você a entender qual abordagem pode ser mais adequada para o seu negócio. 

Compreendendo os aplicativos em nuvem: uma história de duas nuvens

Os aplicativos baseados em nuvem são semelhantes a uma peça de mobília muito apreciada e usada que você decidiu mudar para uma nova casa. Esses aplicativos foram originalmente projetados para serem executados em servidores locais ou computadores pessoais, mas foram realocados para a nuvem. Embora essa mudança ofereça os benefícios da nuvem, como acesso remoto e infraestrutura física reduzida, ela também traz algumas peculiaridades dos móveis antigos.

Esses aplicativos são totalmente integrados, o que significa que seus componentes estão interconectados e dependem uns dos outros. Essa integração pode ser um ponto forte, proporcionando consistência e confiabilidade. No entanto, isso também significa que quando uma parte do aplicativo precisar de uma atualização ou encontrar um problema, todo o sistema poderá precisar ser colocado offline. Isso pode levar ao tempo de inatividade, o que pode interromper as operações e afetar a produtividade.

Por outro lado, os aplicativos nativos da nuvem são como uma casa construída do zero, projetada para se adequar às características específicas de sua localização. Esses aplicativos são projetados especificamente para o ambiente de nuvem desde o início. Eles foram desenvolvidos para serem flexíveis, escaláveis ​​e resilientes, aproveitando ao máximo os recursos da nuvem.

Os aplicativos nativos da nuvem geralmente empregam uma arquitetura de microsserviços. Isto significa que são compostos por serviços pequenos e independentes que trabalham em conjunto, tal como uma equipa desportiva bem coordenada. Cada ator (ou serviço) tem uma função específica e pode operar independentemente dos demais. Essa independência significa que partes individuais de um aplicativo nativo da nuvem podem ser atualizadas, dimensionadas ou até mesmo colocadas off-line sem interromper todo o sistema.

Comparando aplicativos Cloud based e cloud native

Então qual é a diferença? No final das contas, é tudo uma questão de design, implementação, manutenção e custo.

Os aplicativos nativos da nuvem (cloud native) são mais rápidos de implantar porque não há hardware ou software para instalar. Eles foram projetados para minimizar interrupções, graças à sua arquitetura de microsserviços. E como você paga apenas pelos recursos de nuvem que usa, eles podem ser mais econômicos.

Os aplicativos baseados em nuvem (cloud based), embora ainda ofereçam os benefícios da nuvem, podem ser mais lentos para implantar e mais sujeitos a interrupções. Como não foram originalmente projetados para a nuvem, talvez não consigam aproveitar ao máximo todos os benefícios da nuvem.

imagem

Artigo originalmente publicado por Cloud Native

DNX Brasil – Soluções cloud-native

Novidade AWS: Amazon Managed Service for Apache Flink

Nessa semana, a AWS (Amazon Web Services) anunciou a renomeação do Amazon Kinesis Data Analytics para Amazon Managed Service for Apache Flink , um serviço totalmente gerenciado e sem servidor para você criar e executar aplicativos de streaming em tempo real usando o Apache Flink .

Continuamos a oferecer a mesma experiência em seus aplicativos Flink sem qualquer impacto nas operações, desenvolvimentos ou casos de uso de negócios em andamento. Todos os seus aplicativos em execução existentes no Kinesis Data Analytics funcionarão como estão, sem quaisquer alterações.

Muitos clientes usam o Apache Flink para processamento de dados, incluindo suporte para diversos casos de uso com uma comunidade vibrante de código aberto. Embora os aplicativos Apache Flink sejam robustos e populares, eles podem ser difíceis de gerenciar porque exigem escalonamento e coordenação de computação paralela ou recursos de contêiner. Com a explosão de volumes de dados, tipos de dados e fontes de dados, os clientes precisam de uma maneira mais fácil de acessar, processar, proteger e analisar seus dados para obter insights mais rápidos e profundos sem comprometer o desempenho e os custos.

Usando o Amazon Managed Service for Apache Flink, você pode configurar e integrar fontes ou destinos de dados com código mínimo, processar dados continuamente com latências inferiores a um segundo de centenas de fontes de dados, como Amazon Kinesis Data Streams e Amazon Managed Streaming for Apache Kafka (Amazon MSK ) e responder a eventos em tempo real. Você também pode analisar dados de streaming de forma interativa com notebooks com apenas alguns cliques com o Amazon Managed Service para Apache Flink Studio com visualizações integradas desenvolvidas pelo Apache Zeppelin .

Com o Amazon Managed Service for Apache Flink, você pode implantar aplicativos seguros, compatíveis e altamente disponíveis. Não há servidores e clusters para gerenciar, nem infraestrutura de computação e armazenamento para configurar, e você paga apenas pelos recursos que seus aplicativos consomem.

Artigo originalmente publicado por Blog AWS

DNX Brasil – Soluções cloud-native

AWS DeepRacer Estudante lança manuais para educadores

Apresentando os manuais educativos para o AWS DeepRacer Estudante — a ferramenta perfeita para educadores integrarem perfeitamente o currículo e os laboratórios básicos de machine learning (ML) em suas salas de aula para estudantes com 16 anos ou mais. Com os manuais para educadores, os educadores podem facilmente aprimorar as habilidades dos alunos nas noções básicas de ML empolgando-os a pilotar veículos autônomos.

 

Com 20 horas de material educacional, treinamento gratuito de modelos e uma liga de corrida autônoma, os estudantes podem se divertir enquanto aprimoram suas habilidades de ML por meio do AWS DeepRacer Estudante. O manual curricular fornece aos educadores todas as informações necessárias para implementar o currículo de ML de forma eficaz com nossos módulos de aprendizado sob demanda. Agora, os educadores podem acessar objetivos de aprendizado, resultados, conceitos-chave e sugestões de atividades para personalizar a experiência de acordo com as necessidades de seus alunos.

 

Os laboratórios práticos permitem que os alunos transformem a teoria em aprendizado prático, com modelos de tutoriais de treinamento e uma competição amigável com a Liga do AWS DeepRacer Estudante. O manual do laboratório oferece recursos para ativações virtuais ou presenciais, garantindo flexibilidade e acessibilidade. As ativações virtuais permitem uma opção fácil e gratuita de engajar estudantes por meio de corridas comunitárias privadas, corridas virtuais ao vivo e da Liga global do AWS DeepRacer Estudante. As ativações presenciais darão vida ao ML, pois os estudantes verão seus modelos competirem em uma pista ao vivo com um dispositivo físico do AWS DeepRacer.

 

Artigo originalmente publicado por Blog AWS

 

DNX Brasil – Soluções cloud-native

Unindo Forças: Como DevOps Transforma o Cloud Computing

A interseção entre DevOps e Cloud Computing tem revolucionado a maneira como as empresas desenvolvem, implementam e gerenciam suas aplicações. A colaboração entre equipes de desenvolvimento e operações, juntamente com a flexibilidade da computação em nuvem, está permitindo que as organizações alcancem níveis de eficiência, escalabilidade e inovação sem precedentes. Neste artigo, exploraremos como a abordagem DevOps e a adoção da Cloud Computing estão se complementando para impulsionar a transformação digital. 

DevOps e a Cultura de Colaboração 

DevOps, uma abreviação de “Desenvolvimento” (Development) e “Operações” (Operations), representa uma mudança cultural que visa eliminar as barreiras tradicionais entre equipes de desenvolvimento e operações. Essa abordagem busca criar uma cultura de colaboração e automação. Permitindo que as equipes trabalhem juntas de maneira mais eficaz desde a concepção até a entrega e manutenção de um software. 

Na era da Cloud Computing, onde as infraestruturas são altamente flexíveis e escaláveis, a colaboração entre desenvolvedores e operadores é essencial para otimizar a implantação e a gestão de aplicações na nuvem. Isso resulta em ciclos de desenvolvimento mais curtos, implantações mais confiáveis e respostas mais rápidas às necessidades do mercado. 

Cloud Computing e Escalabilidade 

A Cloud Computing fornece recursos computacionais sob demanda, eliminando a necessidade de investir em infraestrutura física. Isso permite que as empresas se concentrem mais em sua competência central, em vez de lidar com questões de hardware e infraestrutura. Além disso, a escalabilidade oferecida pela nuvem é um trunfo importante para as práticas DevOps. 

Uma das principais vantagens da Cloud Computing é a capacidade de dimensionar recursos vertical e horizontalmente de acordo com a demanda. Isso se alinha perfeitamente com os princípios DevOps, onde as mudanças frequentes são esperadas. Se uma aplicação precisa lidar com um aumento repentino no tráfego, as equipes de DevOps podem escalar os recursos da nuvem de forma rápida e eficiente, mantendo a disponibilidade do serviço. 

Automação: O Pilar Comum 

Tanto o DevOps quanto a Cloud Computing dependem fortemente da automação para alcançar resultados eficientes e consistentes. A automação é o cerne da cultura DevOps, permitindo a criação de pipelines de integração contínua, entrega contínua (CI/CD) e implantação automatizada. Esses processos reduzem os erros humanos, melhoram a qualidade do software e aceleram o tempo de lançamento no mercado. 

Na nuvem, a automação é igualmente crucial. As infraestruturas podem ser provisionadas, configuradas e gerenciadas por meio de código, utilizando práticas conhecidas como “Infraestrutura como Código” (IaC). Isso possibilita a criação de ambientes consistentes e repetíveis, reduzindo o risco de discrepâncias entre ambientes de desenvolvimento, teste e produção. 

Conclusão 

A colaboração entre DevOps e Cloud Computing é uma combinação poderosa que está moldando a forma como as empresas desenvolvem e entregam software. A abordagem DevOps promove a colaboração entre equipes, acelera o ciclo de vida de desenvolvimento e melhora a qualidade do software, enquanto a Cloud Computing oferece flexibilidade e escalabilidade sob demanda. 

Adotar essa abordagem requer uma mudança cultural e investimentos em automação, mas os benefícios são evidentes: implantações mais confiáveis, respostas mais ágeis às mudanças do mercado e a capacidade de escalar recursos de maneira eficiente. À medida que as empresas continuam sua jornada de transformação digital, a sinergia entre DevOps e Cloud Computing desempenhará um papel vital na busca por uma vantagem competitiva no cenário tecnológico em constante evolução. 

 

Afinal, você sabe o que é um API Gateway?

Com o aumento considerável do uso dos conhecidos cloud providers, alguns tópicos que eram restritos ao vocabulário dos profissionais de infraestrutura acabaram transbordando para outras áreas, em especial para os times de desenvolvimento. Um destes termos é o API Gateway.

Afinal, você saberia descrever para que serve este componente? Bem, se fosse possível achar um exemplo do nosso cotidiano que se assemelhasse às atividades e responsabilidades de um API Gateway, uma boa sugestão seria o contexto de uma portaria de um prédio empresarial.

Imagine que você é um fornecedor de uma empresa que está neste prédio e que você precisa entregar um pedido. Nesse cenário, dependendo da portaria, você:

  1. Não terá acesso direto à empresa em questão;
  2. Você terá de interagir com um intermediário (um(a) recepcionista por exemplo)
  3. Caso você precise se dirigir até o andar da empresa, a recepcionista irá fazer algumas confirmações com empresa por motivos de segurança;
  4. Além dessas confirmações, para entrar no prédio você receberá um cartão de acesso que permite apenas acessar o andar da empresa em questão;

Se convertermos o cenário da portaria do prédio para um cenário de uma aplicação web qualquer, as empresas seriam as APIs, a encomenda seria uma requisição HTTP, e a portaria seria o API Gateway.

Essas responsabilidades relacionadas ao isolamento, controle de acesso e ser um intermediário entre as requisições definem o escopo de atuação de um API Gateway:

– Isolamento: as requisições HTTP nunca chegam diretamente ao serviço, o API Gateway tem a responsabilidade de recebê-las e redirecionar para o serviço correspondente de forma transparente.
– Proxy Reverso: para o solicitante, as respostas das requisições se apresentarão como do próprio serviço; no entanto, o API Gateway é que estará se passando de serviço realizando os redirecionamentos, tanto de requisição como de resposta.
– Autenticação: é possível delegar ao API Gateway a camada de autenticação e acesso para as APIs em questão, sendo capaz de implementar o fornecimento de tokens, ou até mesmo cenários do protocolo Oauth 2.0.

Mas como tudo no mundo de TI há um preço, ao implementar um API gateway à frente de suas APIs, tenha em mente que:

1. Adição de um elemento na sua infraestrutura  – aumento de complexidade e manutenção ;
1. Dependendo do tipo de implementação, o API Gateway poderá ser um ponto único de falha, ou seja, caso ele falhar, nenhuma aplicação conseguirá acessar às suas APIs;
1. Aumento de latência, haja vista que para cada requisição será obrigatório a passagem pelo API Gateway, e o mesmo será responsável por redirecionar a requisição, coletar a resposta e devolver ao remetente de forma transparente;

No mundo Open Source podemos destacar três ferramentas que visam resolver esse tipo de problema. O primeiro é o Kong – derivado do famoso _NGINX_, que estende suas características para atuar como um API Gateway. O segundo que vale menção é o KrakenD, que além de atuar como API Gateway, foi construído para ser escalado, ou seja, não sofrer do mal de ser um single point of failure. Por fim, o Traefik também pode ser considerado um API Gateway – desenvolvido em GO, além dessas responsabilidades já citadas, se destaca por ter uma funcionalidade de service discovery automático, ou seja, identifica as APIs de sua infraestrutura sem precisar de esforços de configuração, além de possuir esse comportamento de forma dinâmica – assim sendo, se algum serviço ficar indisponível ou adicionarmos novas APIs em nossa infraestrutura, ele é capaz de identificar tais status.

Nos cloud providers (como AWS, GCP, Digital Ocean, OCI, Azure entre outros), os API Gateways nos são apresentados como um produto da própria cloud, em geral, responsável por direcionar as requisições para as APIs ou, em arquiteturas _serverless_, para funções.

Artigo originalmente publicado por 4.Linux

DNX Brasil – Soluções cloud-native

 

Sustentabilidade da computação em nuvem: quão verde é a nuvem?

A sustentabilidade da computação em nuvem ou ‘Nuvem Verde’ refere-se a uma nuvem amiga do ambiente que reduz as emissões de carbono e promove a utilização de energia renovável para reduzir as necessidades energéticas. Todos os principais provedores de nuvem tomaram medidas para converter seus data centers em nuvem verde. O pilar de sustentabilidade da AWS é um exemplo de como a Amazon promove uma nuvem ecologicamente correta.

O que é computação em nuvem verde?

A computação em nuvem verde é um conjunto de práticas benéficas que reduzem o consumo de energia e as emissões de carbono. A computação verde defende o uso de energia renovável de diferentes fontes. Tem três objetivos principais:

  • Maximizando a eficiência energética
  • Promover a reciclagem
  • Minimizando o uso de materiais perigosos

Como funciona a computação em nuvem verde?

Os provedores de nuvem empregam diferentes técnicas e processos que resultam em data centers mais ecológicos. Aqui estão algumas dessas técnicas:

Fonte de energia renovável

Os fornecedores de cloud utilizam fontes de energia renováveis ​​para reduzir as necessidades energéticas dos data centers. Essas fontes incluem energia solar, eólica, hidrelétrica e enormes bancos de baterias para armazenar a energia coletada. Alguns fornecedores de nuvem utilizam créditos de energia renovável para equilibrar a sua pegada de carbono.

Otimizando a Instalação

Os fornecedores de cloud tomam muitas medidas para garantir a redução do consumo de energia nos seus data centers. Os fornecedores de nuvem, especialmente os gigantes da tecnologia, usam técnicas baseadas em IA e aprendizado de máquina para monitorar e sugerir o uso otimizado de energia. Isso inclui otimizar a arquitetura, o layout dos andares e a localização do data center para otimizar o consumo de energia.

Outras etapas incluem:

  • Utilize o calor excessivo produzido pelos data centers para aquecer edifícios próximos
  • Coloque o data center em um clima frio, no subsolo ou mesmo no oceano

Otimizando a infraestrutura

A infraestrutura em nuvem é um elemento central no consumo de energia. Os provedores de nuvem usam hardware moderno, que consome menos energia. Eles também usam hardware que utiliza diferentes técnicas de economia de energia, como tensão dinâmica e escala de frequência. Da mesma forma, a aplicação de diferentes técnicas para maximizar a utilização de recursos, incluindo virtualização e contentorização, resulta em menos servidores e num consumo de energia reduzido.

Otimizando o Fluxo de Trabalho

Os provedores de nuvem também aplicam técnicas para otimizar o fluxo de trabalho para minimizar o consumo de energia. Algumas das técnicas são:

  • Dividir a carga de trabalho entre diferentes servidores de forma inteligente para maximizar a utilização de recursos
  • Otimizando rotas de rede para reduzir o tráfego de rede
  • Otimizando o armazenamento portátil e o cache do servidor para reduzir chamadas de rede
  • Automatizando tarefas rotineiras para economizar tempo e energia

Por que a computação em nuvem é ambientalmente sustentável?

Veja como a computação em nuvem apoia a sustentabilidade:

Maior taxa de utilização

O uso de data centers locais resulta em uma baixa taxa de utilização porque você provisiona demais a infraestrutura para lidar com cargas de trabalho inesperadas. A computação em nuvem pode fazer uso inteligente de servidores com altas taxas de utilização e maior eficiência. A infraestrutura de nuvem pública é geralmente 2 a 4 vezes mais eficiente do que os data centers tradicionais devido à melhor utilização da infraestrutura.

Reduza as necessidades de eletricidade

A infraestrutura local precisa de muita manutenção e requer UPS, eletricidade, sistemas de refrigeração, etc. Mover seu software para a nuvem economizará eletricidade significativa. Conforme afirma o estudo de caso do Laboratório Nacional Lawrence Berkeley , mover aplicativos de negócios como CRM, e-mail, etc., para a nuvem pode economizar eletricidade suficiente a cada ano para atender às necessidades de eletricidade de Los Angeles durante um ano. Um estudo semelhante afirma que a mudança para a nuvem economizaria 87% no consumo de energia .

Velocidade de atualização de hardware

A infraestrutura tradicional de data center é usada por muito tempo antes de expirar ou ser substituída devido ao alto custo de atualização de servidores. Devido a uma melhor taxa de utilização, a infraestrutura em nuvem é substituída muito mais cedo. O novo hardware é mais eficiente em termos energéticos que seu antecessor. Quanto mais eficiente em termos de energia for o hardware, mais dinheiro os fornecedores de nuvem economizarão. Eventualmente, menos energia será usada a longo prazo.

Impacto climático reduzido

Os data centers baseados em nuvem reduzem as emissões de carbono em comparação com os data centers tradicionais. De acordo com a Amazon , ele usa 77% menos servidores, 84% menos energia e utiliza uma combinação de energia 28% mais limpa. Isto traz uma redução geral nas emissões de carbono de 88% em comparação com data centers locais.

Artigo originalmente publicado por Blog AWS: Generative AI Foundations

DNX Brasil – Soluções cloud-native

 

Generative AI Foundations on AWS

Generative AI Foundations on AWS é um novo curso técnico de aprofundamento que fornece fundamentos conceituais, conselhos práticos e orientação prática para pré-treinar, ajustar e implantar modelos de base de última geração na AWS e além. Desenvolvido por Emily Webber, líder mundial de fundações de IA generativa da AWS, este curso prático gratuito e o código-fonte do GitHub de suporte lançados via  AWS Youtube . Se você está procurando uma lista de reprodução com curadoria dos principais recursos, conceitos e orientações para se atualizar sobre os modelos básicos e, especialmente, aqueles que desbloqueiam recursos generativos em seus projetos de ciência de dados e aprendizado de máquina, não procure mais.

Durante este mergulho profundo de 8 horas, você será apresentado às principais técnicas, serviços e tendências que o ajudarão a entender os modelos de fundação desde o início. Isso significa quebrar teoria, matemática e conceitos abstratos combinados com exercícios práticos para obter intuição funcional para aplicação prática. Ao longo do curso, nos concentramos em um amplo espectro de técnicas de IA generativa progressivamente complexas, fornecendo uma base sólida para entender, projetar e aplicar seus próprios modelos para obter o melhor desempenho. Começaremos recapitulando os modelos de fundação, entendendo de onde eles vêm, como funcionam, como se relacionam com a IA generativa e o que você pode fazer para personalizá-los. Em seguida, você aprenderá a escolher o modelo de fundação certo para se adequar ao seu caso de uso.

Depois de desenvolver uma forte compreensão contextual dos modelos de fundação e como usá-los, você será apresentado ao assunto principal deste curso: pré-treinamento de novos modelos de fundação. Você aprenderá por que deseja fazer isso, bem como como e onde é competitivo. Você ainda aprenderá como usar as leis de dimensionamento para escolher o modelo, o conjunto de dados e os tamanhos de computação corretos. Abordaremos a preparação de conjuntos de dados de treinamento em escala na AWS, incluindo a escolha das instâncias e técnicas de armazenamento corretas. Abordaremos o ajuste fino de seus modelos de fundação, avaliando técnicas recentes e compreendendo como executá-las com seus scripts e modelos. Vamos mergulhar no aprendizado por reforço com feedback humano, explorando como usá-lo habilmente e em escala para realmente maximizar o desempenho do seu modelo de fundação.

Por fim, você aprenderá como aplicar a teoria à produção implantando seu novo modelo de base no Amazon SageMaker , inclusive em várias GPUs e usando os principais padrões de design, como geração aumentada de recuperação e diálogo encadeado. Como um bônus adicional, vamos orientá-lo através de um mergulho profundo em Stable Diffusion, apresentar as melhores práticas de engenharia, levantar o LangChain e muito mais.

Artigo originalmente publicado por Blog AWS: Generative AI Foundations

DNX Brasil – Soluções cloud-native

Do data warehouse ao data fabric: a evolução da arquitetura de dados

No século passado, os dados se tornaram a força vital de todas as organizações, desde gigantes do comércio eletrônico até provedores de assistência médica e agências governamentais. Coletar e gerenciar data de forma eficaz pode fornecer às organizações insights valiosos para auxiliar na tomada de decisões . No entanto, isso provou ser uma tarefa assustadora.

Tão importante quanto data,  o CIOinsight  relata que apenas 10% das organizações sentem que sua empresa se destacam no gerenciamento de análise. Reconhecendo essa lacuna significativa na utilização de data, as organizações adotaram arquiteturas de data modernas para preencher a lacuna.

As arquiteturas de dados  são  estruturas e sistemas estruturados  que definem como eles são organizados, integrados e acessados ​​dentro de uma organização. A arquitetura define o projeto e estabelece diretrizes para os dados e como eles fluem pelos sistemas de armazenamento.

A evolução da arquitetura 

Ao longo dos anos, a arquitetura de dados evoluiu para se adaptar às crescentes necessidades das empresas. Uma transformação notável discutida nesta seção é a mudança na arquitetura de dados de armazéns lógicos para malhas de dados.

O Armazém Lógico (Logical Warehouse)

Os armazéns lógicos, também conhecidos como armazéns de data, são a base do gerenciamento de há décadas. Esses data warehouses são  repositórios centrais projetados para armazenar dados de diferentes fontes,  como sistemas transacionais, arquivos de log de aplicativos, etc., fornecendo uma visão unificada das informações.

Em geral, os warehouses lógicos usam  processos Extract, Transform, Load (ETL)  para extrair dados dos sistemas de origem, transformá-los para garantir a consistência e carregá-los no warehouse. Os armazéns lógicos destinam-se exclusivamente a  realizar consultas e análises  e  geralmente contêm grandes quantidades históricas .

Desafios dos Armazéns Lógicos

Embora os armazéns lógicos servissem ao seu propósito, eles enfrentaram vários desafios à medida que os volumes de dados aumentavam. Algumas das principais limitações incluíam:

  • Data Silos : armazéns lógicos geralmente resultam em  “data silos”, onde diferentes departamentos ou equipes mantêm seus próprios conjuntos de dados isolados, levando a inconsistências e duplicações.
  • Desempenho : como eles precisavam passar por vários processos e estágios antes de serem disponibilizados para análise, isso afetava muito o desempenho dos data warehouses.
  • Escalabilidade : A implementação de data warehouses é complexa e cara devido às limitações de hardware. Também exigia experiência em modelagem, processos ETL e gerenciamento de banco, tornando mais difícil lidar com o crescimento exponencial de dados.

Artigo originalmente publicado por Cloud Native

DNX Brasil – Soluções cloud-native

Como a Inteligência Artificial se tornou um Diferencial Competitivo nas Empresas

A evolução da tecnologia tem revolucionado a forma como as empresas operam e competem no mercado. Uma das tecnologias mais impactantes nesse cenário é a Inteligência Artificial (IA). A IA deixou de ser apenas uma tendência futurista para se tornar um diferencial competitivo real e tangível para empresas de diversos setores. Neste artigo, exploraremos como a IA se transformou em um fator crucial para o sucesso empresarial. Além de como as organizações estão aproveitando essa tecnologia para se destacar no mercado altamente competitivo de hoje. 

IA: Conceito e Evolução 

A Inteligência Artificial se refere à capacidade das máquinas de simular processos de inteligência humana, como aprendizado, raciocínio e tomada de decisões. O campo da IA evoluiu consideravelmente nas últimas décadas, passando de algoritmos simples para algoritmos complexos baseados em redes neurais artificiais, que são capazes de aprender a partir de médios e grandes volumes de dados. 

IA como Diferencial Competitivo 

  • Automatização: Liberando o Potencial Humano: Um dos impactos mais notáveis da IA é agilidade, através da automação da tomada de decisões, ou pelo menos de parte dela. Tarefas repetitivas e demoradas podem ser realizadas eficientemente por sistemas de IA permitindo que os colaboradores se concentrem em atividades de maior valor, como estratégia e inovação. 
  • Reconhecimento de padrões: A IA tem a capacidade de examinar grandes volumes de dados em tempo real, identificando padrões e insights que seriam inacessíveis aos seres humanos. Isso capacita as empresas a tomar decisões mais embasadas e estratégicas, aprimorando suas operações e abordagens de mercado. 
  • Revitalização do Atendimento ao Cliente: Chatbots e assistentes virtuais, alimentados por IA, revolucionaram o atendimento ao cliente. Esses sistemas respondem a perguntas, solucionam problemas rotineiros e até personalizam a experiência do cliente, elevando a satisfação e a fidelização. 
  • Antecipação de Tendências de Mercado: A IA é uma aliada na previsão de tendências futuras ao analisar dados de mercado e comportamento do consumidor. Isso permite que as empresas se adaptem rapidamente às mudanças e antecipem as demandas dos clientes. 
  • Personalização Excepcional de Produtos e Serviços: Por meio da análise de dados dos clientes, a IA viabiliza a oferta de produtos e serviços personalizados. Isso não apenas amplia a satisfação do cliente, mas também impulsiona vendas e lealdade à marca. 

IAs generativas 

Estamos vivenciando uma época verdadeiramente empolgante no campo das Inteligências Artificiais Generativas (IA). Um exemplo exemplar é o ChatGPT, que lança luz sobre o extraordinário universo das novas IAs capazes de interagir com texto e mídia de maneira excepcional. Hoje, essas IAs não apenas compreendem textos e imagens, mas também transcendem essas capacidades, sintetizando uma variedade de mídias, como texto, fotos, áudio e vídeo. Esses avanços não apenas revolucionam a maneira como nos comunicamos digitalmente, mas também abrem portas para interações mais imersivas e dinâmicas com as máquinas. Além disso, as IAs generativas contemporâneas expandiram suas fronteiras para o mundo digital mais amplo. Demonstrando habilidades impressionantes, como a leitura de documentos, a exploração de bancos de dados, pesquisas na web e até mesmo a execução de tarefas de codificação. 

A Inteligência Artificial se transformou em um diferencial competitivo vital para as empresas modernas. Além de otimizar operações, também fornece insights valiosos para impulsionar a tomada de decisões estratégicas. À medida que a tecnologia continua a avançar, as empresas que abraçam a IA estarão mais bem posicionadas para se destacar em um mercado global cada vez mais competitivo. Portanto, investir em IA não é mais uma opção, mas sim uma necessidade para garantir um futuro de sucesso empresarial. 

O que a AWS acha de sustentabilidade na nuvem?

Sustentabilidade na nuvem: A disciplina de sustentabilidade aborda o impacto ambiental, econômico e social de longo prazo de suas atividades comerciais. A Comissão Mundial das Nações Unidas sobre Meio Ambiente e Desenvolvimento define o desenvolvimento sustentável como “o desenvolvimento que atende às necessidades do presente sem comprometer a capacidade das gerações futuras de atender às suas próprias necessidades”. Sua empresa ou organização pode ter impactos ambientais negativos, como emissões diretas ou indiretas de carbono, resíduos não recicláveis ​​e danos a recursos compartilhados, como água potável.

Ao criar cargas de trabalho em nuvem, a prática da sustentabilidade é entender os impactos dos serviços usados, quantificar os impactos durante todo o ciclo de vida da carga de trabalho e aplicar princípios de design e práticas recomendadas para reduzir esses impactos. Este documento enfoca os impactos ambientais, especialmente o consumo e a eficiência energética, uma vez que são importantes alavancas para os arquitetos informarem ações diretas para reduzir o uso de recursos.

Ao focar nos impactos ambientais, você deve entender como esses impactos são normalmente contabilizados e os impactos subsequentes na própria contabilidade de emissões de sua organização. O Protocolo de Gases de Efeito Estufa organiza as emissões de carbono nos seguintes escopos, juntamente com exemplos de emissão relevantes dentro de cada escopo para um provedor de nuvem como a AWS:

  • Escopo 1: Todas as emissões diretas das atividades de uma organização ou sob seu controle. Por exemplo, combustão de combustível por geradores de backup de data center.
  • Escopo 2: Emissões indiretas de eletricidade comprada e usada para alimentar data centers e outras instalações. Por exemplo, emissões de geração de energia comercial.
  • Escopo 3: Todas as outras emissões indiretas das atividades de uma organização de fontes que ela não controla. Os exemplos da AWS incluem emissões relacionadas à construção de data centers e à fabricação e transporte de hardware de TI implantado em data centers.

Do ponto de vista do cliente da AWS, as emissões de suas cargas de trabalho em execução na AWS são contabilizadas como emissões indiretas e parte de suas emissões de Escopo 3. Cada carga de trabalho implantada gera uma fração do total de emissões da AWS de cada um dos escopos anteriores. A quantidade real varia de acordo com a carga de trabalho e depende de vários fatores, incluindo os serviços da AWS usados, a energia consumida por esses serviços, a intensidade de carbono das redes elétricas que atendem aos datacenters da AWS onde são executados e a aquisição de energia renovável da AWS.

Este documento primeiro descreve um modelo de responsabilidade compartilhada para a sustentabilidade ambiental e, em seguida, fornece as melhores práticas de arquitetura para que você possa minimizar o impacto de suas cargas de trabalho reduzindo o total de recursos necessários para sua execução nos datacenters da AWS.

Artigo originalmente publicado por AWS

DNX Brasil – Soluções cloud-native

Novidade AWS: suporte no Amazon CloudWatch

Agora, o Amazon CloudWatch oferece suporte ao Service Quotas na observabilidade entre contas, permitindo que os clientes rastreiem e visualizem a utilização e os limites de recursos em vários serviços da AWS a partir de várias contas da AWS em uma região usando uma conta de monitoramento central.

As cotas são limites ou valores máximos de recursos, ações e itens do serviço da AWS em sua conta da AWS. Usando o Service Quotas entre contas, os clientes podem ver essas cotas para todas as contas de origem em uma única conta de monitoramento e evitar alcançar os limites. Os clientes não precisam mais rastrear cotas fazendo login em contas individuais. Em vez disso, a partir de uma conta de monitoramento central, eles podem criar painéis e alarmes para o uso de Service Quotas da AWS em todas as contas de origem.

O Service Quotas entre contas já está disponível em todas as regiões comerciais da Amazon Web Services, incluindo as regiões Amazon Web Services China (Pequim), operada pela Sinnet e Amazon Web Services China (Ningxia), operada pela NWCD.

Para começar a usar, o primeiro passo é configurar a observabilidade entre contas do Amazon CloudWatch. Quando a configuração estiver concluída, consulte a documentação sobre visualização de Service Quotas para obter mais informações. O Service Quotas está disponível sem custos adicionais. O preço padrão se aplica às APIs, aos alarmes e ao painel.

Artigo originalmente publicado por AWS: What´s New!

DNX Brasil – Soluções cloud-native

Shopping cart

close
close
Start typing to see posts you are looking for.
Set your categories menu in Theme Settings -> Header -> Menu -> Mobile menu (categories)
Scroll To Top
Twitter YouTube linkedin