AWS Cloud Experience Curitiba 2019

No último dia 29 aconteceu o evento AWS Cloud Experience em Curitiba. Um evento gratuito voltado para a comunidade de Cloud Computing, que abordou os principais serviços da AWS, tendências e melhores práticas com a plataforma. Todas as sessões foram apresentadas por especialistas AWS e algumas com a participação de clientes que compartilharam suas experiências e cases de negócio durante a transição ou implementação na nuvem da AWS.

Castelo do Batel em Curitiba

O evento foi realizado no Castelo do Batel na região central de Curitiba, um lugar espetacular que encanta os olhos assim que se chega no local, deixando perceber a dedicação da Amazon em garantir uma experiência diferente aos seus “builders” — assim como preferem chamar seus clientes/usuários.

O evento iniciou com uma apresentação da parceria entre a AWS com a Intel e logo após subiu ao palco Cleber Morais, Diretor Geral da AWS Brasil, que deu introdução ao evento agradecendo a participação de todos e apresentou números surpreendentes da AWS, na qual registrou um crescimento de 37% no último ano e ainda lançou 1957 novos recursos — você não leu errado, são mil novecentos e cinquenta e sete mesmo — na nuvem no ano de 2018.

Com isso, se aproveitou o gancho para destacar a importância do foco no cliente e seus negócios, pois 90% destes novos recursos são serviços voltados para necessidades específicas de clientes. Clientes que foram ouvidos para tornar possível a criação de serviços que façam sentido e tragam valor no negócio.

Também foram apresentadas empresas que criaram cases de sucesso. Como é o caso do iFood que processa milhões de pedidos diariamente em horários de pico, a Embraer que acompanha informações de vôos e aviões em tempo real e o NuBank que é a maior fintech da América. Além do EBANX, uma empresa de Curitiba, que processa e calcula milhares de pagamentos digitais do Brasil e do exterior em sua plataforma para nomes como Sony e Spotify.

Alguns clientes locais também marcaram presença e apresentaram rapidamente seus cases. Como a RCI, o banco do grupo Renault Nissan no Brasil, que em 2013 levou para a nuvem todo seu ambiente on premisse que funcionava na França com sérios problemas de latência e custo.

A Grpcom apresentou o case do jornal Gazeta do Povo, que foi o primeiro jornal do Brasil a se tornar 100% digital, um jornal centenário em Curitiba. Vale destacar que 3 anos antes da migração para a AWS, o grupo havia investido milhões em um publisher para facilitar as publicações em todas as plataformas, que foi abandonado para dar lugar ao serviço na nuvem. E assim, o jornal alcançou a maior audiência no país durante as eleições de 2018 e hoje é o 4º maior jornal do Brasil.

O evento, que estava de casa cheia, girou no formato de apresentações simultâneas no mesmo local e com o auxílio de aparelhos FM os participantes optavam entre as apresentações conforme desejava. A primeira na qual acompanhei foi a de redução de custos e instâncias Spot, onde foram apresentadas as melhores práticas de utilização da plataforma para otimizar os custos, separadas em cinco pilares:

1. Tamanho certo das instâncias: mensurar e acompanhar o desempenho das instâncias contratadas para garantir que se está utilizando os recursos corretamente.
2. Explorar a elasticidade: reservar apenas recursos que são primordiais para o funcionamento da plataforma e explorar mais a elasticidade da nuvem para recursos corriqueiros.
3. Utilizar o modelo de custo adequado: a AWS disponibiliza três modelos de custo: reserva; sob demanda e; spot. Cabe ao usuário identificar qual o modelo que se encaixa ao perfil da sua plataforma.
4. Otimizar o armazenamento: sem sombra de dúvidas esse é o ponto mais debatido durante as apresentações de custos. A AWS disponibiliza inúmeras formas e ferramentas de armazenamento de dados, é preciso estudar para não extrapolar os custos de armazenamento.
5. Medir e monitorar: o que não se mede, não se controla. Por isso, é muito importante utilizar as ferramentas de monitoramento de custos e alertas disponíveis. Assim é possível descobrir onde estão os gargalos e os recursos que podem ser reavaliados.

