Um usuário 4G vai experimentar uma experiência muito acima da média em termos de largura de banda e latência do que um usuário 3G, mas o mesmo usuário 4G também vai ser direcionado de volta à rede 3G durante algum tempo devido à cobertura da área, capacidade ou por outros motivos. No caso em questão, os dados do OpenSignal mostram que, em média um usuário 4G nos EUA recebe serviço LTE em apenas aproximadamente 67% do tempo. Na verdade, em alguns casos, mesmo o usuário 4G vai encontrar-se utilizando redes 2G ou, pior, ficará sem serviço.

Todas as conexões são lentas por algum tempo. Todas as ligações falham algumas vezes. Todos os usuários experimentam esses comportamentos em seus dispositivos, independentemente de suporte, geografia ou tecnologia subjacente: 4G, 3G ou 2G.

Você pode usar o aplicativo OpenSignal Android para rastrear suas próprias estatísticas em tempo real para redes 4G / 3G / 2G, além de muitas outras métricas.

Por que isso importa?

As redes não são confiáveis, a latência não é zero, e a largura de banda não é infinita. A maioria dos aplicativos ignora essas simples verdades e projeta seus softwares para o melhor cenário, o que leva a experiências ruins sempre que a rede se desvia do mundo ideal. Nós tratamos esses casos como exceções, mas na realidade eles são a regra.

• Todos os usuários 4G são usuários de 3G em algum momento.
• Todos os usuários de 3G são usuários de 2G em algum momento.
• Todos os usuários 2G estarão offline em algum momento.

Construir um produto para um mercado dominado por 2G vs. 3G vs. 4G pode exigir uma arquitetura totalmente diferente e um conjunto de características específicas para cada rede. No entanto, um usuário 3G também será um usuário 2G em algum momento; um usuário 4G pode ser tanto um usuário 3G quanto um 2G por algum tempo, e todos os usuários estarão offline em algum momento. Um aplicativo bem sucedido é aquele que é resistente a flutuações na disponibilidade e desempenho da rede: ele pode aproveitar o máximo do desempenho, param e continuam trabalhando quando as condições melhoram.

Então, o que vamos fazer?

Como geralmente não há de um plano que reaja à variabilidade no desempenho da rede, é comum que existam falhas. Em vez disso, temos de aceitar essa condição como um caso normal de operação e projetar nossos aplicativos em conformidade com essas falhas. Uma estratégia simples, mas eficaz, é adotar uma abordagem Chaos Monkey dentro do ciclo de desenvolvimento:

• Defina um SLA aceitável para cada solicitação de rede
  • Pedidos interativos devem respeitar constantes do tempo de percepção.
  • Solicitações em segundo plano podem levar mais tempo, mas não devem ser ilimitadas.
• Faça da falha a norma, em vez de uma exceção
  • Forçar o modo offline durante alguns períodos de tempo.
  • Forçar uma fração dos pedidos a exceder o SLA definido.
  • Lidar com falhas de SLA em vez de ignorá-las.

Desempenho da rede degradada e períodos offline são a norma, e não uma exceção. Você não pode viver em modo offline, ou adicionar uma “experiência de rede com qualidade” garantidamente, sendo assim, não é possível adicionar desempenho ou segurança mais tarde. Para ter sucesso, precisamos projetar nossos aplicativos com essas restrições desde o início.

Ferramentas e APIs

Você está usando um proxy de rede para emular uma rede lenta? Isso é um começo, mas não capta a verdadeira experiência mediana de seu usuário: um usuário 4G navega rápido na maioria das vezes e fica com conexão lenta ou offline por algum tempo. Precisamos de melhores ferramentas que possam emular e forçar esses comportamentos quando desenvolvemos nossas aplicações. Testar aplicativos contra a rede localhost, na qual a latência é zero e a largura de banda é infinita, é uma receita para o fracasso.

Precisamos de APIs e frameworks que possam facilitar e nos guiar a fazer as escolhas de design apropriadas para explicar a variabilidade no desempenho da rede. Pela web, o ServiceWorker vai ser uma peça fundamental: ele permite simulação offline, e permite o controle total sobre o ciclo de vida do pedido, tais como controle de SLA, atualizações em segundo plano, e muito mais.

***

Ilya Grigorik faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: https://www.igvita.com/2015/01/26/resilient-networking/