Análises de Mercado: O que fazer e o que não fazer


Eu pensei muito em um título para esse post. O título original era algo como “Não deixe que os outros pensem por você”, mas achei que alguns leitores poderiam se ofender com isso e realmente não é uma questão de deixar os outros pensarem em você, mas como usamos o conhecimento desenvolvido por outros para construir a nossa própria visão sobre determinado assunto. 

Além disso, poderia parecer que eu estava contra o trabalho de empresas como o Gartner, IDC, Forrester e outras, o que também não é o caso. Tenho um grande respeito pelo trabalho dessas empresas, acho que elas prestam um enorme serviço aos nossos clientes e conheço pessoas geniais em todos os lados desse relacionamento (vendors, analistas e clientes).

Então, afinal, qual o motivo desse post? O motivo é ajudar a – esperançosamente – melhorar um pouco a forma com que todos nós usamos essas análises de mercado. 

Atualmente funciona mais ou menos assim: Sempre que surge uma análise (pode ser um Gartner Magic Quadrant, um IDC MarketScape, um Forrester Wave, ou qualquer outra análise que você imaginar), imediatamente os vendors se dividem em 2 grupos: Aqueles bem avaliados que vão colocar essa análise em todas as apresentações para clientes e aqueles que não foram tão bem avaliados assim, que vão expor suas mais diversas justificativas de porque não foram bem avaliadas. (estou apenas expondo o modelo e não estou fazendo crítica a nenhuma empresa). 

E esse modelo é errado! Um vendor/solução é muito mais do que simplesmente um ponto ou um círculo em uma imagem, então, sem mais delongas, vamos a nossa lista de Faça ou Não Faça:


Não Faça:

  • Não fique apenas na figura de resumo. Por exemplo, um Magic Quadrant do Gartner tem, em geral, mais de 25 páginas. Apesar da figura do quadrante ser uma síntese interessante, o documento tem muito conteúdo relevante e explicativo no documento, com o PORQUE da classificação de cada solução.
Nota: Felizmente, na maioria das vezes, a EMC está bem posicionada nessas análises. Depois de combinadas, Dell+EMC estarão no quadrante dos líderes em 22 “Magic Quadrant” do Gartner.
  • Não tome nenhum documento como verdade absoluta sobre uma tecnologia. Lembre-se que o analista, por mais inteligente e agnóstico que ele seja, ainda é uma pessoa (ou grupo) expondo sua visão sobre determinado tópica. Reflita o PORQUE dos pontos levantados no documento e o que significam para você, a sua empresa e a sua estratégia. 
  • Não use análise patrocinadas que COMPAREM vendors. Quase sempre são análises tendenciosas.


Faça:

  • Entenda que existem dois tipos de análise: as de Market Share – baseadas em dados concretos* e demonstram qual vendor está com a melhor estratégia de vendas (qualidade do produto, preço adequado, propaganda bem executada, cobertura de mercado, etc) e as análise de produto/vendor – essas em geral bem mais discutidas, falam dos aspectos técnicos e características das soluções.
* quando os vendors não são empresas públicas eles não têm obrigação de divulgar seus números. Isso torna o trabalho dos analistas mais difícil, tendo que estimar os números de vendas o que algumas vezes leva a erros como aconteceu recentemente com o Market Share to Gartner para All-Flash-Array. (não é uma crítica nem ao Gartner nem a Pure. Apenas estou ilustrando um exemplo de que empresas de análise também são feitas por humanos, e como tais sempre sujeitas ao erro)
  • Se seu vendor preferido não está bem posicionado em uma análise, pergunta a ele o PORQUE (aliás, o PORQUE é uma palavra poderosíssima que usávamos muito na infância, mas quando adultos acabamos tendo medo de usar essa palavra tanto quando deveríamos)
  • Entenda o contexto e momento no qual o documento foi escrito, especialmente para soluções novas, nas quais o mercado ainda está em formação, se movendo muito rápido e ainda não há uma definição clara de quais características fazem uma solução melhor que a outra.

