+55 11 3995-6919 / +55 11 3900-1010

Conectando On-Premises na AWS

Conectando On-Premises na AWS via Direct Connect

Com a popularização da utilização dos serviços em Cloud, uma das maiores necessidades é fazer com que o ambiente On-Premises de uma empresa possa se conectar ao ambiente Nuvem. Com a finalidade de fazer um uso eficiente dos seus recursos. Pensando em alguns itens importantes nessa conectividade, temos a disponibilidade, o baixo custo, a velocidade de acesso à informação e a segurança dos dados.
Atualmente o uso desse acesso se dá através de um serviço baseado em internet chamado de VPN. Ele permite que, possamos manter uma conectividade entre a Cloud e o ambiente On-Premises conforme podemos ver no exemplo abaixo:

DESENHO 1 – CONECTIVIDADE CLOUD_ON-PREMISES VIA VPN

Utilizando esse método de conectividade, os dados que serão trafegados por essa tecnologia são criptografados e encaminhados via Link de Internet entre os ambientes. O que permite dizer que o tráfego está sendo enviado de forma segura. No entanto, a alta velocidade não é garantida, bem como a redundância. Já quando se trata dos links públicos da empresa, esses fatores são dependentes da qualidade do provedor que oferta essa conectividade, gerando uma certa dificuldade no gerenciamento e disponibilidade da informação via VPN.

Direct Connect

Para melhorarmos essa comunicação entre AWS Cloud e o On-Premises, a Amazon nos fornece uma opção de conectividade através de um serviço chamado Direct Connect. Ele utiliza uma conexão L2L via um Parceiro AWS (Links dedicados com a Equinix ou Tivit e compartilhado (hosted) com outras operadoras como Telium e Mundivox) para conectar esses ambientes, como se fosse uma extensão da rede interna do On-Premises para a AWS.
Conforme pode ser visto no desenho abaixo, provendo uma conexão dedicada, melhoramos o desempenho e aceleramos a transferência de dados com segurança e bom custo-benefício utilizando São Paulo e Rio de Janeiro como opções. Para locais mais afastados o custo pode ser maior.

DESENHO 2 – CONECTIVIDADE CLOUD_ON-PREMISES VIA DIRECT CONNECT

Basicamente, o Direct Connect é um link dedicado que conecta a AWS ao ambiente On-Premises. Após essa comunicação física estabelecida, as duas partes devem fazer o uso do protocolo dinâmico conhecido como BGP para estabelecer a sessão de divulgação dos blocos IPs, tanto da AWS quanto do ambiente On-Premises. Esse protocolo permite os filtros através das políticas de BGP que ajudam no bom funcionamento e gerenciamento do serviço.
Com esse modelo de conexão, que antes era utilizado para a comunicação via VPN, associamos o VGW, ou Virtual Private Gateway , ao Direct Connect. Assim o uso da VPN passa a ser redundante ao Direct Connect automaticamente através da prioridade do serviço pela AWS. Em caso de falha no serviço, a VPN assumirá o tráfego sem precisar de intervenção manual para o funcionamento, ou seja, aumentamos a disponibilidade, melhoramos a taxa de transferência, temos redundância na conectividade e mantemos a segurança do transporte da informação. Conforme mostra o desenho abaixo:

DESENHO 3 – CONECTIVIDADE CLOUD_ON-PREMISES VIA DIRECT CONNECT

Até então, esse cenário ainda é o mínimo requisitado para um bom uso do serviço de Direct Connect. Pois mantemos nossa redundância através da VPN, tendo como requisito para esse failover o uso da Internet. Todavia, para adotarmos as melhores práticas fornecidas pela AWS e no intuito de utilizar o serviço de forma mais eficiente e segura. É recomendado que o Direct Connect seja conectado entre AWS e On-Premises por duas conexões físicas distintas. Sendo, por exemplo uma conexão física entre AWS x Equinix-SP4 e uma outra AWS x TIVIT-SPO. Dessa forma temos uma redundância efetiva do serviço. Além de manter o mesmo padrão de funcionamento sem necessidade de acesso para a nuvem via Internet. Sendo assim, não só o desempenho, segurança e disponibilidade se mantém no mesmo nível. Como também, nesse caso, teremos resiliência:

DESENHO 4 – CONECTIVIDADE CLOUD_ON-PREMISES VIA DIRECT CONNECT REDUNDANTE

Como conclusão temos que, o Direct Connect é o serviço que aumenta não apenas a velocidade da sua conexão com a AWS. Consequentemente diminuindo a latência. Como também, se usado da maneira correta, proverá maior disponibilidade, resiliência, redundância e segurança da informação. Levando em consideração que no modelo de cobrança da AWS em cima de DTO (Data Transfer Out). Utilizando o serviço de Direct Connect a cobrança fica mais barata. Bem como o serviço se paga ao tempo de uso de dados que são utilizados por ele.

Laia mais textos técnicos escritos pelos colaboradores da Darede em nosso blog!

Infraestrutura como Código: Como automatizar o provisionamento de serviços na nuvem

Atualmente o termo DevOps se popularizou no mundo da tecnologia. Sua definição se baseia simplesmente na união de desenvolvimento com operações. E dentre as ferramentas que compõem estes processos integrados está a infraestrutura como código. Esse termo é uma metodologia de processos de provisionamento de infraestrutura tecnológica usada para que as respectivas equipes. As de DevOps principalmente. O objetivo é que elas possam gerenciar e provisionar infraestrutura por meio de código de forma programática. Ao invés de ter que recorrer ao acesso físico ao hardware ou até mesmo através de portais ou ferramentas de configuração.
Resumindo, a abordagem Infraestrutura como Código nada mais é do que a entrega de uma infraestrutura ágil. Utilizando-se de codificação simples e objetiva.E sem a necessidade de diversos passos e processos para se preparar um ambiente, sem perder o poder de controle, segurança, qualidade e disponibilidade.

