Na corrida de hoje para acelerar o tempo de carregamento do site, cada milissegundo importa. A equipa de Kinsta testou e estudou o impacto da velocidade do website nas vendas, conversões, experiência do usuário e engajamento do usuário.

Mas há uma advertência. Embora a otimização no local seja importante para melhorar a velocidade, não é o único aspecto que devemos considerar.

A infra-estrutura de hardware e rede que suporta o nosso website e o liga aos nossos visitantes é importante. Eles importam tanto que quando uma Rede de Entrega de Conteúdo como a Cloudflare cai, alguns grandes nomes na internet sentem a falta de energia:

Hoje vamos discutir porque é que a Google está a investir muito dinheiro na sua infra-estrutura de rede e algumas das diferenças na rede de nível superior e na rede de nível padrão da Google Cloud Platform.

Largura de Banda e Latência (Critérios Chave para o Desempenho da Infraestrutura de Hospedagem)

Antes de mergulhar em detalhes sobre a rede da Google Cloud, é importante entender primeiro os dois conceitos a seguir: largura de banda e latência.

A largura de banda é a capacidade de throughput da rede, medida em Mbps; enquanto a latência é o atraso ou a soma de todos os atrasos que diferentes roteadores ao longo do caminho adicionam às nossas solicitações e respostas web.

Figurativamente, a largura de banda ou vazão pode ser retratada como a capacidade da mangueira de água para permitir um certo volume de água por segundo. A latência pode ser comparada com o atraso desde o momento em que o tubo de água é aberto até começar a jorrar.

Devido à pequena sobrecarga no estabelecimento da conexão entre diferentes roteadores, cada “salto” ao longo do caminho adiciona uma pequena quantidade de latência às solicitações e respostas finais.

Assim, quanto mais distante estiver o visitante e o servidor onde o site está hospedado, maior será a latência. Além disso, quanto mais fragmentada for a rede, maior será a latência.

Podemos imaginar isto usando uma ferramenta chamada traceroute, ou tracejado nas janelas. Nas capturas de ecrã seguintes, utilizámo-lo para controlar os atrasos de encaminhamento de dois pedidos, feitos a partir da Europa. Especificamente:
um para weibo.com:

Weibo.com

Weibo.com

e outro para bbc.co.uk:

Bbc.co.uk

Bbc.co.uk

Como esperávamos, o número de saltos para o site na China é quase 2x maior do que para o europeu. Então é a latência adicionada comparada a um pedido para um site hospedado no Reino Unido.

As três colunas que o tracert mostra representam três roundtrips (RTT). Cada linha representa diferentes roteadores ou saltos ao longo do caminho. Eles geralmente têm URLs que nos ajudam a determinar onde esse roteador específico está localizado.

O tempo de ida e volta para os roteadores na China / Hong Kong leva cerca de um terço de segundo.

Nós usamos pingdom para carregar um site hospedado em Londres a partir da localização de Pingdom na Austrália, para tentar estabelecer o compartilhamento que a rede tem nos tempos de carga geral de um site.

Exemplo de tempos de carga

Exemplo de tempos de carga

Estes são os dados de um pequeno arquivo CSS carregado neste cenário de teste. A parte Conectar tem a maior participação no carregamento desse recurso, seguida por SSL e Espera. Todo o tempo até, e incluindo o tempo de espera, juntos, também é conhecido como time to first byte (TTFB), que inclui latência de rede.

Quando os Provedores de Serviços de Internet anunciam a velocidade da conexão de internet, eles normalmente anunciam em sua largura de banda (a “largura da mangueira” lembra?) o que realmente não é um medida de velocidade. Aumentar a largura do tubo pode aumentar a velocidade do site apenas até certo ponto. É mais útil quando precisamos de uma grande quantidade de dados enviados por segundo, como quando transmitimos conteúdo de vídeo de alta definição. Mas para os usuários que podem estar jogando jogos multiplayer em tempo real online, a latência será muito mais importante.

