Hoje fiquei sabendo que meu amigo João Jr, mais conhecido como Jonny, assumiu a Gerência Geral da netRevenda.com.

Parabéns ao Vicente e ao Diego pela ótima contratação.

http://blog.netrevenda.com/2011/01/04/joao-jr-assume-a-gerencia-geral/

2010 foi o ano em que a “computação na nuvem” (cloud computing) se tornou apenas “nuvem” (cloud), e todos perceberam que “nuvem”, “SaaS” e todos os outros XaaS (PAAS, IAAS, DAAS) eram implementações diferentes da mesma ideia – um conjunto de serviços de computação disponíveis online que se podem expandir ou contrair de acordo com as necessidades.

Nem toda a confusão foi esclarecida, claro. Mas, vendo os serviços específicos oferecidos pela Amazon, Microsoft, Oracle, Citrix, VMware e uma série de outras empresas, muitos profissionais de TI puderam ter uma ideia mais concreta do que a “nuvem” é realmente.

Cinco aspectos se tornaram mais claros até mesmo para os mais experientes gestores de TI. São eles:

1. Nuvens “externas” e “internas” não são tão diferentes
No início de 2010, a questão mais comum era se a nuvem deveria ser inserida no firewall ou contratada fora.

Uma vez que os mesmos dados e aplicações empresariais migrem para a nuvem, interna (em servidores dentro do firewall) ou pública, a empresa proprietária dos dados enfrenta o mesmo risco. Razão pela qual muitas empresas estejam apostando mais em nuvens “híbridas” do que apenas internas ou públicas, de acordo com o guru da virtualização da Gartner, Chris Wolf.

“Com as nuvens internas, tem-se uma determinada quantidade de benefícios desde a partilha de recursos e eficiência, mas não se tem a elasticidade que é o real motivo para a venda da nuvem”, explicou Wolf à CIO.com.

2. De que são feitas as nuvens? De outras nuvens
Durante 2010, muitas empresas de computação na nuvem minimizaram o papel da virtualização e da visão “end-to-end” da VMware, na qual as empresas usam infraestruturas de servidores virtuais para suportar o compartilhamento de recursos e a gestão de recursos na nuvem dentro do firewall, antes de partir para o uso da nuvem pública.

Os fornecedores de cloud computing oferecem aplicações, armazenamento, poder de computação, etc., à vontade, sob demanda, através de uma ligação à Internet, sem a necessidade de ter uma infraestrutura de servidores virtuais dentro da empresa.

Os dois ambientes, por definição, são virtualizados, concordam os analistas. E quase sempre estão instalados em centros de dados, “parques” de servidores virtuais ou até mesmo em serviços completos de cloud fornecidos por outras empresas.

3. “Nuvens” não libertam as TI de “porcas e parafusos”
Há uma suposição de que a cloud computing consiga tornar sofisticados serviços de TI transparentes para o usuário final, fazendo com que deixem de se preocupar com o hardware e o software que os executam.

Isso não significa que as pessoas que gerem os servidores não tenham que conhecer do seu negócio, de acordo com Bob Laliberte, analista no Enterprise Strategy Group. Suportar as clouds significa tornar os servidores, armazenamento, redes e aplicações mais rápidos e estáveis, com menos atrasos do que nunca, segundo Vince DiMemmo, gestor de cloud e serviços de TI no prestador de serviços e infra-estrutura do centro de dados Equinix.

Sem infra-estrutura “à prova de balas”, a computação na nuvem é lenta, diz, e os usuários finais não aceitam a lentidão.

