Entrega contínua com PaaS (Plataform as a Service) - Continuação

Relacionadas a publicação anterior ainda precisamos responder duas questões relevantes:

  

Quais soluções utilizar?

Quais as vantagens obtidas?

Caso não tenha lido a publicação inicial, que gerou a necessidade de responder tais questionamentos, confira o post anterior - Entrega contínua com PaaS (Plataform as a Service)

O ponto é que dependerá das soluções utilizadas, bem como do tipo de demanda da organização em que você aplicará tal solução. Veja que os fatores para que ocorra tal variação serão o tamanho da organização, o orçamento disponível para a implantação, a estrutura a ser orquestrada, a cultura e a maturidade do ciclo de desenvolvimento.

Aqui utilizaremos algumas soluções que são bem aceitas pelo mercado, onde você poderá substituir de acordo com seu cenário. Não estamos tratando de configuração e uso de solução, mas sim propondo um modelo de ciclo e exemplificando com ferramentas disponíveis e de fácil acesso, ou seja, sem nos preocuparmos com licenciamento e custos de sustentação.

Considerando que na primeira publicação implantamos a ideia de entrega contínua e uso do PaaS, agora  mostraremos  as soluções em um cenário de exemplo.

Premissas e pré-requisitos para o ambiente proposto:

Pré-requisitos

1. Ao menos duas máquinas virtuais para simular o ambiente;

2. Recursos físicos disponíveis para que o fluxo publicado no post inicial seja efetivado:

Premissas

1. Uso dos seguintes componentes:

• IDE (Integrated development environment): Será utilizada para o desenvolvimento do código.
• Repositório de versões: Controlador de versões, gerenciar alterações e mesclagens.
• Ferramenta de integração contínua (CI - Continuous Integration): Fará a integração entre o ambiente do desenvolvimento e os ambientes disponíveis de evolução da aplicação, originalmente publicando alterações no ambiente de desenvolvimento, testes, homologação e produção.
• PaaS (Plataform as a Service): Plataforma que em nosso cenário fictício será o hospedeiro da aplicação nos ambientes mencionados acima.

2. Como falamos acima, as soluções utilizadas foram definidas por padrão de mercado ou melhor adaptação e conhecimento, o leitor pode adaptar as soluções desde que saiba trabalhar com as mesmas;

3. Licenciamento não serão abordados;

4. Desconsideraremos que não é interessante termos os ambientes (desenvolvimento, etc…) em um mesmo servidor físico, sem isolamento de rede, geográfico, e demais recomendações que a ISO 27001 julga relevante.

Quais soluções utilizar?

Na camada de PaaS como solução para uma infraestrutura (datacenter) local ou híbrida, o projeto mais maduro é o OpenShift. Para realizar a integração uma boa indicação é o  Jenkins , devido ao número relevante de plugins disponíveis. Com estes plugins o ciclo é facilitado, pois podemos integrar com repositórios GIT/GITHUB, projetos Maven para geração do artefato e não esquecendo da camada de dados plugins para o FlywayDB ou Liquibase.

Quanto a qualidade de código, testes de performance e etc, o Jenkins tem plugins de uso simplificado para utilização do Sonar, jMeter e demais soluções.

Por ser um integrador, não poderia faltar um plugin para realizar a publicação da aplicação no PaaS, o que justifica ainda mais as escolhas mencionadas acima.  

Quais as vantagens obtidas?

Poderia citar inúmeras vantagens adquiridas pelo uso do CD, CI, mas focaremos em uma em específico, que é gerada pela composição de soluções mostradas na publicação, independente do valor investido ou do tamanho da organização, e de extrema importância para o desenvolvedor: o ganho de agilidade e preocupar-se com o que importa - a qualidade do desenvolvimento, reduzindo a complexidade de infraestrutura para publicação de aplicações.

Legendas

PaaS: Plataform as a Service

CD: continuous delivery

CI: Continuous Integration  

IDE: Integrated development environment]]

