a

Tecnologia que interessa!

Tecnologia da informação aplicada - por Christian Guerreiro.

Notícias e novidades em Tecnologia da Informação, Dicas de Apps para Android e iPhone, Big Data, Computação em Nuvem, Governança de TI, ITIL, COBIT, Segurança, Software Livre, Virtualização

Página do Tecnologia que Interessa no Facebook! Twitter do Tecnologia que Interessa! Perfil Google+ de Christian Guerreiro - Tecnologia que Interessa!

sábado, 21 de fevereiro de 2015

HTTP/2 - Perguntas Frequentes (saiba tudo sobre as mudanças no funcionamento da web!)


O HTTP 1.1 estava aí há mais de 15 anos e nem me dei conta.

Acho que você também não, né ?

Eis que chega o HTTP/2 pra mostrar que mudanças eram necessárias.

Adaptei a excelente FAQ do HTTP/2 no Github pra trazer informação útil e de qualidade pra você. Enjoy!

Questões gerais

Por que revisar o HTTP?

O HTTP 1.1 tem servido bem a web há mais de quinze anos, mas a sua idade começa a transparecer.

Carregar uma página web é uma tarefa mais intensiva do que nunca, e carregar todos esses ativos de forma eficiente é difícil, porque HTTP praticamente só permite uma solicitação por conexão TCP.

No passado, os navegadores usavam múltiplas conexões TCP para emitir solicitações paralelas. No entanto, há um limite para isso; se muitas conexões são usadas, isso é igualmente improdutivo (o controle de congestionamento de TCP é efetivamente negado, levando a eventuais congestionamentos que prejudicam não só o desempenho, como também a rede), e isso é fundamentalmente injusto (porque os navegadores estão pegando mais do que a parte que lhes cabe dos recursos da rede).

Ao mesmo tempo, o grande número de pedidos significa um monte de dados duplicados “no cabeamento”.

Estes fatores significam que os pedidos HTTP 1.1 acabam tendo muita sobrecarga; então se muitas solicitações são feitas, pior é o desempenho.

Isso tem levado a indústria a um lugar em que a melhor forma de fazer as coisas como spriting, dados inline, domain sharding (dados em vários domínios paralelizando conexões) e concatenação (concatenar arquivos pra fazer requisição única).

Estes hacks são indicações de problemas ocultos no próprio protocolo, e causam um número de problemas por conta própria quando utilizados.

Quem fez o HTTP/2?

HTTP/2 foi desenvolvido pelo Grupo de Trabalho do IETF, o qual mantém o protocolo HTTP. Ele é composto por uma série de implementadores HTTP, usuários, operadores de rede e especialistas em HTTP.

Note que enquanto a nossa mailing list está hospedada no site W3C, ela não é um esforço do W3C. Apesar disso, Tim Berners-Lee e a W3C TAG são mantidos atualizados de em relação ao progresso do grupo.

Um grande número de pessoas contribuiu para o esforço, mas os participantes mais ativos incluem engenheiros de projetos “grandes”, como Firefox, Chrome, Twitter, pilha HTTP da Microsoft, Curl e Akamai, assim como uma série de implementadores HTTP em linguagens como Python, Ruby e NodeJS.

Para saber mais sobre como participar no IETF, consulte o Tao da IETF; você também pode ter uma noção do que está contribuindo para a especificação no gráfico de colaborador do Github, e quem está colaborando na nossa lista de implementações.

Qual a relação com o SPDY?

O HTTP/2 foi discutido pela primeira vez quando se tornou evidente que o SPDY foi ganhando força com os implementadores (como Mozilla e ngnix), e foi mostrando melhorias significativas sobre HTTP/1.x..

Depois de um convite à apresentação de propostas e de um processo de seleção, SPDY/2 foi escolhido como base para HTTP/2. Desde então, houve uma série de mudanças, com base na discussão do Grupo de Trabalho e feedback dos implementadores.

Ao longo do processo, o núcleo de desenvolvedores do SPDY tem sido envolvido no desenvolvimento de HTTP/2, incluindo também Mike Belshe e Roberto Peon.

Em fevereiro de 2015, o Google anunciou seus planos para remover o suporte para SPDY em favor de HTTP/2.

É HTTP/2.0 OU HTTP/2?

O Grupo de Trabalho decidiu abandonar a versão secundária (".0"), porque ela tem causado muita confusão no HTTP/1.x.

Em outras palavras, a versão HTTP apenas indica compatibilidade de conexão, e não conjuntos de funcionalidades ou "marketing".

Quais as principais diferenças para o HTTP/1.x?

De forma simplificada, o HTTP/2:
  • É binário, em vez de textual;
  • É totalmente multiplexado, em vez de ordenado e bloqueante;
  • Pode, portanto, usar uma conexão para o paralelismo;
  • Usa compressão de cabeçalho para reduzir a sobrecarga;
  • Permite que os servidores façam “push” das respostas de forma proativa em caches de cliente.

Por que HTTP/2 é binário?

Protocolos binários são mais eficientes para analisar, mais compactos “no cabeamento”, e mais importante, são muito menos propensos a erros, em comparação com protocolos textuais, como HTTP/1.x, porque muitas vezes eles têm uma série de recursos intuitivos para "ajudar" com coisas como manipulação de espaços em branco, capitalização, finais de linha, links em branco e assim por diante.

Por exemplo, HTTP/1.1 define quatro formas diferentes de analisar uma mensagem; em HTTP/2, há apenas um código pra lidar com isso.

É verdade que o HTTP/2 não é utilizável através de telnet, mas nós já temos algumas ferramentas de apoio, como o plug-in do Wireshark.

Por que o HTTP/2 é multiplexado?

HTTP/1.x tem um problema chamado "bloqueio de cabeçalho-de-linha", onde efetivamente apenas uma solicitação pode ser destacada a cada conexão.

