selo-aws-partner

Conforme o uso de cloud computing começa a se popularizar, obtemos arquiteturas cada vez mais complexas, gerando a necessidade de atualizações frequentes e ágeis, por isso o conceito de microsserviços se tornam uma boa opção para se construir um ambiente em cloud. E essa abordagem tem se consolidado como o preferido entre as empresas de tecnologia, uma vez que de acordo com pesquisa da Kong, 84% das organizações entendem que arquiteturas em microsserviços representam um novo paradigma ao desenvolver aplicações e as utilizam em seus ambientes em cloud.

Mas, o que são microsserviços?

Imagine um quebra-cabeças. E cada peça é construída por pequenas equipes e de forma independente. Mas que juntas elas formam um conjunto unificado. Os microsserviços funcionam praticamente dessa forma. Eles são uma abordagem de arquitetura em que são realizados pequenos serviços de forma autônoma, mas que se comunicam entre si através de APIs ou outras tecnologias. A arquitetura baseada em microsserviços, podem trazer escalabilidade para o ambiente, entregas contínuas, resiliência, além oferecer a capacidade de desenvolver aplicações com maior velocidade, e tirar proveito dos constantes avanços tecnológicos.

Confira nossos especialistas falando sobre o conceito de microsserviços

Microsserviços X Monolito

A arquitetura monolítica é uma forma mais tradicional de desenvolver aplicações, pois ela trabalha em apenas um monolítico executável, ou seja, ao contrário da arquitetura em microsserviços, a equipe de TI trabalha em um processo único em que diversos módulos do sistema são executados em uma mesma máquina, assim compartilhando recursos de processamento, memória, bancos de dados e arquivos. Essa característica não anula a capacidade de se obter um ambiente totalmente escalável, porém neste caso toda a arquitetura será escalada. Mas as dependências de processos comprometem a disponibilidade de arquiteturas monolíticas, bem como um maior impacto no sistema em casos de falhas.

Com uma arquitetura em microsserviços é construída em blocos independentes podendo ser executados de forma autônoma. Fazendo com que possam ser corrigidos em casos de falhas de forma isolada e escalados do mesmo jeito em picos de demanda, assim trazendo flexibilidade de redução de custos para o ambiente. A partir da comunicação via APIs ou desacoplamento, a arquitetura de microsserviços também pode ser reaproveitada em múltiplas aplicações.
Como pode ser visto na imagem a seguir:

Assim como apresentada na imagem acima enquanto a arquitetura monolítica trabalha com todos os serviços em um único processo, os microsserviços podem ser divididos em diversos serviços e pequenas equipes de forma que facilite o desenvolvimento de uma aplicação em cloud.

Também é importante ressaltar que após anos de uso de arquiteturas com microsserviços, foram desenvolvidas uma série de boas práticas sobre como devemos implementá-las, por isso é imprescindível buscar um parceiro como a Darede que pode lhe guiar nesse universo.

Acompanhe outros artigos sobre o mundo da TI no blog da Darede!

OUTRAS PUBLICAÇÕES

DNS, dúvidas quando precisa hospedar uma aplicação? – Parte 2

