Dados grandes, NoSQL e Google versus AWS

The Serverless Superheroes Series com Lynn Langit

Bem-vindo ao "Serverher Superheroes"!
Neste espaço, converso com os fabricantes de ferramentas, inovadores e desenvolvedores que estão navegando no mundo novo e corajoso de aplicativos de nuvem "sem servidor".

Para a edição de hoje, conversei com Lynn Langit, um grande arquiteto de dados e nuvem. Lynn é um especialista no desenvolvimento do Google Cloud, um AWS Community Hero e um antigo funcionário da Microsoft. A seguinte entrevista foi editada e condensada para maior clareza.

Forrest Brazeal : A maioria das pessoas que conheço foca apenas uma nuvem, mas parece ser bom em tudo! Você fala em todo o mundo e trabalha com clientes em AWS, Azure e Google Cloud Platform. O que a palavra "sem servidor" significa para você e seus clientes?

Lynn Langit : a definição comum é "o cliente final não é responsável pelo servidor". Na verdade, eu ainda elevou essa definição ainda mais. Eu tenho trabalhado de perto com um amigo chamado Anton Delsink, que trabalha com o Azure Stack.

Dirigimos a Noruega juntos em uma viagem recente e criamos esta definição de sem servidor: "um serviço que abstrai o gerenciamento de contêineres". Então, nossa nova palavra-chave é "sem recipiente".

Você apenas explodiu minha mente! Então, qual é o futuro dos contêineres? Você não acha que os clientes vão querer trazer seus próprios contêiner para plataformas FaaS?

Eu tenho uma resposta de mordida de som: eu não me importo. Para mim, os recipientes são as novas máquinas virtuais. Todo esse frenesi sobre contêineres e, mais especificamente, sistemas de gerenciamento de contêineres – olha, alguém deve gerenciar as coisas. Eu quero pagar os provedores da nuvem para fazê-lo, então eu não preciso.

Agora na realidade, não crio muitas soluções sem servidor para clientes ainda. Algumas pessoas ainda preferem recipientes sem servidor, e suas razões geralmente são portabilidade e controle. Se você não tem uma necessidade convincente dessas opções, e você pode obter valor dos serviços sem servidor, por todos os meios, vá assim.

Você é um especialista em dados na nuvem, e sempre pensei que o conceito de "sem servidor" ficaria muito escorregadio na camada de dados. Para mim, parte do ponto de arquiteturas "sem servidor" é que você paga apenas pela capacidade que você usa, mas muitos serviços de dados o cobram por hora (RDS) ou por capacidade provisória (DynamoDB) para que você pague até mesmo se o seu serviço não receber nenhum tráfego. Você acha que um serviço de pagamento por consulta como o AWS Athena é o futuro?

Acho que o Google está assumindo a liderança aqui. Eles forneceram soluções de dados sem servidor ou sem servidor fora da caixa por anos. Quero dizer, o BigQuery saiu desde 2011. É uma solução noOps SQL-on-files type. Mesmo Cloud Spanner – você configurou uma instância, mas o único botão que você precisa girar é para utilização.

Uma vez que você atingiu um certo número eles defendem a obtenção de mais nós, mas é isso. É muito interessante que, como o Google está tentando adicionar a funcionalidade do warehouse de dados empresariais ao BigQuery, coisas como segurança granular e streaming, a AWS construiu tão rapidamente Athena e adicionou integrações com serviços como Glue.

Então, minha previsão é que, à medida que o Google expande seu portfólio de dados – como fizeram ao adicionar o BigTable – vai empurrar os outros provedores da nuvem como o AWS para oferecer o ajuste automático, menos controles para RDS e RedShift e EMR. E eu acho que você verá isso mais cedo e não mais tarde, porque o Google está realmente empurrando-os, e vimos que a AWS responde muito rapidamente a qualquer tipo de ameaça competitiva para o domínio da nuvem.

Certo, o que provavelmente é o motivo pelo qual eles investiram tanto na Aurora como um RDBMS proprietário. Você mencionou Athena, que joguei um pouco. Esse serviço fica caro muito rápido se você não o usar de forma otimizada, arquitetando seus dados de forma específica em colunas. Isso limita a utilidade do serviço, ou isso mudará as coisas sobre como as pessoas acessam dados sem servidor?

Bem, Athena é mais adequado para um certo tipo de dados. Consultas ad hoc em arquivos de log, realmente. Se você quer um volume alto, você deve ter algum tipo de compressão.

Mas, assim como o Docker e a Lambda são difíceis para os desenvolvedores de aplicativos terem suas mentes em volta – e é por isso que temos eventos como o ServerlessConf – acho ainda mais difícil para os profissionais de dados ter suas mentes em torno de implementações "sem servidor" ou servidor-lite. Porque há todo esse histórico de DBAs gerenciando clusters e tal. Então, o novo paradigma é assustador, e acho que os DBAs tendem a cavar em seus calcanhares e resistir.