CloudFormation

A Amazon Web Services (AWS) possui um serviço chamado CloudFormation que provisiona sua infraestrutura na nuvem através de um código em formato JSON ou YAML. Caso o usuário não possua experiência com esses modelos existe o CloudFormation Designer: uma ferramenta gráfica que o auxilia a criar e modificar seus modelos de template.
A vantagem de ter sua infraestrutura baseada em código se dá através da possibilidade de colocar um ambiente em produção com apenas um clique. Bem como replicar o mesmo quantas vezes for necessário. Por exemplo: uma aplicação precisa estar em mais de uma região. Neste caso é necessário pegar seu template e aplicar no CloudFormation na região desejada. Assim sua infraestrutura estará pronta em minutos! Dessa forma não será preciso convocar um grande time de TI para subir a infraestrutura manualmente. Além de ganhar tempo e reduzir possíveis falhas.

Representação do CloudFormation

No CloudFormation também temos o conceito de modelo que são os templates nos mesmos formatos. Eles descrevem os recursos da AWS que são necessários para fazer a implantação da aplicação. E as pilhas (stack) são o conjunto de recursos descrito nos modelos. Elas podem ser criadas, atualizadas e excluídas com facilidade!
Sabemos que é preciso realizar um upgrade na infraestrutura à medida que nosso negócio cresce. Por este motivo é muito importante ter um controle de versões. Para que quando ocorra algum problema seja possível identificar com mais rapidez o que foi feito. E assim voltar para uma versão estável do ambiente assim deixando-o disponível novamente sem prejudicar os usuários. Lembrando que ao criar ou atualizar sua pilha o CloudFormation avisa se houver algum erro.
Agora você deve estar se perguntando sobre o valor para ter essa automatização, eis uma boa notícia: não há custo para usar o CloudFormation. Contanto que sejam recursos da AWS. Serão cobrados apenas os recursos que forem provisionados com instâncias EC2, Elastic Load Balancing etc.

Ansible

Além da ferramenta provida para a AWS existem também algumas ferramentas que são adotadas pela comunidade para o mesmo objetivo. O Ansible que é uma ferramenta de automação de código aberto usada para configurar servidores, instalar softwares e executar uma alta espécie de tarefas de TI a partir de uma localização central. O Ansible é operado hoje pela RedHat e tem todo o suporte desta grande empresa. Trazendo uma grande confiabilidade à ferramenta.

É um mecanismo sem agente de um para muitos, onde todas as instruções são executadas a partir de uma máquina de controle que se comunica com clientes remotos preferencialmente em SSH, embora outros protocolos também sejam suportados.
Além disso, o Ansible também provê uma linguagem simples de se escrever em YAML, ou seja, de fácil interpretação para suporte, desenvolvedores e gerentes de TI.
No início da ferramenta, somente rodava em Linux Core. Porém, agora também roda no Windows sem precisar de formas alternativas para funcionar.
A vantagem mais clara de utilizar uma ferramenta como o Ansible é que não há limitação à plataforma de nuvem que a ferramenta está aplicada, podendo, com alguns ajustes, portar o código para ser aplicado em uma nuvem diferente, ou mesmo facilitar a migração do seu workload caso esse seja seu objetivo.

O ponto negativo no entanto está na necessidade de se prover a infraestrutura para operar o Ansible. Tendo que lidar com a gestão tanto da parte de sistemas operacionais quanto de software, adicionando uma camada de trabalho extra para operar o serviço.

Até mais!
Para mais artigos sobre o mundo da AWS confira em nosso blog!


Amazon Workspaces

Solução Home Office – Amazon Wokspaces

O uso da VPN (Virtual Private Cloud) vem cada vez mais se popularizando no país. Assim como o Home Office e os usuários remotos.
Esse artigo tem como foco empresas que utilizam o serviço web da Amazon. Uma vez que a plataforma tem disponível a solução DaaS na nuvem da AWS. Isso mesmo! Um serviço que entrega desktops totalmente acessíveis de qualquer lugar. Desde que o dispositivo tenha conexão com a internet. Seja ele um tablet, laptop ou até mesmo um smartphone.

Estamos falando das Amazon Workspaces, então, vamos imaginar um cenário muito comum nos dias atuais, digamos que devido toda a paralisação por conta do COVID-19, sua empresa teve que enviar seus funcionários para trabalhar de casa, no entanto, eles não utilizam laptops,mas sim, computadores de mesa, dessa forma, se torna inviável levá-los para casa não é?

Com essa tecnologia, é possível provisionar Desktops na nuvem para que os colaboradores possam acessar a AWS através dessa máquina, seja ela Windows ou Linux. As workspaces rodam dentro de uma VPC na AWS, visto isso, o ideal é que haja também uma vpn Site-to-Site entre essa VPC e o ambiente On Premises da Empresa, assim, através dos desktops virtuais, também será possível acessar recursos internos como sistemas ou servidores que rodam no escritório.
Com o propósito de simplificar o gerenciamento de dezenas, centenas, ou até milhares de Desktops virtuais, também é possível utilizar o Amazon AD Connector, para que os usuários possam acessar apenas suas respectivas máquinas através de seus usuários provisionados dentro do AD da empresa, elevando a segurança das máquinas, GPO para limitar acessos, assim como no escritório.
A Workspace é integrada com o Amazon KMS, sendo assim, todo e qualquer acesso ao volume persistente passa por uma camada de criptografia, paralelo a isso, nenhum dado do usuário é armazenado no dispositivo de acesso, viabilizando a segurança da informação.

Serviço On Demand