Publicação também disponível em: http://ilegra.com/beyonddata/

Entrega contínua com PaaS (Plataform as a Service)

Ao escrevermos sobre PaaS devemos ter o conceito que estamos trabalhando com um modelo de plataforma direcionado à aplicações e alguns  de seus objetivos específicos – razões de sua existência – são a simplificação, flexibilização, em função da utilização de estrutura como serviço, que proporcionarão maior agilidade do processo de provisionamento de aplicações.

Quando mencionamos PaaS, desprenda-se da ideia de que seu negócio será deslocado para o datacenterde um fornecedor externo, nem pense em uma caixa preta, pois é possível trabalhamos com PaaS em seu datacenter local, de forma híbrida com integração externa ou somente em um fornecedor externo.

Devemos estar atentos às demandas da organização, identificar necessidades de acordo com critérios claros de aplicabilidade de uma solução e urgência da mesma. A soma da consistência e acerto de seus critérios resultará na aderência e sucesso do projeto.

Existe razão de utilizarmos como modelo de plataforma o PaaS em busca de flexibilização e agilidade se o processo de desenvolvimento das aplicações na organização alvo utiliza métodos que não demandam tal agilidade? Respondendo a este questionamento, podemos relacionar a aplicabilidade do PaaS com a Entrega Contínua (CD – Continuous Delivery)?

Antes de responder a questão, resumiremos aqui Entrega Contínua. Entrega Contínua consiste em uma abordagem de desenvolvimento, gestão, e ou automação que permita entregar valores de forma ágil ainda que trabalhe com ciclos que garantam a confiabilidade do valor entregue.

Não esqueçamos de responder a pergunta anterior. Na humilde opinião de quem vos escreve, sim, grande parte da justificativa do uso do PaaS se aplica a Entrega Contínua como abordagem de desenvolvimento de aplicação. Não desacreditando que Entrega Contínua não possa ser feita em outros modelos tal qual o IaaS (Infrastructure as a Service), mas como o fator observado é o motivo e valia, sim, o uso do PaaS agrega muito na agilidade do processo de entrega da aplicação.

Para esta publicação nos propusemos apenas que idealize uma solução simples de entrega contínua, ou seja, absorva o conceito do ciclo que envolve, desde um ambiente integrado para desenvolvimento de software (IDE) até a publicação no ambiente de desenvolvimento da plataforma apresentada, PaaS.

Você é o desenvolvedor, que em conjunto com uma equipe, trabalhou dias no desenvolvimento de um micro serviço que tem como função integrar, consumindo informações de um sistema legado e que disponibilizará para um novo módulo de uma aplicação web que está em desenvolvimento por outra equipe da sua organização. Tal integrador foi desenvolvido na linguagem Python, e utiliza recursos auxiliares, peculiares e conflitantes com aplicações existentes.

Veja que ao utilizarmos o PaaS como modelo de plataforma este não seria um evento impactante no projeto, uma vez que pode-se entregar como serviço uma plataforma exclusiva que atende os requisitos da aplicação alvo sem que reflita ou conflite com as demais aplicações ou ativos da organização.

Uma vez criada a plataforma para a aplicação em questão chega a hora de dar agilidade no processo de publicação da aplicação, não esquecendo o ciclo de promoção dos ambientes.

Em um início de tarde, você utilizando sua IDE, realiza o *commit em seu repositório local de GIT. Avalia então necessidades de *merge. Passados os procedimentos de controle de versão seu trabalho, assim como os de outros, estão na *branch master do repositório GIT da equipe. Através de um *hookconfigurado que dispara um job em uma ferramenta de automação para geração do artefato.

Com o artefato gerado após passar por testes de cobertura, unitários, funcionais e de performance integrados na ferramenta de automação. Tal artefato é publicado no ambiente de desenvolvimento do PaaS sem interação humana. E quando o build for finalizado com sucesso, você,  assim como sua equipe, poderá comemorar o resultado de dias de trabalho.