Confira a segunda parte do artigo sobre DNS. Escrito por Flávio Rescia. DNS, você sabe o que é, mas sempre tem dúvidas quando precisa hospedar uma aplicação? Até então falamos apenas de solução de nomes para IP, porém não existe apenas esse tipo de resposta, essa é a principal função do DNS, porém não é a única. Agora vamos entender as entradas DNS que podem ser utilizadas e quando utilizamos: Entrada Tipo A É a que falamos até agora, serve para resolver um nome como www.xpto.com.br para um IP como 200.200.200.1 Entrada do Tipo CNAME Para facilitar a configuração são usadas entradas CNAME (do inglês Canonical Name, Apelido), que são entradas que apontam nomes DNS como www.xpto.com.br para outro nome como www.darede.com.br. (Ferrou, agora babei!) A sacada aqui é evitar a necessidade de mudar o DNS de www.xpto.com.br sempre que o IP mudar. Imagina que o site www.xpto.com.br esteja no mesmo servidor que o www.darede.com.br que aponta para 200.1.1.1, caso tenhamos que mudar nosso provedor e trocar o IP 200.1.1.1 para outro IP, como 202.1.1.1, precisaremos trocar apenas a entrada www.darede.com.br e não o www.xpto.com.br. Uma vez que www.xpto.com.br continuará apontando para www.darede.com.br. Parece bobagem? Imagina que você tenha 1000 sites apontando para www.darede.com.br e mude a operadora ! A desvantagem no uso de CNAME é que será necessário o cliente resolver duas vezes: • www.xpto.com.br > www.darede.com.br • www.darede.com.br > 200.1.1.1 Entradas CNAME hoje são muito utilizadas por serviços gerenciados (como AWS CloudFront, AWS ELB), uma vez que o serviço lhe oferece um nome e você cria um CNAME de seu domínio (como www.darede.com.br) e aponta para o nome oferecido pelo provedor do serviço. Caso os IPs da AWS mudem, nós não precisamos nos preocupar. DICA: De acordo com a RFC não é possível criar entradas do tipo CNAME para ‘naked domain’ (exemplo darede.com.br). Nesse caso temos que configurar uma entrada ‘A’ direto para o IP. Quando precisamos apontar o ‘naked domain’ para um serviço gerenciado (que não há IP fixo), temos duas opções: 1. Apontar para um servidor (esse sim com um IP fixo), e fazer um redirecionamento HTTP 301 para ele; 2. Para AWS, podemos usar uma entrada A com Alias. Alias é um recurso da AWS para criar entradas ‘A’ para serviços gerenciados AWS (como Elastic LoadBalancer, S3, CloudFront, API Gateway, etc). O AWS Route53 garante que a entrada sempre aponte para os IPs atuais do serviço gerenciado. Entrada Tipo MX Um e-mail é enviado para voce@seudominio.com.br certo? Qual o nome DNS do seu servidor de RECEBIMENTO de e-mails? seudominio.com.br? NÃO. Geralmente seudominio.com.br aponta para seu site e não para seu servidor de recebimento de e-mail. E agora? Para isso existe a entrada do tipo MX, que vem de Mail eXchange (também acho bizarro devia ser ME, kk!). O MX aponta para nossos servidores de recebimento de e-mails (SMTP/S). Esse tipo de entrada pode apontar tanto para IP quanto para nomes, e possui uma particularidade, cada entrada possui dois valores: • Nome ou IP do servidor de recebimento de e-mail; • Prioridade, que é usada para redundância de servidores; Entradas do tipo TXT Para muitos serviços que surgiram anos após a primeira versão do protocolo HYPERLINK “https://www.ietf.org/rfc/rfc1034.txt”DNSs era preciso validar se um domínio é mesmo de propriedade de determinada pessoa/empresa. Como fazer isso? Simples, lhe faço um desafio ao mantenedor do domínio. Crio um código de teste (como 123codigo) e peço para o mantenedor configurar uma entrada 123codigo.dominio.com.br, se essa entrada for criada, significa que realmente ele tem acesso ao SOA, logo posso confiar que ele é responsável por esse domínio. Mas criar uma entrada ‘perdida’ para isso, parece uma gambiarra né? Como tudo em tecnologia que parece gambiara vira padrão. As entradas do tipo TXT surgiram para isso. É possível atribuir um texto qualquer (não apenas um nome ou IP) a essa entrada, que funciona como uma variável para qualquer finalidade. O SPF que surgiu anos depois, é um exemplo de utilização de entrada TXT. Como o serviço de e-mail, que foi criado HYPERLINK “https://tools.ietf.org/html/rfc821” à HYPERLINK “https://tools.ietf.org/html/rfc821” HYPERLINK “https://tools.ietf.org/html/rfc821″décadas atrás, não possuía uma validação da origem do e-mail, qualquer um podia (e ainda pode) enviar e-mails em nome qualquer domínio. O SPF surgiu como um padrão para garantir o dono do domínio de origem possa informar ao servidor de recebimento (destino) os IPs que podem enviar e-mail em nome de @dominiodeorigem.com.br. Para isso era/é usada uma entrada TXT. Em 2014 foi criado um outro tipo de entrada DNS dedicada a SPF. Um uso típico de entradas TXT é a validação de serviços cloud, como Google, AWS e Azure se você pode mesmo usar seu domínio. Entrada Tipo PTR É o contrário de entradas do Tipo ‘A’, usada para apontar um IP (200.1.1.1) para um nome (www.xpto.com.br). Essa entrada causa muita confusão, uma vez que ela só pode ser usada pelo mantenedor do IP e não do domínio. Em geral o mantenedor do IP é o provedor de seu Link de Internet ou serviço na nuvem. Assim somente o provedor poderá configurar o reverso de seu IP, caso precise, a única forma é abrir um chamado com eles. Os usos práticos desse tipo de entrada são poucos, mas importantes: • Identificação em caso de testes como traceroute por exemplo: • Velocidade de algumas aplicações, como SSH e traceroute, uma vez que essas aplicações, de forma nativa, resolve o Reverso do IP, o que causa lentidão quando a entrada não existe por ficar tentando resolver; • Controle SPAM, novamente o e-mail kkk! Como o SMTP foi inventado antes da invenção do SPAM, ele não previu seu uso, uma das técnicas para evitar SPAM é garantir que haja um vínculo entre o mantenedor do IP e seu utilizador, a técnica é simples. Se você está em uma LAN House, não vai conseguir pedir para configurar o reverso nele, então o servidor SMTP de recebimento espera que o IP aponte para um nome, e que esse nome aponte para o próprio IP. Caso isso não aconteça, o