Como último tópico, iremos abordar o custo. Como tudo em cloud, esse serviço também se encaixa como On demand. Ou seja, a empresa pagará apenas o utilizado de recursos nas workspaces. Uma vez que se o usuário irá trabalhar apenas em horário comercial. Porque eu devo pagar um recurso que fica full-time? Não faz muito sentido, não é?
Assim, os custos são reduzidos a ponto de não haver a necessidade da compra de hardware. Podendo entregar uma solução compatível com outros serviços, altamente disponível, totalmente gerenciável, facilmente escalável, seja escalabilidade de quantidade de Desktops ou de recursos computacionais. Onde há segurança nos dados e redução de custos, tudo isso na nuvem.
Leia mais sobre home office em nosso blog!

Processo de Integração e Deploy Contínuo (CI/CD) na AWS – Parte 2

Abaixo, segue um tutorial simples e eficaz de como realizar esta arquitetura na sua rede AWS.
Hands On!
Para começarmos, será necessário criarmos duas IAM Roles:
• IAM role para o CodeDeploy realizar o deploy na EC2 instance;
• IAM role para a EC2 acessar o S3.

1° CodeDeployRole:

– Vá até o seu console da AWS e entre no serviço do IAM:

– Após acessar o serviço do IAM, clique em Roles:

– Agora, clique em Create Role:

– Selecione o serviço do CodeDeploy:

– Selecione o Case do CodeDeploy e depois clique para adicionar as permissões:

– Selecione AWSCodeDeployRole e clique em Next:

– Dê um nome a sua Role e clique em Create Role:
https://www.darede.com.br/wp-content/uploads/2020/04/24140109/Processo-de-Integra%C3%A7%C3%A3o-e-Deploy-Cont%C3%ADnuo-na-AWS-7.png

– A regra foi criada com sucesso:

2° S3 Role:

Agora faremos um processo parecido com o anterior, porém, agora selecionaremos o serviço de EC2.

– Clique novamente em Create Role depois, selecione EC2:

Clique em Next.
– Nas permissões, selecione AmazonS3ReadOnlyAccess:

Clique em Next.
– Agora, dê um nome para role que acabamos de criar:

– Clique em Create role.

3° Vamos criar uma instância EC2 que receberá o deploy.

Para que funcione perfeitamente, será necessário utilizarmos o CodeDeploy Agent na máquina:
– Primeiro, vamos criar uma instância. Acesse o Painel EC2 > Instances e vá em Launch Instance:

– Neste tutorial, iremos utilizar um Amazon Linux:

– Agora, selecione a instância do tipo t2.micro:

Clique em Next.
– Agora, selecione sua VPC, sua Subnet e Auto-assign Public IP deixe como Enable.

– Na parte do IAM Role, selecione a role que criamos para a EC2:

– Mais pra baixo, desça até a parte do Advanced Details, mais precisamente na parte do User data e cole o seguinte código:
#!/bin/bash
yum -y update
yum install -y ruby
yum install -y aws-cli
cd /home/ec2-user
aws s3 cp s3://aws-codedeploy-us-east-1/latest/install . –region us-east-1
chmod +x ./install
./install auto

Para saber mais sobre User data, clique aqui.

Deve ficar algo parecido com isto:

Lembrando que, os valores das regiões estão de acordo com a região que estou trabalhando, neste caso North Virginia (EUA).

Clique em Next.
– Na próxima página, referente ao volume, não será necessária nenhuma alteração, é o suficiente para realizarmos este tutorial.
Clique em Next.
– Na parte das TAGS, iremos adicionar a tag Name, para que possamos identificar a máquina no painel das instâncias:

Chave: Name
Valor: EC2-CodeDeploy
– Agora, parte dos Security Group’s, selecione as opções de liberação para SSH e HTTP. Na parte do Source selecione My IP. Deve ficar algo assim:

Clique em Next.
– Confirme todas as informações e clique em Launch. Selecione uma chave. pem que você tenha acesso e finalize o processo de criação.

4° Após a máquina estar com o Estado Running, acessa-a via SSH.

Neste procedimento, estou usando o PuTTY, caso queira saber mais, clique aqui.

– Após acessar a máquina via SSH, vamos validar se o CodeDeploy Agent está instalado:

Rodando como o esperado.

– Agora, nós iremos criar os arquivos necessários para o deploy funcionar.

– Entre no /tmp da máquina:

– Crie uma pasta para receber os arquivos:

– Rode o seguinte comando:
url -O http://s3.amazonaws.com/aws-codedeploy-us-east-1/samples/latest/SampleApp_Linux.zip

– Descompacte o arquivo:

– Delete o arquivo .zip:

– Digite os seguintes comandos de acordo com a documentação do Github:
git init
git add .
git commit -m “first commit”
git remote add origin git@github.com:YOUR_USERNAME/YOUR_REPOSITORY.git
git push -u origin master

5° Agora, iremos criar a parte do CodeDeploy.

– Acesse a console da AWS e filtre pelo serviço do CodeDeploy:

– Após acessar o serviço, clique em Applications:

– Clique em Create Application:

– Dê um nome para sua aplicação e selecione a plataforma EC2:

Clique em Create Application.
– Depois que criamos a aplicação, é necessário criamos o grupo de depoloy (Deployment group), onde nós apontamos para onde deve ser direcionado o deploy. Clique em Create Deployment Group:

– Dê um nome para seu grupo de deploy:

– Seleciona a role criamos no primeiro passo:

– Na parte de configuração do ambiente, é onde selecionamos para qual recurso iremos apontar o deploy, neste caso, utilizaremos o TAG Name da EC2 para identificarmos o recurso:

– Nas configurações de deploy (Deployment settings), deixe esta configuração:


– Como neste caso não temos Load Balancer nesta arquitetura, podemos desabilitar esta opção:

Clique em Create Deployment Group.

6° Com essas configurações feitas, podemos testar o deploy de forma manual:

– Para isso, entre no deployment group que acabamos de configurar. Este é o caminho:

– Após acessar, clique em Create deployment:

– Selecione a opção que sua aplicação está no Github. Depois dê um nome à sua conexão com o git e clique em Connect to GitHub:


– Será aberto um pop-up solicitando autorizar a integração:

Pode confirmar a integração entre as plataformas.
– Deverá aparecer algo parecido com isto em sua tela:

– Preencha os dados com o nome do repositório e o ID do commit, gerado pelo passo quatro que fizemos:


A tela deverá ficar assim:

O nome do repositório deve ter o seguinte formato: “GITHUB_USERNAME/REPOSITORY_NAME”
– Dê uma descrição ao seu deployment:

– No final da página clique em Create Deployment.

Após isso, podemos notar que a estrutura está funcional e operando:

7° Agora, iremos usar o recurso do CodePipeline para automatizar todo este processo de deploy sempre que houver alterações no repositório:

– Entre no serviço do CodePipeline:

– Depois clique em Create Pipeline.
– Dê um nome para sua pipeline:

Clique em Next.
– Agora no Source selecione GitHub:

– Clique em Connect to GitHub:

– Forneça acesso ao CodePipeline:

– Selecione o repositório:

– Também selecione a Branch:


– Usaremos os webhooks padrões do GitHub:

Clique em Next.
– Neste tutorial, não será necessário utilizarmos o codebuild, então podemos pular esta parte. Clique em Skip build stage:

– Seguindo, escolha o provedor de deploy (Deploy provider) o CodeDeploy que já está devidamente configurado:

Selecione a região e as outras duas informações que criamos nos passos anteriores, na configuração do CodeDeploy:

Clique em Next.
– Agora revisando as informações, desça até o final da página e clique em Create Pipeline.

– Note, que a Pipeline rodou perfeitamente e já fez o deploy automático do último commit utilizado no repositório:

8° Para validar o sucesso do deploy, vá até o painel das Instâncias EC2 e procure a instância que criamos neste tutorial:


– Procure pelo campo Public DNS(IPv4):

Copie este valor.
– Abra uma nova guia e acesse este endereço.
Será exibida uma tela como essa:

9° Agora, nós iremos validar o funcionamento do deploy automatizado.

Iremos fazer uma modificação qualquer no código, iremos realizar o push para o GitHub e a alteração será automaticamente aplicada na instância EC2.
– Acesse a máquina Linux e abra o arquivo .html com seu editor de texto favorito:

Neste caso, usei o VIM para editar o arquivo.
– Após abrir o arquivo, editei a cor de fundo da página:
Antes:

Depois:

– Depois de alterado, vamos commitar as alterações:

– Agora nos resta realizar o push:

Coloque suas credenciais e finalize o processo.
– Acessando as pipelines, é possível ver o deploy funcionando automaticamente:


– Volte na página web que abrimos anteriormente e dê um F5, note que a cor da página mudou:

Bom, finalizamos por aqui nossa configuração de CI/CD de uma forma simples e eficaz.

Workloads Microsoft

Modernização de Workloads Microsoft SQL na AWS

A AWS desenvolveu o Migration Acceleration Program (MAP). Um programa para que o cliente possa trazer a suas cargas de trabalho com segurança e performance. Se adequando a sua estrutura de negócio. Seja em ambiente Windows ou Linux.

Vamos entender como seria a modernização de cargas de trabalho do Microsoft SQL Server para a AWS.

Vamos trazer um cenário que o cliente possui um servidor com um SQL Server. Ele deseja trazer essa carga para da AWS. Levando em consideração que a sua preocupação seja somente comercial. Ou seja, a atenção do cliente está voltada somente em questões comerciais do negócio. Assim desejando que esse banco seja gerenciado pela AWS. O serviço mais indicado é o Amazon RDS (Relational Database Service) que é uma aplicação da AWS que automatiza tarefas demoradas de administração, como provisionamento de Hardware, atualização de patches, backups, entre outros.
Um outro cenário é de um cliente que também possui um servidor com um SQL Server e deseja trazer essa carga para da AWS, porém ele deseja ter total gerencia do banco, seja por sua própria equipe de suporte, ou através de suporte de um parceiro AWS. Neste exemplo podemos utilizar uma instância EC2 para essa carga de trabalho, a AWS fornece várias ferramentas que podem ser utilizadas para a migração de servidor. para sanar dúvidas de qual serviço empregar, ou como usar, é de grande valia utilizar o recurso de MAP, assim auxiliando o cliente nessa decisão. Lembrando que este serviço pode ser utilizado não somente para migração de ambiente, mas também para a modernização de outros recursos. Lembre-se na dúvida, sempre peça ajuda!

Quer saber mais? Acesse o link de documentação MAP da AWS – https://aws.amazon.com/pt/migration-acceleration-program/

Link da documentação sobre RDS AWS – https://aws.amazon.com/pt/rds/

Leia mais sobre o mundo da AWS em nosso blog!

Processos CI/CD

Processo de Integração e Deploy Contínuo (CI/CD) na AWS – Parte 1