Agora restará avaliar a janela de publicação, aprovação e demais processos que sua organização realiza para promover o build para os ambientes de teste,  homologação e produção.

Surgirão questionamentos tais como:

• Quais soluções utilizar?
• Quais as vantagens obtidas?

Continua!

commit: confirmar alterações/adições em um repositório

merge: mesclar alterações/adições em um repositório

branch master:  nome do branch padrão no Git

hook: disparar scripts quando certas ações ocorrerem

build: versão "compilada" de um software ou parte dele

Agradecimentos aos amigos e colegas César Mesquita, Lincolm Aguiar e Milton Duarte, pela paciência, orientação е incentivo qυе tornaram possível а conclusão desta postagem.

Publicação também disponível em: http://ilegra.com/beyonddata/

JBoss/Wildfly - Um cluster sem multicast, mod_cluster ou mod_jk

Diversas publicações na Internet apresentam uma forma de realizar a configuração no Wildfly de um cluster com replicação de sessão e com balanceamento de carga quando temos no ambiente a composição de Wildfly(infinispan, jgroups), Apache e mod_cluster ou mod_jk. Também outro cenário comum nas publicações é que é permitido o multicast, ou seja, a propagação de informações para diversos destinatários usando UDP.

Em datacenters privados é possível tal configuração, mas vamos levar para a realidade do VPC da Amazon, onde temos o Overlay Multicast como opção para fazer Multicast que para a habilitação deve ser seguido um roteiro de ajustes, instalações de pacotes e etc, que não julguei interessante uma vez que podemos utilizar um meio mais simples de configurar o reconhecimento de host-controller do cluster.

Caso sua necessidade seja trabalhar com AutoScale, então o Overlay se justifica principalmente por não fixar configurações no domain.xml, deixando mais dinâmica sua configuração, entretanto se este não é sua necessidade, vamos simplificar e transformar o multicast em uma lista de hosts de host-controllers.

Mais um item interessante de mencionar, citando replicação de sessão, é alterarmos a comunicação dos objetos de sessão de UDP para TCP, pois isso transformará a replicação em algo mais confiável.

Mas quais ajustes são necessários e em quais arquivos?

Na minha publicação não tratarei de como configurar um cluster, pois isto podes achar em diversos sites com a correta orientação, mas vou citar especificamente as configurações que citei acima do initial_hosts do jgroups e também do método TCP com TCPPING. Para realizar estes ajustes segue um exemplo de configuração do domain.xml que podes adaptar a tua realidade de ambiente:

IMPORTANTE: Aplique as configurações abaixo no profile utilizado, no HA ou Full-HA, onde o que está em negrito são os ajustes realizados.

Observe que o nome ‘master’ e ‘slave1’ são os node identifier no host.xml. Também libere a porta 7600 nos SecurityGroups.

Mas por que não utilizar o mod_cluster ou mod_jk? Quando estamos um ambiente AWS* podemos utilizar o próprio LoadBalancer(ELB) como balanceador e health-check* das instâncias, semelhante a funcionalidade do mod_cluster, e que também é baseado em loadfactor para distribuir as conexões. Ao fazemos isto precisamos necessariamente não expor a interface de gerenciamento(bmanagement) deixando-a apenas como loopback ainda que possas contar com as regras de SecurityGroups, também precisaremos uma página simples de teste dentro do WAR/EAR para  o ELB, uma que pode retornar ‘OK’ após fazer alguns testes funcionais na aplicação para termos a certeza de funcionamento de DataSource e demais componentes relacionados a aplicação.  

Certificados SSL também podem ser instalados no ELB, assim como a camada de cache pode ser CloudFront, mas se precisar envolver redirecionamentos para atender o negócio da aplicação então não tem como fugir de um webserver, então poderá utilizar o Apache com mod_cluster ou mod_jk como frontend para o ELB. Sugiro o uso do mod_cluster como balanceador em função do loadfactor mais eficiente com relação ao mod_j.

