[Microsoft Azure] Conhecendo o App Service Environment (ASE)

O App Service Environment é um serviço premium que fornece um ambiente dedicado e totalmente isolado que inclui Web Apps, API Apps e Mobile Apps.

Alguns benefícios de utilizar o App Service Environment:

• Capacidade de grande escala – vertical/horizontal (Até 50 instâncias premium)

OBS: A maior instância hoje é a P4 que chega até 8 núcleos de CPU com 14 GB de memória RAM e 250 GB de disco SSD mais detalhes aqui.

• Ambiente e Apps isolados
• É possível estabelecer uma VPN (Virtual Private Network), mas o que isso quer dizer? Os web apps podem fazer chamadas de dentro da aplicação para um rede interna. Ponto negativo, apesar de estar de dentro de uma Virtual Network (VNet) os Web Apps não tem IP interno, ou seja, qualquer requisição deve ser feita através de URL Pública e/ou VIP
• Outro ponto positivo, como está dentro de uma VNet é possível criar várias regras de acesso entre rede interna e requisições oriundas da Internet
• Suporta Express Route, para quem não conhece é um link dedicado entre o cliente e o Microsoft Azure
• Load Balance, existe a possibilidade configurar o ELB (External Load Balance) e o ILB (Internal Load Balance), pelo ELB o acesso pode ser feito a partir da rede pública (Internet) no VIP do ASE, já no ILB o acesso é apenas interno, apesar de ter um VIP, ele é utilizado apenas para a Microsoft dar suporte em caso de algum incidente ou chamado.
• Escala global

Pontos negativos

• A escala do ASE (front-end e worker pool) pode demorar de duas a três horas
• Prisionamento do ASE pode ser muito lento
• Custo elevado para quem está utilizando com poucas APPs

Entrando um pouco na arquitetura do produto..

O ASE é totalmente dedicado para o cliente/subscription do Azure e pode ser escalado até 50 instâncias como mencionamos acima.

Front-End: O front-end é responsável por receber requisições HTTP/HTTPs e fazer o balanceamento das requisições entre um aplicativo e outro, então toda requisição externa é gerenciada por ele. O front-end por design de produto tem necessidade de no minímo duas (02) instâncias Premium 2. Importante conhecer isso, pois vai fazer diferença na hora de precificar o produto. O front-end pode ser escalado de duas formas:

1) Pode ser escalado manualmente acrescentando instância uma à um

2) Pode ser escalado de acordo com alguns parâmetros de desempenho, exemplo: CPU, Memória, Disk Queue, Http Status Code (2xx, 3xx, 4xx e 5xx), etc, é necessário adaptar a necessidade de negócio, aqui no Grupo LTM utilizamos por CPU e Memória

Worker-Pool: Por padrão são 3 worker pools, cada um deles tem recursos dedicados de computação, para cada worker pool pode ter um ou mais plano de serviços, o plano de serviço é onde define o tamanho da instância, se é P1, P2, P3 ou P4, e onde você “aloca” as APPs, por exemplo, tenho Plano de Serviço “1” e o Plano de Serviço “2”, sendo o plano 1 com tamanhos de instância P3 e com escala até 20 e o Plano 2 com tamanhos de instância P1 com escala até 4.

Se eu tenho aplicativos que consomem mais recursos e precisam escalar muito, eu coloco no Plano 1 e para os aplicativos que por exemplo são Admins ou algo do género que consomem menos recursos de computação eu poderia colocar no Plano 2, e esses aplicativos poderia facilmente ser migrado para outro plano de serviços sem downtime.

Eu conversei com algumas pessoas e li alguns artigos e normalmente dividem o workerpool por ambiente, por exemplo: Worker Pool 1 para o ambiente de produção associado a um plano de serviço com mais instância e maior escalabilidade, já o worker pool 2 poderia ser utilizado para o meu ambiente de QA com um plano de serviço e instância menores, e assim por diante, porém isso não é uma verdade absoluta, você pode utilizar da maneira que for conveniente para o negócio da empresa.

Mais detalhes sobre plano de serviços aqui.

O ASE pode ser criado através de powershell, automation, templates ou o mais simples que é pelo portal do Azure (portal.azure.com) todo gerenciamento, administração e monitoramento é feito através de portal que pode ser personalizado a gosto do “freguês” e intregado com outros serviços. O artigo está ficando um pouco longo vou parar por aqui e abaixo vou deixar alguns links para referência para quem quiser se aprofundar mais sobre o Application Service Environment.

App Service Environment Documentation
Azure App Service plans in-depth overview
Introduction to App Service Environment

Até o próximo.
Erick Albuquerque