Mike Belshe, um dos coautores da especificação HTTP/2 e do protocolo SPDY, fez uma análise do impacto do aumento da largura de banda na velocidade de carregamento do website vs. o efeito da diminuição da latência na velocidade de carregamento do website.

Aqui estão os achados da Belshe com curadoria em um belo gráfico:

Tempo de carga/alteração de largura de banda vs. Tempo de carga/alterações de latência

Tempo de carga/alteração de largura de banda vs. Tempo de carga/alterações de latência

Deve ficar claro que melhorar a velocidade do website aumentando a largura de banda não é a forma mais eficaz de alcançar um melhor desempenho. Por outro lado, ao reduzir o RTT (round-trip-time) ou a latência, podemos ver melhorias consistentes do tempo de carregamento da página.

Redes vs Internet Peering vs Transit

Para entender um pouco melhor o nosso tópico, precisamos explicar o básico da topologia da internet. Em sua essência, a internet global consiste em múltiplas redes globais, regionais e locais.

A partir de 2018, existem mais de 60.000 AS (Sistemas Autónomos). Estas redes pertencem a governos, universidades, ISPs.

Entre estas, destacam-se as redes Tier 1, Tier 2 e Tier 3. Estes níveis representam a independência de cada rede na Internet como um todo.

  • As redes de nível 1 são independentes, no sentido de que não têm de pagar para se ligarem a qualquer outro ponto da Internet.
  • As redes de nível 2 têm acordos de troca de tra fego com outros ISP, mas tambeÂm pagam pelo traà nsito.
  • As redes de nível 3, o nível mais baixo, ligam-se ao resto da Internet através da compra de trânsito a partir de níveis mais elevados. São praticamente como consumidores que têm de pagar para aceder à Internet.

A relação de peering significa que duas redes trocam tráfego numa base de igualdade, pelo que nenhuma delas paga à outra pelo trânsito, e devolvem o mesmo gratuitamente.

O principal benefício do peering é uma latência drasticamente mais baixa.

Como as solicitações web passam pela rede hierárquica dos ISPs

Como as solicitações web passam pela rede hierárquica dos ISPs

Na imagem acima, vemos um cenário clássico, em que o pedido web passa pela rede hierárquica de ISPs nos níveis 1, 2 e 3 para recuperar um website hospedado em um diretório num centro de dados numa localização remota.

As setas representam o percurso do pedido web. Setas tracejadas representam as conexões de trânsito, e setas de linha cheia representam as conexões de peering.

Uma vez alcançado o prestador de serviços de nível 1, a sua relação com outro prestador do mesmo nível é uma relação entre pares. As redes Tier 1 ligam-se a outras e transmitem os seus pedidos exclusivamente através de parceiros peering. Podem chegar a todas as outras redes na Internet sem pagar pelo trânsito.

Também podemos ver um cenário alternativo, em que dois provedores da camada 2 têm um acordo de peering, designado com cor turquesa. O número de saltos neste cenário é menor e o site levará muito menos tempo para carregar.

Protocolo de Gateway de Fronteira

O BGP é um protocolo sobre o qual raramente se fala, excepto em contextos muito técnicos. No entanto, este protocolo está no cerne da Internet tal como a conhecemos hoje. É fundamental para a nossa capacidade de aceder a praticamente tudo na Internet e é uma das ligações vulneráveis da pilha de protocolos da Internet.

O Protocolo de Gateway de Fronteira é definido em IETFs Request For Comments #4271 de 2006 e desde então tem tido várias atualizações. Como diz o RFC:

“A principal função de um sistema de fala BGP é trocar informações sobre a acessibilidade da rede com outros sistemas BGP.”

Simplificando, o BGP é um protocolo responsável por decidir a rota exata de uma solicitação de rede, sobre centenas e milhares de nós possíveis até seu destino.

Protocolo de Gateway de Fronteira

Protocolo de Gateway de Fronteira