Qualquer outra dúvida pertinente ao Wildfly também podes recorrer à documentação do produto que é bem rica em detalhes, seja para o analista de infraestrutura como para o desenvolvedor. O link está disponível nas referências da publicação.

* Wildfly - chamarei nesta publicação somente assim e não mais de JBoss apesar de eu particularmente não gostar do novo nome

* AWS - Amazon Web Services

* health-check - modelo que checagem para saber se o serviço da instance está ativo e funcional, respondendo as condições que especificaste no ELB

Referências:

https://aws.amazon.com/articles/6234671078671125

https://docs.jboss.org/author/display/WFLY10/Documentation

Publicação também disponível em: http://ilegra.com/beyonddata/

Glassfish - Importar um certificado válido e existente

Quando você precisar migrar um ambiente ou uma aplicação para o Glassfish, você encontrará algumas adversidades. São elas:

1. Migrar os certificados de um Oracle Wallet(p12) para um Java Keystore/Truststore; (imaginando que o ambiente legado é um OHS (Oracle HTTP Server));
2. Importar certificado de outro ApplicationServer com o keystore já configurado.

Não incluo aqui a criação de um novo certificado SSL, certificado auto assinado, ou renovações, pois a “privatekey” pode ser recriada sem problemas. Já a publicação se aplica quando a chave privada não pode ser recriada por alguma razão, seja pelo uso de um outro sistema ou impacto de negócio.    

Privatekey: Chave privada usada no sistema de criptografia baseado em chaves.

Mas qual o grande problema? Bem, o Glassfish suporta apenas um keystore e um truststore que vem previamente setado para uso do alias ‘s1as’. Quando configurado o ‘http-listener-2’, atendendo a porta 28181, este certificado não é reconhecido como válido, pois é para fins administrativos. Portanto, é necessário substituí-lo, o que é mais comum, ou incluir um novo alias no keystore localizado no diretório ‘config’ do domain.

IMPORTANTE: Sete a variável $JAVA_HOME para o mesmo JDK do oracle_commons dentro do $MIDDLEWARE_HOME. Os comandos abaixo incluem o JDK/bin no PATH, então não precisei passar o PATH completo do orakpi e keytool.

1. Migrar os certificados de um Oracle Wallet(p12) para um Java Keystore:

orapki wallet pkcs12_to_jks -wallet ewallet.p12 -pwd coloque_a_senha_do_wallet_aqui -jksKeyStoreLoc keystore.jks-conv -jksKeyStorepwd changeit -jksTrustStoreLoc cacerts.jks-conv -jksTrustStorepwd changeit

2. Importar certificado de outro ApplicationServer com o keystore já configurado;

Como mencionado, o Glassfish suporta apenas um keystore. Logo precisará fazer o merge do keystore e do truststore:

keytool -v -importkeystore -srckeystore cacerts.jks-conv -srcstoretype JKS -destkeystore cacerts.jks -deststoretype JKS

keytool -v -importkeystore -srckeystore keystore.jks-conv -srcstoretype JKS -destkeystore keystore.jks -deststoretype JKS

Neste ponto precisará saber as senhas de todos os JKSs, pois serão solicitadas as senhas dos keystores de origem e destino. Caso as mesmas não estejam, utilize o comando abaixo para ajustá-las:

keytool -keypasswd -new changeit -keystore keystore.jks -storepass "senha do keystore" -alias orakey1 -keypass "senha antiga"

Possíveis problemas durante o processo serão relacionados ao keystore de origem ser 32 bits e o de destino 64 bits.Então sugiro manter como o de destino o que atenda o hardware de seu ambiente de Glassfish, assim como a senha do certificado alias que deseja utilizar tem que ser igual. Logo, utilize todas as senhas iguais a senha do master-password do Glassfish.

Não esqueça de após o merge dos keystore alterar o alias do certificado SSL do ‘http-listener-2’ para o alias desejado. Para visualizar o alias utilize o comando abaixo:  

keytool -list -v -keystore keystore.jks

Referências:

https://en.wikipedia.org/wiki/Public-key_cryptography

