Google Cloud Onboard – Porto Alegre

Google Cloud Onboard PortoAlegreEstive participando no dia 02 de junho do Google Cloud Onboard, um evento simultâneo em 17 cidades de América Latina. No Brasil, o evento principal aconteceu em São Paulo (Allianz Arena), com transmissão ao-vivo para outras 7 cidades. Aqui em Porto Alegre, a sessão de um dia inteiro aconteceu no Cinemark do Bourbon Ipiranga. Apesar de  meu foco principal ser Microsoft Azure, considerei importante participar e poder comparar as duas plataformas.

Sobre o formato do evento, não achei muito interessante. A proposta de um simples streaming não proporciona interação alguma com os participantes, apesar de achar legal a ideia de reunir o público em uma sala de cinema, distribuindo pipoca, cachorro-quente e refrigerante. O que nos causou estranheza (outros colegas de empresa estavam presentes), foi a interrupção da transmissão durante uma demonstração, pois já era a hora programada para o almoço (a demonstração continuou acontecendo em São Paulo). Tirando o keynote (Renato Carvalho/José Papo) e a palestra final sobre carreira (por Marcelo Leite), todas as outras apresentações foram feitas pela mesma pessoa (Michel Pereira). O apresentador mostrou bastante domínio do conteúdo, mas na minha opinião a organização se equivocou em escalar a mesma pessoa para todas as atividades técnicas, causando um certo cansaço no público (e tenho certeza que o apresentador estava esgotado).

Já sobre os serviços apresentados, praticamente a mesma linha dos ofertados no Azure e AWS. Chamou atenção o fato de a concorrência não ter seu nome falado em momento algum – o máximo foi o “competidor A, competidor B”. Alguns serviços foram apresentados como algo inovador, mas já são ofertas públicas da concorrência há pelo menos dois anos. O .Net teve pouquíssimas referencias (não entendi se foi proposital, ou se a plataforma tem limitações quanto a esta tecnologia).

Uma das coisas que eu achei interessante, é o fato das VM´s na Google Cloud poderem ter sua configuração personalizada, não ficando limitadas a tamanhos pré-definidos como temos no Azure (CPU e memória). Esta característica foi muito salientada, pois tem impacto direto no custo, diminuindo situações de superdimensionamento. Mas o que eu realmente achei sensacional, foram as apresentações de Big Data (terabytes processados em poucos segundos) e Machine Learning (em especial a API de Video Intelligence).

Minha avaliação geral do evento Google Cloud Onboard é média, principalmente pelo fato do formato do evento, não pelo conteúdo em si – realmente é difícil um overview da plataforma em apenas algumas horas.

Vídeo completo do evento

Download das apresentações

 

Traffic Manager – Integrando Azure e AWS

Em praticamente toda documentação ou literatura a respeito de Cloud Computing, o cenário híbrido é abordado. Parte dos recursos on premise, parte na nuvem. Abordagem muito comum, presente em praticamente todas as empresas que estão neste movimento. E soluções distribuídas entre os provedores de public cloud (cloud x cloud), já pensou em implementar? Distribuir a carga do seu website entre Azure e AWS, implementar roteamento baseado em performance (latência) ou até mesmo implementar failover? Sim, é possível – e simples. É nesta hora que entra um de meus serviços preferidos no Azure: o Traffic Manager.

Basicamente, a função do Traffic Manager é distribuir o tráfego entre endpoints localizados em diferentes datacenters. Sendo totalmente DNS based, ele não atua como proxy ou gateway: apenas direciona os clientes diretamente ao endpoint, não “enxergando” o trafégo entre eles.

Azure Traffic Manager - Integrando Azure App Service e AWS Elastic Beanstalk