Por fim, talvez o item mais importante da lista: eleja os vendors que você quer que façam parte do futuro da sua empresa (por cultura, tecnologia, qualidade, visão) e crie PARCERIAS duradouras. Desenvolva entre esses vendors os seus trusted advisors. Pessoas que você possa realmente confiar, que não queiram só te vender um produto, que querem o que é melhor para sua empresa e que poderão te ajudar a montar sua estratégia para a TI.


Indisponibilidade da AWS: cuidado com as conclusões erradas



Para aqueles que não viram, alguns serviços da AWS ficaram indisponíveis no dia 20/Set (http://status.aws.amazon.com/) afetando alguns clientes famosos, como Netflix, Airbnb, IMBd e Tinder. (para esse último, felizmente o downtime foi no domingo... se fosse no sábado a noite poderia ter estragado o final de semana de vários solteiros)

Nos próximos meses essa notícia vai ser ecoada, de forma mais ou menos sutil, entre outros provedores de nuvem pública ou privada, como uma forma de alegar que as aplicações não estão seguras na AWS e que os clientes deveriam migrar para a solução de Cloud “A” ou “B”, ou dizer que a solução segura é na nuvem privada.

E essa é simplesmente a conclusão ERRADA sobre o problema... que atire a primeira pedra quem nunca teve um downtime :)

Então que conclusões, ou melhor ainda, que lições podemos aprender com isso?

1. Tenha um catálogo de serviço que inclua também informações como nível acordado de serviço para cada serviço/aplicação (ITIL). Essa informação já constitui o primeiro filtro para saber AONDE colocar essa aplicação. Nuvens publicas possuem SLA definidos para seus serviços como por exemplo, AWS ECS: https://aws.amazon.com/ec2/sla/ e Azure Virtual Machine http://azure.microsoft.com/en-us/support/legal/sla/virtual-machines/v1_0/

Se o SLA oferecido não atende os seus requisitos você precisa buscar outras soluções, como por exemplo: cluster entre múltiplos Availabilities Zone (no caso da AWS), ou usar uma private cloud – desde que você consiga montar um ambiente com SLAs melhores e esteja Ok com esse custo – lembrando que quando disponibilidade tende a 100% o custo tende a infinito. :)




2) Tenha sempre um plano de fuga! Se por qualquer razão (custo e/ou qualidade de serviço) determinada solução – no caso, provedor de nuvem pública – não atender mais as suas necessidades, como fazer para portar as suas aplicações para outro lugar?



Infelizmente não existe a Portabilidade Universal de Nuvem e algumas nuvens são muito mais difícil de sair!

Esse é outro fator relevante na escolha da solução ou do seu CSP (Cloud Service Provider). Por exemplo, eu escrevi AQUI, sobre a preocupação das empresas sobre diminuir o grau de dependência dos vendors de infraestrutura, porém como diminuir a dependência com provedores de nuvem publica?

Por definição, uma empresa não pode construir a sua própria nuvem publica, mas você pode escolher um provedor que te dê mais flexibilidade/mobilidade dos workloads.

Essa mobilidade pode acontecer na camada de Infraestrutura (VMs) e em geral envolve compatibilidade de hypervisors. Por exemplo, se você escolher o Azure como sua nuvem publica, você poderá mover workloads entre o Azure e uma infraestrutura privada, baseada em Hyper-V. Idem para nuvens públicas baseadas no vCloud Air e hypervisor VMware.

Outra opção, pelo menos para parte de suas aplicações, é adotar o conceito das Cloud Native Applications, aplicações menos dependente da infraestrutura. (tradicional, virtualizada ou “as-a-Service”), que podem ser portadas facilmente entre nuvens (escrevi um pouco sobre isso AQUI).

