Cloud Computing

O que é uma aplicação multitenant?

Com a popularização das plataformas de cloud computing e do conceito de SaaS (Software as a Service), onde o cliente paga pelo acesso aos serviços que o software provê (e não ao software em si), um outro termo técnico se tornou muito frequente quando falamos de desenvolvimento de software: o termo multitenant. Softwares no “estilo” de um SaaS e que rodem em provedores de cloud quase que obrigatoriamente são implementados de maneira a suportar múltiplos inquilinos. Mas, no final das contas, o que é um software que implementa o conceito de multitenancy? Como eu posso construir um software que implemente esse conceito?

Desenvolvedor Java Web Júnior
Formação: Desenvolvedor Java Web Júnior
A formação Desenvolvedor Java Web nível Júnior da TreinaWeb tem como objetivo a introdução à tecnologias web que são utilizadas em conjunto com o Java para a criação de aplicações e páginas web. A formação aborda as estruturas básicas para o desenvolvimento web: o HTML 5, o CSS 3 e o JavaScript. Em seguida, são abordadas as estruturas essenciais para o desenvolvimento de aplicações web com o Java em conjunto com o HTML, o CSS e o JavaScript, como o Java Server Pages (JSP), a JSTL (Java Server Pages Standard Library) e a EL (Expression Language). No fim, um dos frameworks para desenvolvimento web com Java mais utilizados no meio corporativo é apresentado: o Struts2.
CONHEÇA A FORMAÇÃO

Antes de tudo: o que é multitenancy?

Basicamente, um software que implementa o conceito de multitenancy foi desenvolvido para suportar múltiplos inquilinos (aliás, a tradução de tenant é inquilino). Isso quer dizer que uma mesma instância de um software multitenant consegue atender a vários clientes (também designados como inquilinos) diferentes ao mesmo tempo.
Pense no desenvolvimento de uma aplicação de gerência financeira, por exemplo. Pode ser que esta aplicação tenha sido concebida para ser como um produto, ou seja: ela foi feita para atender diferentes pessoas em diferentes empresas. E, falando em termos de faturamento, provavelmente este software será vendido para diferentes empresas o utilizarem… Uma possibilidade é que cada cliente tenha a sua própria máquina em um provedor de cloud computing com esse software de gestão financeira instalado. Dessa maneira, é como se todos os usuários da empresa A acessassem o software no servidor X, enquanto todos os funcionários da empresa B acessassem o software no servidor Y. Essa arquitetura certamente funciona, mas ela traz alguns problemas que podem ser difíceis para serem resolvidos, principalmente em larga escala:

  • Quando o software precisar ser atualizado, a atualização precisará ser aplicada em múltiplos servidores. Há o risco de algum cliente ficar sem a atualização, caso a atualização não seja aplicada em algum servidor por esquecimento ou falhas no processo;
  • O fato de cada cliente ter a sua própria máquina dedicada pode tornar a manutenção do software muito cara à medida que mais e mais clientes forem adquirindo o software, já que mais e mais instâncias no provedor de cloud computing precisarão ser contratadas.

Perceba que, com os pontos destacados acima, o software de gestão financeira em questão corre o sério risco de se tornar insustentável, seja do ponto de vista técnico, seja do ponto de vista de custos envolvidos. Porém, existe uma maneira de corrigirmos estes pontos: se o nosso software pudesse atender as empresas A e B na mesma instância ao mesmo tempo, sendo capaz de diferenciar de alguma maneira quando os dados da empresa A devem ser exibidos e manipulados; e quando os dados da empresa B devem ser exibidos e manipulados. Nessa situação, o nosso software de gestão financeira se tornaria um software multitenant, tendo como tenants as empresas A e B.

Uma arquitetura baseada no conceito de multitenancy propiciaria:

  • Redução na complexidade do processo de gestão do software para múltiplos clientes. Por exemplo, o caso da atualização: não haveria o risco de algum cliente não obter a atualização em questão, tendo em vista que a instância do sotware seria única;
  • Economia com infraestrutura. Por mais que, provavelmente, a instância de um software multitenant precisa ser mais poderosa pelo fato de atender múltiplos tenants ao mesmo tempo, ainda sim provavelmente o custo será menor do que se tivéssemos várias instâncias distintas servindo para vários clientes de maneira distinta;
  • Maior facilidade na obtenção de métricas com relação a utilização do software em questão, tendo em vista que estamos falando nesse caso de uma única instância.