HTTP/1.1 tentou corrigir isso com pipelining, mas não abordou completamente o problema (uma resposta grande ou lenta ainda pode bloquear outras depois dela).

Além disso, o pipelining se verificou muito difícil de implementar, por conta de muitos intermediários e servidores não processarem corretamente a funcionalidade.

Isto obriga os clientes a usar um número de heurísticas (muitas vezes adivinhando) para determinar quais pedidos colocar em uma conexão de origem; uma vez que é comum para uma página carregar 10 vezes (ou mais) o número de conexões disponíveis, isso pode afetar severamente o desempenho, muitas vezes resultando num "efeito cascata" de solicitações bloqueadas.

A multiplexação trata desses problemas, permitindo que várias mensagens de solicitação e resposta estejam em transição ao mesmo tempo; é possível até mesmo se misturar partes de uma mensagem com outra na conexão.

Isto, por sua vez, permite a um cliente utilizar apenas uma conexão por origem para carregar uma página.

Por que só uma conexão TCP?

Com o HTTP/1, os navegadores abriam entre quatro e oito conexões por origem. Uma vez que muitos sites usam múltiplas origens, isso pode significar que um único carregamento de página abre mais de trinta conexões.

Uma aplicação abre tantas conexões simultaneamente que rompe uma série de premissas sobre as quais o TCP foi construído; já que cada conexão irá iniciar uma enxurrada de dados na resposta, há um risco real de que os buffers da rede estourem, causando congestionamento e retransmissões.

Além disso, o uso de tantas conexões monopoliza injustamente os recursos de rede, "roubando" de outras aplicações mais bem comportadas (por exemplo, VoIP).

Qual a vantagem do Servidor Push?

Quando um navegador solicita uma página, o servidor envia o HTML na resposta, e depois precisa esperar para que o navegador analise o HTML e emita os pedidos de todos os ativos incorporados antes que se possa começar a enviar as imagens, JavaScript e CSS.

O servidor push permite que o servidor, para evitar esse atraso na viagem, possa "empurrar" as respostas que ele acha que o cliente terá em seu cache.

Por que precisamos de compressão do cabeçalho?

Patrick McManus da Mozilla mostrou isso claramente calculando o efeito dos cabeçalhos em uma carga média da página.

Se você assumir que a página tem cerca de 80 ativos (que é conservador na web de hoje), e cada pedido tem 1.400 bytes de cabeçalhos (de novo, não é incomum, graças aos cookies, referer, etc.), é preciso pelo menos 7 a 8 idas e vindas para colocar os cabeçalhos "no cabeamento". Isso sem contar o tempo de resposta - esse tempo é apenas para obtê-los do cliente.

Isso é por causa do mecanismo Slow Start do TCP, que encaminha os pacotes em novas conexões com base em quantos pacotes foram reconhecidos (ack) - efetivamente limitando o número de pacotes que podem ser enviados para as primeiras transmissões.

Em comparação, até mesmo uma compressão suave em cabeçalhos permite que esses pedidos cheguem até a conexão dentro da mesma roundtrip – talvez até no mesmo pacote.

Essa sobrecarga é considerável, especialmente quando você leva em conta o impacto sobre os clientes móveis, que normalmente têm latência de várias centenas de milissegundos, mesmo em boas condições.

Por que HPACK?

O SPDY/2 propôs a utilização de um contexto GZIP único em cada sentido para a compressão de cabeçalho, que era simples de implementar, bem como eficiente.

Desde então, um grande ataque foi documentado contra o uso de compressão de fluxo (como GZIP) dentro de criptografia; CRIME.

Com CRIME, é possível para um atacante que tem a habilidade de injetar dados no fluxo criptografado, "sondar" o texto simples e recuperá-lo. Como se trata da web, JavaScript torna isso possível, e houve demonstrações da recuperação de cookies e tokens de autenticação usando CRIME para recursos HTTP protegidos por TLS.

Como resultado, não poderíamos usar a compressão GZIP. Não encontrando outros algoritmos adequados para este caso de uso, bem como seguros, criamos um esquema de compressão novo, específico para o cabeçalho e que opera em uma granularidade menor; uma vez que os cabeçalhos HTTP, muitas vezes não mudam entre as mensagens, isso ainda dá eficiência de compressão razoável, e é muito mais seguro.

O HTTP/2 pode tornar cookies (ou outros cabeçalhos) melhores?

Este esforço foi constituído para trabalhar em uma revisão do protocolo de conexão - ou seja, como os cabeçalhos HTTP, métodos, etc. são colocados "no cabeamento", para não mudar a semântica do HTTP.

Isso porque HTTP é tão amplamente utilizado. Se usássemos esta versão do HTTP para introduzir um novo mecanismo de estado (um exemplo que tem sido discutido) ou alterar os métodos de núcleo (felizmente, isso ainda não foi proposto), isso significaria que o novo protocolo seria incompatível com a web existente.

Em particular, queremos ser capazes de traduzir a partir de HTTP/1 para HTTP/2 e vice-versa, sem perda de informação. Se começássemos a "limpar" os cabeçalhos (e a maioria vai concordar que os cabeçalhos HTTP são bastante confusos), teríamos problemas de interoperabilidade com grande parte da web existente.

Fazer isso seria apenas criar atrito contra a adoção do novo protocolo.

Dito isto, o Grupo de Trabalho HTTP é responsável por todas as versões do HTTP, não apenas HTTP/2. Como tal, podemos trabalhar em novos mecanismos que sejam independentes de versão, desde que eles sejam compatíveis com versões anteriores à da web existente.

E quanto ao uso do HTTP "fora do navegador"?

Aplicações não navegadoras devem ser capazes de usar o HTTP/2 tão bem quanto já usam o  HTTP.

O feedback inicial foi de que HTTP/2 tem boas características de desempenho para "APIs" HTTP, porque as APIs não precisam considerar coisas como pedidos sobrecarregados em seu design.