Na verdade, acho que isso prejudicou a adoção do BigQuery, e é por isso que existe desde 2011 e somente em 2016 a Amazon sentiu a necessidade de sair com Athena. Você e eu sabemos que poderiam criá-lo mais cedo, mas o mercado não estava lá.

Eu acho que muitas pessoas (incluindo alguns desses DBA de salto de heel) tendem a associar "sem servidor" com "NoSQL". Na verdade, eu sei que as pessoas que acreditam que o banco de dados relacional está caindo no caminho, dão ou recebem algumas coisas como aplicações financeiras que precisam de consistência transacional. Você acha que isso é uma suposição justa? Por que ou por que não?

A tendência do NoSQL nos últimos anos foi realmente interessante para mim. Afinal, quando trabalhei na Microsoft escrevi livros no SQL Server. Eu fiz um monte de data warehousing tradicional com OLTP e OLAP e tudo isso. Quando eu deixei a Microsoft e fui independente em 2011, houve muito hype em torno do Hadoop e do NoSQL. E o que eu costumo encontrar é que não foi possível entregar.

A maioria dos meus compromissos de consultoria são em torno de dados na nuvem. As pessoas dizem "você pode nos ajudar a obter o valor comercial do NoSQL Database X?" E para muitas pequenas e médias empresas, não posso. Eles não têm a equipe, a vontade, a necessidade, para mudar.

Hoje, se um cliente diz que deseja implementar sua própria pilha NoSQL, eu realmente os desafio. Quero dizer, às vezes eles têm algum talento de Cassandra realmente forte ou algo assim, mas essa é uma exceção bastante rara. Eu vejo o NoSQL como muito exagerado e com muito pouco valor comercial. Ele levanta uma grande bandeira vermelha para mim, e eu recuperei muitas implementações noSQL falidas, converti-as para o RDS.

Então, para esclarecer, quando você fala sobre o NoSQL levantando bandeiras vermelhas, você quer dizer que as pessoas gerenciam suas próprias implantações em vez de confiar em serviços gerenciados de um provedor de nuvem?

Parcialmente. Para ser sincero, acho que muitos dos produtos independentes do NoSQL vão desaparecer. Ou serão comprados pela Amazon ou pela Microsoft ou pelo Google, ou não poderão competir. Vai ser um espaço muito pequeno. Eu acho que a Redis vai sobreviver, porque eles têm alguns aspectos realmente únicos para sua implementação. Cassandra, não tenho certeza.

Quero dizer, passei por um período em que eu estava obcecado com o NoSQL. Eu fiz apresentações – "NoSQL para o SQL Developer" – Eu realmente pensei que era o futuro. Mas cheguei à conclusão de que, assim como os recipientes, as implementações do NoSQL são uma distração. Skip containers – vá para as funções. Skip Cassandra – vá para o DynamoDB ou um serviço relacional gerenciado.

Então, parece que você não está desistindo de bancos de dados relacionais para sistemas sem servidor.

De modo nenhum. Se um cliente tiver um caso de uso para o NoSQL, recomendarei o NoSQL do provedor da nuvem. Mas eu lembro uma vez que eu era um arquiteto em uma solução AWS IoT, onde até mesmo a arquitetura de referência usava DynamoDB.

Mas eles estavam tendo todos os tipos de problemas, e um dia eu simplesmente decidi mudar para Aurora. Freaked todo mundo – eles disseram, "O que você está fazendo?" Eu disse: "O que estamos fazendo? Nós estamos enviando um produto. "E nós fizemos.

Digamos que queria criar um aplicativo que precisasse gerir dados de estado e transações de usuário em tempo real, bem como fornecer armazenamento de dados e processamento de dados grandes no back-end. E eu não queria que eu gerenciasse meus servidores de banco de dados. Se você pudesse magicamente acenar uma varinha e colocar os melhores serviços em conjunto com os vários provedores da nuvem para fazer isso, como você projetaria a camada de dados?

Vamos começar com o armazenamento de objetos. Embora a AWS tenha feito grandes melhorias no processo de gerenciamento do ciclo de vida do S3, uma coisa que eu adoro do Google é que eles possuem uma API unificada para o Google Cloud Storage. O conceito de glaciar da AWS está incluído, então você possui uma conexão nearline, coldline, multi-and single-regional embrulhada, e é apresentada de forma muito simples. O que eu não gosto é que está faltando alguns recursos do S3 – registro, controle de versão, métricas. Então, é um tipo de tentativa entre um lago de dados no Google Cloud Storage ou S3.

Próxima coisa: ingerir streaming. Esta é uma área onde eu estou fazendo muito trabalho agora. Os sistemas que existem por aí parecem ser todos executados em Kafka. Pessoalmente, gosto do Kinesis – rápido, fácil, simples – e o Google Cloud Pub / Sub também é bom. Mas há diferenciação de recursos entre Kafka e os tubos de nuvem. Gostaria que os vendedores da nuvem tivessem mais características do Kafka – Estou procurando por isso: invente este ano!