Os tipos de roteamento possíveis são:

  • Priority: roteamento de tráfego com prioridade para um endpoint primário, sendo o secundário um backup. Exemplo: o endpoint primário do meu website rodando no Azure, e o secundário no AWS. Caso o primeiro esteja down, o tráfego será atendido pelo segundo.
  • Weighted: distruibuição do tráfego entre os endpoints, no estilo “round-robin”. Ou ainda é possível definir um “peso” por endpoint.
  • Performance: meu preferido. Neste método posso ter meus endpoints distribuídos geograficamente. Os clientes serão roteados para o endpoint com menor latência, baseados em sua localização. Exemplo: o mesmo website deployed em regiões diferentes (Brasil e Oeste dos EUA): muito provavelmente, os clientes baseados no Brasil serão atendidos pelo website que roda em nosso país, assim como os clientes dos Estados Unidos possivelmente serão atendidos pela instância rodando naquele país:

Nota: e outros países além do Brasil e Estados Unidos? Em todos os testes que fiz até hoje, utilizando algumas ferramentas (como GeoPeeker), todas as requisições foram atendidas por instancias localizadas nos Estados Unidos (originadas da Ásia e Europa). Não testei América Latina, pois no plano gratuito da ferramenta, países como Argentina não estão disponíveis.

  • Geographic: roteamento “fixo” a endpoints específicos, baseados na localização geográfica. Ainda não utilizei.

Tipos de endpoint:

  • Azure: usados para serviços que estão hospedados no Azure.
  • External: para todos externos ao Azure. Ou seja: para endpoints on-premises ou em outro cloud provider (como AWS ou Google Cloud)
  • Nested: combinação de diferentes perfis do Traffic Manager.

Para este exemplo de integração, nos interessam dos tipos: Azure e External. Teremos uma instância do website rodando como PaaS no Azure (WebApp), e a outra rodando no AWS Elastic Beanstalk, sendo seu endpoint configurado como tipo “External”. A grande sacada do Traffic Manager é essa: se for External, não interessa se está hospeado em sua infraestrutura interna ou em outro cloud provider – ele considera o endpoint do mesmo tipo.

A documentação completa pode ser encontrada neste link.

Implementação:

Assumo que a aplicação já esteja deployed, tanto no Azure Webapps como no AWS Elastic Beanstalk. Neste exemplo, utilizei um projeto .Net que usamos no Global Azure Bootcamp (obrigado Gabriel Molter). Para fins de demonstração, adicionei hard-coded  o cloud provider em questão. O deployment foi feito separadamente em cada um dos serviços, mas poderia ser facilmente integrado no VSTS Online.

Traffic Manager - Aplicação Exemplo - Hospedada no Azure

Traffic Manager - Aplicação Exemplo - Hospedada no AWS

 

A configuração é extremamente simples. Basta criar um Traffic Manager profile, escolhendo nome (formando a URL <nome>.trafficmanager.net), Resource Group e Routing Method. Neste exemplo, o método de roteamento escolhido é o Priority, pois quero reproduzir um cenário onde o Azure seja meu hosting principal e o AWS ecundário, posteriormente simulando um downtime no primeiro. Note que esse método de roteamento pode ser alterado a qualquer momento.

TrafficManager-Azure-AWS-Integration-10

Um detalhe sobre o TTL: como o Traffic Manager é baseado em DNS, é necessário a definição de um TTL (Time-To-Live). Isso significa que uma vez feita a consulta pelo cliente, as próximas consultas deste ao Traffic Manager serão feitas somente após a expiração do TTL. Este valor é definido em segundos (sendo 300 o padrão).

TTL maior ou menor: na minha opinião, vai depender do método de roteamento utilizado, No caso de Priority, com o objetivo de failover, sugiro um TTL menor do que o padrão (caso o ocorra algum problema com o endpoint, não faz sentido ter que esperar 5 minutos para ser redirecionado para uma instancia “saudável”). Posso utilizar o menor TTL possível, indendente de método? Pode, mas lembre-se que a cobrança do Traffic Manager se dá por número de consultas efetuadas pelos clientes.

Assim que o deployment do Traffic Manager estiver completado, basta adicionar os endpoints:

Azure:

  • Type “Azure endpoint“,
  • Name: “Azure” – (ou qualquer outro de sua preferência)
  • Target  resource type: “App Service“, pois estou adicionando um endpoint de uma Azure Web App (PaaS). Outras opções são endpoints de VM´s no Azure ou Cloud Service:
  • Target resource: basta selecionar a Web App (as opções disponíveis aqui são baseadas na escolha do campo acima)
  • Priority: “1” – ou seja, será meu endpoint primário (menor valor, maior prioridade)

