Endrigo Antonini

AWS - Conceitos - Resumo de estudos

March 26, 2019 | 9 Minute Read

amazon-web-services-logoIniciei recentemente os estudos quanto a plataforma, serviços e os recursos que são disponibilizados na AWS. Estou cursando o AWS Fundamentals: Going Cloud-Native via a portal de e-Learning Coursera.

O objetivo desse post é de servir como bloco de notas com destaques e conceitos importantes que tenha aprendido durante esse treinamento, bem como de agregar meu ponto de vista e outras informações que eu também jugar necessária.

Para evitar que o conteúdo fique muito extenso e maçante irei quebrar o conteúdo em vários posts sendo esse o primeiro de N posts.

O que é cloud?

Existem várias formas de explicar o conceito. A maior parte dos materiais que tratam a respeito acabam apenas tratando dos pontos técnicos para apresentar o que seria a nuvem (tradução de Cloud). Por isso acredito que a definição que foi feita durante o curso é extremamente simples e é capaz de fazer com que pessoas não técnicas consigam também entender a definição de Cloud:

On-demand

Sob demanda, isso é, você utiliza recursos e serviços somente quando precisa. Em muitas organizações esse é um drama tremendo pois, quando estiver iniciando um projeto, precisa prever o tamanho da infraestrutura que vai precisar para 5 anos de projetos. Isso sem mesmo ter a garantia de que o mesmo irá vingar.

Pay-as-you-go

Pay-as-you-go, na tradução livre pague o que utilizar, é uma visão diferente quanto a forma de pagar pelos recursos que você está utilizando, isso é, se nesse momento você precisa apenas de um servidor para aguentar a carga que sua aplicação terá, por que configurar 6 servidores nesse momento se isso é um recurso que você está prevendo para daqui 1 a 2 anos de projeto? Esse modelo auxilia bastante pessoas e empresas a poderem realizar a famosa experimentação quando estiverem montando seu MVP, fazendo com que o custo dessa primeira implementação não seja exorbitante e que possa inviabilizar o projeto como um todo.

Serviços através da Internet

Permite que funcionalidades e serviços de TI sejam entregues para a organização através da internet de forma segura, isso é, se bem configurado e seguindo procedimentos que garantam a segurança do ambiente e também dos serviços que estejam nela publicados.

Por que cloud?

Essa é uma boa pergunta! Normalmente quando vamos falar com pessoas que estão acostumadas a utilizarem todos os recursos dentro do próprio Data Center (on-premises) acabamos escutando perguntas do tipo: "Porque eu deveria migrar para a Cloud se eu tenho a infraestrutura?", "É melhor a gente comprar todos os servidores que estamos acreditando que o projeto vai precisar!". Aqui vão alguns pontos que eu pessoalmente utilizaria para responder esse tipo de questionamento:

  • "Deveríamos nos preocupar com o nosso diferencial de mercado, com o que mais sabemos fazer (core business) e não com coisas que são padrões e comuns para qualquer organização."
  • "Não deveríamos investir tanto dinheiro em infraestrutura de largada para projetos que estão sendo testados pela empresa e podem ser cancelados do dia para a noite"
  • "A infraestrutura da nossa aplicação deveria estar dimensionada para o momento, com uma certa folga, e não para anos luz a frente do momento."

Esse seria o início da minha linha de raciocínio para responder questionamentos nesse nível.

Modelos computacionais na nuvem

Existem algumas formas de publicar e executar uma aplicação. A mais utilizada é denominada de "on-premises". Essa classificação indica que toda a aplicação está rodando dentro da própria empresa, isso é, o servidor de aplicação, banco de dados e outros serviços que são utilizados pela aplicação estão instalados em servidores que são geridos pela própria empresa em seu Datacenter. Além desse modelo, temos também os modelos abaixo:

Infraestrutura como serviço - Infrastructure as a Service (IaaS)

Fazendo uma escadinha quanto a terceirização dos seus recursos de TI, podemos afirmar que esse é o modelo menos intrusivo para a empresa contratante, isso é, quando você utiliza um provedor cloud em modelo de IaaS, você estará recebendo, como o próprio nome indica, infraestrutura! Isso quer dizer que você irá receber um computador (ou equipamentos de rede), mas será sua responsabilidade gerencia-lo, configura-lo e mante-lo atualizado. Tirando o fator de que o computador (nesse exemplo) não está rodando em seu datacenter, esse é o modelo mais próximo do modelo tradicional on-premises.

Para exemplificar esse caso, vamos dizer que você precisa publicar o site da empresa. Tanto no modelo on-premises quanto no modelo IaaS você precisará configurar o sistema operacional do computador, instalar um servidor web e configurar sua página web para ser executada dentro dessa aplicação. A grande diferença entre o on-premises e o IaaS é onde esse serviço está executando e as responsabilidades que você delegou para um terceiro.

Plataforma como serviço - Platform as a Service (PaaS)

Continuando nossa escalada quanto aos modelos, podemos afirmar que no modelo PaaS você delega um pouco mais de responsabilidade pro provedor e espera receber um serviço de mais alto nível em comparação ao IaaS.

Seguindo o exemplo anterior onde você deseja publicar o site da empresa, no modelo PaaS você iria contratar diretamente o servidor web. Mas mesmo assim você precisaria configura-lo para atender as suas necessidades e publicar o site. A responsabilidade de gerenciar o sistema operacional que executa esse servidor é do provedor de serviço Cloud.