Podemos imaginar cada nó como um Sistema Autônomo ou uma rede que consistiria de vários nós ou roteadores, servidores e sistemas conectados a ele.

No protocolo BGP, não há nenhum algoritmo de auto-descoberta (um mecanismo ou protocolo pelo qual cada nó recém-conectado pode descobrir nós adjacentes para se conectar), em vez disso, cada par BGP tem que ter seus pares especificados manualmente. Quanto ao algoritmo de caminho, para cita um especialista da Cisco:

“O BGP não tem uma métrica simples para decidir qual é o melhor caminho. Em vez disso, ele anuncia um extenso conjunto de atributos com cada rota e usa um algoritmo complexo que consiste em até 13 passos para decidir qual é o melhor caminho.”

Os sistemas autónomos transmitem dados de encaminhamento aos seus pares, no entanto, não existem regras rígidas que possam ser aplicadas relativamente à selecção dos canais horários. O BGP é um sistema implicitamente baseado na confiança e esta pode ser uma das maiores falhas de segurança da Internet de hoje. Roubo em 2018, quando O tráfego do MyEtherWallet.com foi sequestrado e mais de 200 Éteres foram roubados (valor de $152.000) expondo essa vulnerabilidade.

Na realidade, esta fraqueza do BGP resulta mais frequentemente em várias redes (AS) que emitem dados BGP com outros interesses em mente que não a eficiência e a eficiência velocidade para usuários finais. Podem ser interesses comerciais, como trânsito pago, ou mesmo considerações políticas ou de segurança.

Desenvolvimento de Cloud Computing, CDN e Edge Market

Devido às necessidades crescentes do mercado de TI, desde a indústria web, jogos online, até a Internet das Coisas e outros, o espaço de mercado para provedores de serviços e produtos que resolvem o problema da latência tornou-se óbvio.

Ano após ano, vemos mais produtos baseados em nuvem que armazenam recursos estáticos perto dos visitantes (Content Delivery Networks) ou aproximam a computação real dos usuários finais. Um desses produtos é o Workers da Cloudflare, que executa Código compatível com motores javascript V8 na rede de nós de borda da Cloudflare. Isto significa que mesmo o WebAssembly ou o código GO podem ser executados muito perto do visitante.

O Lambda@Edge by Amazon é outro exemplo dessa tendência, assim como a parceria entre a Intel e a Alibaba Cloud para oferecer a Plataforma de Computação Joint Edge visando o mercado IoT.

Outra que vale a pena mencionar é que a rede global da Google de nós de cache serve tanto como uma CDN quanto como uma rede de caching e entrega de vídeo para sua subsidiária. YouTube.

Para ilustrar o quão refinada e avançada a indústria da nuvem se tornou, e o quanto ela conseguiu reduzir a latência de rede para usuários finais, vamos dar uma olhada no GaaS.

GaaS é a abreviatura de Gaming as a Service. É uma oferta de nuvem que dá aos usuários a capacidade de jogar jogos hospedados e executados na nuvem. Este artigo compara alguns produtos proeminentes no nicho GaaS.

Todos aqueles que já compraram uma TV ou um projetor de vídeo para jogos, ou passaram algum tempo configurando o Miracast ou outra conexão de fundição entre uma TV e outro dispositivo, saberão o quão crítica é a latência. No entanto, existem provedores de GaaS que agora oferecem streaming de jogos com resolução de 4k e taxa de atualização de 60Hz… e os jogadores não precisam investir em hardware.

O drama da recente proibição da Huawei pelos EUA chamou a atenção para a questão das redes 5G e para a necessidade urgente de uma via clara para melhorar a infra-estrutura mundial de redes.

Sensores que transmitem enormes quantidades de informação em tempo real, com latência mínima, para coordenar cidades inteligentes, casas inteligentes, veículos autônomos dependerão de redes densas de dispositivos de ponta. Latência é o teto atual para coisas como carros automotores, com diferentes informações de sensores, dados LIDAR, processamento destes dados vs dados de outros veículos.