Tendo dito isso, o foco principal das melhorias que estamos considerando são os casos de uso típicos para navegação, uma vez que este é o caso de uso de núcleo para o protocolo.

Nosso comunicado diz o seguinte sobre isso:

A(s) especificação(ões) resultante(s) pretendem atender aos seguintes objetivos para implantações comuns existentes para o uso do HTTP; em particular, a navegação na web (desktop e móvel), não navegadores ("APIs" HTTP), serviços web (em uma variedade de escalas), e intermediários (proxies, firewalls corporativos, proxies "reversos" e redes CDN). Da mesma forma, extensões semânticas atuais e futuras para HTTP/1.x (por exemplo, cabeçalhos, métodos, códigos de estado, diretivas de cache) devem ser suportadas no novo protocolo.

Note que isso não inclui usos de HTTP onde se confia em comportamentos não especificados (por exemplo, estados de conexão tais como limites de tempo ou afinidade de cliente, e  proxies de“interceptação”); esses usos podem ou não ser habilitados no produto final.

O HTTP/2 exige criptografia?

Não. Depois de uma ampla discussão, o Grupo de Trabalho não teve consenso para exigir o uso de criptografia (por exemplo, TLS) para o novo protocolo.

No entanto, algumas implementações afirmaram que só irão apoiar HTTP/2 quando ele for usado por uma conexão criptografada.

O que HTTP/2 fez para melhorar a segurança?

HTTP/2 define um perfil de TLS que é requerido; isso inclui a versão, uma lista negra "ciphersuite" e extensões usadas.

Veja as especificações para obter mais detalhes.

Há também a discussão de mecanismos adicionais, como o uso de TLS para URLs http:// (a chamada "criptografia oportunista"); veja o draft da respectiva especificação.

Posso usar HTTP/2 agora?

HTTP/2 está atualmente disponível no Firefox e no Chrome para teste, utilizando o identificador de protocolo "h2-14".

Existem também vários servidores disponíveis (incluindo um servidor de teste de Akamai, Google e site principal do Twitter), e uma série de implementações de código aberto que você pode implementar e testar.

Veja a lista de implementações para mais detalhes.

HTTP/2 substituirá HTTP/1.x?

O objetivo do Grupo de Trabalho é que os usos típicos de HTTP/1.x possam usar HTTP/2 e ver algum benefício. Dito isto, não podemos forçar o mundo a migrar, e por causa da maneira que as pessoas implantam proxies e servidores, é provável que HTTP/1.x ainda esteja em uso por algum tempo.

Haverá um HTTP/3 ?

Se o mecanismo de negociação introduzido pelo HTTP/2 funcionar bem, deve ser possível que suporte novas versões do HTTP muito mais facilmente do que no passado.

Questões de Implementação

Por que as regras em torno da continuação dos quadros HEADERS?

A continuação existe pelo fato de que um único valor (por exemplo, Set-Cookie) pode exceder 16KiB - 1, o que significa que ele não cabe em um único quadro. Decidiu-se que a maneira de lidar com isso menos propensa a erros era exigir que todos os dados de cabeçalhos fossem em quadros back to back, o que tornou a decodificação e gerenciamento do buffer mais fácil.

Qual é a quantidade de memória mínima ou máxima para o estado do HPACK?

O receptor sempre controla a quantidade de memória utilizada no HPACK, e pode definí-la zero, no mínimo, com um máximo relacionado com o inteiro máximo representável em um quadro SETTINGS, atualmente 2^32-1.

Como posso evitar manter o estado de HPACK?

Enviar um quadro SETTINGS ajustando a quantidade de memória (SETTINGS_HEADER_TABLE_SIZE) para zero, então fazendo reset (RST) de todos os fluxos de conexão até que um quadro de definições com o bit ACK setado seja recebido.

Por que há um único contexto de compressão/controle de fluxo?

Simplicidade.

As propostas originais tinham grupos de fluxo, os quais compartilhavam contexto, controle de fluxo, etc. Embora isso beneficiasse proxies (e a experiência de utilização dos usuários através deles), isso acrescentou um pouco de complexidade. Foi decidido que iríamos começar com a coisa simples, ver o quão doloroso seria, e enfrentar a dor (se houver) em uma futura revisão do protocolo.

Por que há um símbolo EOS em HPACK?

A codificação Huffman do HPACK, por razões de eficiência de CPU e segurança, aloca cadeias codificadas em Huffman para o próximo limite de bytes; pode ser necessário entre 0 e 7 bits de preenchimento para qualquer sequência de caracteres.

Se considerarmos a decodificação Huffman isoladamente, qualquer símbolo que seja mais longo do que o necessário para preenchimento iria funcionar; no entanto, o projeto do HPACK permite a comparação inteligente de bytes em strings codificadas com Huffman. Ao exigir que os bits do símbolo EOS sejam utilizados para preenchimento, podemos garantir que os usuários possam fazer comparação de sequências codificadas Huffman para determinar a igualdade. Isto por sua vez significa que muitos dos cabeçalhos podem ser interpretados sem ser decodificados.

Posso implementar HTTP/2 sem implementar HTTP/1.1?

Sim, em grande parte.

Para HTTP/2 sobre TLS (h2), não é necessário implementar o identificador ALPN do HTTP1.1, não sendo requerida qualquer característica do HTTP/1.1.

Para HTTP/2 sobre TCP (h2c), é necessário para implementar uma solicitação de atualização inicial.

Clientes h2c precisarão gerar uma solicitação OPTIONS para "*" ou uma solicitação HEAD para "/", que são relativamente seguros e fáceis de construir. Os clientes que procuram implementar apenas HTTP/2 vão precisar tratar respostas HTTP/1.1 sem um código 101 como erros.