Em resumo, conheça/defina os SLAs para as suas aplicações, analise as ofertas de mercado (não existe solução única para tudo), e tenha sempre um plano de fuga!


Fazer ou Comprar?



Essa é uma pergunta antiga, em geral associada ao mundo de desenvolvimento de software, quando empresas avaliam se deveriam comprar um novo software de um fornecedor estabelecido no mercado ou desenvolver um novo aplicativo “in-house” (com ou sem o uso de fábricas de software).

Porém, nos últimos meses tenho tido várias conversas com clientes que estão passando pelo mesmo dilema, só que em outras camadas como INFRAESTRUTURA, CLOUD, BIG DATA, etc. Isso acontece pelo crescimento de algumas novas tendências como, por exemplo:
  • Adoção de software livre, como o Openstack (mencionado AQUI)
  • Crescimento de arquiteturas Convergentes (discutido AQUI)
  • Uso de tecnologias de virtualização de outros componentes da infraestrutura, como rede e storage. (Openvswitch, NSX, ScaleIO, Cepth, ECS, etc) (mencionado AQUI)

Mas qual caminho seguir?



O lado do “faça você mesmo”, significa adotar menos soluções prontas de fornecedores, como hardware whitebox (Open Compute Project) e investir em soluções de software open source “vanilla”. 

Vantagens: Independência de fornecedores, maior flexibilidade da sua infraestrutura para atender requisito de negócio 

Desvantagens: Necessidade de criação e manutenção de um time técnico grande e altamente especializado. Problemas inerentes ao desenvolvimento de novas soluções, como uma maior instabilidade. 

O outro caminho como podem imaginar, significa adotar soluções prontas, preferencialmente envolvendo o menor número possível de fornecedores. A solução torna-se simples e fácil de ser implementada, gerenciada e suportada. A empresa pode ter uma equipe de TI enxuta e manter a eficiência operacional. Mas a escolha de uma solução ruim ou a escolha do fabricante errado pode trazer consequências, como aumento elevado de custos e rigidez para utilizar novas tecnologias que tragam benefícios aos negócios.

Felizmente essa não é uma questão de “OU” (o caminho A OU B). É mais uma questão de qual lado começar a botar mais peso. 


Mas em qual lado colocar mais peso? Alguns Para isso é preciso fazer uma análise da infraestrutura e soluções, determinar a maturidade do mercado, grau de dependência a abstração dos componentes e até mesmo a estratégia de cada CIO e sua visão para sua área de TI.