Content Delivery Networks e Cloud Computing Providers estão na vanguarda desta corrida. Já falámos sobre o Protocolo QUIC / HTTP3 a ser implementado pelos líderes da indústria capazes de controlar o ciclo de resposta ao pedido.

Como os Provedores de Nuvem Resolvem o Problema da Latência?

A AWS pode ser o maior provedor de nuvem por participação de mercado. Em 2016, eles investiram no Sistema de Cabo Submarino Transpacífico da Hawaiki com o objetivo de proporcionar maior largura de banda e diminuir a latência entre o Havaí, Austrália e Nova Zelândia, que foi seu principal objetivo. primeiro investimento em infra-estrutura submarina. Ele… entrou em funcionamento em 2018.

Cabos de fibra óptica submarina

Cabos de fibra óptica submarina (Fonte de imagem: NEC)

Nessa altura, o Google já estava muito à frente da sua concorrência na criação de espinhas dorsais submarinas. Um ano antes do primeiro investimento da Amazon, a ITWorld publicou um artigo intitulado: “Os data centers do Google crescem muito rápido para redes normais e, por isso, criam suas próprias redes”.

Na verdade, foi em 2005 que um jornalista técnico Mark Stephens, também conhecido como Robert X Cringely escreveu no seu coluna para PBS.org, comentando sobre a onda de compras do Google do fibra escura (infraestrutura de fibra ótica não utilizada):

“Isto é mais do que outra Akamai ou mesmo uma Akamai com esteróides. Esta é uma Akamai dinâmica, inteligente e termonuclear, com um canal de retorno dedicado e hardware específico para aplicações. Haverá a Internet, e depois haverá o Google Internet, sobreposto no topo.”

Infra-estrutura de cabos de rede em nuvem do Google

Infra-estrutura de cabos de rede em nuvem do Google (fonte: Google)

Em 2010, em um artigo no zdnet.com, diz Tom Foremski:

“O Google é uma daquelas empresas que possuem uma grande parte da Internet”, e continua: “O Google concentrou-se em construir a Internet privada mais eficiente e de menor custo de operação. Esta infra-estrutura é fundamental para o Google, e é fundamental para compreender o Google.”

Naquela época, o artigo de Cringley levantou algumas preocupações sobre o Google tentando assumir o controle da internet, mas as coisas ficaram mais claras quando a empresa lançou o site Google Fiber, a tentativa da Google de conquistar o mercado de ISP nas maiores cidades dos EUA. Desde então, o projeto desacelerou tanto que a TechRepublic publicou um post mortem do projeto em 2016, mas investimentos em infraestrutura, agora em escala global, não abrandou.

Google’s O último investimento, previsto para entrar em funcionamento este ano, é uma espinha dorsal que liga Los Angeles nos EUA e Valparaíso no Chile, com uma filial para a futura ligação ao Panamá.

“A internet é comumente descrita como uma nuvem. Na realidade, é uma série de tubos molhados e frágeis, e o Google está prestes a ter um número alarmante deles”. — VentureBeat

Por que o Google está Investindo Tanto em sua Infra-estrutura de Rede?

Roteiro standard

Roteiro Padrão

Todos nós sabemos que O Google é o motor de busca número um, mas também:

  • Possui a maior plataforma de vídeo
  • É o maior provedor de e-mail (Gmail e G Suite)
  • Ganha bastante dinheiro com os seus produtos de computação em nuvem (taxa de execução anual de mais de $8 bilhões de dólares)

É por isso que ele precisa da menor latência possível e da máxima largura de banda possível. Google também quer possuir a infra-estrutura real, porque a sua “fome insaciável” por mais largura de banda e latência coloca o Google, e seus pares de empresas de grande escala como a Amazon ou Microsoft, em uma posição onde eles precisam para chegar a soluções de hardware e software completamente personalizado.