Servidores h2c podem aceitar um pedido que contém o campo de cabeçalho de atualização com uma resposta fixa 101. Pedidos sem o token de atualização h2c podem ser rejeitados com um código de status 505 (versão HTTP sem suporte), que contém o campo de cabeçalho de atualização. Os servidores que não desejam processar resposta HTTP/1.1 devem rejeitar o fluxo 1 com um código de erro REFUSED_STREAM imediatamente após o envio do prefácio de conexão para incentivar o cliente a repetir o pedido via HTTP/2.

Questões de Implantação

Como depurar HTTP/2 se ele é criptografado?

Há muitas maneiras de obter acesso aos dados da aplicação, mas o mais fácil é usar NSS keylogging em combinação com o plug-in Wireshark (incluído nas últimas versões de desenvolvimento). Isso funciona tanto com o Firefox quanto com o Chrome.

Conclusão

Demorou mas chegou.

Refletindo após a leitura da especificação do HTTP/2, ficou claro pra mim que o trabalho do protocolo estava sendo feito pelos navegadores, como registramos no caso do Chrome e Firefox aqui no blog (embora sem a noção que descrevo agora).

Entendo que isso significa que os navegadores terão condição de evoluir para áreas anteriormente não priorizadas, como interface com usuário, integração com serviços (redes sociais, por exemplo) e outras coisas muito legais que não dava pra fazer porque a prioridade era entregar um desempenho satisfatório pro usuário e fazer malabarismos pra lidar bem com áudio, imagem, vídeo e texto da melhor maneira possível.

E você, o que achou da nova versão do HTTP ? Diz aí!
Mais...

sexta-feira, 20 de fevereiro de 2015

5 maneiras de fazer a Internet trabalhar pra você! (IFTTT agora mais poderoso com as "Do" Apps)

5 maneiras de fazer a Internet trabalhar pra você! (IFTTT agora mais poderoso com as "Do" Apps)

Os leitores do blog já conhecem o IFTTT desde 2011.

O serviço evolui a passos largos, e agora conta com nada mais nada menos que 4 apps, o IFTTT (que agora se chama IF) e mais 3 apps "Do": Do Button, Do Câmera e Do Note.

A idéia das apps "Do" é facilitar ainda mais a integração entre os zilhões de serviços na web, deixando estas integrações a um clique de botão de distância.

Seguindo a linha das receitas prontas e criadas pelos próprios usuários, basta escolher a que lhe for mais útil e pronto, poderá acionar aquela atividade com um clique, seja tuitar uma foto, salvar um documento no Google Drive ou desligar a lâmpada da sala.

Vamos exemplificar o que pode ser feito pra deixar mais claro como você pode simplificar ainda mais sua vida :)

Salvar um arquivo no Dropbox ao conectar o wifi

O Do Button é o mais versátil, tendo opções mais variadas de integração entre serviços, e permite, por exemplo, utilizar o canal "Android Device" pra identificar automagicamente quando seu smartphone conectar o wifi (dá pra escolher uma rede específica se quiser) e utilizar outro canal para a ação a ser realizada, neste exemplo seria salvar um arquivo no Dropbox a partir de uma URL fornecida.

Publicar no facebook novas postagens do blog

Essa eu uso muito!

Com o canal "Blogger" o IF detecta quando publico um novo texto no blog e replica o mesmo no Facebook (dá pra escolher outras redes sociais).

IF e Hootsuite são os responsáveis pela avalanche de textos sobre tecnologia no meu facebook pessoal :)

Agradecer novos seguidores no Twitter

Essa preciso implementar!

Usando o canal "Twitter" como this e como that  (if this than that :) é possível detectar quando alguém te segue e enviar uma mensagem de agradecimento pra pessoa.
Receitas Do Câmera - backup de fotos pro Google Drive, Facebook, Flickr, etc

Fazer backup das fotos do Flickr no Dropbox

Do Câmera é focado em fotos (dãããããa), e possibilita usar o canal "Flickr" pra detectar uma nova foto ou set (a foto tem que ser pública infelizmente) e utilizar outro canal para a ação a ser realizada, neste exemplo seria salvar a foto no Dropbox.
Receitas Do Notes - tuitar, registrar idéias no evernote, mandar email, etc

Registrar idéias para posts, ebooks, etc

O Do Note pode me ajudar a resolver um grande problema: minhas idéias se perdem no vazio da mente (falei bonito, hein?). Sabe aquela "sacada genial" que todos temos no banho ou logo antes de dormir, mas que se perde pelo caminho ? O Do Note ajuda a registrar rapidamente aquela anotação, antes que se vá da memória.

Conclusão

O IFTTT já mostrou sua utilidade, tanto que é um serviço muito citado mundo afora, e não para de crescer e atrair investidores. Uso o serviço há anos e recomendo!

Agora eles estão preparando o terreno para a monetização do serviço, já que cada uma das "Do Apps" só permite o uso de 3 receitas na versão gratuita. Ou seja, você tem 9 receitas se usar as 3 apps. Provavelmente vão cobrar de quem quiser mais receitas.

Porém, não notei qualquer restrição no uso de receitas através da app IF ou do site IFTTT.com, embora algumas receitas que criei sejam desativadas de vez em quando. Não sei se vai continuar assim.

E você ? Já usar o IF ou algum "Do app" ? Comenta aí!
Mais...

segunda-feira, 16 de fevereiro de 2015

Estudo mostra que instituições públicas brasileiras ainda não estão prontas para a nuvem

Tipos de Computação em Nuvem - Híbrida, Pública e Privada - On e Off-Premise
O informativo COBIT Focus traz um estudo interessantíssimo dos brasileiros Wellington Evangelista e João Souza Neto, que mostra, através da análise de órgãos públicos, que as instituições públicas brasileiras ainda não estão preparadas para utilizar serviços na nuvem.

O estudo consistiu da elaboração e aplicação de um questionário baseado nas recomendações do COBIT 5, dividido em duas partes: uma dedicada a entender a organização, e outra relacionada à tecnologia mesmo.