Multitenant e isolamento de dados

O fato de termos uma única instância de software traz um problema: como vamos fazer para separar os dados entre os diferentes tenants de nossa aplicação? Para resolver este problema, podemos utilizar três estratégias diferentes: chave estrangeira, schema segregado e banco de dados segregado.

Multitenancy com chaves estrangeiras

Essa é a maneira mais simples e primitiva para separarmos os dados de nossos diferentes tenants. Com essa estratégia, cada tabela envolvida na aplicação terá uma chave estrangeira para uma tabela de controle dos tenants. Todos os dados de todos os tenants ficariam juntos no mesmo banco de dados, sendo segregados justamente por essa chave estrangeira. Quando um usuário acessasse a aplicação, esta iria verificar o tenant vinculado ao usuário e mostraria somente os dados das tabelas cujas linhas tivessem a foreign key atrelada ao tenant do usuário.

A vantagem dessa estratégia é que sua implementação é muito simples e muito barata, tendo em vista que envolve somente a utilização de chaves estrangeiras e filtros. Porém, esta estratégia tem basicamente dois pontos ruins… Um ponto é que a performance pode ficar gravemente comprometida no caso de uma quantidade muito grande de dados e/ou uma quantidade muito grande de tenants. O outro ponto é que o banco de dados é único para todos os tenants, ou seja: se um dos tenants executar uma operação muito pesada no banco (como uma consulta muito extensa ou uma carga de dados muito grande), todos os outros tenants irão sofrer com a lentidão ou até mesmo com a queda do banco de dados, já que este é único para todos os usuários. Por isso, essa estratégia não é recomendada para aplicações com uma volumetria muito grande de dados e/ou de tenants.

Multitenancy com segregação via schema

Nesta estratégia, a instância do banco de dados ainda é compartilhado entre todos os tenants, como ocorre na estratégia com chaves estrangeiras. Mas, desta vez, cada tenant possui seu próprio schema, ou seja: a instância do banco é a mesma para todos, mas essa instância tem múltiplos conjuntos das tabelas da aplicação isolados para cada tenant.

A principal vantagem dessa estratégia é justamente o isolamento lógico entre os dados dos diferentes tenants, reduzindo o possível impacto que um tenant pode causar nos demais tenants da aplicação (como no caso de uma deleção de dados acidental – com schemas diferentes, essa deleção acidental ficaria restrira ao tenant/schema que a causou). Também trata-se de uma estratégia barata, pois ela ainda é fundamentada em uma única instância de banco de dados. Porém, trata-se de uma estratégia de implementação um pouco mais complexa, o que pode encarecer um pouco o processo de adoção desta estratégia. Outro ponto diz respeito ao esforço gerencial dos diferentes schemas da aplicação, que é sensivelmente maior do que na estratégia de replicação de chave estrangeira. Esta estratégia também pode gerar problemas no caso de uma volumetria de dados um pouco maior.

Desenvolvedor Java Web Pleno
Formação: Desenvolvedor Java Web Pleno
A formação Desenvolvedor Java Web nível Pleno da TreinaWeb tem como objetivo a apresentação de tecnologias mais avançadas para o desenvolvimento de aplicações web dentro da plataforma Java. Além de serem abordados frameworks e bibliotecas populares no desenvolvimento web, como o jQuery e o Bootstrap, a formação também dá um foco especial a um dos mais importantes frameworks dentro do ecossistema Java: o Spring, largamente utilizado para criação principalmente de aplicações baseadas na web.
CONHEÇA A FORMAÇÃO
Multitenancy com segregação via banco de dados

Nesta estratégia, cada tenant tem uma instância de banco de dados dedicada, sendo a aplicação capaz de realizar conexões a múltiplos bancos de dados diferentes ao mesmo tempo.