Vamos exercitar rapidamente alguns exemplos:
  • Servidores: Dificilmente justifica-se construir o seu próprio servidor. É um componente aonde a abstração de camada de virtualização torna mais fácil a substituição de componentes. As empresas e as pessoas já estão acostumadas a gerenciar estes componentes. 
  • Storage: Está no meio do caminho. Algumas arquiteturas já permitem uso de hardware commodity + software para que as empresas montem seu próprio storage. (Ceph, VSAN, ScaleIO e ECS por exemplo). Mais em muitos casos as empresas ainda não estão prontas para terem que gerenciar por conta própria múltiplas camadas e fornecedores (hardware e software) para manter o storage funcionando. 
  • Soluções de IaaS e PaaS, surgiram com as empresas tentando montar suas próprias soluções (usando componentes dos mais diversos fabricantes (servidor, rede, storage, orquestrador, element managers, portal, automatizador, etc) e o que a maioria das empresas está descobrindo é que quanto mais partes, mais difícil é o “Faça você mesmo” (como eu comentei um pouco AQUI). Por isso estão surgindo soluções, como o EHC, que é uma “Cloud in a Box”, justamente para tentar entregar os benefícios de uma nuvem, de uma forma simples e rápida. 

E a lista vai longe, como banco de dados (Exadata), e em níveis diferentes como uso de soluções open source "produtizadas", como Cloudera & Hortonworks para big data/hadoop.

Não existe um caminho óbvio. Para cada componente e para cada empresa a resposta pode ser diferente e pelo menos por enquanto o mercado não mostra uma tendência maior para nenhum lado. 

Como sempre tento fazer posts curtos (a regra é que dê para ler em 10 minutos), mas é claro que com isso não dá para abordar todos os aspectos de um tema. Quer acrescentar algo? Descorda de algo? Comentários são *sempre* bem-vindos!




DevOps ou "a próxima onda da TI"


Quem trabalha com TI há alguns anos já deve ter percebido que a TI vive de ondas. Mainframes, arquiteturas cliente-servidor, Cloud Computing, Big Data, e agora... DevOps.
(não quer dizer que a tecnologia de uma onda seja necessariamente nova ou que substitua a onda anterior)

Cada onda surge por uma confluência de amadurecimento tecnológico, surgimento de novos fornecedores/soluções e necessidades das empresas. E cada onda está sempre sujeita a um ciclo de maturidade próprio, como o do gráfico abaixo: tudo começa com uma grande expectativa que essa nova onda irá resolver todos os problemas, depois existe uma "vale das desilusões" quando percebe-se as limitações e descobre-se novos problemas e desafios da nova onda, até chegar no platô da produtividade, quando o mercado atinge a maturidade de produtividade usando as tecnologias da nova onda.



O objetivo básico de DevOps é otimizar o desenvolvimento de softwares e a entrega de novos serviços pela TI, através de uma maior integração entre a área de desenvolvimento e a área de operação, com um número maior de interações entre as áreas, permitindo entregas frequentes de software.

Junto com DevOps surgem novos termos, arquiteturas & conceitos a serem estudados, debatidos e implementados:
  • TI Bimodal (Gartner) e Terceira Plataforma (IDC), ambos abordados brevemente AQUI.

  • Containers (como Dockers) com todo seu ecosistema (como Mesos e Kubernetes)  

  • Plataformas de PaaS (como CloudFoundry)

  • Infraestrutura definida por software

  • Cloud Computing (inclusive com uso mais eficiente de nuvem pública) 

  • Novos modelos de desenvolvimento de aplicações, as chamadas "Cloud Native Applications" ou "CNA" (quem não adora um novo acrônimo!). Eu já havia coloca um livro muito legal sobre o tema AQUI. Sobre esse tema vale também a leitura deste excelente SITE, listando os 12 fatores para aplicações modernas, como por exemplo:
    • o uso de micro-serviços
    • Stateless application servers
    • Setup do ambiente de aplicação de forma declarativa e automatizada
    • Repositório central de código
    • Menor ou nenhuma dependência da infraestrutura
Muitos dos temas listados acima se complementam. Apenas para citar alguns: a adotar algumas das premissas da TI Bimodal é importante para que as empresas possam acelerar seu ciclo de desenvolvimento e aproveitar as vantagens do uso de "Cloud Native Applications". Desenvolver "Cloud Native Applications" considerando os "12 fatores" é importante para que as empresas possam utilizar nuvem pública com todo seu potencial de benefício... e a lista segue com os demais componentes.


Como sempre tento fazer posts curtos (meu objetivo é que você possa ler em menos 10 minutos), mas mas com isso não dá para abordar todos os aspectos de um tema. Quer acrescentar algo? Descorda de algo? Comentários são *sempre* bem-vindos!




EMC Forum




Na semana passada (26/Ago) foi o EMC Forum Brasil, com mais de 1.200 participantes!



Muita coisa legal, como a palestra do Doug Cutting, criador do Hadoop!

Eu fiz uma palestra também - muito mais modesta :) - falando sobre a solução AFA (All Flash Array) da EMC, o XtremIO, e os impactos dessa solução para as aplicações e a infraestrutura do Data Center ágil.

Para quem não pode ir e quiser ver a apresentação, clique aqui.

Big Data pra crianças