No que se refere à organização, o questionário traz perguntas como "O departamento de TI tem acordos de nível de serviço estabelecidos com as áreas de negócio ?" e "Os processos afetados pela migração/adoção dos serviços em nuvem foram identificados?", organizadas em categorias como operação, estratégia corporativa e gestão de contratos e serviços.

No que se refere à tecnologia, o questionário traz perguntas como "Há um plano de contingência para os processos de negócio em caso de interrupção do serviço na nuvem pelo provedor ?" e "Considerando a confidencialidade dos dados manuseados pelas aplicações, as leis relevantes foram analisadas com relação ao armazenamento de dados por terceiros em países estrangeiros e foi determinado que há baixo ou nenhum risco para o negócio ?", organizadas em categorias como operação, segurança da informação e infraestrutura de TI.

O questionário foi aplicado a cinco instituições públicas no Brasil e os resultados mostraram que há a necessidade de aumentar bastante o nível de maturidade de processos afetados pela tecnologia de computação em nuvem, através de atividades como definição de acordos de nível de serviço entre TI e áreas de negócio, elaboração de plano de contingência, análise das questões legais relativas ao armazenamento de dados em localidades fora do país, dentre outras.

O resultado permite uma reflexão que resulta na observação do quanto às organizações brasileiras ainda precisam amadurecer em termos de governança de TI. Questões básicas como a definição de acordos internos entre TI e áreas de negócio, bem como gestão do relacionamento com fornecedores, ainda são tratadas de maneira muito desalinhada com o que prega o COBIT em sua mais nova versão, que completa 3 anos em abril deste 2015.

Conclusão

O estudo traz uma contribuição muito significativa, em minha opinião, na medida em que fornece meios objetivos para que empresas possam avaliar o quanto estão preparadas para adotar serviços na nuvem.

Pena que a velocidade do amadurecimento nos processos de governança, especialmente nos órgãos do governo, é muito lento. Lamentável.

Confira o estudo completo aqui.

E você ? O que achou do estudo ? Sua empresa está pronta para a nuvem ?
Mais...

terça-feira, 10 de fevereiro de 2015

Big Data é uma piada (não é o que você está pensando!)

Há muita controvérsia em torno da tecnologia de Big Data.

Há quem desdenhe.

Há quem desconfie.

Há quem acredite.

Há quem aplique.

Há até quem não está nem aí.

Seja qual for seu interesse na tecnologia, acredito que vai se divertir (quem sabe até refletir) com as imagens a seguir. Confira!

Big Data é como sexo na adolescência: todo mundo fala, ninguém realmente sabe como fazer, todo mundo pensa que todo mundo está fazendo, então todo mundo diz que está fazendo. :)
Big Data é como sexo na adolescência: todo mundo fala, ninguém realmente sabe como fazer, todo mundo pensa que todo mundo está fazendo, então todo mundo diz que está fazendo. :)

Muita gente se preocupando em obter dados sem sequer saber o que fazer com eles. Cômico ou trágico ?
Muita gente se preocupando em obter dados sem sequer saber o que fazer com eles. Cômico ou trágico ?

Criar meios de analisar os dados e extrair informação útil para tomada de decisão é o grande desafio! Não adianta pressa.
Criar meios de analisar os dados e extrair informação útil para tomada de decisão é o grande desafio! Não adianta pressa.

A coleta de dados cada vez mais presente nos serviços que usamos na Internet faz com que seja cada vez mais difícil se esconder. A Internet não é terra de ninguém faz tempo.
A coleta de dados cada vez mais presente nos serviços que usamos na Internet faz com que seja cada vez mais difícil se esconder. A Internet não é terra de ninguém faz tempo.

Separar o joio do trigo não é fácil!
Separar o joio do trigo não é fácil!

Em breve numa barraca de frutas perto de você :)
Em breve numa barraca de frutas perto de você :)

Complicado colocar esses dados na nuvem, hein ?
Complicado colocar esses dados na nuvem, hein ?

Facebook = CIA, ou "O espião é você mesmo" :)
Facebook = CIA, ou "O espião é você mesmo" :)

23,5% bem vindo é ótimo!!!
23,5% bem vindo é ótimo!!!