A principal vantagem deste modelo é que agora o isolamento chega a ser “físico”, levando em consideração que cada tenant terá sua instância de banco de dados exclusiva. Isso mitiga mais ainda o impacto de operações que os tenants podem fazer e que possam prejudicar a experiência dos outros tenants. O ganho de performance nessa estratégia também é perceptível, já que estamos falando de instâncias de bancos de dados isoladas e diferentes para cada tenant. Porém, esta estratégia é sensivelmente mais complicada de ser implementada do ponto de vista técnico: a aplicação terá que ser capaz de se conectar a múltiplos bancos de dados ao mesmo tempo de acordo com o usuário que estiver acessando a aplicação. Além disso, será necessário provisionar uma instância de banco de dados para cada tenant, o que também torna esta a estratégia mais cara entre as três estratégias descritas.

Configurando um servidor web para produção com o ServerPilot

O ServerPilot é um serviço de configuração e gerenciamento de servidores web. Ele faz a instalação de todos os pacotes e configurações necessárias para os serviços funcionarem, além disso, ele possui gerenciamento de aplicativos, bancos de dados e outras ferramentas via painel. Outro ponto interessante é que ele mantêm o sistema operacional sempre atualizado e configura por padrão o firewall da máquina.

PHP - Testes unitários com PHPUnit
Curso de PHP - Testes unitários com PHPUnit
CONHEÇA O CURSO

Tipos de Aplicativos

Basicamente qualquer aplicativo que utilize a linguagem de programação PHP e banco de dados MySQL podem ser instalados nele. Aplicativos que utilizam outros bancos de dados como PostgreSQL também podem ser instalados, porém é necessário instalar e configurar o banco no Linux de forma automática.

Na hora de criar uma aplicação dentro de um servidor o ServerPilot permite escolher a versão do PHP que ele rodará, com isso, é possível rodar até mesmo aplicativos legados com versões mais antigas do PHP. Outra característica que permite a flexibilidade é que ainda terá total liberdade e acesso ao seu servidor para fazer algum ajuste caso uma aplicação específica precise.

Requisitos da instalação

O ServerPilot faz um setup inicial no servidor para instalar todos os pacotes que ele utiliza. Para esse processo acontecer sem problemas o servidor deve estar complemente limpo. O sistema operacional requerido pelo ServerPilot é o Ubuntu, veja as características que ele deve ter:

requisitos do ServerPilot

O ServerPilot não impõem a utilização de nenhum serviço de nuvem específico, é possível instalar o ambiente em qualquer máquina que possua um IP público, acesso SSH com root e até mesmo uma máquina dentro da sua rede.

Onde instalar o servidor?

Apesar da possibilidade de ser instalado em qualquer local, para um servidor web usado em produção é aconselhável usar uma máquina na nuvem, a não ser que você tenha bons servidores, redundância de internet e outros recursos de infraestrutura dentro da sua empresa.

Uma das opções mais viáveis tecnicamente e em relação a custo benefício são as VPS (Virtual Private Server), são máquinas instalada na nuvem onde é possível ter total acesso ao sistema, alguns dos serviços mais conhecidos de VPS são Digital Ocean, Linode, OVH, AWS, Locaweb VPS.

Além das listadas acima, com a popularização das VPSs quase todos os serviços de cloud possuem esse recurso à venda. Se possível, escolha um serviço com servidor no Brasil, assim diminui a latência.

Vale lembrar que ao escolher o serviço é necessário verificar se existe a imagem do Ubuntu conforme os requisitos do ServerPilot.

Instalação da VPS

Basicamente todos os serviços possuem uma interface de administração bem parecidas. Ao criar uma VPS terá que configurar as seguintes informações:

criação da vps ubuntu

Forma de acesso é importante usar senha ao invés de chave pública, pois será configurado dentro do ServerPilot.

Setup inicial

A primeira coisa que precisamos fazer é criar uma conta no ServerPilot. Após a criação da conta precisamos conectar o servidor, clique em + Connect Server e preencha os dados do seu servidor:

Imagem conexão do ServerPilot com servidor

Entre com o IP da máquina onde será instalado, senha do root e uma nova senha que será criada para o usuário serverpilot que se conectará na máquina através do SFTP uma versão segura do FTP para colocar os arquivos da aplicação no servidor.

Criando a aplicação

Um servidor pode conter várias aplicações e vários bancos de dados. Selecione o servidor que criamos, na imagem abaixo o servidor já possui duas aplicações:

lista aplicações web ServerPilot

Clique no botão + Create App e preencha para criar uma nova aplicação:

imagem criação nova aplicação PHP