Falando sobre o modelo de custo mais recente, a AWS disponibiliza instâncias Spot, que é um leilão de instâncias/máquinas que estão ociosas no momento. Elas funcionam sob-demanda, o valor flutua de acordo com a demanda e disponibilidade e para contratar uma instância Spot é necessário definir o limiar que se deseja pagar.

As instâncias spot do Amazon EC2 permitem aproveitar a capacidade não utilizada do EC2 na Nuvem AWS. Em comparação com a definição de preço sob demanda, as instâncias spot oferecem descontos de até 90%. Elas podem ser usadas para vários aplicativos stateless, tolerantes a falhas e flexíveis como big data, cargas de trabalho conteinerizadas, CI/CD, servidores web, computação de alta performance (HPC) e outras cargas de trabalho de teste e desenvolvimento. — Amazon AWS

Entretanto, a Amazon pode reivindicar as instâncias Spot caso ela for utilizada sob reserva de algum outro cliente. Desta forma, se perde desempenho e para retomar o fluxo normal de funcionamento deverá contratar outra instância sob demanda. Mas segundo os dados disponibilizados, 95% das instâncias Spots não foram reivindicadas nos últimos 3 meses.

A palestra seguinte foi sobre Data Lake (DL), um assunto em alta no momento que a AWS domina e fala com propriedade. Foi destacado que não existe um serviço exclusivo para DL dentro da plataforma, mas que devemos trabalhar com um conjunto de serviços que combinados tornam isso possível. Recentemente a AWS lançou o Lake Formation, que facilita a criação e configuração de um DL seguro na nuvem.

Foram abordados os desafios de se trabalhar com DL devido ao seu crescimento exponencial, o fato de existirem diversas fontes de dados — logs, streaming, sensores, storage, arquivos — além da diversidade de tipos de dados — imagens, texto, vídeo, áudio, gráficos. Diferente de um Data Warehouse (DW) que normalmente é utilizado exclusivamente para BI (Business Intelligence), um DL pode ser utilizado por diversos setores e pessoas com os mais distintos cargos simultaneamente.

O objetivo do DL é ter um repositório de dados centralizado e seguro, eliminando os chamados “Silos” que consistem em bases desconexas de dados. O foco está em disponibilizar um armazenamento seguro e escalável com baixo custo, permitindo acesso rápido a qualquer dado para visualização, análise, analytics, machine learning ou movimentação de dados.

A AWS possui diversas certificações a nível mundial, é considerada segura em qualquer lugar do mundo e hoje conta mais de 10.000 DL espalhados pelo globo rodando em sua plataforma. Para fazer parte deste movimento e dominar um base de dados centralizada, existe um roteiro na qual pode ser seguido para facilitar a absorção do tema:

1. Configurar o armazenamento: quais serão os tipos de armazenamento utilizados?
2. Mover os dados: como os dados serão movidos para a nuvem?
3. Limpar, preparar e categorizar os dados: os dados são consistentes e válidos?
4. Configurar e aplicar políticas de segurança e conformidade: seus dados estão seguros?
5. Segurança: seu ambiente na nuvem está seguro?
6. Disponibilizar esses dados: seus dados estão prontos para serem acessados e visualizados?

É bem provável que muita empresa se assuste com esse “simples” passo-a-passo, pois como é possível garantir que tudo isso se realize sem gastar muito tempo e dinheiro? Bem, pra isso que a Amazon criou o Lake Formation, o objetivo deste serviço é abstrair esse roteiro afim de facilitar a absorção e criação de um DL reduzindo custos.

Por fim, foi a palestra sobre desenvolvimento de aplicativos Serverless que se destacam pela escalabilidade e na praticidade de não haver servidores para provisionar ou administrar, além de não pagar por tempo ocioso de máquina.