Para aqueles me conhecem sabem que eu sou um palestrante de diversos eventos de TI. Desde pequenos grupos de executivos como no CIO Brasil ou IT Forum até para centenas (milhares?) de participantes como no VMware vForum.

Para quem já teve a oportunidade de palestrar para um grupo (não importa o tamanho), sabe do desafio. Definitivamente não é algo fácil. (Dizem que algumas pessoas têm mais medo de falar em público do que da própria morte)

Mas essa semana eu tive um desafio bem diferente – e para ser honesto, até um pouco mais assustador: fazer uma palestra de Big Data para duas turmas da 6ª série do ensino fundamental. :) Olha a galerinha aqui:


 






Foi um misto de apresentação (é difícil montar um powerpoint tentando imaginar como a mensagem vai aterrissar na mente de uma criança) + vídeo + jogo interativo para tentar mostrar o que é Big Data e como isso está mudando o mundo em que vivemos.

É interessante notar a diferença no comportamento das crianças com relação aos adultos: as crianças sentam nas primeiras fileiras e interagem muito, perguntando, tentando criar as analogias delas para entenderem os conceitos e compartilhando as experiências delas. Se isso fosse uma palestra para adultos provavelmente teríamos todos sentados no fundo, a maioria sem perguntar nada (mesmo que não estivesse entendendo) e provavelmente checando esporadicamente os e-mails no celular. Particularmente o modelo das crianças me parece melhor. :)

Abaixo as fotos do Joel Brawerman explicando Big Data e uma foto minha tentando organizar o jogo :)






E o resultado? As crianças adoraram (com crianças você sabe imediatamente se elas gostaram ou não) :) e foi uma experiência absolutamente incrível! As crianças passam uma energia revigorante!



Quem quer um storage grátis?


Quer criar uma camada de storage definido por software, utilizando hardware commodity de servidores já existentes no datacenter para criar uma camada de armazenamento sem hardware dedicado?

Quer criar uma solução hiperconvergente (mais informações aqui)?

E que tal um storage que pode fazer mais de 10.000 milhões de IOPS usando servidores x86?


A EMC está oferecendo o ScaleIO, ILIMITADO e SEM RESTRIÇÕES. Só clicar no link, fazer download e usar: http://www.emc.com/storage/scaleio/index.htm


E para completar a solução, você pode baixar uma controladora de software para gerenciar todo o seu ambiente de armazenamento (baseado em ScaleIO, ou storages tradicionais da EMC ou de outros fabricantes como NetApp, HP, IBM, etc).

O CoprHD, disponível sem custo aqui, é a versão software-livre do ViPR. (por exemplo, pense no Fedora, a versão livre do RedHat Enterprise Linux)


Obs: Para o CoprHD, diferentemente do ScaleIO, a EMC está liberando o código do produto, dentro do MPL 2.0 (https://www.mozilla.org/MPL/), ou seja, se quiser pode escrever código e complementar alguma funcionalidade do produto, que seja particular ao seu ambiente!

Livro GRÁTIS: Migrating to Cloud-Native Application Architectures


Muito tem se falado sobre a Terceira Plataforma, TI Bimodal, DevOps, mas ainda são termos recentes e que muitas vezes ainda são difíceis de serem contextualizados ou completamente entendidos por todos nós, profissionais de TI que vivemos a TI da Segunda Plataforma, de aplicações cliente-servidor.

A Pivotal está disponibilizando de forma gratuita o livro Migrating to Cloud-Native Application Architectures, explicando um pouco dessa transformação do modelo de desenvolvimento de aplicações. Assim como o próprio conceito de DevOps, essa é uma leitura para todos os profissionais de TI - desenvolvedores ou não.

Vale a leitura: http://pivotal.io/platform-as-a-service/migrating-to-cloud-native-application-architectures-ebook

EMC World vLabs




Esse post não é para falar das novas tecnologias anunciadas no EMC World (para isso teremos outros posts – não esqueça de se cadastrar para acompanhar o blog por email ou RSS).

Esse post é para falar sobre os vLabs – laboratórios virtuais para os participantes do EMC World testarem na prática todas as tecnologias da EMC.

Esse ano foram mais de 3.000 vLabs!!!

Apesar de não mostrarem necessariamente tendências para o futuro das empresas, eles dão uma ideia dos principais temas de interesse dos participantes do EMC World. E pra mim não foi nenhuma surpresa os líderes da lista:
  • AFAs (All-Flash-Array) com XtremIO; 
  • SDDC (Software-Defined Data Center), com ViPR, NSX e ScaleIO;
  • VMAX & VNX - afinal, é um evento da EMC :)
  • Data Protection
  • HyperConverged Infrastructure com VSPEX Blue
  • Integração com VMware e Openstack