https://docs.oracle.com/cd/E19798-01/821-1751/6nmnci6aa/index.html

http://www.webfarmr.eu/2010/04/import-pkcs12-private-keys-into-jks-keystores-using-java-keytool/

https://www.sslshopper.com/article-most-common-java-keytool-keystore-commands.html

Publicação também disponível em: http://ilegra.com/beyonddata/

WLS - Weblogic, um motivo para migrar seu OAS

Um dia o gerente de desenvolvimento chega a sua mesa e reporta que a era do seu Oracle Application Server (OAS) 10g chegou ao fim. Ele valoriza um relatório objetivo e visualmente agradável com análise de impacto de negócio bem enumerada e suficiente para que a renovação ou atualização de licenciamento seja uma necessidade imediata.

E se é você que precisa entregar este relatório bem fundamentado, quais os pontos para chegar a tal conclusão? Além disso, como através de diferenças técnicas você poderá apoiar o relatório para que sejam correlacionadas ao negócio? Essa publicação citará algumas diferenças e evoluções técnicas entre o OCJ4 e o Weblogic, de forma a gerar insumos que lhe darão motivações técnicas para impactar o negócio.

Resumidamente a história é a seguinte, a Oracle, até a versão 10gR3 de sua suíte de middleware, tinha, dentre os componentes que formam o OAS como contêiner JavaEE, o OCJ4. Com a aquisição da BEA em 2008, o contêiner foi substituído pelo Weblogic na versão 11g.    

Isto pode parecer uma alteração simples, mas não é, e por se tratar de outro contêiner JavaEE, mudam, além de a atualização de versão dos componentes, o que já é algo preocupante, também a administração e interação das aplicações com o servidor de aplicação. Para o time de desenvolvimento, isso significa mais do que atualizar seu projeto dos frameworks utilizados, mas também identificar e estudar os métodos com que este novo contêiner irá interagir, seu plano e funcionamento de publicação e  a estruturação diferenciada do processo. Em uma organização que utiliza as demais soluções da suíte, tais como, Forms & Reports, BI ou SOA a complexidade aumenta exponencialmente.

Em um comparativo técnico simples, o principal valor agregado na migração e que por si só já a justifica, ainda que não demonstre a relação de urgência, somente de importância, é a atualização da especificação JavaEE suportada, a última versão do OC4J tem compatibilidade completa com as especificações do JavaEE 1.4, enquanto o Weblogic12cR2 tem compatibilidade com as especificações JavaEE 7. Ou seja, isto permite ao desenvolvedor trabalhar com novas abordagens da linguagem, em uma versão com o Java mais recente e com novas features e correções de bugs que darão maior agilidade ao time e um aumento de performance significativo com relação as versões anteriores. Assim, ao não proceder com a migração, suas aplicações estão fadadas a descontinuidade ou legado.  

Demais recursos do Weblogic com relação ao OC4J podem ser evidenciados na arquitetura, administração e configuração de recursos, managedservers e planos de implantação, ou seja, uma lista que pode ser obtida de acordo com o negócio da sua organização. Para tal, sugerimos realizar um comparativo baseado nas documentações dos produtos, pois as features que poderão ser relevantes a sua organização serão indiferentes a outras, cabe ao gestor responsável pelo processo de avaliação da migração julgar o que será aderente a seu time de desenvolvimento e operação.

Para motivações de negócios, consideramos s razões técnicas que consistem no uso de uma especificação atual que entrega performance, gestão e desenvolvimento de aplicações em um menor tempo, tais razões são de forma geral:

1. Uma maior capacidade da equipe em desenvolvimento de novos recursos ou versões da sua aplicação;
2. Possibilitar com  o ganho de performance  inclusive a revisão de recursos físicos ocupados pela sua camada de middleware de sua organização;
3. Sem adicionarmos as relevantes alterações que a atualização traz ao seu negócio em específico.

Custo e método de migração