A peça chave dos microseviços são as funções Lambda que se encarregam de chamar outros serviços. As funções Lambda precisam ser acionadas através de eventos externos, podem executar códigos das mais diversas linguagens e por estarem na plataforma AWS, conseguem tilizar todos os seus serviços.

Fluxograma de funcionamento de microserviços

Entretanto, para o desenvolvimento de aplicativos Serverless existem algumas precauções que precisam ser atendidas e para isso palestrante abordou a metodologia chamada de “The Twelve-Factor App”. Para fins didáticos o desenvolvimento foi separado em 12 fatores chave, da seguinte forma:

1. Código-fonte: esse tópico é meio obvio hoje em dia, mas ainda é válido ressaltar que, é primordial existir apenas uma fonte para obter código por aplicação. Uma ferramenta de controle de versão é essencial para gerar as diversas implantações do sistema.
2. Dependências: declarar e isolar explicitamente as dependências, cuidar ao usar as tags LATEST para não gerar conflito de versão entre implementações do mesmo código-fonte (dev, homologação, produção). Além de validar as co-dependências para evitar parada de serviços por terceiros.
3. Configurações: sempre armazenar as configurações de ambientes separada do código-fonte. Cada ambiente possui uma configuração de acesso a banco, por exemplo, e esse tipo de configuração não pode estar acoplada ao código-fonte.
4. Serviços de Retaguarda (Backend): trate os serviços de backend como recursos anexados, não isole-o com outros recursos como por exemplo, a base dados.
5. Build, release, run: é necessário uma separação estrita entre os estágios de construção, implantação e execução via script para definir exatamente o que cada parte é responsável por fazer.
6. Processo sem estado (Stateless): execute a aplicação como um ou mais processos que não armazenam estado, tudo é executado e armazenado em algum sistema de storage ao final do seu processo.
7. Vínculo de porta: exporte serviços via vínculo de portas, como API de serviços Lambda que suportam chamadas síncronas e assíncronas.
8. Concorrência: escale através do processo modelo. As funções Lambda são dimensionadas automaticamente com base na carga, mas sempre são limitadas com base nos recursos que foram configurados previamente.
9. Descartabilidade: a velocidade de inicialização da função Lambda é importante, isso pode variar considerando tamanho do pacote da aplicação ( e dependências) + linguagem utilizada + VPC (ou não) + chamadas de código. Por isso é importante descobrir onde estão os gargalos de inicialização e execução da aplicação.
10. Desenvolvimento/Produção semelhantes: é muito importante manter o ambiente de desenvolvimento, homologação e produção o mais similar possível. Com aplicações serverless, isso pode ser alcançado mais facilmente.
11. Logs: sempre monitorar a saúde da aplicação e tratar os logs como fluxo de eventos que estão acontecendo.
12. Processos administrativos: rede tarefas de administração/gestão em processos pontuais.

Seguindo os princípios de microserviços, combinados com as ferramentas serverless (Lambda) e seguindo o modelo de 12 fatores tratado acima, se torna mais harmonioso o processo de alcançar uma arquitetura ágil e escalável na plataforma AWS.

Participar de um evento da AWS é sempre uma garantia de sucesso, a casa sempre estará cheia de pessoas interessadas e empolgadas para compartilhar suas experiências e aprender ainda mais com todo esse ecossistema que a Amazon AWS proporciona.

Foi um dia inteiro ouvindo e dividindo histórias de sucesso para saber quais caminhos seguir. Bem como as dores na construção de aplicativos/serviços na nuvem para saber por onde não seguir, que é tão importante quanto.

Hoje em dia, trabalhar na nuvem já se tornou uma tarefa comum entre as empresas de tecnologia e a Amazon AWS continua investindo tempo e desenvolvendo novos recursos para tornar essa experiência cada vez mais prática, segura e estável.