Para ETL, algumas coisas interessantes estão acontecendo. Ainda não estive em AWS Glue. Eu realmente adoro um produto ETL fabricado pela Matillion . Você pode obter o seu AMI no AWS Marketplace. É como o SQL Server SSIS em um navegador, então você tem representação visual das transformações, e seu DBA da velha escola é "Oh, isso parece ser minha ferramenta ETL!"

O longo e o curto é – se você está ETL-ing ou ELT-ing, eu prefiro uma ferramenta em vez de uma API. Amazon realmente brilha lá. Eu realmente não gosto do seu pipeline de dados nativo, mas eles brilham por causa de fornecedores como o Matillion. Por outro lado, o Google exige que você codifique tudo contra suas APIs, geralmente em Java.

E isso tem sido um grande negativo: o Google é uma nuvem focada em desenvolvedores. Você codifica tudo primeiro e, em seguida, as ferramentas vêm mais tarde, se alguma vez. Mesmo que sua nuvem seja realmente poderosa e realmente escalável, esse não é apenas o paradigma. Considerando que o AWS é uma nuvem do DevOps, e acho que esse foi um dos fatores de seu sucesso, em particular os dados, porque os administradores de rede e os DBAs têm mais referências.

Na camada relacional, eu realmente adoro Aurora e o resto das implementações RDS. Estou interessado em Spanner, mas novamente é um caso do Google levar seus próprios produtos e liberá-los, não entendendo que o resto do mundo não funciona na escala do Google.

Como o fato de a Spanner não suportar chaves estrangeiras, e não há nenhuma ferramenta de importação e conversão de esquema. Quem vai levar um aplicativo corporativo existente e mudar o esquema relacional? Não está acontecendo. E o fato de o Google nem abordar isso me deixa triste, porque o fato é que a Spanner é uma tecnologia maravilhosamente linda.

Essa falta de fazer um produto completo, mesmo que o Google ofereça mais no espaço de dados, faz-me tender a me concentrar na Amazon. Embora eu fique atento ao que o Google está fazendo, porque o que o Google realmente está fazendo é forçar a Amazon a fazer melhores produtos. Bom para os clientes, ruim para o Google.

E, finalmente, no domínio do grande processamento de dados, é um verdadeiro toque entre EMR e Cloud Dataproc. As máquinas virtuais do Google são pré-aquecidas e tão rápidas, elas aparecem em segundos. Eu faço muitos protótipos, então é ótimo para mim. Se você estiver fazendo cargas de trabalho explosivas, você pode usar o Preemptible, a versão do Google do Spot. Gostaria que a AWS atualizasse o EMR, tornasse-o um pouco mais moderno – estou procurando isso no re: inventar também. Para ser honesto, agora mesmo tendem a usar os DataBricks .

Quais outras maneiras que você pensa que sem servidor podem transformar dados grandes e vice-versa?

ETL ainda é o problema grande e ruim no mundo dos dados. Gostaria de ver mais ferramentas ETL que incluem aprendizagem de máquinas e estatísticas. "Parece que esta informação precisa de X." "Este esquema é A e esse esquema é B. Parece que você precisa de transformações do ABC". Aplicando cálculos regulares, mas a aprendizagem de máquinas em particular, os problemas de ETL serão mágicos. Vai ser interessante ver o que acontece com a Cola sair.

A outra coisa é a democratização da aprendizagem por máquinas. Eu sempre confesso quando as coisas são difíceis – isso faz parte da minha marca. Eu tenho trabalhado em entender como criar modelos TensorFlow e MXNet que fornecem valor comercial real por mais de seis meses. Até agora não sou capaz de fazê-lo. E a maioria das pessoas com quem falo, se eles são honestos, também não conseguem fazer isso. A maioria das pessoas pode completar os exemplos do Hello World-level, mas há uma camada de tradução perdida entre as amostras e, na verdade, a construção de modelos de negócios.

Estou realmente fascinado pelo espaço, porque na aprendizagem de máquinas existem excelentes serviços sem servidor, Rekognition API e Polly e Lex, e continuará a existir mais desses. Mas como chegamos a onde a API e as ferramentas estão maduras o suficiente para que uma pessoa de negócios que entenda estatísticas possa fazer um modelo? Eu acho que há muitos trabalhos de API, ferramentas e visualização a serem feitos aqui.

Como você acha que nós no espaço da nuvem pode ajudar a tornar o servidor ainda mais acessível para novos alunos?

Uma maneira de aprender sem servidor é criar um caso de uso IoT. Eu realmente gosto de construir com Alexa – eu fiz isso em todo o espectro com crianças, professores de escola, até desenvolvedores malcriados. Eu também gosto do Serviço de Cerveja Simples . Coloque as pessoas em um ambiente que é divertido, tem um baixo custo para a entrada, e eles vão dizer "Oh, eu posso realmente fazer isso!" Eu trago Echo Dots porque eles desarmam as pessoas.

Aqui está o único aspecto de sem servidor que não podemos perder de vista: esta tecnologia traz consigo uma tremenda quantidade de mudanças. É assustador; é perturbador. Falha ao reconhecer que é apenas reter as oportunidades.

Volte em breve para outra edição de Serverher Superheroes.