Software como serviço - Software as a Service (SaaS)

A maioria das pessoas já consomem serviços através desse modelo mas não se dão conta, isso é, esse modelo indica que você está contratando um software e a sua responsabilidade é apenas de utiliza-lo e de fornecer/consumir os dados ali publicados.

Dando continuidade do exemplo de publicação do site da empresa, nesse cenário iríamos contratar um provedor onde ele fornece e gerencia inclusive o servidor web, isso é, você seria responsável apenas em publicar as informações.

Outro exemplo clássico de SaaS é a própria forma de utilizar o e-mail através de serviços como Google, Microsoft e afins. Onde você, como usuário, apenas acessa a aplicação web e manda seu e-mail sem nem ao menos precisar se questionar quais são as configurações que estão aplicadas no servidor.

Modelos de publicação de aplicação

Apesar de termos falado de on-premises quanto a modelo computacional na nuvem, na verdade o mesmo é explicado dentro de modelos de publicação (deploy). Abaixo estão a explicação dos três modelos, onde temos dois extremos e um modelo híbrido.

On-premises

É quando a aplicação está publicada em maquinas virtuais dentro da própria infraestrutura da empresa. Em sua maioria das vezes o modelo de publicação de aplicação segue um modelo muito parecido com as aplicações legadas da empresa porém através do uso de algumas tecnologias mais recentes como virtualização e gerenciamento de aplicação. Por esse motivo, esse tipo de infraestrutura algumas vezes é denominado de "cloud privada"

Cloud

Trata-se de quando a aplicação e todos os componentes que essa depende estão publicados e rodando em um provedor externo a empresa. Independentemente de estar utilizando IaaS, PaaS ou SaaS todos os componentes da mesma não estão internalizados na empresa.

Híbrida

Como o próprio nome sugere é a mistura dos dois mundos anteriores, onde a aplicação executa parte dentro da infraestrutura da empresa e parte em um provedor de cloud. Esse modelo muitas vezes é utilizado para permitir que a empresa possa ganhar a elasticidade que um provedor de cloud pode prover sem perder o acesso a sistemas e controles legados.

Outras informações da AWS

A AWS possui uma área de Produtos e Serviços, isso pois a mesma trabalha tanto como IaaS, PaaS e/ou SaaS. Digo e/ou pois você não é obrigado a utilizar apenas um desses modelos! Não existe regra para isso e nem mesmo algo que te prenda a utilizar apenas um modelo. Os serviços oferecidos pela AWS vão desde armazenamento de arquivo, CDN a até mesmo produtos relacionados a IoT.

A mesma também possui o chamado APN - AWS Partner Network. Como o próprio nome sugere, trata-se de empresas parceiras da AWS que possuem como objetivo auxiliar seus clientes a terem sucesso na conversão de produtos e plataformas para a Cloud.

Dentro da AWS você também irá encontrar uma área denominada de AWS Marketplace, isso é, a mesma permite que você venda seu serviço para pessoas que utilizam os serviços da AWS.

Regiões

Regiões (regions) dentro da AWS são locais onde os Datacenters estão instalados. Vale a pena ressaltar que uma região é auto contida e possui todos os serviços necessários para rodar independentemente do estado de qualquer outra região. Outro ponto importante para lembrar é que cada região está em acordo com suas leis locais, isso é, servidores que estão no Brasil, por exemplo, devem seguir a LGPD (Lei Geral de Proteção de Dados), já os que estão em países dentro da União Europeia devem seguir a GDPR (General Data Protection Regulation) e assim por diante.

Ainda quanto a regiões, vale a pena ressaltar que uma região tem por definição ter no mínimo dois datacenters (eles denominam de Availability Zones) ativos e distantes entre si para evitar situações de desastre (Durante a criação desse post a AWS possui 3 Availability Zones em 1 região em São Paulo). A aplicação pode estar em execução simultaneamente em mais de um datacenter e isso não é um problema pois todos esses datacenter são conectados através de várias redes de fibra óptica fazendo com que a latencia entre elas tenda para nulo.

Para decidir em que região levantar suas aplicações, existem algumas perguntas chaves que podem te ajudar na tomada de decisão:

  • Onde a maioria dos meus clientes estão localizados? Se a grande maioria está no Brasil, não faz tanto sentido colocar os servidores na Austrália, por exemplo.
  • Quanto estou disposto a pagar? Nem toda região tem o mesmo preço para os mesmos produtos, por isso é importante levar em consideração o custo da operação também.
  • Eu tenho alguma restrição legal? Existem mercados que são regulados por normativas e leis. Por isso é importante verificar se sua empresa está enquadrada em alguma dessas leis que a obrigaria, por exemplo, a manter todos os dados armazenados em território nacional.
  • Os serviços que eu preciso estão disponíveis nessa região? A Amazon publica de forma periódica vários novos produtos e serviços, mas nem sempre em todas as regiões simultaneamente. Por isso é preciso verificar antes de escolher a região se o serviço desejado está disponível nela.

Conclusões

Esse post contém informações e conceitos gerais sobre Cloud, modelos computacionais e de deploy. Nele também foi possível verificar uma rápida introdução sobre conceitos que começam a permear o ecossistema da AWS, como Regiões e Availability Zones.

comments powered by Disqus

Related Posts

Autenticidade no git com o uso de chave GPG

Introdução ao Maven

Merge no Visual Studio 2013 com git