Precisamos selecionar os seguintes dados:

  • Nome da aplicação
  • Domínio que será usado para acessá-la. Geralmente o domínio é apontado para o servidor onde está a VPS e dentro do gerenciador de DNS da plataforma direcionado para o IP do servidor.
  • A versão do PHP que deve ser utilizado.
  • O Servidor onde ela será instalada.
  • O usuário do sistema usado pela aplicação.

Uma opção interessante é, se você for usar WordPress, ele já faz a instalação automaticamente, basta marcar WordPress na criação da aplicação com os dados configurados:

Imagem instalação automática do WordPress

No caso do WordPress que ele já faz a instalação automaticamente basta acessar o endereço do seu domínio e terá a aplicação funcionando:

Imagem WordPress instalado automaticamente

Acessando os arquivos

Se sua aplicação não for WordPress será necessário acessar o servidor para inserir os arquivos. Isso pode ser feito através de SSH para clonar um repositório GIT, por exemplo, ou pode ser feito direto via SFTP usando um cliente como FileZilla:

Imagem conexão FTP filezilla ao ServerPilot

A senha do SFTP é aquela inserida no momento em que conectamos ao servidor para instalação. Ao conectar terá dentro da pasta apps o diretório de cada aplicação criada, basta colocar os arquivos da aplicação dentro dessa pasta:

imagem listagem de arquivos

Para finalizar, vale lembrar que uma aplicação pode ter vários bancos de dados, basta realizar a criação dentro da aplicação:

Imagem bancos de dados do ServerPilot

Conclusão

O serviço ServerPilot é uma opção muito interessante para desenvolvedores que precisam colocar suas aplicações online sem a necessidade de se preocupar com toda a parte de configuração dos serviços. A versão gratuita do ServerPilot atende bem a maioria dos casos. Existem também outros serviços de gerenciamento de servidor como por exemplo o Forge do Laravel, focado em PHP, mas ele não tem uma versão gratuita.

CodeIgniter 3 - Framework PHP
Curso de CodeIgniter 3 - Framework PHP
CONHEÇA O CURSO

Aumente a segurança na Digital Ocean com o Cloud Firewalls

A Digital Ocean está sempre com novidades e um ponto que chama atenção é a contínua melhora da plataforma. A empresa está sempre lançando novos recursos que são documentados através de uma comunicação clara com os desenvolvedores, seja através do blog, documentação ou contato direto com a comunidade. Outro fator relevante é a facilidade de se usar os novos recursos e esse é, certamente, outro ponto forte da plataforma.

Segurança na nuvem

Ao configurar qualquer servidor ligado na internet a segurança é uma das primeiras coisas que devemos pensar. Antes da Digital Ocean possuir o recurso Cloud Firewalls que veremos nesse artigo, era necessário configurar iptables manualmente no Linux. O grande problema da configuração manual não está quando temos apenas uma máquina para rodar determinado serviço, mas quando várias máquinas são utilizadas ou quando existe uma rede com Load Balancers e outros recursos dentro da plataforma e aí esse trabalho de configuração manual pode se tornar bastante complexo.

Em outras plataformas a utilização de firewall padrão não é novidade, por exemplo, na AWS esse recurso já existe há algum tempo.

Conceitos básicos do Cloud Firewalls

Antes, alguns aspectos que precisamos conhecer:

  • No firewall existem as regras de entrada e as regras de saída;
  • Dentro de uma regra é possível selecionar o protocolo, porta única ou range de portas e quem terá permissão de acesso;
  • Por fim, temos as VPSs e tags que esse firewall será aplicado. Um VPS pode ter muitos firewalls e um firewall pode ser aplicado a vários VPS’s;

Veremos na prática alguns exemplos.

Gerenciamento do Firewall

Para criar um novo firewall podemos acessar o gerenciador de 2 modos, na tela principal no menu Networking > Firewalls ou nas configurações de uma Droplet específica no menu Networking > Firewalls > Manage Firewalls. No gerenciador basta clicar em Create Firewall para criar um novo.

Por padrão, o firewall aceita conexões na porta 22 (SSH) de qualquer IP, seja IPv4 ou IPv6. Veja a imagem:

Imagem porta de entrada padrão

Vamos supor que você queira liberar a porta do SSH somente para um IP específico (e essa prática é encorajada):

Liberação porta de entrada ip especifico