O vLabs ficam disponíveis durante TODO O ANO, 24x7 e SEM CUSTO. Se você é um parceiro EMC, acesse http://portal.demoemc.com / Se você é um cliente EMC fale com o seu representante.



Visões do Gartner Data Center Conference



No começo de abril, tivemos em São Paulo a Conferência Gartner Data Center, Infraestrutura e Operações de TI.

Esse texto é sobre as principais mensagens trazidas pelo Gartner:


1. TI BIMODAL, com modo 1 sendo a TI tradicional e o modo 2 sendo a TI voltada a inovação.
Em resumo:
  • Modo 1 é onde rodam os sistemas de registro e de manutenção das operações. Aqui ficam os bancos de dados, aplicações e web servers tradicionais, altamente dependentes de resiliência de infraestrutura.
  • Modo 2 é onde rodam seus sistemas de inovação e diferenciação da concorrência. Aqui ficam as aplicações desenvolvidas em PaaS, com microservices, containers, stateless run e com resiliência nativa da aplicação ou da plataforma.
  • Chama-se BIMODAL, por serem quase duas TIs totalmente distintas. Com distintos requisitos de governança, infraestrutura, modelo e arquitetura de aplicações.
  • Criar esse ambiente de inovação rápida é fundamental para a sobrevivência das empresas, mas pela razão escrita acima, boa parte das empresas vai falhar na sua tentativa de implementar a TI BIMODAL 
A imagem abaixo mostra uma ilustração rápida da diferença entre aplicações “Modo 1” e “Modo 2”. Rodar aplicações Modo 1 em plataforma Modo 2, em geral, leva a catástrofes de disponibilidade. Rodar aplicações Modo 2 em plataforma Modo 1, em geral, leva a desperdício de recursos e difícil elasticidade. Entender essa diferença é fundamental para poder planejar sua infraestrutura de forma correta.



O IDC cobre o mesmo tema, mas com uma nomenclatura diferente, referindo-se a SEGUNDA e TERCEIRA plataforma. Acho que vocês já viram esse gráfico aqui:



2) OSS (Open Source Software) vai crescer e se tornar uma parte importante e estratégica da TI corporativa (muito alinhado ao MODO 2). Os principais pontos
  • Por que? Evitar o VENDOR LOCKIN e REDUZIR CUSTOS 
  • OSS não é sinônimo de Software Grátis. Apesar destes terem distribuições sem custo, as empresas devem optar pelas distribuições pagas com suporte dos vendors 
  • Para os vendors de tecnologia isso vai trazer um desafio financeiro, forçando-os e evoluir como “Software Providers” 


3) Decisões de arquiteturas devem ser feitas baseadas em TCO, ao invés de considerar simplesmente o preço de aquisição. Por exemplo, quando falamos de um servidor básico, o SO é responsável por apenas 25% do custo total desse servidor. A maior fatia, 50% fica com custo de pessoal para administrar esse servidor. Com isso será que vale a pena optar por um OS com licença mais barata, mas que seja mais difícil (ou caro) encontrar mão-de-obra para administrá-lo? (não é uma pergunta retórica, já que a resposta pode variar para cada empresa. A pergunta é apenas para conscientizar da importância desse tipo de análise). O mesmo vale para todo o stack da TI, como aplicações, bancos de dados, e até mesmo cloud.





