Master

Plataformas

Adote?

    Experimente?

    • Muitos de nossos times que já usam AWS descobriram que o AWS Cloud Development Kit (AWS CDK) é um padrão sensato da AWS para habilitar o provisionamento de infraestrutura. Particularmente, eles gostam do uso de linguagens de programação de primeira classe em vez de arquivos de configuração, o que permite aos times usar as ferramentas existentes, abordagens e habilidades de teste. Como acontece com ferramentas semelhantes, ainda é necessário cuidado para garantir que as implantações permaneçam fáceis de entender e manter. O kit atualmente suporta TypeScript, JavaScript, Python, Java, C # e .NET. Novos provedores estão sendo adicionados ao núcleo do CDK. Também usamos o AWS Cloud Development Kit e o HashiCorp's Cloud Development Kit for Terraform para gerar configurações do Terraform e habilitar o provisionamento usando a plataforma Terraform com sucesso.

      Histórico
    • Continuamos observando aumento no interesse e no uso de Backstage, bem como na adoção de portais para pessoas desenvolvedoras, à medida que as organizações buscam apoiar e otimizar seus ambientes de desenvolvimento. Conforme o número de ferramentas e de tecnologias aumenta, alguma forma de padronização se torna cada vez mais importante para ter consistência, para que as pessoas desenvolvedoras possam se concentrar na inovação e no desenvolvimento de produtos, em vez de terem que reinventar a roda. Backstage é uma plataforma de código aberto do Spotify para a criação de portais de desenvolvimento. É baseada em modelos de software, ferramentas de infraestrutura unificadas e documentação técnica consistente e centralizada. Sua arquitetura de plugins permite extensibilidade e adaptabilidade no ecossistema de infraestrutura de uma organização.

      Histórico
    • Delta Lake é uma camada de armazenamento de código aberto, implementada pelo Databricks, que tenta levar transações ACID para o processamento de big data. Em nossos projetos de lago de dados ou malha de dados habilitados pelo Databricks, nossos times continuam preferindo usar o armazenamento Delta Lake em vez do uso direto de tipos de armazenamento de arquivos, como S3 ou ADLS. Claro, isso se limita a projetos que usam plataformas de armazenamento que suportam Delta Lake ao usar formatos de arquivo Parquet. O Delta Lake facilita os casos de uso simultâneos de leitura/gravação de dados em que a transacionalidade no nível de arquivo é necessária. Achamos a impecável integração do Delta Lake com a API de processamento em lote e microlote do Apache Spark muito úteis, principalmente recursos como versionamento — que possibilita acessar dados em um determinado momento ou reverter um commit — bem como suporte a evolução de esquemas, embora existam algumas limitações nesses recursos.

      Histórico
    • Materialize é um banco de dados de streaming que permite fazer computação incremental sem pipelines de dados complicados. Basta descrever seus cálculos por meio de visualizações SQL padrão e conectar o Materialize ao fluxo de dados. A ferramenta subjacente de fluxo de dados diferencial executa computação incremental para fornecer saída consistente e correta com latência mínima. Ao contrário dos bancos de dados tradicionais, não há restrições na definição dessas visualizações materializadas e os cálculos são executados em tempo real. Usamos Materialize, junto com Spring Cloud Stream e Kafka, para consultar fluxos de eventos em busca de insights em sistemas distribuídos orientados a eventos, e gostamos bastante da configuração.

      Histórico
    • Desde que mencionamos Snowflake pela última vez no Radar, ganhamos mais experiência com a plataforma, bem como com a malha de dados como uma alternativa para warehouses e lagos de dados. Snowflake continua a impressionar com recursos como viagem no tempo, clonagem de cópia zero, compartilhamento de dados e com o seu marketplace. Não encontramos nada de que não tenhamos gostado nele, o que fez nossas pessoas consultoras, de forma geral, o preferirem às alternativas. O Redshift está se movendo em direção à separação entre armazenamento e computação, o que tem sido um ponto forte do Snowflake, mas ainda assim o Redshift Spectrum não é tão conveniente e flexível, em parte pela limitação imposta pela herança do Postgres (a propósito, ainda gostamos do Postgres). As consultas federadas podem ser um motivo para usar o Redshift. Quando se trata de operação, o Snowflake é muito mais simples de executar. BigQuery, que é outra alternativa, é muito fácil de operar, mas em uma configuração com várias nuvens, o Snowflake é uma escolha melhor. Também podemos dizer que usamos o Snowflake com sucesso com GCP, AWS e Azure.

      Histórico
    • Fontes variáveis são uma maneira de evitar a necessidade de encontrar e incluir arquivos de fonte separados para diferentes pesos e estilos. Tudo fica em um arquivo de fonte e você pode usar as propriedades para selecionar o estilo e o peso necessários. Embora não seja algo novo, ainda vemos sites e projetos que poderiam se beneficiar dessa abordagem simples. Se você tiver páginas que incluem diferentes variações da mesma fonte, sugerimos experimentar a abordagem de fontes variáveis.

      Histórico

    Avalie?

    • Apache Pinot é um armazenamento de dados OLAP distribuído, construído para fornecer análises em tempo real com baixa latência. Ele pode ingerir de fontes de dados em lote (como Hadoop HDFS, Amazon S3, Azure ADLS ou Google Cloud Storage), bem como fontes de dados de stream (como Apache Kafka). Se a necessidade for uma análise de baixa latência voltada para o usuário, as soluções SQL-on-Hadoop não oferecem a baixa latência necessária. Mecanismos OLAP modernos como Apache Pinot (ou Apache Druid e Clickhouse, entre outros) podem atingir latência muito menor e são particularmente adequados em contextos em que análises rápidas, como agregações, são necessárias em dados imutáveis, possivelmente, com ingestão de dados em tempo real. Construído originalmente pelo LinkedIn, o Apache Pinot entrou na incubação da Apache no final de 2018 e, desde então, adicionou uma arquitetura de plugin e suporte a SQL, entre outros recursos importantes. O Apache Pinot pode ser bastante complexo de operar e tem muitas partes móveis, mas se seus volumes de dados forem grandes o suficiente e você precisar de capacidade de consulta de baixa latência, recomendamos que avalie o Apache Pinot.

      Histórico
    • Bit.dev é uma plataforma colaborativa hospedada em nuvem para componentes de UI extraídos, modularizados e reutilizados com Bit. Web Components já existem há algum tempo, mas construir uma aplicação de front-end moderna juntando pequenos componentes independentes extraídos de outros projetos nunca foi fácil. É aqui que o Bit é útil. É uma ferramenta de linha de comando elegante que permite extrair um componente de uma biblioteca ou de um projeto existente. Você pode construir seu próprio serviço em cima do Bit para colaboração de componentes, ou usar o Bit.dev.

      Histórico
    • Desde que mencionamos pela primeira vez a detecção de dados no Radar, o LinkedIn evoluiu o WhereHows para DataHub, uma geração seguinte da plataforma que lida com a detecção de dados por meio de um sistema de metadados extensível. Em vez de rastrear e extrair metadados, o DataHub adota um modelo baseado em push, no qual componentes individuais do ecossistema de dados publicam metadados por meio de uma API ou de um stream para a plataforma central. Essa integração baseada em push transfere a propriedade da entidade central para times individuais, tornando-os responsáveis por seus metadados. À medida que mais empresas tentam se tornar orientadas por dados, ter um sistema que ajuda na descoberta de dados e no entendimento da qualidade e da linhagem dos dados é fundamental, e recomendamos que você avalie essa capacidade no DataHub.

      Histórico
    • Feature Store é uma plataforma de dados específica de aprendizado de máquina que aborda alguns dos principais desafios enfrentados hoje pela engenharia de recursos, por meio de três capacidades fundamentais: (1) uso de pipelines de dados gerenciados para remover dificuldades de pipelines conforme novos dados chegam; (2) catalogação e armazenamento de dados de recursos para promover descoberta e colaboração de recursos entre modelos; (3) veiculação de dados de recursos de maneira consistente durante o treinamento e a interferência.

      Desde que o Uber revelou sua plataforma Michelangelo, muitas organizações e startups criaram suas próprias versões de lojas de recursos. Exemplos incluem Hopsworks, Feast e Tecton. Vemos potencial na Feature Store e recomendamos que você a avalie cuidadosamente.

      Histórico
    • JuiceFS é um sistema de arquivos POSIX distribuído e de código aberto, construído com base em Redis e armazenamento de objetos. Ao construir novas aplicações, nossa recomendação sempre foi interagir diretamente com o armazenamento de objetos, sem passar por outra camada de abstração. No entanto, JuiceFS pode ser uma opção se você estiver migrando aplicações legadas que dependam de sistemas de arquivos POSIX tradicionais para a nuvem.

      Histórico
    • À medida que mais empresas se voltam para eventos como uma forma de compartilhar dados entre microsserviços, coletar analytics ou alimentar lagos de dados, Apache Kafka tornou-se a plataforma favorita para apoiar um estilo arquitetural orientado a eventos. Embora o Kafka fosse um conceito revolucionário em mensagens persistentes escaláveis, muitas partes móveis são necessárias para fazê-lo funcionar, incluindo o ZooKeeper, brokers, partições e mirrors. Embora possam ser particularmente difíceis de implementar e operar, elas oferecem grande flexibilidade e poder quando necessário, especialmente em uma escala empresarial. Por causa da alta barreira de entrada apresentada em todo o ecossistema Kafka, damos as boas-vindas à recente explosão de plataformas que oferecem a API do Kafka sem Kafka. Entradas recentes como Kafka on Pulsar e Redpanda oferecem arquiteturas alternativas, e o Azure Event Hubs para Kafka oferece alguma compatibilidade com APIs de produtor e consumidor do Kafka. Alguns recursos do Kafka, como a biblioteca cliente de streams, não são compatíveis com esses brokers alternativos, portanto, ainda há razões para escolher o Kafka entre as alternativas. Resta saber, entretanto, se as pessoas desenvolvedoras de fato irão adotar essa estratégia, ou se é apenas uma tentativa da concorrência de afastar usuários da plataforma Kafka. Em última análise, talvez o impacto mais duradouro do Kafka seja a conveniência do protocolo e da API fornecidos a clientes.

      Histórico
    • NATS é um sistema de filas de mensagens rápido e seguro com uma variedade incomum de recursos e targets de implantação em potencial. À primeira vista, você pode se perguntar por que o mundo precisaria de outro sistema de filas de mensagens. As filas de mensagens existem em várias formas há quase tanto tempo quanto as empresas usam computadores, e passaram por anos de refinamento e otimização para várias tarefas. Mas o NATS tem várias características interessantes e é único em sua capacidade de escalar, que vai de controladores incorporados a superclusters globais hospedados em nuvem. Particularmente, intriga-nos a intenção do NATS de oferecer suporte a um fluxo contínuo de dados de dispositivos móveis e IoT e por meio de uma rede de sistemas interconectados. No entanto, alguns problemas complexos precisam ser resolvidos, como garantir que consumidores vejam apenas as mensagens e os tópicos aos quais têm acesso permitido, especialmente quando a rede ultrapassa os limites organizacionais. O NATS 2.0 introduziu um framework de controle de segurança e acesso que oferece suporte a clusters multitenant, onde as contas restringem o acesso do usuário a filas e tópicos. Escrito em Go, o NATS foi adotado principalmente pela comunidade da linguagem Go. Embora existam clientes para praticamente todas as linguagens de programação amplamente utilizadas, o cliente Go é de longe o mais popular. No entanto, algumas de nossas pessoas desenvolvedoras descobriram que todas as bibliotecas cliente de linguagem tendem a refletir as origens Go da base de código. Aumentar a largura de banda e a capacidade de processamento em pequenos dispositivos sem fio significa que o volume de dados que as empresas devem consumir em tempo real só aumentará. Avalie o NATS como uma plataforma possível para transmitir esses dados internamente e entre empresas.

      Histórico
    • Opstrace é uma plataforma de observabilidade de código aberto destinada a ser implantada na própria rede da pessoa usuária. Se não usamos soluções comerciais como Datadog (por exemplo, por questões de custo ou residência de dados), a única solução é construir sua própria plataforma composta de ferramentas de código aberto. Isso pode exigir muito esforço — o Opstrace destina-se a preencher essa lacuna. Ele usa APIs de código aberto e interfaces como Prometheus e Grafana e adiciona recursos, como TLS e autenticação. O núcleo do Opstrace executa um cluster Cortex para fornecer API Prometheus escalável, bem como um cluster Loki para os logs. É uma plataforma relativamente nova e ainda carece de recursos quando comparada a soluções como Datadog ou SignalFX. Ainda assim, é uma adição promissora a este espaço e vale a pena ficar de olho.

      Histórico
    • Temos visto o interesse no Pulumi crescer de forma lenta, mas contínua. O Pulumi preenche uma lacuna no mundo da programação de infraestrutura, no qual o Terraform mantém uma posição sólida. Embora o Terraform seja uma ferramenta testada e aprovada, sua natureza declarativa sofre com recursos de abstração inadequados e testabilidade limitada. O Terraform é adequado quando a infraestrutura é totalmente estática, mas as definições de infraestrutura dinâmica exigem uma linguagem de programação real. Pulumi se distingue por permitir que as configurações sejam escritas em TypeScript/JavaScript, Python e Go — sem necessidade de linguagem de marcação ou modelagem. O Pulumi tem foco fortemente voltado para arquiteturas nativas da nuvem — incluindo contêineres, funções sem servidor e serviços de dados — e oferece bom suporte para Kubernetes. Recentemente, o AWS CDK surgiu como desafiante, mas Pulumi continua a ser a única ferramenta neutra em nuvem nesta área. Estamos antecipando uma adoção mais ampla do Pulumi no futuro e otimistas por uma ferramenta viável e um ecossistema de conhecimento emergente para apoiá-lo.

      Histórico
    • Redpanda é uma plataforma de streaming que fornece uma API compatível com Kafka, permitindo que ela se beneficie do ecossistema sem ter que lidar com as complexidades de uma instalação Kafka. Por exemplo, o Redpanda simplifica as operações enviando-as como um único binário e evitando a necessidade de uma dependência externa como o ZooKeeper. Em vez disso, ele implementa o protocolo Raft e realiza testes abrangentes para validar se foi implementado corretamente. Um dos recursos do Redpanda (disponível apenas para clientes corporativos) é a transformação em linha WebAssembly (WASM), usando um mecanismo WASM incorporado. Isso permite que as pessoas desenvolvedoras criem transformadores de eventos em sua linguagem de escolha e compilem para WASM. O Redpanda também oferece latências de cauda muito reduzidas e maior rendimento devido a uma série de otimizações. Redpanda é uma alternativa interessante ao Kafka e vale a pena avaliar.

      Histórico

    Evite?

    • Observamos anteriormente que as provedoras de nuvem disponibilizam cada vez mais serviços no mercado. Também documentamos nossas preocupações de que às vezes os serviços são disponibilizados antes de estarem totalmente prontos. Infelizmente, em nossa experiência, Azure Machine Learning se enquadra na última categoria. Um dos vários novos participantes no campo de plataformas limitadas de baixo código, o Azure ML promete mais conveniência para cientistas de dados. No final das contas, entretanto, ele não cumpre sua promessa. Na verdade, nossas pessoas cientistas de dados ainda acham mais fácil trabalhar com Python. Apesar de esforços significativos, encontramos dificuldades para escalar e a falta de documentação adequada mostrou ser mais um problema. Por essas razões, movemos a plataforma para o anel Evite.

      Histórico
    • Produtos que são suportados por empresas ou comunidades estão em constante evolução, pelo menos aqueles que ganham força na indústria. Às vezes, as organizações tendem a construir frameworks ou abstrações baseadas em produtos externos para atender a necessidades muito específicas, imaginando que a adaptação trará mais benefícios do que os produtos existentes. Estamos observando organizações tentando criar produtos caseiros de infraestrutura como código (IaC) com base nos existentes. Essas organizações subestimam o esforço necessário para manter essas soluções em evolução de acordo com suas necessidades e, após um curto período de tempo, percebem que a versão original está em muito melhor estado do que a sua. Há ainda casos em que a abstração do produto externo reduz as capacidades originais. Embora tenhamos visto histórias de sucesso de organizações criando soluções caseiras, queremos alertar sobre essa abordagem, pois o esforço necessário não é desprezível e uma visão de produto de longo prazo é necessária para ter os resultados esperados.

      Histórico
    Não encontrou algo que você esperava achar?

    Cada edição do Radar inclui blips que refletem nossas experiências nos seis meses anteriores. Talvez já tenhamos falado sobre o que você procura em um Radar anterior. Às vezes, deixamos coisas de fora simplesmente porque há muitas a serem abordadas. Também pode estar faltando um tópico específico porque o Radar reflete nossa experiência, não se baseando em uma análise abrangente do mercado.

    Novo,Modificado,Sem alteração