Nós PoP

Nós PoP

Os pontos de presença, ou nós PoP de borda, estão nas bordas da rede global privada de cabo do Google. Lá eles servem como pontos de entrada e saída para o tráfego que se conecta aos centros de dados do Google.

A Lei de Moore é uma observação de Gordon Moore, co-fundador da Intel, que afirma que a cada dois anos, o número de transistores que podemos colocar em um circuito integrado dobrará. Durante décadas, essa expectativa se manteve verdadeira, mas agora, a indústria da computação está prestes a colocar a lei de Moore à prova, talvez assinando seu fim em um futuro próximo. PARA TUA INFORMAÇÃO, O CEO da NVIDIA proclamou a lei de Moore morta no início deste ano.

Então, como isso se relaciona com o setor de nuvem e com a infraestrutura de rede do Google?

No Open Networking Foundation Connect Event em dezembro de 2018, o vice-presidente do Google e TechLead for Networking, Amin Vahdat, admitiu o fim da lei de Moore e explicou o enigma da empresa:

“A nossa procura de computadores continua a crescer a um ritmo espantoso. Vamos precisar de aceleradores e de um computador mais bem acoplado. O tecido da rede vai desempenhar um papel fundamental na ligação destes dois juntos.”

Uma forma de os provedores de nuvem acompanharem a crescente demanda por poder de computação é o clustering. Clustering, para simplificar, significa reunir vários computadores para trabalhar em um único problema, para executar processos de uma única aplicação. Obviamente, uma pré-condição para beneficiar de tal configuração é a baixa latência ou a capacidade séria da rede.

Quando o Google começou a projetar seu próprio hardware, em 2004, os fornecedores de hardware de rede pensavam em termos de boxes, e roteadores e switches precisavam ser gerenciados individualmente, via linha de comando. Até então, o Google estava comprando clusters de switches de fornecedores como a Cisco, gastando uma fortuna por único switch. Mas o equipamento ainda não conseguiu acompanhar o crescimento.

O Google precisava de uma arquitetura de rede diferente. A demanda na infraestrutura do Google estava crescendo exponencialmente (um A partir de 2015, o artigo de investigação da Google afirma que a sua capacidade de rede cresceu 100x em dez anos) e o seu crescimento foi tão rápido que o custo de aquisição do hardware existente também os incitou a criar as suas próprias soluções. O Google começou a construir switches personalizados a partir de chips de silício commodity, adotando uma topologia de rede diferente que era mais modular.

Cansado do suporte de hospedagem do WordPress de nível 1 sem as respostas? Experimente nossa equipe de suporte de classe mundial! Confira nossos planos

Os engenheiros do Google começaram a construir sobre um antigo modelo de rede de telefonia chamado Clos Network, que reduz o número de portas necessárias por switch:

“A vantagem da rede Clos é que você pode usar um conjunto de dispositivos idênticos e baratos para criar a árvore e ganhar alto desempenho e resiliência que de outra forma custaria mais para construir. — Redes Fechadas: O que é velho é novo novamente, Mundo em Rede

Mais sobre este modelo como um Palestra da Universidade de Harvard disponível online.

Para este novo hardware modular, a equipa da Google teve também de redefinir os protocolos existentes e construir um sistema operativo de rede personalizado. O desafio que eles estavam enfrentando era pegar um grande número de switches e roteadores e operá-los como se fossem um único sistema.

A pilha de rede personalizada juntamente com a necessidade de redefinir protocolos levou o Google a recorrer ao Software Defined Networking (SDN). Aqui está uma palestra de Amin Vahdat, Vice-Presidente da Google, Engineering Fellow e líder da equipa de infra-estruturas de rede, a partir de 2015, explicando todos os desafios e as soluções que encontraram:

Para os mais curiosos, há este interessante post de blog vale a pena ler.

Espresso