Outro recurso legal é o uso de Tags. Dentro da plataforma é possível criar tags para agrupar recursos, por exemplo, vamos supor que você queira liberar o acesso à porta do MySQL somente para as droplets que possuam a tag servidor-web:

Abertura porta de entrada para uma Tag

Nas regras de saída temos algo bem parecido:

Portas de saída padrão firewall

Por padrão as regras de saída são:

  • Permite tráfego ICMP de qualquer endereço IPv4 e IPv6
  • Permite tráfego de saída TCP para todas as portas em qualquer endereço;
  • Permite tráfego de saída UDP para todas as portas em qualquer endereço;

É possível configurar essas regras para ficarem mais restritivas, apesar do tráfego de saída não ser tão perigoso como o de entrada.

Por fim, deve ser escolhido o local onde o firewall será aplicado, pode ser em um ou mais Droplets ou Tags:

Locais onde o firewall será aplicado

No exemplo acima está sendo aplicado a todos os recursos com a Tag servidor-web e ao Droplet treinaweb-test.

Conclusão

Um dos princípios de segurança mais importantes é a permissão mínima. Sempre que for configurar seu firewall libere apenas as permissões mínimas necessárias para as conexões usadas no seu servidor. Serviços como SSH e MySQL preferencialmente devem ser liberados para acesso somente ao IP do administrador ou de alguma outra máquina que acesse esse serviço e, com isso, restringe-se a maioria dos ataques possíveis.

Por fim, vale destacar os limites do Firewall da Digital Ocean:

  • Quantidade total de regras de entrada e saída de um firewall: 50
  • Quantidade de Droplets por Firewall: 10
  • Firewalls por Droplet: Ilimitado
  • Tags por Firewall 5.
  • Droplets por tag: Ilimitado

Caso queira mais de detalhes, você pode acessar o exemplo oficial.

HTTP - Fundamentos
Curso de HTTP - Fundamentos
CONHEÇA O CURSO

Os tipos mais comuns de hospedagem de sites

Uma das coisas mais importante para criação de um site ou sistema web seguro e confiável, independentemente da plataforma escolhida, é o servidor onde ele será hospedado. Se você não sabe o que é uma hospedagem e um domínio, recomendo a leitura desse artigo. Existem alguns tipos de serviços que podemos escolher baseado no porte e nas necessidades das nossas aplicações e cada um deles possui vantagens e desvantagens.

C Avançado
Curso de C Avançado
CONHEÇA O CURSO

Hospedagem compartilhada

Geralmente esse é o tipo de hospedagem de entrada da maioria dos pequenos sites e blogs. Nele, uma empresa possui servidores onde são colocados vários sites, por isso o nome compartilhado. A principal vantagem dessa modalidade é o baixo custo, além de que na maioria das hospedagens é incluso serviço de email, painel administrativo de fácil configuração entre outros recursos.

Toda a parte da segurança do servidor é de responsabilidade da empresa de hospedagem, é preciso confiar na expertise dela. A principal desvantagem é o baixo poder de processamento, dependendo da quantidade de acessos o site pode ficar offline nos momentos de pico.

Hospedagem em servidor dedicado

Esse tipo de hospedagem é uma “evolução” da compartilhada e possui as mesmas características dela, sendo que a principal diferença está no poder de processamento. Nessa modalidade o site possui um servidor somente para ele, o que garante um maior poder de processamento. A segurança do servidor normalmente também é garantida pela empresa de hospedagem. As principais desvantagens são o alto custo e a dependência da hospedagem, o que limita o acesso, mesmo o servidor sendo totalmente do seu site, pode ser que você não tenha acesso administrativo ao sistema operacional dele, dependendo da hospedagem.

Hospedagem específica para plataforma

As plataformas de CMS e e-commerce como WordPress, Joomla, Drupal, Magento entre outras, tomaram um tamanho tão grande na web que existem serviços especializados em hospedá-las. A principal vantagem é que possuem uma série de especialistas na plataforma e na segurança dela, além de oferecer ferramentas que podem ajudar a melhorar a performance e confiabilidade do site. A principal desvantagem é o custo, devido aos serviços personalizados e suporte.

Wordpress - Criação de lojas virtuais com WooCommerce
Curso de Wordpress - Criação de lojas virtuais com WooCommerce
CONHEÇA O CURSO

Hospedagem na nuvem