4) Cuidado com o “BYO - Faça você mesmo”. (ligado também a questão de TCO). Sempre existe uma “escala mínima” para compensar BYO. Isso vale para tudo, desde construir um datacenter até construir seus próprios servidores – mas a escala muda, dependendo do que se está analisando. Você não é o Google ou Facebook, então pare de tentar fazer igual a eles. (ok, eu admito que essa última parte é “interpretação extensiva” minha)



5) O futuro do datacenter passa por Software-Defined Data Center e Integrated Systems
  • SDDC vai permitir o surgimento de novas arquiteturas como a HYPERCONVERGENTE (já abordada em outro blog meu). 
  • SDDC vai permitir a redução da complexidade operacional do datacenter, reduzindo o TCO. 
  • Integrated Systems vai permitir a redução da complexidade de toda a cadeia de TI (arquitetura, aquisição, operação e suporte), aumentando SLAs e reduzindo o TCO. O Gartner também mostrou seu quadrante mágico:




6) O preço da nuvem pública vai continuar caindo, obrigando os fornecedores (e as equipes de TI) a serem mais criativas



7) IoT vai crescer, impulsionar ainda mais Big Data, e trazer novos desafios para a TI.



8) As empresas devem buscar reduzir custos de I&O (Infrastructure & Operations). (também para permitir aumentar investimentos na TI MODO 2).

























Discussão sobre Infraestrutura Convergente



Infraestrutura convergente - ou na sigla em inglês CI (Converged Infrastructure) – tem ganhado interesse do mercado, tanto de fornecedores de soluções quanto de gestores de TI. Uma prova disso é a estimativa do IDC do crescimento vertiginoso desse tipo de solução, formando um mercado de quase 18 bilhões de dólares até o final de 2016. Isso significa que uma parcela significativa da infraestrutura dos datacenters será convergente.








E como todo conceito/termo (relativamente) novo, CI ainda está em formação, evoluindo a cada dia. Além disso, sempre existirão discussões sobre como o produto X ou Y deve ser classificado... haja visto, por exemplo, que há mais de uma década se discute sobre definição de storages highend e midrange :) 

Aviso: a partir daqui é a minha interpretação do que tenho visto no mercado com relação a CI. 

Para começo é preciso saber que existem vários tipos de Infraestrutura Convergente. Da figura abaixo, os 3 tipos de esquerda (em contorno azul) são mais tradicionais/antigas, já mais consolidadas no mercado. As da direita, em cinza, são as mais inovadoras.



A variedade dos tipos de CI, reflete a complexidade das empresas e da TI moderna que precisa suportar diversos tipos de sistemas e aplicações. (sem falar da mudança que TI está sofrendo entre P2 e P3, mas isso é assunto para outro post)

Com isso cada tipo de CI tem seu uso mais indicado, com seus prós e contras.



Além de todos os aspectos mencionados, existem mais 2 pontos importante de serem comentados:

1) Arquiteturas “Hyper-Convergentes”: São arquiteturas que usam caixas (servidores) com camadas de softwares para fornecer os componentes de uma infraestrutura (processamento, armazenamento e rede). A descrição se assemelha ao “Common Modular Building Blocks”, porquê esse tipo de CI demanda uma arquitetura hyper-convergente, mas uma arquitetura hyper-convergente pode existir dentro de outros tipos de CI, como “Integrated Reference Architecture” e “Integrated Infrastructure”. Por isso o modelo hyper-convergente é um sub-tipo para arquitetura de TI. 

