Pensando em usar OpenStack com bare-metal? Você precisa conhecer o RackHD!
Dentre os diversos projetos que compõe o Openstack, o Ironic é o responsável pelo provisionamento e controle de hardware (servidores x86). Mas quem já teve a oportunidade de trabalhar com esse projeto, sabe que ele não é nem um pouco simples de ser utilizado e muitas vezes requer muita customização e até um pouco de (muito?) desenvolvimento para que ele consiga entregar servidores de forma automatizada.
Então se você pretende automatizar e orquestrar o gerenciamento de servidores, você deveria olhar um projeto recentemente lançado pelo EMC{code}, chamado RackHD!
O RackHD, pode ser integrado com o Openstack/Ironic (através de um módulo chamado Shovel), ou com outras soluções como Ansible ou Puppet (ou virtualmente qualquer outro orquestrador/automatizador do mercado que você esteja disposto a fazer a integração).
O principal objetivo do RackHD é aportar funcionalidade e simplicidade no gerenciamento de hardware físico da sua infraestrutura.
E vale ressaltar que o Rack HD NÃO é um produto! É código aberto que você pode baixar, usar e alterar como quiser! (e contribuir de volta para a comunidade, é claro!)
Quer entender um pouco mais? Dá uma olhada nessa demo:
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).
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. :)
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.
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:
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.
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.
Assinar:
Comentários (Atom)