A principal vantagem é a escalabilidade. Nos principais provedores desse serviço é possível começar com pouco processamento e espaço e escalar conforme a demanda.

Nuvem PaaS (Platform as a service)

Nesse tipo de hospedagem a empresa vende o poder de processamento e armazenamento na nuvem, além de toda a plataforma necessária para o seu software funcionar. A grande vantagem é a facilidade de configuração e segurança, uma vez que não é necessário configurar quase nada para ter o seu software funcionando. A segurança da plataforma é garantida pelos analistas de segurança do serviço. A desvantagem é o valor, já que além do servidor, é necessário pagar os custos da plataforma disponibilizada.

Nuvem IaaS (Infrastructure as a Service)

Nesse tipo de hospedagem a empresa vende apenas a infraestrutura como serviço, disponibilizando servidores limpos na nuvem e fica a cargo do cliente configurar todo o resto. É preciso escolher manualmente os softwares necessários para rodar a aplicação e toda a arquitetura e segurança deve ser configurada manualmente. A principal vantagem desse tipo de hospedagem é a flexibilidade, é possível ter desde pequenas até aplicações de grande porte e definir todas as regras para que elas sejam, por exemplo, automaticamente escaladas numa arquitetura horizontal (usando mais de um servidor). A desvantagem está na administração, é necessário um analista de infraestrutura para configurar todos os serviços necessários para a sua aplicação funcionar.

Grandes players do mercado nesse segmento:

  • Amazon Web Services (AWS)
  • Microsoft Azure
  • Digital Ocean
  • Linode
  • Entre outras.

Conclusão

Os servidores de hospedagem são algo essencial para a segurança e confiabilidade do seu sistema, por isso é importante um cuidado especial na sua escolha. Pesquise na internet a reputação das empresas que oferecem o tipo de serviço que você precisa. Outro ponto importante é dar preferência para servidores que possuem infraestrutura no Brasil, se seus usuários estão majoritariamente localizados aqui, isso pode diminuir o tempo de carregamento do seu site (latência).

HTML5 e CSS3 - Desenvolvimento web Avançado
Curso de HTML5 e CSS3 - Desenvolvimento web Avançado
CONHEÇA O CURSO

Como se preparar para falhas em alguma região da AWS

Na terça-feira de carnaval, vários sites e aplicativos móveis que utilizam a AWS (Amazon Web Services) enfrentaram uma brusca interrupção na disponibilidade do serviço. A Web ficou, por algumas horas, “quebrada”. Para você ter ideia da dimensão do problema, foram afetados, de alguma forma, Trello, Quora, Wix, Giphy, Slack, Dropbox, Instagram, Vine e até mesmo o Github. Rumores eram de que toda a AWS estava offline mas, na verdade, os problemas afetaram apenas os servidores da região us-east-1 (N. Virginia), que é apenas uma das 14 regiões que a AWS possui.

C++ Intermediário
Curso de C++ Intermediário
CONHEÇA O CURSO

Segundo a própria Amazon a raiz do problema aconteceu no S3, o serviço de storage da empresa, um dos mais antigos e que serve como base para uma série de outros serviços da AWS, como o Elastic Block Store de volumes do EC2 que utiliza persistentemente os servidores do S3.

Por não afetar a zona sa-east-1 (localizada em São Paulo), a mais utilizada por serviços do Brasil e também devido a maioria dos desenvolvedores estarem pulando carnaval (ou não) o problema acabou não sendo tão divulgado.

Aqui no TreinaWeb, a nossa arquitetura está toda na AWS, especificamente na região de São Paulo (sa-east-1), a ideia é ter o mínimo de latência (apesar dessa ser uma das regiões mais caras de toda a AWS, você sabe, impostos praticados no Brasil e tudo mais). Da nossa parte, não tivemos nenhum problema. No entanto, o nosso gateway de pagamento usava alguns serviços daquela região americana e tivemos alguns contra-tempos limitados ao checkout. Mas, os alunos não deixaram de acessar os cursos e usufruir dos serviços do site.

O histórico, da identificação até a resolução do problema:

1) 11:49 AM PST We can confirm increased query failure rates when running queries and executing DDL statements in the in US-EAST-1 Region.