Antes de introduzir o assunto de CI/CD, precisamos entender um conceito que vem ganhando grande força no mundo da tecnologia: o DevOps. Esse termo é bem sugestivo pois se deriva da junção das palavras “desenvolvimento” (em inglês, development) e “operações” (em inglês, operations). Essa palavra descreve um conjunto de práticas para integração entre as duas equipes. Entretanto, há a possibilidade de incorporação de outros setores. Como por exemplo, o de controle de qualidade, permitindo adotar processos automatizados para um desenvolvimento rápido e seguro de aplicações e serviços.
Também não podemos deixar de falar de Pipeline, uma vez que esses assuntos estão diretamente ligados. Na tradução literal, pipeline, traz o conceito aplicado a gasodutos e encanamentos. Na área de TI, esse termo vem se mostrando cada vez mais atual e utilizado. Seu objetivo, é automatizar o processo de entrega de um software. Usando publicações e correções em uma aplicação de forma contínua. E assim, garantindo a qualidade na entrega final deste processo.

Vantagens de se utilizar pipeline:

  • Automatização benéfica, agilizando o processo e evitando erros humanos; (Quanto menos erros, a entrega será mais rápida)
  • Fácil integração de pequenas atualizações;
  • Como os desenvolvedores não se preocupam em entregar o código até produção, eles conseguem ficar mais focados na configuração de novas features;
  • Possibilidade de realizar atualizações de código pequenas, frequentes e reversíveis.
  • Concentração de logs de teste, atualizações e deploys ficam acessíveis para verificação a qualquer momento;
  • Bugs são identificamos de forma mais rápida, agilizando as correções.
  • CI – Continuous Integration

    Bom, a definição básica de integração contínua (CI) é a prática de automatizar a integração de alterações individuais de código, chamadas de branches, de vários colaboradores em um único projeto de software através do merge de diversos branches em um código consolidado. O processo de CI é composto por ferramentas automáticas que apontam, a correção do novo código antes da integração.
    Temos exemplos de ferramentas de repositórios de cógido com esse recurso, o GitHub, BitBucket, GitLab entre outros. Vale lembrar que na AWS temos o serviço do CodeCommit, que é extremamente funcional e de uso parecido dessas ferramentas mais famosas, visto que ele hospeda repositórios baseados em Git. Caso queira ter mais informações sobre este serviço, clique aqui.

    CD – Continuous Deployment/ Continuous Delivery

    Há dois conceitos ligados a sigla CD. Mas seu principal objetivo é a prática de desenvolvimento de software em que as alterações de código são criadas, testadas e preparadas automaticamente para a liberação em um ambiente de produção. Ele expande a integração contínua. Implementando todas as alterações de código. Seja em um ambiente de teste, ambiente de produção ou em ambos. Após a conclusão do estágio de construção. Quando a liberação deste deploy é feita de forma de aprovação. Ou seja, é necessária uma intervenção humana para a esteira ser finalizada, temos o conceito de Continuous Delivery. Já quando este processo é totalmente automatizado, com todos os testes funcionando, sem a autorização explícita humana, temos o conceito de Continuous Deployment. Algumas das ferramentas mais famosas para este processo temos o Jenkins. Ele utilizado em todo o mundo, devido a sua grande comunidade e infinidade de plugins, garantindo inúmeras integrações.
    Na AWS, temos o AWS CodePipeline. Ele nos ajuda nessa integração. Na plataforma, temos serviços como o CodeBuild, para você compilar sua aplicação. E o CodeDeploy para realizar os deployments em seus recursos necessários para seu software. Para entender melhor sobre o AWS CodePipeline, clique aqui.

    Em uma estrutura padrão de CI/CD, temos a seguinte estrutura de funcionamento:

    AWS Code Pipeline

  • Source: O local onde está o código da aplicação;
  • Build: Momento em que é efetuado um merge do código já existente com o código de atualização. Aqui também pode ser efetuado a compilação da sua aplicação. Gerando toda estrutura;
  • Test: Este passo é um dos essenciais para garantir uma entrega rápida e segura. Aqui são efetuados testes automatizados para garantir o pleno funcionamento da aplicação.
  • Staging: Após os passos acima ocorrerem perfeitamente, a aplicação é enviada para um ambiente de staging, mais próximo a realidade em que sua aplicação irá funcionar. Nele são realizados testes adicionais de funcionamento da aplicação e infraestrutura antes de ir definitivamente para o ambiente de produção.
  • Production: Finalizando a pipeline, temos o ambiente de produção, após ter sido devidamente testado e atualizado com os processos anteriores, além de depender do nível de maturidade dos seus testes, essa nova versão lançada está funcionando perfeitamente e foi atualizada de forma automática. Finalizando o CI/CD.
  • Deploy Automatizado

    Vamos agora criar na prática um exemplo de deploy automatizado simples na AWS juntamente com seu GitHub, uma das plataformas de versionamento de código mais utilizadas no mundo , para que você veja as várias maneiras de possíveis integrações na AWS. Para isso, foi realizado a seguinte arquitetura:

    Na ilustração acima, os desenvolvedores fazem o “push” da aplicação para o Github. Neste momento, juntamente configurado com o AWS CodePipeline, o Git dispara um webhook toda vez que ocorre uma alteração de código. Assim o CodePipeline gera um Artefato da aplicação, manda para um bucket S3 e aciona o CodeDeploy para finalizar o deploy automático em uma Instância EC2. Lembrando que, como fizemos um método simples de deploy, não temos um passo de build ou test, esta ilustração serve apenas para que você veja a configuração de um continuous deployment de maneira fácil.
    Na parte 2 traremos um tutorial de como realizar esta arquitetura na sua rede AWS.

    Cloud e Coronavírus – O mundo do trabalho pós-pandemia

    Quarta-feira, 11 de março de 2020, o diretor geral da Organização Mundial da Saúde (OMS), Tedros Adhanom Ghebreyesus, declarou que, a partir daquele dia, viveríamos uma pandemia causado pelo coronavírus. Nas semanas seguintes, diversas lideranças políticas de todo o mundo começaram a anunciar regimes de quarentena em suas cidades, estados, províncias, países. Enquanto algumas resistiram em reconhecer que a situação era de calamidade. Fomos apresentados a uma situação atípica no mundo. Teríamos que ficar em casa, poderíamos sair apenas por necessidade. Restaurantes tiveram que operar apenas com delivery. Empresas tiveram que mandar seus colaboradores para casa.

    Novo normal

    Essa nova realidade potencializou o conceito de home office, que já tinha uma certa popularidade em alguns setores. Mas diante da situação que esse vírus nos colocou, a ideia do trabalho remoto foi sendo difundida em massa. E é aí que a cloud computing entra em campo. Da noite para o dia, equipes precisaram incluir na rotina de trabalho ferramentas remotas, as quais visam manter ativas as atividades de um negócio durante esta crise. Algumas delas podem ser vistas no post anterior.
    Algumas empresas certamente tiveram grandes dificuldades de implementar esse modelo. Uma vez que de acordo com a Kaspersky, 44% dos trabalhadores da América Latina trabalhavam em lugares com uma política restritiva ao uso de smartphones.

    E por causa disso, boa parte das empresas tiveram que se adaptar a essa nova realidade. Que ficou focada em investimentos no setor de TI. Transferindo toda sua estrutura para a nuvem. Necessidades como, a segurança da informação, o compartilhamento de dados, o aumento da produtividade em ambientes de TI, dentre outras, ficaram cada vez mais evidentes. Atividades que irão mudar totalmente as relações de trabalho, pois ao perceber a redução de custos oriundas desse novo cenário, empresas certamente repensarão sobre a manutenção de grandes espaços físicos para suas operações, tanto que analistas do setor de tecnologia estimam que a utilização de trabalho remoto no Brasil irá aumentar cerca de 30%. O e-commerce e o ensino a distância serão outros departamentos que certamente terão um crescimento agudo após a pandemia.

    Uma adaptação menos dolorosa

    Provavelmente será uma adaptação certamente menos dolorosa. Pois num passado recente tivemos uma crise de escala global que mudou o panorama da relação da tecnologia com o ambiente empresarial: Os ataques terroristas de 11 de setembro de 2001. As consequências deste ataque influenciaram diretamente a perspectiva do setor de TI no mundo. Principalmente na área de proteção de dados. Uma vez que boa parte das empresas detinham sua sede em uma das torres do World Trade Center e seus datacenters no prédio ao lado. Os quais foram perdidos com a queda das torres. Diante disso executivos de TI perceberam que deveriam estar preparados para o improvável. Como na crise a qual estamos enfrentando.

    O home office no mercado de trabalho da tecnologia da informação já é uma realidade em diversos setores já algum tempo. Mas devido ao cloud, (e à pandemia, é claro) este conceito se espalhou. Num passado recente, desenvolvedores estavam mais acostumados em realizar o trabalho remoto. Mas hoje em dia já é possível um profissional do setor de infraestrutura trabalhar à distância. Tudo graças a computação em nuvem.

    E agora?

    O que podemos concluir diante desses fatos, é que as relações trabalhistas serão vistas de forma diferente, e o uso de soluções cloud poderão ser determinantes para o sucesso de um negócio. A Darede, com mais de 7 anos no mercado, oferece diversos tipos de soluções que ajudarão a modernizar o ambiente de TI de uma empresa, contando com profissionais altamente capacitados que prestam um atendimento personalizado e estão preparados para atuar em todas as necessidades do cliente principalmente neste período em que o trabalho remoto é essencial para a manutenção das atividades de uma empresa.
    Leia mais artigos sobre home office em nosso blog!

    Afinal, o que é Cloud?

    O termo tem uma conotação muito abrangente e nos últimos anos um apelo de Marketing muito maior que uma definição técnica, tudo hoje é relacionado com Cloud/Nuvem com o intuito de agregar valor comercial ao produto ofertado.
    Qualquer definição dada ao termo pode ser contestada, uma vez que não existe um órgão, instituição ou comitê que especifique termos de tecnologia, até projetos como o Techterms e Wikipédia, são a opinião de pessoas a respeito do uso do termo e não uma unanimidade. Assim o conteúdo desse artigo é nossa opinião sobre o uso do termo Cloud e mais importante nossa definição do que ”Cloud Computing” (que para nós são coisas diferentes).


    O início

    Desde o primeiro diagrama de tecnologia que vi, o desenho da nuvem representa a Internet ou uma conexão WAN (externa à rede Interna):


    Diagrama/Topologia de Rede de Exemplo

    Fica claro então, que Cloud está relacionado a rede pública, ou o que está externo ao ambiente de rede interna.
    Muito antes do termo Cloud ser usado, serviços já eram oferecidos na Internet, como hospedagem de sites, email, streaming de vídeo, etc. Tudo mudou com o conceito de ”Cloud Computing”, que foi largamente difundido com o lançamento dos primeiros produtos da AWS (Amazon Web Services).

    Com o sucesso dos produtos da AWS e da popularização do termo, outros serviços passaram a ser associado a Cloud, inclusive serviços de Internet que já existiam se associaram ao termo Cloud como apelo de Marketing e como símbolo de inovação.

    Como diversos produtos são associados ao termo Cloud, organizamos eles em grupos, ou tipos de produtos Cloud. Uma abordagem mais utilizada (inclusive pela Microsoft) organiza os produtos Cloud em:

    • OnPremise: Ao que está desassociado da nuvem, fora da Cloud;
    • Infrastucture As A Service (IaaS): Quando os equipamentos, ou Infraestrutura, são oferecidos como serviço, e o Sistema Operacional (Windows, Linux, etc) é responsabilidade nossa (quem contrata);
    • Plataform As A Service (PaaS): Aqui o Sistema Operacional não é responsabilidade do cliente, não temos acesso ao Windows/Linux, usamos por exemplo, apenas o Banco de Dados, Servidor Web, etc.
    • Software As A Service (SaaS): Aplicação completa oferecida como serviço, o cliente apenas consome o App, exemplo são ERP, Serviço de Email, Spotfy, Netflix, etc.


    Fonte: https://azure.microsoft.com/pt-br/overview/what-is-paas/

    Porém para nós da Darede, a visão acima não é o melhor agrupamento, uma vez que não agrupa serviços que devem/podem ser comparados entre si, e a linha entre eles é muito tênue e pode causar confusões. Entendemos que o melhor agrupamento dos serviços de Cloud são:

    • Cloud Computing: Aqui é o que a maior parte dos profissionais de TI entendem por Cloud, funciona como uma terceirização de hardware. Porém diferente de colocation, VPS e Servidor dedicado, que já existiam antes do conceito de ”Cloud Computing”, aqui falamos em:
    o AWS,
    o Azure,
    o e Google Cloud Platform.

    • Licenciamento como Serviço (LaaS): É muito comum ver software sendo vendidos ’em Cloud’. A ideia aqui é pagar pelo tempo que usa e não um valor pela aquisição de licença como o antigo modelo praticado desde a década de 80. A receita tem sido boa tanto para quem vende, como para quem compra. Exemplos de LaaS:
    o Adobe,
    o Pacote Office,
    o AutoCAD

    • Software como Serviço (SaaS): Aqui incluímos sistemas que são contratados como serviço e hospedados na Internet. O fornecedor usa sua grande infraestrutura de equipamentos e vende em pequenas fatias, por exemplo $1 por usuário por mês. Aqui alguns produtos em SaaS:
    o Google G Suite,
    o Office 365,
    o Pipedrive,
    o SalesForce
    o Dropbox,
    o Spotfy,
    o Netflix

    Agora fica mais fácil entender qual ‘Set’ de produtos você irá utilizar em cada um dos Modelos de Cloud, ou usar onPremise se fizer sentido.

    Aqui algumas perguntas que pode lhe ajudar a montar esse ‘Set’ de fornecedores de serviços em cloud:
    1. Utilizar email corporativo próprio ou SaaS?
    2. Adquirir uma licença de 10 mil reais ou pagar 200 reais por mês para usa-la?
    3. Qual fornecedor de “Cloud Computing” usar?
    4. Hospedar uma aplicação onPremise ou em “Cloud Computing”?
    5. Vou armazenar meus arquivos onPremise, em “Cloud Computing” ou usando algum SaaS?

    Cloud Computing
    Agora vamos nos aprofundar um pouco em ”Cloud Computing”, que é a maior área de atuação Darede, pois está diretamente associada ao uso de poder computacional para nossas aplicações.

    É muito comum ver fornecedores de serviços de Infraestrutura na Internet que se intitula “Cloud Computing”, quando está na verdade oferecendo produtos anteriores a “Cloud Computing” abaixo exemplo de produtos que NÃO SÃO “Cloud Computing”:

    • Colocation: Espaço com energia, ar-condicionado e acesso à Internet para instalarmos nosso computador;
    • Servidor Dedicado: Quando o servidor é instalado na estrutura do provedor de serviço e nós temos acesso ao Sistema Operacional;
    • VPS: Sigla para Virtual Private Server, que é simplesmente um servidor virtual contratado como serviço;
    Mas afinal, qual o limite entre Cloud Computing e Infraestrutura com Serviço na Internet? Entendemos que para ser considerado “Cloud Computing”, o produto precisa ter, no mínimo:
    • Política do “Pague somente pelo que use”;
    • Capacidade Ilimitada* de crescimento imediato;
    • Estrutura “scriptável” onde é possível interagir com 100% através de APIs, ou outro método.

    *Capacidade Ilimitada pode ser muito abrangente, afinal sempre há um ou alguns limites, mas o que quero dizer, é ter uma capacidade disponível de centenas ou milhares de vezes maior que a capacidade mínima contratada.
    Com isso, muitos de vocês que estão lendo devem ter percebido (e esse é o intuito principal desse artigo), que Cloud Computing é muito mais que Infraestrutura Como Serviço na Internet e talvez até descoberto coisas que não sabia! =)

    Aqui uma lista de coisa que você pode fazer com “Cloud Computing” e talvez não soubesse:

    • Pagar por servidor por segundo ligado (sim se um servidor fica liga 90 segundos, você pagará apenas por esses segundos, caso desligue, para de pagar);
    • Aumentar sua capacidade computacional em 10, 100, 1000 vezes por apenas algumas horas e pagar somente por isso;
    • Possuir um site de contingência pagando R$0, e pagar por ele apenas pelos dias utilizados (e se forem utilizados);
    • Hospedar sua aplicação em Datacenters distintos sem pagar nada por isso;
    • Criar um script para subir uma estrutura em poucos segundos, seja ela de 1 serviço/servidor ou de centenas de milhares;
    • Ter a mesma capacidade computacional de empresas referência em tecnologia e inovação (como Amazon, americanas.com.br, MercadoLivre, R7) pagando proporcionalmente ao tamanho do seu negócio;
    • Fazer seu backup pagando U$0,004 (sim, menos de meio centavo);
    • Ter velocidade de Internet ILIMITADA!


    Flávio Rescia
    Gerente de Operações
    flavio.rescia@darede.com.br

    Sócio Fundador Darede, graduado em Redes de Computador e Sistemas de Informação, ministra aulas de Redes de Computador no SENAI e possuí vasta experiência com provedores de Internet, tecnologia para mercado financeiro e Cloud Computing.

    As maiores vantagens das soluções Cloud que você precisa conhecer!

    Primeiramente, vamos esclarecer do que se trata: Computação em nuvem, ou Cloud Computing, descreve o ato de armazenar, gerenciar e processar dados online, em nuvem, em vez de em seu próprio computador. Essa tecnologia fornece uma maneira simples de acessar servidores, armazenamento, banco de dados e um amplo conjunto de aplicativos pela internet. Funciona como uma terceirização de hardware, mas como assim? Empresas administram e orquestram grandes Datacenters que possuem hardwares, disco rígidos, GPUS, e recursos de rede capazes de atender demandas gigantes de infraestrutura.

    Cloud computing é um termo que surgiu com o avanço e aprimoramento da tecnologia, claro que anos atrás já era utilizada para serviços específicos. Porém com o passar do tempo a computação em nuvem se tornou mais comum e barata, empresas e usuários viram ótimas oportunidades de empreendimentos utilizando essa estrutura.

    A Cloud Computing já é uma realidade não só no mercado mundial, como também no brasileiro. A série de vantagens que ela proporciona é bastante extensa, e é compreensível o motivo pelo qual esse mercado se tornou tão atrativo de maneira tão rápida e intensa: Cada vez mais empresas estão migrando seus sistemas para a Cloud Computing!

    Mas quais são essas vantagens? Confira abaixo algumas delas:

    • Otimização de processos

    A cloud computing automatiza a maioria das tarefas, como análise, manutenção e backup. São coisas simples que, quando somadas, fazem muita diferença no fim do dia de trabalho.

    • Mobilidade

    A Cloud Computing permite o acesso móvel a dados corporativos por meio de dispositivos e smartphones, e essa é uma ótima maneira de garantir que ninguém seja deixado de lado.

    • Custo-benefício

    Aqui, estamos falando de ROI – Retorno sobre investimento. Uma vez que sua empresa estiver na nuvem, o acesso fácil aos dados do negócio economizará dinheiro a cada processo. O serviço em Cloud é vendido e utilizado ‘as a service’, ou seja, você paga pelo recurso que utiliza. A diferença no cenário Cloud de hoje se da pela variedade de integração e recursos que a plataforma oferece, agregando custos extras em troca do serviço e gerenciamento do seu workflow. Para aqueles preocupados em pagar por recursos que não utilizam, a nuvem é ideal, pois para a maioria de seus serviços, você só paga pelo que consumir.

    • Recuperação de desastres

    Outra das grandes vantagens da Cloud Computing é como ela permite que sua empresa contorne imprevistos. Serviços baseados em nuvem oferecem uma fácil recuperação de dados para todos os cenários de emergência, sejam eles desastres naturais ou simples quedas de energia.

    • Sustentabilidade

    Por sua não exigência do uso de muitos equipamentos próprios, a computação em nuvem traz muitos benefícios de sustentabilidade, como economia de energia, de espaço, menor necessidade de sistemas de refrigeração, redução na emissão de dióxido de carbono, entre outros.

    Com tantas possibilidades de agregar valor ao negócio, a Cloud Computing é uma transformação que deve ser buscada por quem deseja se diferenciar e obter um maior sucesso frente à concorrência no mercado.


    Flávio Rescia
    Gerente de Operações
    flavio.rescia@darede.com.br

    Sócio Fundador Darede, graduado em Redes de Computador e Sistemas de Informação, ministra aulas de Redes de Computador no SENAI e possuí vasta experiência com provedores de Internet, tecnologia para mercado financeiro e Cloud Computing.

    Modificando Parâmetro “Copy Tags to Snapshot” Aurora Postgres

    Poucos sabem, mas todos os recursos da AWS são disponíveis via API, esse é um dos segredos do sucesso da AWS e de outras soluções de Cloud, pois dessa forma você pode automatizar qualquer operação da infraestrutura.

    Porém alguns recursos não são disponíveis na Console (interface web), em geral a AWS lança novas funcionalidades primeiro apenas em API e posteriormente disponibiliza esse recurso na Console WEB.

    Esse é um exemplo, em bancos de dados RDS Aurora Postgres não conseguimos alterar o valor “Copy tags to snapshots” (que é usado para colocar a mesma TAG que estão no RDS nos snaphots criados à partir dele), via Console WEB. Provavelmente essa funcionalidade deve ser implementada em breve, enquanto isso pode fazer via API, como via aws cli por exemplo:

    —————————————————————

    Opção desabilitada e pode ser vista em RDS > Instances > rds_name

    —————————————————————

    Ao tentar modificar essa opção não existe:

    —————————————————————

    Alteração não disponível em: RDS > Instances > instance_name > Modify

    —————————————————————

    Primeiro listamos os bancos que não estão com essa opção habilitada:

    $ aws rds describe-db-instances --output table --region us-east-1 --query 'DBInstances[*].[DBInstanceIdentifier,CopyTagsToSnapshot]' | grep False
    | db1-123445566123123 | False |
    | db2-123445566123123 | False |
    | db3-123445566123123 | False |
    | db5-123445566123123 | False |
    | db7-123445566123123 | False |
    | db8-123445566123123 | False |
    | db0-123445566123123 | False |

    Agora podemos habilitar essa opção com o comando abaixo

    $ aws rds modify-db-instance --db-instance-identifier db1-123445566123123 --copy-tags-to-snapshot --apply-immediately

    O comando deverá retornar um json, com as informações atuais do banco (já com a modificação), que pode ser constatada inclusive via Console WEB:

    —————————————————————

    Parâmetro alterado pode ser visto pela Console WEB

    —————————————————————


    Flávio Rescia
    Gerente de Operações
    flavio.rescia@darede.com.br

    Sócio Fundador Darede, graduado em Redes de Computador e Sistemas de Informação, ministra aulas de Redes de Computador no SENAI e possuí vasta experiência com provedores de Internet, tecnologia para mercado financeiro e Cloud Computing.