O expresso é o mais recente pilar da SDN do Google. Permite que a rede da Google vá além das restrições dos routers físicos na aprendizagem e coordenação do tráfego que entra e sai para os parceiros de peering da Google.

O Espresso permite ao Google medir o desempenho das ligações em tempo real e basear a decisão no melhor ponto de presença para um visitante específico em dados em tempo real. Desta forma, a rede do Google pode responder dinamicamente a diferentes congestionamentos, desacelerações ou interrupções nos seus parceiros Peering / ISP.

Além disso, o Espresso torna possível utilizar o poder computacional distribuído do Google para analisar todos os dados de rede de seus pares. Todo o controle e lógica de roteamento não residem mais com roteadores individuais e Border Gateway Protocol, mas são transferidos para a rede de computação do Google.

“Alavancamos nossa infraestrutura de computação em larga escala e os sinais da própria aplicação para aprender como os fluxos individuais estão funcionando, conforme determinado pela percepção de qualidade do usuário final.” — O expresso torna o Google Cloud mais rápido, 2017

Como Isso é Relevante para a Google Cloud Network?

O que cobrimos até agora vai destacar todas as questões e desafios (tanto com base em hardware como em software) que a Google atravessou para reunir o que é provavelmente a melhor rede privada global atualmente disponível.

Quando se trata de participação de mercado, a Google Cloud Platform é o terceiro fornecedor global (depois da AWS e da Microsoft Azure Cloud). Mas em termos de sua infra-estrutura de rede privada premium, deixa seus concorrentes muito para trás, como mostram os dados da BroadBand Now:

Propriedade do cabo submarino

Propriedade do cabo submarino, Setembro de 2018. (fonte: BROADBANDNOW, Centerfield BBN LLC)

Em 2014, a GigaOM publicou um artigo comparando a AWS e a Google Cloud Platform, mas apenas uma semana depois, eles publicaram outro, intitulado: “O que eu perdi no debate entre o Google e a Amazon cloud – fibra!”, onde eles reconhecem que o Google está anos à frente em termos de infraestrutura.

“Ter tubos grandes e rápidos disponíveis para o seu – e para o tráfego dos seus clientes – é um grande negócio.” — Barb Darrow, GIGAOM

Premium do Google vs. Redes de Nível Padrão

Plataforma Google Cloud Network

Plataforma Google Cloud Network

A Google Cloud Platform oferece duas camadas de rede diferentes que diferem tanto em preço como em desempenho.

Rede de Nível Superior do Google Premium

Com a Rede Premium Tier do Google, os utilizadores podem tirar partido da rede global de fibra óptica, com Pontos de presença distribuídos globalmente. Todo o tráfego de entrada (entrada) do cliente para os centros de dados do Google é encaminhado para o Ponto de Presença mais próximo, que é distribuído globalmente, e então a solicitação é encaminhada 100% sobre o backbone privado do Google. Como dissemos em um artigo anterior – isso pode significar uma latência 30% melhorada ou uma largura de banda 50% melhor.

No regresso, todos os dados enviados do centro de dados para o visitante são encaminhados utilizando Política da Batata Fria. Ao contrário do Roteamento Hot Potato, utilizado na rede padrão Tier, onde o tráfego é, o mais cedo possível, entregue (ou descartado) a outros ISPs, roteamento Premium Tier significa que o tráfego de saída é mantido o maior tempo possível na própria fibra do Google, e é entregue aos colegas ou ISPs de trânsito o mais próximo possível do visitante.

Para pôr as coisas nos termos do leigo. Os pacotes de nível superior passam mais tempo na rede do Google, com menos oscilações e, portanto, têm melhor desempenho (mas custam mais).

Para os fãs de ficção científica entre nós, pode ser comparado a um wormhole cósmico, que transfere o nosso tráfego diretamente para o nosso destino sem passar pela internet.

Em Kinsta, utilizamos a Rede de Camadas Premium da Google Cloud com todos os nossos planos de hospedagem gerenciada do WordPress. Isso minimiza a distância e os saltos, resultando em um transporte global mais rápido e seguro de seus dados.