4. Pequenas coisas fazem grandes diferenças
A virtualização permite que várias aplicações e sistemas operacionais sejam executados pelo mesmo hardware, como se cada um deles tivesse o seu próprio servidor. O problema com isso, diz o analista da IDC, Gary Chen, é que todos pensam que têm a interface de rede e o “bus” de entrada/saída (input/output para o processador também só para si.

Em um servidor com variados sistemas operacionais virtuais, o “engarrafamento” para o desempenho já não é a velocidade com que os dados podem ir e vir entre o servidor e o armazenamento externo, mas o número de bits que podem passar pelo “bus” de dados ao mesmo tempo, diz Chen.

Essa é uma razão pela qual o Virtual I/O esteja se tornando um tema cada vez mais “quente”, levando ao que o analista da Forrester, John Rymer, chama de “virtualização distribuída” – na qual I/O, memória e outros componentes são abstraídos uns dos outros, assim como os sistemas operacionais externos, e a definição de “servidor” altera-se para significar que recursos uma aplicação necessita no momento.

5. “Ano – e não Era – do Desktop Virtual”
2010 era para ser o Ano do Desktop Virtual, com a Microsoft, Citrix e VMware competindo para capturar o que os analistas esperavam ser uma onda de adopção das empresas.

Os desktops virtuais foram um tema quente em 2010 mas o crescimento não foi tão grande quanto os analistas ou fornecedores esperavam.

Em vez de padronizar os desktops virtuais e mover todos os seus utilizadores imediatamente para facilitar a migração para o Windows 7, a maioria das empresas adotou por um número crescente de “sabores” da tecnologia, mas apenas onde fazia mais sentido.

“Estamos vendo um monte de projetos táticos, mas não um monte de projetos estratégicos”, diz o analista da IDC, Ian Song.

Isso não quer dizer que não tenha havido um grande crescimento ou adoção até das versões DAAS. Mas 2010 não foi uma onda, diz Song.

As duas principais razões, segundo ele, foram a complexidade e o ROI comparativamente baixo da virtualização de desktops em relação aos servidores virtuais. Outro foi o crescente foco – até dentro das empresas – dos tablets, smartphones e outros dispositivos não-PC que têm de ser virtualizados para se tornarem seguros, confiáveis para clientes de aplicações empresariais.

“Esperamos ouvir muito sobre isso da Citrix e da VMware e de um conjunto de operadoras de telecomunicações” este ano, diz Song. E “vai ser grande”

Fonte: IDGNow

A velocidade da resposta de websites é um fator fundamental para a usabilidade. Muitos designers e desenvolvedores acreditam que elementos visuais como layout, gráficos ou fontes determinam a usabilidade. Porém a velocidade efetiva de resposta de um site é essencial para determinar a qualidade da experiência do usuário.

Além disso, o mecanismo de busca do Google usa desempenhos de sites para determinar a posição em que ele aparecerá em resultados de pesquisas. Sites mais rápidos terão melhor visibilidade. Portanto, investir em melhorias de desempenho aumentará os benefícios para os proprietários do site.

O que os usuários esperam em termos de desempenho de um site?

Passageiros de um ônibus não se preocupam com a marca do combustível que o veículo usa nem com o tamanho do motor, apesar de estes elementos terem um importante impacto na duração da viagem. Semelhantemente, na web, os internautas não querem saber se o conteúdo da página é originado de um questionário do sistema de gerenciamento de base de dados ralacional dinâmica (RDBMS) que inclui uma intersecção de cinco pontos ou se o conteúdo é resultado de um arquivo plano estático.

As expectativas dos usuários variam de um site a outro, baseadas em fatores como:

• O valor do conteúdo do site e da interação que ele oferece

• O número de concorrentes ou sites alternativos que oferecem conteúdo ou serviços similares

• A etapa no fluxo de trabalho do usuário ou a sequência de interação com múltiplas etapas (algumas sequências tem pontos de pausa naturais conforme o usuário absorve o material, enquanto outras etapas existem para transições rápidas)

Considere o exemplo hipotético de um site que advinha os números sorteados na loteria da próxima semana. Neste cenário, os internautas tranquilamente esperariam uma hora para a página se carregar. Entretanto, em um contexto em que o internauta visa uma transação simples, principalmente no caso de haver alternativas da concorrência (como reservar um quarto de hotel ou comprar um livro), as expectativas em relação à velocidade de resposta do site são muito menos complacentes. É muito mais provável que um usuário abandone o site depois de quatro ou cinco segundos se a página não se carrega completamente ou se o layout é confuso.

Quanto tempo uma página pode demorar para se carregar?

Variantes desta pergunta incluem:

Quão rápida deve ser uma página de login?

Quão rápida deve ser uma tela que carrega dados de um sistema remoto?

Quão rápida deve ser uma página de redirecionamento a base de dados?

Quão rápida deve ser uma página principal (a primeira página que o visitante vê)?

A resposta para todas essas perguntas é “o mais rápido possível”.

Fatores diversos como layout, estrutura do site, fontes e gráficos afetam a usabilidade e a eficácia de um site, mas o único fator essencial é a velocidade de resposta que um site oferece.  Com todas as características equitativas, um sistema mais rápido será mais eficaz e oferecerá um maior nível de usabilidade. Isso está baseado em fatores humanos como curtos períodos de atenção e processamento visual de informação. Um atraso de mais de um segundo interromperá a sequência do pensamento, já que a atenção do usuário se deslocará para outros assuntos, como e-mail, café ou conversas paralelas. É possível que isso aconteça sem que o usuário se dê conta da sua distração. Os usuários podem não ser capazes de explicar porque preferem um site a outro, mas o mais provável é que a causa seja a diferença de velocidade de respostas.

Por exemplo, sites bem sucedidos no altamente competitivo mercado de mecanismos de busca são aqueles que carregam páginas mais rapidamente – sites como Yahoo! e Google. No final dos anos 1990, quando havia vários sites de pesquisa, como Lycos, Excite, AltaVista, Magellan e Snap, que evoluíam para portais de consumo, esses sites tentavam se diferenciar usando ferramentas e design extremamente pesados. Contudo, o único que obteve sucesso foi o Yahoo!. Ele era o site mais plano, mas também o mais simples e rápido. Posteriormente, o Google surgiu na liderança, devido em parte ao design, que era ainda mais simples, e aos tempos de resposta mais rápidos.

Mais recentemente, sites de comércio eletrônico confirmaram que quanto mais rápidos são, mais receita geram. Diferenças de velocidade se relacionam com as expectativas e percepções dos usuários. Os usuários avaliam sites comparando as alternativas disponíveis. Gerentes de sites devem identificar concorrentes. Alguns usuários (que usam aplicações corporativas internas, por exemplo), são “cativos, sem opção. Outros usuários gostam de poder escolher e levam em conta características implícitas de baixo custo em termos de tempo e alto valor em termos de conteúdo.

Quais princípios de desempenho são definidos pelos 100 melhores sites?

Mecanismos de busca como o Google, que atua em um setor altamente competitivo, tem princípios de tempo de resposta de 400 milisegundos entre o momento em que uma solicitação chega ao data center e o momento em que os resultados saem do data center. (O que acontece fora do data center, na internet aberta, também é importante para o usuário, mas não pode ser controlado diretamente pelo Google).

O princípio dos 400 milisegundos deriva da época do AltaVista, na década de 1990. O mecanismo de busca ocupou uma posição de liderança no mercado por causa da qualidade dos seus resultados de busca e pela sua rápida resposta. No caso do Google, a página de resultados pode não ser plana, mas por trás disso existe o software e o sistema de “ciência do foguete”. Durante 400 milisegundos, os dados são reunidos a partir de 300 subsistemas diferentes para organizar dinamicamente a página de pesquisa e resposta. Implementar esse nível de resposta rápida exige inovações em arquitetura de sistema, disciplina e rigor de execução.

Em certos contextos, o Gartner chama esta de necessidade de processamento extremo de transação (XTP). Para chegar a este nível de desempenho, aplicações comerciais online, redes sociais e empreendimentos de software como serviço usam amplamente a rede de arquiteturas e tecnologias in-memory, como plataformas de cachês distribuídas (incluindo memcached, ehcache, Terracotta e Oracle Coherence), para melhorar o desempenho de acesso ao sistema de gerenciamento de base de dados (DBMS). Alguns fornecedores, como a IBM e a Virident, oferecem este tipo de tecnologia na forma de aplicações.

Qual é o tempo de latência esperado entre o servidor web e o navegador do usuário final?

O desafio aqui é que o tempo gasto na nuvem da web varia muito e depende de fatores como geografia, topologia da rede e localização do data center. Além do tempo na nuvem, existem outros fatores que afetam a latência de um ponto ao outro, incluindo o hardware do usuário, a conectividade disponível e a escolha do navegador. A maioria desses fatores está fora do controle do operador do site.

A maioria dos sites que oferecem uma resposta rápida foca na parte do canal de processamento de dados entregue pela web que pode ser controlado: o tempo transcorrido entre o momento em que a solicitação chega ao data center e o momento em que a página de resultados deixa o data center para chegar ao usuário. Sites sofisticados usam um princípio interno de 400 milisegundos. Dependendo do usuário e da sua conectividade, isso pode resultar em um tempo de espera pela exibição da página de resultados de dois ou três segundos.

Existem diversas causas de latência, potencialmente em todo estágio do canal de processamento de dados que conecta o navegador do usuário com os servidores no data center. Os culpados mais comuns incluem o DBMS, a conexão para sistemas back-end, o servidor de aplicação e o script. O DBMS pode sofrer o peso dos complexos de dados com pontos de intersecção e índex. O sistema pode também estar acessando uma aplicação back-end como a da SAP ou um sistema de estrutura herdada por meio de uma trança de mensagem ou de um barramento de serviço corporativo, ou até por meio de uma ferramenta de gerenciamento de processo corporativo (BPM).

O tempo de permanência da nuvem contribui majoritariamente com a latência, e o número de solicitações em cada página (relacionado com o número de elementos em cada página) pode aumentar esse intervalo. Muitos sites tentam controlar aspectos do canal de processamento de dados da latência empurrando o processamento e o conteúdo para mais perto do usuário via data centers distribuídos em diversas regiões geográficas ou usando redes de entrega de conteúdo (CDNs) que empurram esse conteúdo ao provedor de serviços de internet local.

Como sites com desempenhos insatisfatórios podem reduzir a latência?

Na ausência de dados objetivos para cada estágio do canal de processamento de dados, a intuição de um desenvolvedor costuma se equivocar ao detectar a causa da lentidão do desempenho. Faça um diagnóstico e elabore um perfil para cada estágio. Uma ferramenta útil para analisar o que acontece no cliente é o Yahoo! YSlow, e seu descendente, o Google Page Speed. Essas ferramentas podem mostrar, por exemplo, que mover uma instrução de JavaScript do topo do arquivo até embaixo permite que o navegador exiba o conteúdo da página conforme surge pelo fluxo de http, em vez de ficar bloqueado enquanto espera que todos os elementos sejam transferidos.

Utilizar eficazmente os dados apresentados por essas ferramentas exige uma certa compreensão de tecnologia web, servidores, protocolos, navegadores e desenvolvimento de aplicações online. Existem alguns fornecedores orientados a corporações, como a Strangeloop, que fazem otimização de desempenho automática por meio de um mecanismo de aceleração colocado na frente do servidor web.

Muitos sites corporativos não dispõem dos recursos (pessoas, ferramentas e conhecimento) para implantar tempo de resposta de subsegundos. Felizmente, sempre há maneiras de compensar a longa latência. Frequentemente, o importante não é a velocidade, mas a percepção da velocidade, combinada com a percepção do valor. Uma técnica simples, como o uso do indicador de progresso, pode reduzir a percepção de latência e aumentar o valor. Por exemplo, no site da Expedia, quando um usuário especifica a data e a destinação, o site exibe uma barra indicadora do progresso (além de uma confirmação visual da solicitação), acompanhada de uma mensagem afirmando que o site está procurando em milhões de registros a melhor oferta para o cliente.

Uma técnica que os desenvolvedores podem usar para reduzir a latência associada com o acesso de bases de dados back-end e aplicações é organizar em camadas uma plataforma de distribuição de cache na frente dos sistemas back-end. Esses são dados que podem ser transferidos de sistemas back-end para a memória central de um servidor intermediário entre a aplicação web e os pontos de origem. Um cliente do Gartner reportou que foi capaz de diminuir o número de transações que chegavam ao ponto de origem em até 65%, dependendo do tipo da transação. Existem várias outras técnicas, fornecedores e produtos que podem auxiliar, mas esses sistemas costumam exigir habilidades técnicas avançadas para uma implantação adequada.

Qual o papel que a Ajax e tecnologias de aplicações de internet sofisticadas desempenham na melhora do tempo de resposta?

Embora técnicas próprias como a Ajax e outros processamentos de ciclo local possam melhorar a receptividade de uma aplicação, em várias situações, o uso extensivo de tecnologias como Flash, Java e ActiveX reduz a latência de interações únicas, com o custo de um tempo de carregamento da página inicial maior.

Por exemplo, o Gmail, do Google, deve começar carregando 200 kilobytes de códigos JavaScript antes de que o usuário veja qualquer conteúdo. Da mesma forma, algumas tecnologias de aplicações online sofisticadas (RIA) começam carregando um enorme arquivo Flash SWF. Esse “carregamento inicial” de latência pode ser aceitável em alguns cenários, mas não em todos. Não faz sentido adicionar cinco segundos ao carregamento da página inicial se haverá apenas um clique de interação com a página antes de o usuário ir para uma seguinte.

Programadores e desenvolvedores podem também tirar vantagem do comportamento humano. Há momentos em que uma pausa é natural na interação do usuário – quando o usuário para analisar o conteúdo e talvez pense nos possíveis resultados. Esses são momentos quando a latência pode ocorrer. Por exemplo, quando um usuário está vendo um álbum de fotos do Facebook, navegando de uma a outra foto, o site já carrega a foto seguinte enquanto o usuário está visualizando a atual.

Como a maioria das respostas para dúvidas de design, há utilidade em diretrizes gerais e melhores práticas, mas a resposta mais eficaz se baseia em informações objetivas sobre o comportamento do internauta no site em questão.

Qual o papel do processo de design centrado no usuário em relação ao desempenho?

Apesar de a velocidade compensar deficiências no design da página, principalmente porque o mantém o usuário entretido, isso só funciona se o site atinge um nível mínimo de usabilidade. Se o usuário tem que parar e pensar, para entender como deve navegar no site, os efeitos benéficos da velocidade são anulados.

Um processo de design centrado no usuário ou orientado à usabilidade é essencial para permitir que o design do site evolua constantemente, baseado em dados sobre o comportamento dos usuários, assim como em testes de usabilidade e avaliações de eficácia.

Desenvolvedores e programadores podem aplicar processos centrados no usuário em técnicas para reduzir a latência inevitável. Programadores devem aplicar essas técnicas no contexto de uma metodologia baseada em constatações empíricas que usam medidas, não opinião, para orientar decisões sobre o tipo de conteúdo intersticial. Testes podem fornecer ajuda significativa nestes casos.

Fonte: Info Abril

Uma estrutura muito grande

Imagine um grande centro de processamento de dados, ligado 24 horas por dia, procurando por novas páginas sem parar. Agora imagine, que esses computadores já localizaram mais de 1 trilhão de páginas. Bilhões dessas páginas fazem parte de um índice, que é consultado cada vez que você faz uma pesquisa. Esse é o Google Search.

Mas… como ele chega a todas essas páginas?

Esse grande conglomerado de computadores rodam um programa conhecido como Googlebot (que também pode ser chamado de spiders).

O segredo para a rastreamento dos bilhões de páginas da web está nos links. Como já sabemos, os links ligam uma página a outra. Ao fazer isso, a página “linkada” se tornou pública, em razão de alguém ter apontado para ela. As spiders do Google aproveitam-se disso para conhecer essas novas páginas. É um processo longo que pode ser simplificado assim:

As spiders percorrem os sites que já são conhecidos por elas na internet, em busca de conteúdo atualizado. Além de se atualizar com as páginas já encontradas anteriormente, as spiders frequentemente acham links desconhecidos por elas, que passarão a ser explorados também. Através desses links, antes desconhecidos, as spiders chegam até as novidades, que começam a fazer parte de seu mapa. Esse processo acontece o tempo inteiro em uma escala gigante!

Como isso é organizado?

O Googlebot processa cada uma das páginas encontradas (!!!) para reunir em um índice gigante as palavras que achou dentro delas, bem como as posições dessas palavras dentro de suas respectivas páginas. Haja processamento, heim?

Daí em diante ele responde às pesquisas organizando este índice, por ordem de relevância.

#HelpTheSpiders

Quando eu aprendi como tudo isso funcionava, logo fiquei com pena das pobres spiders. Já pensaram o que significa vasculhar cada página da internet em busca de links que levam a novas páginas? Claro, elas são automatizadas… mas de qualquer forma podemos poupar boa parte do esforço do Google e ganhar tempo agilizando o trabalho de localização e indexação de nossas páginas usando sitemaps!

What the hell?

Basicamente, como o nome informa, é o mapa do site. Existem dois tipos de sitemaps. Por enquanto, vamos focar nos que ajudam os buscadores.

Esses têm um valor grande para as spiders. Um mapa assim é constituído por um arquivo XML que fica no seu servidor. Esse mapa informa aos robôs das buscas onde exatamente eles podem encontrar cada página do seu site.

O Google gosta disso! Isso agiliza o trabalho de rastreamento e indexação de sites de maneira muito eficiente.

Fonte: Discovery

Para aqueles que desejam começar no ramo de webhosting (ou apenas conhecer um novo painel de controle) mas não querem investir altos valores comprando licenças de painéis de controles, aqui vai a dica: Hosting Controller é uma ótima opção para quem esta começando. A nova versão para servidores Linux é totalmente gratuita

Conheça mais detalhes do Hosting Controller clicando aqui

Para acessar a versão demo clique aqui

O Carlos Zamora, do Zamora Blog, entrevistou Filipe Mendes CEO da Hostdime no Brasil. Ainda não tive a oportunidade de conhecer o Filipe Mendes, porém achei muito interessante publicar esta entrevista pois o Filipe tem grande conhecimento do mercado de webhosting no Brasil e no mundo.

O Carlos dividiu a entrevista em duas etapas, a primeira já esta disponível no site dele.

Algumas fotos do Escritório da Hostdime no Brasil

[Show as slideshow]

[View with PicLens]

Clique aqui para ler a primeira parte da entrevista, diretamente do site do Zamora Blog.

Segundo o site Netcraft, o Apache, servidor web mais popular do mundo, teve um crescimento de 4.3 Milhões de sites.

Nginx, já citado por aqui, também teve um bom crescimento e atualmente existem cerca de 13 milhões de sites em todo o mundo que utilizam o Nginx.

Já coloquei um post aqui sobre o Market Share de Servidores Web no mundo.

Fonte: Netcraft

O Google nunca declarou oficialmente a quantidade de servidores que a empresa possui para manter todos os seus serviços funcionando. Mas em uma recente apresentação Jeff Dean, Engenheiro do Google, mostrou que eles tem se preparado para gerenciar cerca de 10 milhões de servidores em um futuro não muito distante.

Não imaginei que uma única empresa poderia chegar tão perto dessa quantidade por alguns anos mas pelo jeito o Google será a primeira empresa a ultrapassar a barreira dos milhões de servidores.

Leia o artigo na íntegra, clique aqui

Fonte: Datacenter Knowledge