Só eu lembrei da Alemanha ? :(
Só eu lembrei da Alemanha ? :(

O hype em torno do termo é grande, mas vai passar, afinal isso sempre acontece com novas tecnologias, embora haja quem defenda que de novo o Big Data não tem nada. Enfim...

Conclusão

O hype em torno do termo é grande, mas vai passar, afinal isso sempre acontece com novas tecnologias, embora haja quem defenda que de novo o Big Data não tem nada.

Enfim...

De todo modo, acredito que a hora de aproveitar é agora, até porque o processo de adoção está lento no Brasil, pois depois que virar commodity... aí será tarde pra alavancar sua carreira usando o hype como trampolim.

E aí, curtiu as imagens ? Tem alguma pra compartilhar ? Manda aí!
Mais...

quinta-feira, 5 de fevereiro de 2015

Chegou o VMware vSphere 6 - isso muda tudo ?

A VMware finalmente lançou a tão aguardada versão 6 da suite de virtualização mais usada no mundo. E que lançamento! Que versão!

Vejamos as novidades.

Novos limites de configuração

A VMware parece fazer questão de manter números impressionantes quando se trata de configurações suportadas, seja em relação a hosts, máquinas virtuais ou recursos como processamento e memória. Vejamos os novos números.

  • 64 hosts por cluster;
  • 8000 VMs por cluster;
  • 480 CPUs por host;
  • 12TB de memória por host;
  • 2048 VMs por host;
  • 128 vCPUs por VM;
  • 4TB de RAM por VM.

vMotion de longa distância

VMware vSphere 6 - vMotion
Um dos recursos que mais me chamou a atenção, e que vamos abordar sob outro ângulo mais adiante, é o vMotion de longa distância, que permite a migração de máquinas virtuais "a quente" para sites remotos, por exemplo, ampliando as possibilidades de distribuição de serviços, flexibilizando as opções de Disaster Recovery, dentre outros benefícios.

Além disso, agora vai ser possível fazer vMotion entre diferentes servidores vCenter, e ainda com suporte ao Microsoft Cluster (inclusive RDM!).

Fault Tolerance multi-processador (SMP)

Outra novidade das mais importantes, na opinião deste blogueiro, é a remoção (pelo menos em parte) das gravíssimas limitações do Fault Tolerance, que agora permite proteger com tolerância a falhas, máquinas virtuais com até 4 processadores e 64 GB de RAM, o que deve fazer com que o recurso passe a ser usado efetivamente por um número significativo de clientes, preenchendo uma lacuna importantíssima em termos de funcionalidade da solução, e aumentando a vantagem da VMware em relação à concorrência.
Comparação entre o VMware vSphere FT 5.5 e 6.0
Comparação entre o FT 5.5 e 6.0

Virtual Volumes

VMware vSphere 6 Virtual Volumes

Pelo que entendi, este recurso deve permitir utilizar (qualquer) storage de forma mais integrada com o ambiente virtualizado, ou seja, o storage vai gerenciar o armazenamento das máquinas virtuais, e não mais o software de virtualização.

Pra que isso funcione há uma série de requisitos, em especial o suporte a containers de armazenamento e à API VASA. Os containers são usados pra armazenar informações de cada VM separadamente (VMDKs, snapshots, etc) e a API delega as operações de armazenamento pro storage, liberando o host.

Outro ponto importante é que as políticas de armazenamento agora podem ser aplicadas por máquina virtual, e não mais por unidade de armazenamento (datastore).

Há quem ache que esta é a principal funcionalidade da nova versão da suite, mas não estou certo disso.

Outras novidades

  • vCenter Single Sign On (SSO) agora é uma plataforma multi-serviços que integra autoridade certificadora, armazenamento de certificados, registro de serviços e o SSO);
  • vCenter Server Appliance agora suporta até 1000 hosts e 10.000 VMs;
  • Suporte ao sistema de arquivos NFS 4.1 com autenticação Kerberos e suporte a recuperação de erros e multipath;
  • Suporte ampliado ao IPv6, incluindo iSCSI, NFS e VMFS;
  • Content Library é o novo conceito que consiste num repositório de templates, imagens ISO, vApps e scripts;
  • Gerenciamento baseado em políticas para provisionamento de VMs baseada em funcionalidade e capacidade, alocação inteligente, monitoramento de aderência a políticas e remediação automática, dentre outras novidades;
  • Suporte ao Storage I/O Control (SIOC - QoS para acesso a armazenamento) e Network I/O Control (NIOC - QoS para priorizar tráfego das VMs) por máquina virtual;
  • Até 8TB e 800 VMs por VMware Data Protection (VDP) Appliance, e backup de aplicação para SQL Server, Exchange e Sharepoint;
  • Melhorias de segurança, incluindo gerenciamento de usuários e senhas, auditoria e gerenciamento do ciclo de vida de certificados;
  • Instant Clone (VMFork) aumenta em 10x o desempenho na clonagem de VMs;
  • Melhorias de desempenho e usabilidade no Web Client (extremamente necessárias, por sinal :);
  • Melhorias no High Availability (HA), Dynamic Resource Scheduler (DRS), Site Recovery Manager (SRM), vSphere Replication, VSAN, dentre outras que poderia ficar horas descrevendo aqui.

A visão de futuro da VMware

Transcrevi a seguir, em tradução livre, um texto excelente do Michael Weber, do Long White Clouds, que entendo ser muito útil para ajudar a compreender a visão de futuro da VMware. Confiram abaixo.
Enquanto um monte de pessoas (eu incluído) estão animadas sobre as questões técnicas do lançamento vSphere 6, há algo muito mais fundamental sobre esta versão. Alguns destaques técnicos incluem clusters de 64 nós, 8000 VMs por cluster, 480 processadores, 12 TB de RAM e 2048 VMs por host, 128 vCPU e 4TB RAM por VM, SMP FT (até 4 vCPU), aprimoramentos para NIOC, VVOLs, melhorias SIOC, e muito mais. 
A razão pela qual esta versão é mais fundamentalmente importante está relacionada com a mesma razão que a Amazon com AWS passou de um nada a líder de mercado. Não é apenas sobre a tecnologia, mas o que a tecnologia permite, mudando o modelo de negócios, reduzindo o atrito, permitindo flexibilidade. O que pode parecer um recurso relativamente pequeno na superfície tem o potencial de mudar a paisagem do mercado de nuvens híbridas baseadas em SDDC. Se você gostaria de saber mais sobre isso, e tudo mais de bom que vem como parte do lançamento do vSphere 6, continue lendo.

VMware está prestes a lançar a versão mais recente do produto vSphere no que eu prevejo que será um momento decisivo para a era Mobile / Cloud. Pela primeira vez, você vai ser capaz de migrar "ao vivo", sem qualquer interrupção, entre datacenters de nuvem privada, para a nuvem pública, em longa distância, numa verdadeira nuvem híbrida e 
datacenter definido por software. 
Você será capaz de implementar a melhoria da qualidade de serviço para todas as aplicações com garantias adicionais de SLA, e escala para níveis sem precedentes. Tudo isso ao mesmo tempo reduz as despesas gerais de gestão e a complexidade de todo o ecossistema. Com políticas que seguem as máquinas virtuais e aplicativos virtuais, independentemente de onde eles estão localizados fisicamente. 
Esta versão precisou de um tempo maior, e por um bom motivo. Há um grande compromisso com a qualidade do produto, o que foi evidenciado pelo primeiro beta público da história do VMware vSphere. Este é um lançamento importante, e é bem merecedor do número de versão 6.0. Muito trabalho duro foi aplicado neste lançamento por milhares de pessoas. Eu pude testar um monte de funcionalidades durante o beta e foi ótimo poder contribuir para o produto. 
Então, por que eu acho que este é um momento de definição? O mundo está mudando com a explosão maciça de smartphones e as aplicações que os suportam. Muitos milhões de usuários estão exigindo seus aplicativos onde e quando quiserem. Os aplicativos precisam ser capazes de escalar maciçamente e sob demanda, e mover-se para onde quer que possa fazer sentido. 
Anteriormente, migrar cargas de trabalho a partir de uma nuvem privada ou SDDC privada para um provedor de nuvem e suportar uma nuvem híbrida, era necessário que os sistemas sendo migrados fossem desligados. Você poderia migrar modelos e fazer ajustes depois, mas isso não é exatamente o mesmo que ser capaz de migrar dinamicamente "ao vivo" qualquer carga de trabalho de seu datacenter para a nuvem sem qualquer tempo de inatividade ou interrupção, e através de longas distâncias. 
Se você realmente queria entregar cargas de trabalho em nuvem e as cargas de trabalho móveis em escala, elas deviam ser escritas para um ambiente de nuvem particular. Então você estava preso em um Hotel Califórnia, onde você pode fazer o checkout, mas nunca pode realmente sair. 
Esta é a diferença fundamental, e a mudança tecnológica fundamental que é potencialmente habilitada pelo vSphere 6, que por sua vez vai quebrar os atuais paradigmas de negócios e modelos atuais. 
As melhorias no VMware vMotion têm o potencial de mudar a maneira como as organizações mantém seus datacenters, aplicações e interagem com os prestadores de serviços em nuvem. É possível migrar cargas de trabalho entre diferentes nuvens sob demanda, com base em regras e políticas de negócios, desde que se baseiem em vSphere 6. 
Então de onde vem a comparação com o Amazon AWS ? A razão pela qual eu acredito que o AWS se tornou bem sucedido, não é por causa da tecnologia, mas porque ele mudou o modelo econômico e de negócios de consumo de infra-estrutura. 
Ela reduziu o atrito, transformou tudo sob demanda, e entregou a equipes de desenvolvimento e aplicações, de uma forma transparente. Com as melhorias do VMware vMotion, permitindo migração entre diferentes servidores vCenter e Longa Distância, provedores de nuvem de serviços podem fornecer ainda menos atrito, sob demanda,  e executar qualquer tipo apropriado de serviço em qualquer lugar. 
Algumas das tiranias da rede e migração em tempo real estão sendo demolidas. Isto pode mudar a maneira que infra-estrutura é consumida e tornar mais fácil para as equipes de aplicativos entregá-los. Mas isso precisa ser misturado com uma construção comercial que os suporte. 
No VMworld em 2014 Bill Fathers, pai do vCloud Air, informou que cerca de 6% das cargas de trabalho eram executadas em ambientes de nuvem. Eu acredito que parte da razão é por causa da dificuldade em migrar cargas de trabalho para a nuvem, e entre diferentes nuvens, sem interrupção, e sem ter que mudar os aplicativos subjacentes. 
Com as mudanças que VMware está começando a entregar a partir de vSphere 6, isso poderia rapidamente mudar a adoção de nuvens compatíveis com VMware. Ainda há muito a fazer em termos de rede, que ainda é uma das barreiras para a nuvem, mas é um longo caminho.
Logo você vai estar dimensionando cargas de trabalho sob demanda para apoiar os milhões de usuários móveis e migrando cargas de trabalho para a nuvem de sua escolha, quase em qualquer lugar do mundo. 
Estive recentemente na Conferência de Usuários VMware em Singapura (VMUG) e ouvi um dos meus colegas, Scott Drummond , falar sobre cloud e localidade. Localidade é importante porque há diferenças de ordens de grandeza computacional conforme os usuários estejam mais longe de seus aplicativos e dados. 
Como isso se relaciona com o lançamento do VMware vSphere 6.0 e vCenter vMotion ? O outro lado do vMotion longa distância é que agora será possível migrar cargas de trabalho sob demanda, mais perto de onde os usuários estão, especialmente quando começamos a ver os serviços em nuvem se tornarem mais locais, e mais miniaturizados ao longo do tempo. 
Palavra final 
À primeira vista, vMotion através de vCenters e longa distância pode não parecer revolucionário. Quando você coloca tudo isso no contexto da nuvem híbrida e SDDC que a VMware tem construído há mais de 5 anos, é mais fácil ver que isso realmente proporciona uma mudança fundamental na forma como os recursos de infra-estrutura podem ser usados. Não vai demorar muito para que a migração de VM aconteça como representado na imagem acima. Que novas possibilidades isto vai abrir para as empresas? Que impactos isso terá na soberania de dados?...

Conclusão

Mais uma vez a VMware traz, mais que uma nova versão, uma onda de inovação, embora a concorrência esteja apertando, como demonstra o crescimento da nuvem Windows Azure da Microsoft, sem falar na líder Amazon, que também não para de inovar.

Entre as duas novidades concorrentes, volumes virtuais e vMotion de longa distância, tendo a concordar com o Michael Webster que a possibilidade de migrar suas cargas de trabalho para a nuvem sem interrupção é algo incrivelmente poderoso e, como dizem os gringos, pode ser um recurso "Game Changer", pois torna mais simples do que nunca o processo de adoção da nuvem para o legado, algo que sempre foi o "calo" de muitas empresas.

Lembro quando conversava com especialistas de um dos poucos datacenters "respeitáveis" que restaram na Bahia e eles temiam quanto à virtualização do cluster Microsoft. Imagine que no futuro eles poderão migrar este cluster pra nuvem de maneira simples e transparente. Fantástico!

Por isso, penso que SIM, o vSphere 6 muda tudo!

E você ? O que achou das novidades ? Quer saber mais e aprender a usá-las ?

Referências

Mais...

quarta-feira, 4 de fevereiro de 2015

Facebook movimentou 10 bilhões de doletas no Brasil em 2014

Facebook movimenta 10 bilhões de dólares no Brasil em 2014
O Clube do Hardware informa a impressionante movimentação financeira do Facebook no mercado brasileiro e mundial ano passado. De repente ficou fácil entender porque a rede do Zuckerberg vale tanto dinheiro...
Segundo estudo da consultoria Deloitte & Touche, o Facebook gerou em2014 mais de US$ 227 bilhões à economia mundial e 4,5 milhões deempregos, sendo US$ 10 bilhões e 231 mil empregos no Brasil. 
O Facebook revelou que 91 milhões de brasileiros se conectam à redesocial todos os meses e que há 2,1 milhões de pequenas empresas compáginas ativas. 
O estudo avaliou ainda negócios que possuem páginas no Facebook,aplicativos e jogos para dispositivos móveis utilizados na rede social emedidas sobre a atividade econômica resultante, bem como a demanda poraparelhos e serviços de conectividade oriundos da rede social.
Atualmente, o Facebook possui cerca de 1,35 bilhão de usuários.
 
Mais informações:http://reut.rs/1ztyD5r

Conclusão

Definitivamente, nem só de baboseira vivem as redes sociais.

Aliás, até as baboseiras que escrevemos são usadas por empresas em campanhas publicitárias para nos entender enquanto consumidores, e assim oferecer aquilo que queremos, ou que não queremos mas podemos ser convencidos de que devíamos querer :)