2) 1:59 PM PST We are starting to see recovery when running SQL queries in the US-EAST-1 region. We continue to see elevated error rates when executing DDL statements in the US-EAST-1 region.

3) 2:12 PM PST We continue to see recovery when running SQL queries in the US-EAST-1 region. We are also starting to see recovery when executing DDL statements in the US-EAST-1 region.

4) 3:25 PM PST We are able to execute SQL queries normally in the US-EAST-1 region. We continue to see increasing recovery when executing DDL statements in the US-EAST-1 Region.

5) 3:44 PM PST Between 9:37 AM and 3:23 PM PST we experienced increased error rates when running SQL queries and executing DDL statements in the US-EAST-1 Region. The issue has been resolved and the service is operating normally.

Por fim:

“The issue has been resolved and the service is operating normally.”

alt

Por mais que tudo tenha sido restabelecido, a Amazon apenas mitigou o problema. E isso não é nenhum demérito. Ela focou os esforços em fazer as coisas voltarem a funcionar. O que não falta é expertise para que, nos próximos dias, eles resolvam, de fato, os verdadeiros problemas estruturais/lógicos que lhes acometeram.

Esse tipo problema, especialmente na AWS, não é regra, é exceção. Mas, como nada está imune, o que podemos fazer para evitar que nossos aplicativos fiquem fora do ar em casos como esse? Abaixo duas válidas opções.

Active-Active ou Active-Passive usando Route53

O termo Active-Active não é especifico da AWS, na verdade ele está relacionado a alta disponibilidade. Basicamente, significa que o trafego é direcionado para um nó que está online ou balanceado entre outros que permanecem ativos, quando uma falha é identificada. Para usar essa solução é necessário uma cópia ativa da sua infraestrutura em outra região. O problema é que para a maioria das aplicações de pequeno porte isso é inviável, devido ao alto preço de ter a aplicação “espelhada” em mais de uma região.

A solução Active-Passive é parecida, porém um pouco mais em conta. Nela as instâncias redundantes só são colocadas completamente online caso o nó primário falhe. A desvantagem está no tempo extra após a queda do nó primário até as instâncias redundantes estarem prontas.

A AWS possui uma ferramenta chamada Route53 que ajuda a direcionar o tráfego automaticamente em caso de falha. Ela possui duas funções adicionais, uma chamada Health Check e outra chamada Traffic Polices. A primeira verifica se está tudo funcionando e a segunda permite definir o que fazer caso encontre algum problema. Essas duas configurações permitem implementar as estratégias acima descritas.

Replicação entre regiões

Caso você não queira usar as opções Active-Active ou Active-Passive, pode-se utilizar apenas a opção replicação entre regiões, nela todos os objetos e metadados como ACLs e tags são armazenados automaticamente em uma outra região escolhida na hora da ativação da opção. Isso pode ser suficiente caso aconteça algum problema no armazenamento da região principal.

Java - Estrutura de dados - Parte 2
Curso de Java - Estrutura de dados - Parte 2
CONHEÇA O CURSO

Concluindo

Apesar da AWS ser um dos serviços mais confiáveis do mercado, sempre que tratamos de softwares que precisam da alta disponibilidade é necessário pensar em alternativas que mitiguem bruscas interrupções, para evitar a perda de dinheiro, sem contar a credibilidade da sua empresa.

Caso queira saber como implementar os recursos acima citados, veja nesse excelente artigo So AWS Went Down. Here’s How You Can be Prepared If It Happens Again

Fontes complementares: theverge e datacenterdynamics

Ruby on Rails Básico
Curso de Ruby on Rails Básico
CONHEÇA O CURSO

A era das ferramentas em forma de serviço

Qual o motivo por trás do surgimento de tantas ferramentas em forma de serviço? Quais as principais e mais indicadas?

O que me levou a pensar sobre esse assunto

No próximo mês (março de 2017) completo cinco anos desde que comecei a trabalhar profissionalmente com desenvolvimento de software. Antes disso, eu estava na faculdade, porém, ainda não tinha feito nada que me rendesse umas “verdinhas”. Apesar de eu ser novo na área de desenvolvimento se comparado com outros profissionais, o tempo nos leva a refletir sobre projetos desenvolvidos, quais eram as expectativas antes de começar a trabalhar e como elas são hoje, os aspectos que nos dá prazer em trabalhar e quais, com perdão da palavra, enchem o saco.

