Esta publicação apareceu originalmente no Blog VMware Office of the CTO
Paralelos históricos
O ano de 2014 marcou o centenário do início da Primeira Guerra Mundial: um evento que teve um terrível custo humano e pavimentou o caminho para grandes mudanças políticas e sociais em todo o mundo. O centenário gerou uma onda de retrospectivas em torno dos eventos e das causas que levaram à Primeira Guerra Mundial (ref. The Sleepwalkers: How Europe went to War in 2014, por Christopher Clark, The Guns of August, por Barbara W. Tuchman). Historiadores sugeriram avanços tecnológicos, especialmente em motores e comunicações, tanto como um motivo para a instabilidade geopolítica que precedeu a guerra, quanto como a causa principal da alta taxa de baixas resultante.
Fronteiras da Europa antes e depois da Primeira Guerra Mundial.
Crédito: The National Archives (R.U.)
A Primeira Guerra Mundial transformou a Europa de terra de poderosos impérios em uma colcha de retalhos de pequenas e muitas vezes fracas nações. Nenhuma área da Europa reflete essa mudança mais dramaticamente do que as Bálcãs, onde os impérios Austro-Húngaro e Otomano deram lugar a dezenas de pequenas nações (ref. The Balkans: A Short History, por Mark Mazower). Foi apenas por meio da unificação econômica e estreita colaboração entre as nações resultantes que a Europa finalmente deixou de lado a tensão e os conflitos armados, permitindo que as nações e as pessoas prosperassem (ref. World Order, por Henry Kissinger).
Sem pretender trivializar a importância e o terrível custo da Primeira Guerra Mundial, não consigo deixar de observar alguns paralelos com o setor de armazenamento de dados hoje. Até há poucos anos atrás, esse setor era dominado por algumas grandes empresas (o equivalente aos impérios), que forneciam produtos e soluções de armazenamento à TI empresarial usando abordagens rigorosas e prescritivas: hardware estritamente controlado, receitas bem testadas para software, dois protocolos de acesso a dados – bloco e arquivo. Esse era o modelo para fornecer armazenamento para a então chamada “segunda plataforma” — aplicativos empresariais e automação que seguiam o tradicional modelo cliente-servidor. Era um mundo simples e o controle das grandes empresas era absoluto.
A terceira plataforma
Essa era a ordem mundial até os anos 2000, quando uma onda de rápida evolução tecnológica surgiu para atender às necessidades de aplicativos em escala de nuvem e casos de uso que iam de mecanismos de pesquisa até novos modelos de comércio eletrônico e mídia social. Essa é a era dos onipresentes serviços da Web, big data e técnicas de análise. O motor a combustão e o telégrafo elétrico mudaram a ordem socioeconômica do mundo na virada do século XX. De maneira semelhante, a virada do século XXI testemunhou a rápida introdução de novas tecnologias para armazenamento orientado a aplicativos, inclusive MapReduce, GFS e seus equivalentes de código aberto (Hadoop, HDFS ), assim com uma miríade de bancos de dados de nova geração que desviam do modelo RDBMS tradicional (por exemplo, HBase, Hive, Cassandra, MongoDB).
A terceira plataforma, um termo com definição ampla usado para descrever a coleção de tais tecnologias, estreou nos data centers de grandes empresas de Internet que estão na vanguarda da evolução da terceira plataforma (Google, Facebook, etc.). Logo, ela começou a penetrar os ambientes empresariais mais tradicionais, graças a empresas que a transformaram em seus modelos de negócios (Cloudera, Hortonworks).
No entanto, ao contrário dos sistemas de armazenamento tradicionais, que pertenciam e eram operados por organizações de TI centrais, novas plataformas de armazenamento de dados são instaladas e operadas por linhas de negócios individuais. Elas são usadas para executar aplicativos e cargas de trabalho que estão no centro das necessidades de grupos de produtos e equipes funcionais individuais, seja P&D, análise de mercado, marketing ou finanças. Mesmo nos raros casos em que elas pertencem a organizações de TI centrais, há uma infinidade de plataformas diferentes e desassociadas, uma para cada aplicativo e conjunto de dados.
O resultado é a balcanização dos sistemas de armazenamento de dados: uma infinidade de pools de dados espalhados geográfica e organizacionalmente pela empresa. Cada plataforma tem seus próprios requisitos de configurações de hardware, de modelos SAN tradicionais a arquiteturas distribuídas mais recentes. Elas têm modelos de gerenciamento completamente diferentes, tudo desde gerenciamento manual a APIs programáticas exclusivamente. Elas podem exigir diferentes tipos de habilidades e experiências. E ainda pior, enormes volumes de dados precisam ser migrados frequentemente entre diferentes pools, dependendo de como os dados são consumidos em diferentes pontos de seus ciclos de vida. Por exemplo, dados são extraídos dos bancos de dados Oracle corporativos para clusters Hadoop onde passam por diferentes níveis de filtragem e análise, somente para que os resultados sejam passados para algum banco de dados não-SQL a fim de serem usados para pesquisas e marketing. A evolução de negócios e aplicativos resulta na proliferação do número de diferentes pools de dados — a situação que fica ingovernável. O CapEx e o OpEx fogem do controle e, mais importante para vários negócios, há um impacto sério na governança de dados e na conformidade normativa.
Como no caso do mundo na virada do século XX, a tecnologia vira uma faca de dois gumes.
A esperança da reunificação
Na minha opinião, o setor precisa seguir dois princípios para resolver o problema da balcanização do armazenamento de dados.
1. Plataformas de armazenamento multifacetadas
Com isso, quero dizer plataformas de armazenamento compatíveis com diferentes abstrações de dados e protocolos de acesso: bloco, arquivo, datastores de chave-valor, só para citar alguns. Ainda mais importante, a arquitetura de tais plataformas deve acomodar múltiplas cargas de trabalho com diversas características, todas compartilhando os mesmos recursos físicos (CPU, barramentos, memória, rede, controladores de armazenamento e dispositivos).
Imagine, por exemplo, um cluster de armazenamento baseado em hardware comum em que alguém pode executar o banco de dados de CRM relacional legado, um cluster HDFS virtual usado pela equipe de técnicas de análise de mercado e um banco de dados Cassandra usado para um novo aplicativo móvel voltado para os clientes. A receita para montar tais plataformas inclui três ingredientes principais:
a. Uma tecnologia de virtualização por meio da qual a plataforma pode identificar e controlar as cargas de trabalho dos diferentes aplicativos e “usuários” que compartilham a plataforma.
b. Gerenciamento de recursos de armazenamento e controles de caminhos de dados (agendamento) adaptáveis para atender aos objetivos de qualidade de serviço de diferentes cargas de trabalho sem interferência entre si.
c. Ferramentas de gerenciamento e APIs para aprovisionamento, configuração, monitoramento e solução de problemas que são ortogonais às diferentes abstrações de dados expostas pela plataforma de armazenamento.
2. Serviços de dados avançados
A consolidação de plataformas é necessária mas não suficiente. Para que serve uma plataforma que possa servir nativamente instâncias de datastores RDBMS, HDFS e chave-valor, se ela exige a cópia elaborada e lenta de dados entre essas instâncias? Por exemplo, a cópia de grandes volumes de dados de arquivos e bancos de dados para HDFS para realização de técnicas de análise e depois para algum banco de dados NoSQL resulta em desperdício de recursos de sistema que poderiam estar disponíveis para execução de cargas de trabalho de aplicativos.
A nova geração de plataformas de armazenamento precisa oferecer potentes serviços de dados para manipulação e transformação eficientes de grandes conjuntos de dados. Entre os exemplos estão:
- Tecnologias de snapshot que podem criar de maneira instantânea e barata snapshots de objetos de dados (volumes, arquivos, bancos de dados). Tais snapshots podem ser usados como conjuntos de dados somente leitura para processamento em mecanismos de técnicas de análise ou como cópias mutáveis (clones) para teste, desenvolvimento e pesquisa. A redução da área de cobertura da capacidade dos dados com mecanismos como a eliminação de duplicação ou a compressão é de fundamental importância nesse contexto.
- Cópias de pontuais no tempo podem ser distribuídas e armazenadas em diferentes locais físicos para proteção de dados e recuperação de desastres. Ao mesmo tempo, oferecendo serviços de metadados para garantir que os dados sejam rastreáveis e auditáveis.
- Primitivas de segurança unificadas para controle de acesso, integridade e criptografia de dados, que se aplicam a diferentes abstrações de dados e protocolos de acesso.
- Serviços de dados que habilitam aplicativos, como o recente recurso AWS Lambda da Amazon, que permite que os desenvolvedores escrevam aplicativos dinâmicos, orientados a eventos, que se adaptam a mudanças e transformações em seus conjuntos de dados. Você pode imaginar serviços semelhantes em torno de metadados para proveniência, segurança e auditoria de dados. Além disso, o conceito de função lambda pode ser estendido para oferecer suporte a um modelo de execução de código no local físico dos dados, por motivos de desempenho ou soberania de dados.
Tais serviços de dados serão oferecidos por meio de APIs programáticas que serão úteis não apenas em ferramentas de automação, mas ainda mais importante nessa era, em aplicativos projetados em torno de transformações e processamentos de dados.
Prevendo o futuro
Levou boa parte do século XX para que as nações europeias atingissem um equilíbrio em que as identidades e os interesses nacionais individuais coexistissem em uma economia e um mercado unificados. (É possível argumentar que as Bálcãs ainda têm um caminho à frente.)
De forma semelhante, o caminho da consolidação e da unificação do armazenamento não será rápido nem fácil. Os participantes da nuvem pública estão desbravando a trilha. Eles ensinam ao setor lições valiosas por meio de seus bastante divulgados sucessos e fracassos. No espaço empresarial (ou na nuvem local, como algumas pessoas gostam de chamar a laaS semelhante a nuvem privada construída em grandes empresas) teremos que viver com ilhas de armazenamento de dados ainda por um longo tempo. No mínimo, a tendência está acelerando.
No entanto, prevejo que nos próximos anos, as organizações de TI vão começar a reconsiderar a situação. As despesas operacionais e os requisitos de governança de dados vão forçá-los a dominar os pools de dados em dispersão.
Eu vejo algumas maneiras óbvias de como as coisas vão evoluir. Como eu previ no passado, o futuro do armazenamento é definido por software. Arrays de disco “parrudos” vão seguir o mesmo caminho dos impérios europeus do século XIX. O hardware, inclusive tecnologias de armazenamento emergentes, será comoditizado — suas propriedades e interfaces serão maduras e estáveis. O valor agregado vem do software. As soluções de armazenamento da terceira plataforma são todas implementadas em software em processamento e redes comoditizados. O software distribuído é o ingrediente principal das plataformas de armazenamento com níveis sem precedentes de dimensionamento e tolerância a falhas. Os serviços de dados (descritos acima) e as APIs programáticas para gerenciá-los são todos ligados ao software que permite que aplicativos legados e de nova geração coexistam nas mesmas plataformas consolidadas; plataformas que oferecem suporte a diversos protocolos e abstrações de dados.
Desejo expandir a questão das APIs programáticas ainda mais. A nova geração de aplicativos será criada em torno de um modelo de composição e transformação de dados dinâmicas. Tais APIs não são apenas a interface para o “plano de controle de armazenamento”. Elas são primitivas essenciais da terceira plataforma. Elas facilitarão o desenvolvimento de aplicativos orientados a dados com escala e sofisticação sem precedentes. As funções lambda são o prenúncio do que está por vir.
O que tudo isso significa para as plataformas do futuro? Os fornecedores de armazenamento se dividem atualmente em grupos distintos: a) plataformas de bloco/arquivo tradicionais que são estendidas superficialmente para exportar as ocasionais APIs REST ou o protocolo HDFS; b) uma confusão de diferentes projetos de código aberto, muitas vezes concorrentes, cada um voltado para casos de uso específicos. Poucas plataformas existentes têm arquiteturas que podem oferecer suporte eficiente a diferentes abstrações de dados e serviços de dados genéricos. Algumas delas usam uma abstração de objetos internos genérica em torno da qual os serviços de dados são implementados; diferentes “personalidades” de dados e protocolos são postos em camadas sobre objetos (por exemplo, RADOS, VSAN, Atmos). Outras se baseiam na abstração básica de um arquivo (por exemplo, GFS, Isilon), sem necessariamente a tradicional semântica POSIX e namespace sugeridos pelos sistemas de arquivos.
Os fornecedores têm um longo caminho para evoluir suas plataformas para o modelo emergente do armazenamento da terceira plataforma. Lições serão aprendidas de provedores de nuvem e da comunidade de código aberto. Em alguns casos, as tecnologias de código aberto serão integradas a plataformas mais tradicionais. Em outros casos, as plataformas evoluirão nativamente. Em última instância, produtos consolidados serão criados para o público geral de TI, de uma maneira ou de outra. Passaram-se várias décadas após a Primeira Guerra Mundial e muitos tratados diferentes para estabelecer uma estrutura política e econômica para uma Europa pacífica e próspera. De forma semelhante, é hora de o setor de TI investir nas arquiteturas de armazenamento certas e preparar-se para a nova era dos agrupamentos de armazenamento de dados.
Para obter mais informações sobre a VMware, acesse nosso site no Brasil. Você também pode nos seguir no Facebook, no Twitter, e no Youtube para receber as notícias mais recentes sobre a VMware.
Contatar o departamento de vendas aqui.