2) BYO (Build Your Own) ou Faça Você mesmo é quando a TI decide montar sua própria infraestrutura convergente. Nesse caso, o que o time da TI fez foi montar uma infra tradicional, não-convergente. 
Mas para complicar um pouco mais as coisas: uma empresa não pode montar uma arquitetura BYO hyper-convergente (usando por exemplo, vSphere, ScaleIO ou VSAN e NSX)? Claro que pode, mas não teria nenhum dos aspectos de simplicidade, suporte, etc que eu mencionei assim. Essa arquitetura teria os mesmos prós (total liberdade de escolha e flexibilidade) e contras (alta complexidade operacional) de uma implementação tradicional de infraestrutura. Por isso que eu disse que hyper-convergente é apenas um sub-tipo para arquiteturas de TI e não um modelo de CI. Talvez de arquiteturas “hyper-convergentes” fossem chamadas de arquiteturas “completely software-defined”, teríamos menos confusão de nomes.

Em resumo, CI vai mudar a forma de TI montar sua infraestrutura, é importante entender os modelos, os players (Gartner e IDC já tem estudos sobre o tema) e montar a sua estratégia!



VSPEX Blue


No ano passado eu escrevi aqui sobre o anúncio de arquitetura hyper-convengente da VMware, o EVO:RAIL.

Esse ano, durante do VMware Partner Exchange, a EMC anunciou o VSPEX BLUE. Appliance hyper-convergente baseado na tecnologia do EVO:RAIL. 

O principal valor do VSPEX Blue é a simplicidade! Compra, instalação, operação e suporte são simplificadas ao máximo! Por exemplo, toda a configuração feita através de wizards e em 15 minutos o appliance já está pronto para receber a primeira VM! Isso faz o EVO:RAIL (e por consequência o VSPEX BLUE ideal para pequenas/médias empresas ou para escritórios remotos)



Cada appliance da figura acima tem 2 Us, 4 servidores e discos que são utilizados para criar uma SAN Virtual, comportando aproximadamente 100 VMs (dependendo obviamente do tamanho da VM). Cada cluster pode crescer até 4 appliances (16 servers no total).

Os detalhes de hardware do appliance são muito similares entre todos os fornecedores que seguem a matriz do EVO:RAIL, por isso a EMC investiu em tecnologias de software para diferenciar o VSPEX Blue:

  • Integração ao EMC Secure Remote Services (ESRS). Mesmo sistema utilizado por toda a nossa linha de storage, que permite ao appliance reportar automaticamente falhas e permite ao suporte EMC tomar ações proativas de reparo dos equipamentos. Com base em pesquisa feita com clientes EMC que usam ou não o ESRS, identificou-se que o ESRS aumenta a disponibilidade média dos sistemas em 15%, além de permitir um tempo de resposta do suporte até 5x mais rápido

  • RecoverPoint for VM, totalmente integrado ao kernel no VMware, permite a replicação individualizada de VMs entre localidades distintas e recuperação simplificada das VMs. 

  • Integração com vSphere Data Protection Advanced (VDPA), baseado em tecnologia Avamar, permite backup das VMs e de algumas aplicações utilizando algoritmos de desduplicações extremamente eficientes, podendo utilizar como repositório dos dados um appliance Data Domain local ou remoto. 

  • CloudArray: é a solução da EMC que permite, através de uma camada de cache inteligente, o uso de storage em nuvem (Amazon, Google, Azure, entre outros), como storage tradicional CIFS, NFS ou iSCSI. 

  • VSPEX Blue Marketplace: mesmo conceito de uma Google Play ou Apple App Store. É uma aplicação que permite aos clientes comprarem soluções aderentes do VSPEX Blue, sendo estas da EMC ou de parceiros homologados. 

  • VSPEX Blue Manager: gerenciador que junta tudas as funcionalidades do VSPEX Blue em uma console simples e fácil. 

O resultado fial é esse :) -




Para mais informações, acesse http://www.emc.com/vspex e https://community.emc.com/community/partner/vspex/vspexplus



Se quier saber mais sobre Infraestrutura Convergente, esse post vai te ajudar!