Nessa minha reflexão sobre esse curto período na área, também tentei lembrar dos principais elementos e ferramentas de uso diário que mudaram nesse tempo. Muitas coisas mudaram, como os serviços de nuvem que mal existiam, os frameworks ficaram mais modernos, novas estratégias para deploy na nuvem, dentre várias outras coisas. Porém, o que mais me chama atenção é a quantidade de serviços que auxiliam no desenvolvimento de software e gerenciamento de equipes e projetos.

F# (F Sharp) - Fundamentos
Curso de F# (F Sharp) - Fundamentos
CONHEÇA O CURSO

Surgimento das ferramentas em forma de serviço

Lembro que na época que fiz o meu TCC tive que procurar uma série de gems para conseguir extrair métricas do código do projeto. Hoje existem ferramentas online que auxiliam na extração desse tipo informação. O ponto principal é que a maioria dessas ferramentas surgiram com o intuito principal de diminuir a complexidade de arquitetura e de configuração que o desenvolvedor precisa fazer para usar um recurso. Na maioria dos casos, usar um serviço é muito mais prático, economiza horas de configurações e estresse. Além disso, em muitos casos, pode ser até mais vantajoso financeiramente (se avaliar o “todo”).

Algumas ferramentas

Não tenho a intenção de indicar a “melhor ferramenta” ou quais as vantagens e desvantagens de cada uma, nem mostrar todas as disponíveis no mercado, até porque, como o título do artigo diz, estamos na era das ferramentas em forma serviços e devem existir milhares por aí que nem nunca ouvi falar.

Vou citar as que conheço ou que já tive contato:

Ferramentas para análise da qualidade de código:

Ferramentas de integração contínua:

Ferramentas para monitoramento:

Ferramentas para hospedagem de repositórios git:

Ferramentas para envio de email:

Ferramentas de servidores de busca:

Ferramentas de controle de projeto e tempo:

Ferramentas de comunicação mais usadas por equipes de desenvolvimento:

Escolha das ferramentas usadas em um projeto

Além das ferramentas citadas acima, que no geral são mais genéricas e podem ser utilizadas em diferentes tipos de projeto, existem muitas ferramentas de domínio especifico da stack que se está utilizando. A maioria dos desenvolvedores adoram testar novas ferramentas, linguagens, serviços e tudo que é tipo de novidade. Em um projeto “ideal” a maioria nós escolheria no mínimo uma ferramenta de cada tipo acima, com todas as funções liberadas e tudo mais. Mas sabemos que não é essa maravilha toda, pois a maioria dos projetos possuem orçamentos apertados, em outros casos os desenvolvedores são freelancers e o custo dessas ferramentas vão acabar saindo do próprio lucro. E fica ainda mais complicado se pensarmos que a maioria desses serviços são pagos em dólar.

Pensando nesse tipo de situação, melhor do que comprometer o orçamento do seu projeto com o uso de diversas ferramentas, é analisar o escopo dele e tentar entender qual a parte mais critica, onde o uso de uma ferramenta teria maior impacto positivo pensando no problema que se está tentando resolver.

Outro ponto interessante é usar um pouco do “jeitinho brasileiro”, mas não no sentido de fazer gambiarra, mas sim no modo de contornar a situação com pouco recurso. É possível comparar 2 ou 3 ferramentas para ver no escopo do projeto qual teria o menor custo. Se o projeto possui um único desenvolvedor, talvez seja interessante usar uma hospedagem de repositórios Git que não cobre por repositórios privados com um único desenvolvedor. Outra ideia é procurar ferramentas open source que fazem o mesmo trabalho e outras ações nesse sentido. Além dessa questão das ferramentas, isso pode ser uma ótima oportunidade para conhecer novos horizontes e talvez se tornar um profissional menos “intolerante” à novas tecnologias.

Conclusão

Acredito que a era dos “serviços de auxilio ao desenvolvimento” veio para ficar. Por isso, é papel nosso, como desenvolvedores, conhecer as principais e escolher as que mais se aplicam aos nossos projetos e orçamentos. Quais serviços você usa e considera como essenciais? Ou você prefere configurar suas próprias ferramentas e ambientes? Deixe seus comentários.

Até a próxima!

XSLT Completo
Curso de XSLT Completo
CONHEÇA O CURSO