Vamos ao que viabiliza ou não uma migração: o custo.  Apesar de os resultados positivos de uma atualização serem facilmente percebidos , o método de migração e a importância ao processo dado pela organização darão  a variação do retorno sobre investimento (ROI), valor presente líquido (VPL), ou payback. Por este motivo, um plano de migração adequado, bem estruturado e planejado afetará os resultados diretamente.

A escolha do método...

A organização, ao contratar o Sustaining Support do Lifetime Support da Oracle, terá direito a atualização dos produtos de middleware sem custo adicional. Caso o mesmo não possua o Lifetime, terá duas opções:

1. Pagar o retroativo do serviço de suporte/atualização e realizar a migração;
2. Comprar uma nova licença.

Com um processo de migração orientado corretamente, com ferramentas do de apoio do fabricante e foco bem dimensionado do time de desenvolvimento e operação, reduzimos os riscos do projeto, mas também contribuímos para  ele ser percebido positivamente na cultura da organização.

Referências:

https://blogs.oracle.com/java-platform-group/entry/upgrading_major_java_versions

https://en.wikipedia.org/wiki/Oracle_WebLogic_Server#cite_note-1

http://www.otmfaq.com/forums/blogs/chrisplough/2-bea-weblogic-vs-oracle-oas-otm-g-log.html

http://docs.oracle.com/middleware/1221/wls/INTRO/intro.htm#INTRO123

http://www.oracle.com/br/support/lifetime-support/index.html

Como última consideração ficam meus agradecimentos ao colega Joel Corrêa (joel.correa@ilegra.com), arquiteto de software na ilegra, que apoiou-me nas dúvidas relacionadas ao desenvolvimento. Ao colega Felipe Lindenmeyer (felipe.lindenmeyer@ilegra.com), executivo de contas na ilegra, que me amparou nas questões de licenciamento e custos.  

Publicação também disponível em: http://ilegra.com/beyonddata/

CDN - CDN é só o que eu preciso para camada de cache?

Primeiro vamos explicar de maneira resumida o que é CDN. CDN, que é a sigla abreviada de Content Delivery Network, provê uma entrega mais eficiente do conteúdo estático do seu site, isto porque possui uma melhor distribuição geográfica para o usuário que requisita tal conteúdo e faz a entrega baseada na geo-localização do requisitante. Isto praticamente elimina o "delay" geográfico para acesso aos dados.

Sua primeira pergunta deve ser: mas eu preciso disto? Isto variará com o público alvo, se o público que queres atingir é concentrado em uma só região, exemplo, tens uma empresa que atende somente o mercado do Rio Grande do Sul e não tem uma prospecção de crescimento geográfica, CDN não será efetiva em sua plenitude, pois agregará somente como uma camada de cache, e mantê-la para essa finalidade exclusiva torna-se caro e pode ser realizado com outras técnicas que mencionaremos abaixo.

A próxima pergunta será: a CDN resolve meu problema geográfico? Sim em termos de cache de conteúdo. Somente a CDN resolve meu problema de performance quando tenho um fluxo grande de requisições? Não. Para tal existem técnicas de crescimento de frontend, backend para ganho de vazão, mas o que abordaremos aqui é a técnica de cache, que permite atender uma demanda maior sem a necessidade de aumento proporcional do backend e frontend.

Quando cito frontend, compreende-se a camada de middleware e não meio-físico, roteadores, balanceadores de carga e etc, mas sim webservers, portais modulares que são os primeiros a receber a demanda, às vezes devolvendo a resposta, outrora distribuindo para servidores de aplicação, integradores e webservices, que aqui são tratados de backends.

Independente do uso de CDN, quando a proporção de acesso aumenta faz-se cada vez mais necessário o uso de cache local, ou seja, a implementação de uma camada antes dos webservers que receberão as requisições, repassarão as mesmas para os webservers, mas já entregarão ao usuário objetos, imagens e outros que constam em sua memória, dando ao usuário a percepção de agilidade no acesso.

 