E você, o que pensa sobre essa movimentação toda ? Te surpreendeu ?
Mais...

segunda-feira, 2 de fevereiro de 2015

[Infográfico] Big Data em Números - O que você precisa saber!

Big Data é o hype do momento, acho que isso todo mundo já sabe.

Ocorre que, mais que um simples modismo, é uma oportunidade.

E que oportunidade!

Oportunidade pras empresas, que tendo acesso a um volume maior de dados, podem fazer análises mais completas e confiáveis.

Oportunidade pra profissionais qualificados, que podem aproveitar a demanda que surge com a novidade (mesmo que não seja tão novidade assim :).

E é pra dar uma idéia mais clara dessa oportunidade que resolvi trazer pra você o primeiro infográfico do Tecnologia que Interessa!, que, baseado nas previsões do Gartner, apresenta números impressionantes, que deixam claro o quanto a tecnologia associada ao fenômeno Big Data está mudando a realidade das empresas.

Confira!


Quero destacar o fato de que, ainda que lentamente, as empresas começam a investir em Big Data aqui no Brasil, e estima-se que este mercado chegue a R$ 1 bilhão até 2018 (este ano R$ 680 milhões).

Nada mal, hein ?

Outra coisa que merece atenção é o fato de que a tecnologia se aplica a qualquer segmento, seja indústria, serviços financeiros, comunicação e mídia ou governo. Observe como o investimento aumenta em ritmo acelerado a cada ano.

