Nós trabalhamos com projetos web, serviços, apis, conversamos e definimos soluções, desenhamos projetos pequenos, médios, mas e quando o bicho pega e você precisa de algo maior? Estar pronto para administrar e resolver problemas do dia-a-dia no desenvolvimento web, consiste em conhecer também infraestrutura. Você precisa conhecer com certo nível de profundidade tudo o que você usa, direta ou indiretamente para que possa tomar suas decisões. Pensando nisso, organizei nesse post alguns pontos referentes à infraestrutura que você não pode deixar de saber.

A infraestrutura é a base para nossos projetos, é ela que provê toda a camada física para que possamos trabalhar, mas seu trabalho não acaba aí. Há uma série de serviços necessários para que sua App ou Api, ou mesmo site funcione com performance e segurança e nesse post quero trabalhar sob os diversos serviços que a infraestrutura provê para que possamos desenvolver e publicar aplicações e serviços em cloud ou on-premise.

Essa é a lista:

• DNS
• HTTP / TCP / UDP
• Web Servers
• Web Cache
• CDN`s
• Web Application Firewalls
• Cloud
• Virtualização
• Containers

Esse post não tem como propósito te ensinar, apenas apresentar e alertar sobre a relevância desses temas para que você se mova. Afinal, mais cedo ou mais tarde poderá pensar em abrir uma startup e talvez se deparará com problemas desse tipo, ou já está passando por alguma dificuldade em sua empresa hoje. Não importa o momento, é importante conhecermos, pois há cenários em que esses mecanismos são mal configurados e afetam diretamente sua aplicação. Se você souber o que está presente em todo o stack, terá maior sucesso no troubleshooting, caso conheça as ferramentas em questão, terá um sucesso maior ainda.

Aqui apresento soluções que nós precisamos usar no dia-a-dia, e por falta de conhecimento, podemos hora ou outra dar uma volta ao mundo para solucionar problemas que já foram muito bem endereçados. Ainda que não tenha o propósito de ensinar, estou colocando alguns vídeos que ilustram o que estou a dizer.

Aqui vai uma dica de ouro:

[dt_quote type=”blockquote” font_size=”big” animation=”none” background=”plain”]

Se você tem um problema hoje, é provável que alguém já tenha tido o mesmo problema no passado. Há uma boa chance de outro alguém já ter solucionado esse problema de forma simples. Há uma possibilidade, menor, muito menor de existir um produto dedicado para a solução deste problema.

Muitos dos problemas que tentamos solucionar nos nossos projetos, implementando features de infraestrutura, podem ser solucionados com poderosas ferramentas dedicadas a atender demandas específicas. Seja na utilização de um AMQP Server (RabbitMQ, por exemplo) ou a utilização de um CDN, ou um Web Cache (como Varnish, por exemplo).

[/dt_quote]

Toda aplicação web começa com sua hospedagem em um servidor web/aplicação geralmente exposto, de cara para a rua. Quanto maior o consumo, maiores são os problemas que vemos nesse desenho descompromissado. A PaaS tende a não nos apresentar esses problemas pois os stacks estão todos bem desenhados para que você não se preocupe com esses recursos, no entanto, você como desenvolvedor precisa conhecê-los, pois na maior parte do PaaS existente no mercado hoje, você vai encontrar uma série de ferramentas administrativas que manipulam/gerenciam algumas das soluções e/ou conceitos/padrões/protocolos que vou abordar aqui.

Sem mais lero-lero, vamos aos temas.

DNS

O DNS tem o papel de resolver NOMES em endereços IP (v4 e v6), mas não fica só nisso.

Em um DNS, existem tipos de registros, que podem auxiliar a resolver problemas no dia-a-dia, como por exemplo, redundância, quando configuramos chaves para identificação de uma lista de nomes que podem responder por uma API ou site.

Podemos usar os tipos services ou tx para brincar com informações públicas, como por exemplo:

Quando você precisa validar a autoridade de um domínio no google | Confirmar o domínio com um registro TXT.

Entendendo um pouco de DNS é possível resolver problemas simples de ambientes de desenvolvimento com serviços públicos e free como DynDNS ou No-IP. Em conjunto com as capacidades dos servidores web em implementar Web Proxies, você consegue facilmente fazer testes e implantar ambientes mais complexos com  3, 5 sites (ambientes de uma mesma aplicação, ou aplicações distintas). Ou caso prefira, implementar servidores de DNS em sua rede, com Windows, ou Linux.

Assim, na próxima vez se deparar com erros como este (abaixo), saberá que o problema está na resolução do nome e poderá concluir, sem nenhuma dúvida que a aplicação não recebeu nenhuma requisição oriunda desta tentativa de acesso.

HTTP, TCP e UDP

Conhecer os protocolos te ajuda a saber que algumas ferramentas de log e monitoração usam UDP para enviar estatísticas e log online, e não estão preocupadas com perdas. Ajuda a entender também que embora seja mais eficiente quando você não precisa da confiabilidade do TCP, você pode acabar floodando uma rede dependendo do que fizer.

Aqui temos um vídeo didático sobre TCP e UDP.

Agora vamos falar de HTTP e alguns outros protocolos web.

Web Server

Aqui vai uma aula completa sobre TCP, HTTP, Web Servers e um pouco mais. Esse vídeo é bem longo, portanto sugiro que pesquise a respeito. Ao falar de web server, devemos não nos abster ao IIS, mas precisamos conhecer o Apache e o Nginx, mesmo sendo desenvolvedores .Net. É muito provável que você use um desses nomes direta ou indiretamente nos próximos anos, ou talvez esteja usando e sequer sabe disso.

Olhar para o NGINX, que pronuncíasse “êngin-éx” (analogia a engine x), usado por uma lista de grandes nomes (abaixo), ajuda a entender muito bem algumas coisas.

Entre outras coisas, a parte de Reverse Proxy, onde você coloca um WebServer entre seu cliente e o web server de processamento, ajudam a compreender como resolver alguns problemas do dia-a-dia de quem está montando sua própria infra, seja com containers ou não.

Aliás aqui temos alguns exemplos:

Aqui no Stack Overflow há um exemplo de pergunta sobre o exato stack que eu uso. Na pergunta ele não menciona docker, no entanto na minha implementação todo o stack é composto com Docker. Uso esse stack para melhorar performance no WordPress de um dos clientes, no entanto nesse site aqui, já uso uma infra mista com cloudflare, dado o número de acessos que tenho (baixo), posso usar o plano free sem dor de cabeça e nem custos.

Web Cache

Por favor, Redis e MemCached não estão nessa categoria!! Não há discussão sobre isso, nem dúvidas, eles não atendem requisições HTTP, portanto não são, ok?! No entanto, ambos são muito usados como storage para quem realmente faz web caching. Redis e Memcached são KeyValue storages, por exemplo o Módulo web-cache do Node diz:

[dt_quote type=”blockquote” font_size=”big” animation=”none” background=”plain”]

Using Redis as a backend, the cache allows the server to avoid making repeated expensive or long-waiting route handling. This is useful for serving static content or a relatively static data API.

This module acts as middleware for web servers built on Connect, such as Express. Other than configuring it in the web server, it does not require any other custom code. It also has some sensible defaults so you can hit the ground running.

The cache expires items not accessed after a configurable age.

Note that a Redis server needs to be running for the cache to operate.

[/dt_quote]

Eu uso Varnish há muitos anos e gosto muito do projeto, esses fluxos ajudam a entender como funciona:

Talvez você possa se questionar sobre o motivo para adicionar um serviço, seja ele qual for, a mais no stack, e se isso não deixaria a aplicação mais lenta. NÃO!! Se estiver corretamente configurado deixa mais rápida! E “corretamente configurado” entenda como: Configurado para não deixar passar para o backend requisições que poderiam ser cacheadas, apenas isso. Varnish faz milagres com webservers, pois consegue remover em muito o load de um webserver, possibilitando assim que o webserver atenda somente às requisições essenciais, aquelas que por algum motivo não podem ser cacheadas, ou ainda não foram.

CDN

Os CDN’s são soluções de cache em modelo PaaS, que no passado trabalhavam exclusivamente com conteúdo estático, mas hoje conseguem fazer o mesmo que o Varnish. Esse site (luizcarlosfaria.net) que você está vendo, está hospedado no hostwinds, nos EUA, mas quem te serve todo o conteúdo, é o CloudFlare, com seu data center de São Paulo. Para que isso funcionasse eu precisei apontar meu DNS (luizcarlosfaria.net) para o CloudFlare, criar algumas regras que digam qual conteúdo nunca é cacheado (páginas de admin do wordpress etc) e pronto. No Hostwinds eu tenho um Nginx, para redirecionamentos, e um apache (para cada site, inclusive esse aqui).

Em um dos meus clientes, usava o Amazon CloudFront. Eu o usava como um CDN tradicional, onde eu tinha uma url específica do CDN (cdn.blablabla.com.br), mas precisava fazer upload do conteúdo estático para o Amazon S3, backend do CloudFront. Mas o CloudFront suporta um modelo bem parecido com o CloudFlare, porém mais limitado, já que o CloudFlare não para em CDN, tem features diversas de segurança e otimizações.

Web Application Firewalls

WAF ajudam a melhorar a segurança com base em políticas de acesso e filtros de segurança que permitem elevar o nível de segurança de aplicações. Não é incomum encontrarmos serviços que se propõem a fazer WAF, cache e muito mais.

Cloud, Virtualização e Containers

Deixei por final o mais gostoso para se falar. Mas o mais relevante a dizer é que a forma como trabalhamos hoje está para morrer e isso é ótimo! As estratégias de deploy que temos hoje não são eficientes se comparadas com alternativas de cloud, virtualização e containers e sob estes aspectos veremos nos próximos meses e anos o abandono em massa de muita coisa da forma como as conhecemos hoje. O que hoje consideramos ser “o padrão”, ou o caminho natural, em um futuro próximo será apenas exceção, aplicações que por alguma feature ou dependência, não puderam ser migradas. Sob esse ponto de vista é extremamente relevante olhar para novas estratégias de deployment para que você comece a se aproximar da nova realidade.

Para quem, assim como eu, está diretamente ligado à plataforma .Net, é bom lembrar que a Microsoft está investindo muito em desenvolvimento cloud, e está desenhando novos modelos, novas estratégias focadas nesse cenário e agora já encara Docker com tamanha prioridade que está na home do microsoft.com/net/core. Por outro lado com containers no Windows Server 2016, vemos um novo modelo de deployment focado no próprio Windows, que já suporta IIS, Nginx e outros, baseados em binários windows.

Conclusão

Há muita coisa que podemos usar no dia-a-dia e as vezes optamos por soluções minimalistas que no final das contas mais atrapalham que ajudam. Existem serviços e produtos especializados em cada item de um stack web, como o caso do HAProxy, que não comentei, mas espero fazer um post detalhado mais à frente. Esses produtos e serviços poupam tempo e possuem aderência global, o que facilita o uso, por achar boa documentação e artigos que ajudem, além de serem amplamente testados.