Tal camada será efetiva quando o índice de acertos (hitratio) do cache for elevado, para tal, deve ficar claro que temos dois métodos de uso:

 

 1 - regras locais: onde a administração da configuração do que será armazenado, ou não, no cache e por quanto tempo é responsabilidade da solução de cache ou webserver. Então regras, ainda que constem no cabeçalho (header) do objeto serão sobrescritas.

if(req.url ~ "^/search/forum_search_results") {    set beresp.http.Cache-Control = "max-age=15";    set beresp.ttl = 15s;    set beresp.grace = 15s;  }

 2 - regras do objeto (HTML, JSP e etc): as configurações de persistência, e do que será armazenado em cache, será realizado no próprio objeto. Um exemplo:

//set headers to NOT cache a page header("Cache-Control: no-cache, must-revalidate"); //HTTP 1.1 header("Pragma: no-cache"); //HTTP 1.0 header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Date in the past //or, if you DO want a file to cache, use: header("Cache-Control: max-age=2592000"); //30days (60sec * 60min * 24hours * 30days) ?>

Quais os headers de cache comuns?

cache-control

Este é o header que faz o controle de cache, para obter informações de controle de um objeto procure por essa palavra-chave.

private ou public

Este parâmetro do header ‘cache-control’ permite aos caches intermediários saberem se devem ou não realizar cache de um objeto, não está relacionado à segurança ou a algum conteúdo que não pode ser visto.

no-cache

Esse parâmetro faz com que o objeto alvo sempre seja revalidado, na prática essa tag diz: não faz cache de mim.

no-store

O parâmetro normalmente é seguido do ‘no-cache’, ele informa a sua solução de cache ou navegador que não se deve armazenar parte dele, no caso, o objeto.

max-age

Ai está a configuração de idade do cache, ou seja, quanto tempo ele deverá expirar. Este valor varia de acordo com o tipo de conteúdo.

Aos mais usados...

Com relação a CDNs temos alguns fornecedores importantes como Amazon,  Microsoft e Akamai. Cada fornecedor possui seus pontos fortes e fracos, entretanto a Amazon é superior no quesito de maturidade e quantidade de oferta de produtos para nuvem. O site dos comparativos podem ser acessados nas referências desta publicação.     

Já quanto ao cache local podemos citar Varnish, Nginx e Traffic Server. O Varnish apesar de ser uma solução de cache com possibilidade extensa de configurações, o que é importante para ajustes específicos em determinados ambientes, perde muito com a falta de suporte ao SSL, e abre caminho ao Nginx em função de sua agilidade em respostas com baixo consumo de recursos.

Vamos aos erros...

Erros comuns relacionados a cache são falhas de expressões regulares, a não inclusão de controle de cache em objetos estáticos, ou a inclusão de controle incorreto de cache em conteúdo dinâmico, o que gera problema para os usuários de renovação de objetos e por consequência falha no acesso da página.  

O tema é complexo e certamente podemos estendê-lo mais, entretanto por hora cabe-nos mencionar que a junção das duas camadas de cache mencionada nesta publicação pode ser interessante e performática, por outro lado, devemos estar atentos à complexidade da junção delas para não transformar algo benéfico em um pesadelo técnico e de gestão de configuração.     

Referências

https://www.varnish-cache.org

https://www.nginx.com

http://trafficserver.apache.org

https://www.akamai.com/us/en/solutions/products/network-operator

https://aws.amazon.com/pt/cloudfront

https://azure.microsoft.com/pt-br/services/cdn

https://www.bizety.com/2016/01/07/nginx-vs-varnish-vs-apache-traffic-server-high-level-comparison

http://www.computerworlduk.com/it-vendors/microsoft-azure-vs-amazon-aws-public-cloud-comparison-which-cloud-is-best-for-enterprise-3624848

https://www.maxcdn.com/blog/cdn-framework-step-2

http://dev.mobify.com/blog/beginners-guide-to-http-cache-headers

Versão também publicada em : http://ilegra.com/beyonddata/