Note ainda que os resultados são bem claros: 2x mais chance de aumentar o desempenho financeiro, 5x mais chance de ser mais rápida que a concorrência, 3x mais chance de melhorar o planejamento.

Definitivamente, não dá pra ignorar uma tecnologia que proporciona benefícios como estes, não acha?

Conclusão

Não canso de dizer que Big Data é uma oportunidade pra você, profissional de TI, que quer (precisa?) dar um salto na carreira, saindo na frente, sendo pioneiro e abraçando com todas as forças a inovação.

E eu estou aqui pra ajudar no que puder, basta entrar em contato.

Aproveito pra divulgar a lista Big Data Brasil, que criei há alguns meses pra trocar idéias sobre o tema, e convido você a participar. Já rolaram várias discussões legais por lá!

E então, o que achou do infográfico ? Se curtiu, compartilha aí!
Mais...

terça-feira, 27 de janeiro de 2015

7 anos de Tecnologia que Interessa!

Aniversário 7 anos Tecnologia que Interessa!

E eis que, mais uma vez, é momento de comemorar.

Comemorar o crescimento, amadurecimento, evolução da minha "cria", que hoje completa 7 anos!

Esta "cria" que é motivo de muito orgulho.

Que me proporciona conhecer pessoas, e entender um pouco mais do mundo através da web.

Que me revela oportunidades que nunca imaginei estarem ao meu alcance.

Que me possibilita coisas boas e ruins, ambas importantes para o crescimento pessoal e profissional.

Que, mais importante que tudo, me conecta com você, que agora lê este texto, e que reconhece alguma utilidade no que escrevo e compartilho por aqui.

Mas deixemos de firulas e vamos ao que interessa!

Neste momento de comemoração, quero aproveitar para dizer a vocês o que esperar desse nosso espaço em 2015.

Aliás, quero fazer um agradecimento especial a cada um dos cerca de 2 mil integrantes da comunidade Tecnologia que Interessa!, sejam os participantes da lista Big Data Brasil, os que acompanham por RSS, email ou alunos. Muito obrigado a cada um de vocês!

Se fui obrigado, por motivos alheios à minha vontade, a reduzir a frequência de postagens, tento compensar com mais informação em cada texto.

Por isso, pode esperar em 2015 ainda mais conteúdo

E em diferentes formatos!

*Vamos estar retomando* o podcast :)

Estou trabalhando no primeiro infográfico.

E vamos ter alguns hangouts também, sobre Virtualização, Governança de TI, Big Data, Software Livre, enfim.

Espero que curtam as novidades!

E fiquem à vontade pra sugerir os temas de TI que mais interessam a você! Sou todo ouvidos :)

Aliás, quero finalizar este texto justamente pedindo um pequeno favor a você.

Poderia responder a uma simples perguntinha ? É rapidinho!

Lá vai...

O que você espera do Tecnologia que Interessa! ?

É muito importante pra mim saber que tipo de informação você espera ver aqui, pra ver o que posso fazer pra te atender da melhor maneira possível, dentro das minhas possibilidades, é claro.

Responde aí, por favor. Valeu!
Mais...

Seguidores

Tecnologia do Blogger.