Como reduzir custos com o Instance Scheduler?

Uma das principais preocupações das empresas ao trabalhar em um ambiente em cloud é a questão dos custos. Pensando nisso, nossos #cloudspecialists Flávio Rescia e Gustavo Lima prepararam um artigo completo sobre como podemos reduzir custos utilizando o AWS Instance Scheduler!

Sustentabilidade & Cloud

A empresa participou do projeto que busca dar continuidade à transformação digital do Banco ABC Brasil. Confere aí! 15/09/2023 Por Flávio Rescia Você certamente já ouviu falar no termo ESG? Talvez até saiba ou imagine o que significa, mas é bom entender bem, pois é um assunto importante, mas delicado e usar o termo inadequadamente, pode se tormar um problema. Essa sigla não é nova no mundo dos negócios, mas atualmente ela vem tomando conta do cenário corporativo mundial. Em inglês ela significa “Environmental, Social and Governance” e traduzindo para o nosso idioma ela representa a sustentabilidade ambiental, social e de governança corporativa.  Em um momento em que as mudanças climáticas vêm causando cada vez mais impacto em nossa sociedade, as empresas privadas e governamentais buscam investir e implementar processos que coloquem a sustentabilidade ambiental como um dos fatores preponderantes para a continuidade de seus negócios. É importante dizer que ESG engloba diversos outros aspectos como inclusão social e diversidade, mas vamos aqui nos centrar o item sustentabilidade, mais especificamente na sustentabilidade com o foco em tecnologia. Sustentabilidade e Tecnologia Diante de nosso cenário atual e de esforços como a política de carbono zero, que já conta com a adesão de muitas empresas, a tecnologia pode ser uma verdadeira aliada para atingir esses objetivos e, ao mesmo tempo agregar cada vez mais valor aos negócios. Uma prova disso é que a Amazon Web Services, em dezembro de 2021, introduziu um novo pilar de sustentabilidade em seu framework de boas práticas para um ambiente em cloud: o Well Architected. Criado em 2015, o Well Architected Framework busca ajudar os clientes a implementarem as melhores práticas em suas infraestruturas de cloud, para assim extraírem o melhor que a tecnologia tem a oferecer. Até 2021 ele era constituído por cinco pilares: Excelência Operacional, Segurança, Confiabilidade, Eficiência de Performance e Otimização de Custos. Hoje ele já conta com o novo pilar, agora voltado para a Sustentabilidade. Pilar de Sustentabilidade O pilar de sustentabilidade é o mais novo integrante do AWS Well Architected Framework e tem como princípio básico adaptar sua arquitetura a fim de maximizar a sustentabilidade e minimizar seu impacto ambiental. Um bom exemplo de sua utilização é a aplicação de serviços de machine learning para detectar comportamento anormal em máquinas industriais, possibilitando assim a manutenção preventiva e a redução de possíveis falhas que possam acarretar incidentes ambientais. Outro excelente exemplo é a utilização de instâncias com processadores de última geração, que são mais eficazes e economizam mais energia, como as instâncias AWS Graviton, que usam processadores ARM que garantem um maior desempenho, utilizando cerca de 60% menos energia.  O pilar de sustentabilidade do Well Architected Framework atua em 6 pontos:  A compreensão do impacto de sua estrutura; O estabelecimento de metas de sustentabilidade; O aumento da eficiência de seus workloads;  A atualização de hardwares e softwares; A utilização de serviços gerenciados; A redução do impacto downstream de suas workloads em nuvem.  A partir desses pontos, a AWS acredita que é possível reduzir o impacto ambiental do ambiente em cloud e garantir uma estrutura totalmente otimizada, eficiente, segura e sustentável.  É importante notar, que além do apelo ESG e o intuito de colaborar com o coletivo de nosso planeta, a aplicação práticas sustentáveis, traz com ela a redução de custo, já que serviços mais sustentáveis em nuvem, são também mais barato. São mais baratos pela eficiência energética é claro, mas também devido às políticas de redução de missão de carbono, e o conceito de crédito de carbono que faz com que governos incentivem em empresas que reduzem a emissão de carbono. O comprometimento da Darede com a Sustentabilidade A Darede segue um sólido empenho em impulsionar a sustentabilidade por meio do desenvolvimento de seus produtos e profissionais, incluindo no seu roadmap de desenvolvimento de médio e longo prazo, com ações incluindo: Treinamento de seus colaboradores nas melhores práticas de acordo com os princípios do Well-Architected. Desenvolvimento de ofertas de serviços em operações com foco em otimização do consumo de recursos, e redução do consumo energético e das emissões de carbono. Conscientização dos clientes sobre os seus workloads e como é possível otimizá-los para uma direção mais eficiente, tanto financeiramente quanto energeticamente. Assim, a Darede reafirma seu compromisso em liderar a transformação para um futuro mais sustentável, impactando positivamente tanto seus clientes quanto o meio ambiente. A Darede é o primeiro (e ainda único) parceiro da AWS é habilitada com “Parceiro Diferenciado de Well-Arcihtected”, esse selo foi em função da prática constante do método da AWS de boas práticas de uso de nuvem. Flavio Rescia Dias CTO & Co-Fundador da Darede flavio.rescia@darede.com.br Atuando desde 2006 no mercado de tecnologia, Flávio Rescia é um dos fundadores da Darede, empresa de consultoria de serviços de TI, na qual atua como CTO. Ele possui diversas especializações no setor, sendo a última a Certificação AWS Solutions Architect – Professional.

Precisa de ajuda? Ligue para nossa equipe no telefone +55 11 3900-1010

SOLICITE UM ORÇAMENTO

Nosso objetivo é oferecer inovação sustentada,
aliando resultados e valores.

© Copyright 2024 - Darede
Todos os direitos reservados | By Damidia Marketing & Conteúdo

EMPRESA

SOLUÇÕES

NEWSLETTER

REDES SOCIAIS

Facebook-square Linkedin Instagram Youtube

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

ACEITAR & FECHAR
RECUSAR