Arquitetura de hospedagem Kinsta

Arquitetura de hospedagem Kinsta

Rede de Camada Padrão do Google

Por outro lado, a rede de camada padrão usa pontos de presença próximos ao centro de dados onde nosso conteúdo ou aplicativo da Web reside. Isto significa que o tráfego de nossos visitantes viajará através de muitas redes diferentes, Sistemas Autônomos, ISPs, e através de muitos saltos até chegar ao seu destino. Neste cenário, a velocidade está comprometida.

O conteúdo que viaja na camada padrão não será capaz de colher plenamente os benefícios do SDN do Google e do vasto poder de computação para calcular as melhores rotas dinamicamente. O tráfego estará sujeito às políticas BGP de todos os sistemas entre o Google e o visitante.

Para pôr as coisas nos termos do leigo. Os pacotes de nível padrão passam menos tempo na rede do Google e mais tempo jogando batata quente em redes públicas e, portanto, têm pior desempenho (mas custam menos).

Além disso, o Premium Tier utiliza o Global Load Balancing, enquanto o padrão Tier oferece apenas o Regional Load Balancing, que traz mais complexidade e mais “footwork” para os clientes Padrão.

A Premium Tier Network oferece um Acordo de Nível de Serviço (SLA) global, o que significa que a Google aceita a responsabilidade contratual pela prestação de um determinado nível de serviço. É como um sinal de garantia de qualidade. As camadas de rede padrão não oferecem este nível de SLA.

Para aqueles que querem saber mais, há uma extensa comparação e documentação das duas camadas no site da Google Cloud. Eles até mesmo fornecem um gráfico útil para ajudá-lo a determinar mais facilmente qual camada de rede você deve usar:

Árvore de decisão Network Service Tiers

Árvore de decisão Network Service Tiers. (fonte: Google Cloud Platform)

Quer saber o que está fazendo da Google Cloud Network uma das pilhas mais rápidas disponíveis atualmente? Dê um mergulho profundo na nossa comparação profunda de níveis Premium vs Padrão. 🚀☁️ #google cloud networkClick to Tweet

Resumo

Durante anos, a Google investiu na criação de uma infra-estrutura de rede global, implementando os seus próprios protocolos e pilhas de rede personalizadas de hardware e software. Em tempos em que a lei de Moore parece se tornar mais fraca ano após ano, a infraestrutura do Google permite que a empresa acompanhe a crescente demanda por recursos de nuvem.

Embora em termos de participação de mercado ainda esteja atrás da Amazon Cloud e da Microsoft Azure Cloud, o Google ganhou alguma vantagem crucial tanto para a fibra que possui, quanto para as soluções de hardware e software de ponta que seus engenheiros implantaram.

Podemos esperar que o Google desempenhe um papel fundamental na tecnologia da IoT, cidades inteligentes, carros sem condutor e a procura de computação de ponta continua a crescer.

O Google Cloud Network Premium Tier é o primeiro produto a utilizar os resultados de rede inovadores da Google. Permite que os clientes tirem partido da rede da Google e de toda a pilha para fornecerem conteúdos a uma velocidade superior. Com as garantias do Google em relação à latência.

Kinsta é dedicado a fornecer o melhor desempenho de hospedagem gerenciada WordPress em uma escala global. É por isso que Kinsta é alimentado com Google Cloud para hospedagem WordPress e usamos a Rede Premium Tier do Google para todos os nossos planos de hospedagem.


Se você gostou deste artigo, então você vai adorar a plataforma de hospedagem WordPress da Kinsta. Turbine seu site e obtenha suporte 24/7 de nossa experiente equipe de WordPress. Nossa infraestrutura baseada no Google Cloud se concentra em escalabilidade automática, desempenho e segurança. Deixe-nos mostrar-lhe a diferença Kinsta! Confira nossos planos