TrafficManager-Azure-AWS-Integration-4

AWS:

  • Type “External endpoint“,
  • Name: “AWS” – (ou qualquer outro de sua preferência)
  • FQDN: url completa do site hospedado na AWS (sem http/https ou barra no final)
  • Priority: “2” – prioridade menor em relação ao site hospedado no Azure

TrafficManager-Azure-AWS-Integration-5

 

Assim que adicionado o endpoint, o Traffic Manager irá fazer um health check:

TrafficManager-Azure-AWS-Integration-HealthCheck

Pronto, basta acessar o endereço definido na criação do serviço (http://<nome>.trafficmanager.net).

 

Resultados (baseado no método Prioridade):

Nota: a aplicação, tanto o Azure AppService, quanto o AWS Elastic Beanstalk, foram deployed na mesma região (Brasil). Estes testes são simples (sem alguma metodologia oficial), podendo haver variação.

Para testar este tipo de cenário, costumo usar o GeoPeeker.

  • Estando os dois endpoints online, considerando Azure com prioridade 1, e AWS com 2, todas as requests foram direcionadas conforme o esperado, ou seja, para o Azure:

TrafficManager-Azure-AWS-Integration-Routed to Azure

  • Através do Azure Portal, parei a minha aplicação, deixando a mesma offline. Todas as requests foram redirecionadas para o AWS:

TrafficManager-Azure-AWS-Integration-Routed to AWS Elastic Beanstalk

Observação: se você for executar este teste, esteja atento ao TTL configurado no serviço. Será necessário aguardar o mesmo expirar, para que o roteamento aconteça de forma correta (lembre-se, é um roteamento DNS based). Outra solução é rodar ipconfig /flushdns na sua máquina.

Outros resultados que obtive:

  • Performance: todas redirecionadas para o Azure.
  • Weighted: das seis requests, quatro foram para o AWS.

Apesar de abordar somente a camada de aplicação de maneira distribuída entre ambos provedores de núvem pública – o banco de dados tem uma complexidade muito maior neste cenário (assunto para outro post) – o Traffic Manager é sem dúvidas uma solução robusta e de rápida configuração. Há não muito tempo atrás, os custos para implementar algo semelhante era absurdamente alto, praticamente inviável para empresas de pequeno porte. E para quem estiver estudando para certificação, o Traffic Manager é assunto na prova 70-533.

Até a próxima! Um Tríplice Fraternal Abraço!

Azure – Notificações Utilizando Webhooks (com Zapier e Twilio)

Durante meus testes / aprendizado no mundo Azure, uma das coisas que eu achei mais interessante foi a possibilidade de utilizar Webhooks, possbilitando diversas customizações na forma em que podemos ser alertados sobre algum evento em nossos serviços no Azure (vídeo exemplo ao final do post).

Da Wikipedia:

Um webhook em desenvolvimento Web é um método de argumentar ou alterar o comportamento de uma página da Web, ou aplicação da Web, com callbacks personalizados. Estas ligações de retorno poderão ser mantidas, modificadas, e geridas por terceiros e responsáveis pelo desenvolvimento que poderão não necessariamente estar afiliados com a origem do site da Web ou aplicação. O termo “webhook” foi inventado por Jeff Lindsay em 2007 a partir do termo de programação de computador Hook.[1]

Ou seja: em determinado evento de meu serviço, em real-time, o Azure irá fazer uma chamada http post para alguma URL (utilizando JSON). A partir deste momento, as possibilidades ficam interessantes.

Vamos para aplicabilidade em um cenário real: um website rodando com auto-scale configurado (Scale-Out), entre 1 e 3 instancias. Regra: se a CPU permanecer acima de 70% por um período de 10 minutos, aumento automático de 1 instancia. Da mesma forma, o oposto (CPU inferior a 70% por determinado período de tempo, diminuição automática de número de instancias – “Scale-In”). Para cada evento “Scale-Out” ou “Scale-In”, gostaria de receber uma ligação de voz para meu celular, com uma mensagem personalizada, fornecendo alguns detalhes (por exemplo: Serviço XYZ Escalou de 1 para 2 Instâncias) ou uma mensagem SMS.

Para conseguir criar este fluxo de maneira relativamente fácil, precisamos de outros dois serviços: Twilio e Zappier, Gostaria de ressaltar que são dois serviços independentes do Azure, sendo duas empresas diferentes. Twilio tem sede em San Francisco/CA, e fornece serviços de mensageria, voz, vídeo e autenticação através de suas API´s 100% cloud based. Já o Zapier fornece componentes (conhecidos como “Zaps”) para integração de aplicações web (ao invés de fazer manualmente chamadas para API´s, este serviço fornece uma abstração de todo esse processo, sendo necessario somente definir os passos necessários e preencher alguns campos).

Quanto ao custo: o Twilio fornece um trial, com crédito de U$ 15.00. O Zapier oferece um plano grátis, mas com limitação de 2 steps por “Zap”. Para fins de teste, são suficientes. Mesmo nos planos pagos, eu acho que vale a pena. É possível agregar um valor imenso aos seus serviços e aplicações por um custo acessível.

Implementação:

  • Crie sua conta no Zapier e Twilio
  • Faça login no Zapier, clique em “Make a Zap”
  • Escolha um nome para o Zap. Na configuração da trigger, opção “Choose App“, escolha “WebHook“:

1 - Azure-Creating-Zapier-Twilio-Webhook

 

  • Em “Choose Trigger“, selecione “Catch Hook“:

2 - Azure-Creating-Zapier-Twilio-Webhook

3 - Azure-Creating-Zapier-Twilio-Webhook

  • Test this Step: obrigatório, caso contrário seu Zap não irá funcionar. Será necessário fazer um HTTP POST para URL do Webhook, utilizando o mesmo payload do passo anterior. No meu caso, eu utilizei o Fiddler para fazer esta chamada (você pode usar qualquer outra ferramenta, como curl por exemplo):

4 - Azure-Creating-Zapier-Twilio-Webhook

5 - Azure-Creating-Zapier-Twilio-Webhook

  • Feito o HTTP POST com sucesso, você será notificado na tela pelo Zapier. A URL utilizada será necessária no último passo de configuração (Azure)
  • O próximo passo é configurar a Action resultante da Trigger recém criada. É neste momento em que o Zap fará a chamada para a API do Twilio:

6 - Azure-Creating-Zapier-Twilio-Webhook

  • Como citado anteriormente, é possível fazer o envio de SMS ou efetuar uma ligação. Escolha “Call Phone“.

7 - Azure-Creating-Zapier-Twilio-Webhook

  • Será necessário fazer autorização do Zap para ter acesso a API. Basta fornecer a “Account SID” e “Auth Token“. Estas informações são encontradas no Twilio Console, seção “Account-> Account Settings“:

8 - Azure-Creating-Zapier-Twilio-Webhook

9 - Azure-Creating-Zapier-Twilio-Webhook

  • O passo seguinte é editar o Template. É neste local onde pode ser configurada a mensagem de voz que você irá receber. Será necessário informar o número telefônico de origem (que é criado durante o cadastro no Twilio), o número de destino (com código do país) e formatar a mensagem. Para fins de exemplo, eu estou utilizando apenas o campo “Description“. Você pode fazer qualquer combinação de campos a fim de deixar o mais personalizado possível.

10 - Azure-Creating-Zapier-Twilio-Webhook

  • Teste este passo, marque o Zap como “On” e finalize:

11 - Azure-Creating-Zapier-Twilio-Webhook

  • A última configuração necessária (e a mais fácil), é no Azure. No blade de configuração do Scale-Out, em Notifications, insira a URL do Zap criado.

12 - Azure-Creating-Zapier-Twilio-Webhook

 

Abaixo criei um vídeo com os passos acima e seu respectivo resultado:

 

Dúvidas? Me contate! Até a próxima.

[ ]´s

Global Azure Bootcamp – Porto Alegre

No último sábado (22 de abril), aconteceu o Global Azure Bootcamp. Como o próprio nome já diz, é um evento global – ocorre no mesmo dia em vários lugares do mundo. Em Porto Alegre o evento foi organizado pelo Lucas Chies (MVP Azure), e aconteceu no auditório do prédio 32 da Puc-RS. Foi um dia intenso, com várias palestras interessantes, contando com a presença dos MVP´s Rafael Felipe, Marcus Vinicius Bittencourt e Rodrigo Crespi. Como membro da MSCoP (Microsoft Community of Practices – Dell), tive a oportunidade de palestrar sobre Azure WebApps, juntamente com meu colega Gabriel Molter. Tentamos levar ao público uma idéia de como o serviço funciona (PaaS), deployment slots na prática de DevOps, distribuição multi-região e balanceamento usando Traffic Manager. Infelizmente devido ao tempo limitado, não conseguimos fazer a demo de Scale-Out que havíamos planejado. Pretendo fazer um post dessa feature em breve.

Global Azure Bootcamp Porto Alegre- Turma reunida ao final do evento
Alunos do IENH em peso

Código de Aplicação usada na demo: https://github.com/Molter/AzureBootcamp2017Demo

Exame 70-533

Recentemente fui aprovado no exame 70-533:Implementing Microsoft Azure Infrastructure Solutions. A última prova de certificação Microsoft que havia feito datava de 2009, ainda nos tempos do .Net Framework 2.0. Aproveitei a promoção Azure Single Pack: 1 exame (com re-take se necessário) + 1 simulado oficial por U$ 99,00. Como parte da política de incentivos da empresa onde eu trabalho, no caso de aprovação ainda poderia pedir reembolso. Entretanto, um desafio: ela precisava ser feita dentro de 10 dias, a fim de submeter a despesa ainda dentro do quarter corrente. Já havia “ensaiado” fazer os exames de Azure anteriormente, mas sempre algum outro compromisso ou desculpa fazia eu postergar a idéia – meus estudos sempre paravam pela metade. Desta vez havia decidido que seria diferente. Apesar do prazo extremamente curto para este tipo de preparação, marquei a prova.

No mesmo dia verifiquei todos os requisitos da prova e comecei a procurar material para estudo. Tenho experiência de dois anos na plataforma e achei que seria tranquilo me preparar para o exame (um gigantesco engano). Em novembro de 2016 este exame passou por um refresh, principalmente no que se refere a deployment model: de ASM para ARM. O livro de preparação que eu possuo cobre apenas ASM. A trilha  para a prova 70-533 no Pluralsight, em sua maioria, também foca em ASM, assim como a maioria das dicas de quem já havia feito a prova. Decidi mesmo assim fazer os treinamentos do Pluralsight, e em caso de dúvidas de como o serviço funcionaria no ARM, focar na documentação oficial.

A prova se resume a 6 tópicos. A cada dia de estudos cobri um tópico, deixando os últimos três dias para fazer o simulado oficial do pacote e revisar os pontos que tive mais dificuldade.

Material de Estudo:

Um site com boas refrências é o Build Azure. Recomendo

A prova:

  • 57 questões, com duas horas disponíveis (completei em 1,5). Score mínimo: 700
  • Powershell: muito, mas muito Powershell (certo momento achei que estava na prova errada)
  • ARM: principalmente automação de deployments de Virtual Machines

Alguns fatos:

  • Tenho certeza absoluta que uma questão não havia alternativa correta (referente a path de logs de Queues). Reportei ao final do exame.
  • Questão duplicada: sim, havia. Li várias vezes para me certificar de que não era pegadinha.
  • Set de questões onde não era permitido voltar (as primeiras 8)

Analisando o relatório recebido ao final do exame (Performance by Exam Section), fica claro que meu melhor desempenho foram nas áreas onde tenho mais experiência e vivência do dia-a-dia. Meu pior desempenho, automação com ARM model. Portanto, nada substitui o Hands-On no Azure Portal. E no Powershell, é claro!

Próximo passo: preparação para os exames 70-532 e 70-534. Prentendo fazê-los em maio.

[ ]´s