Enable javascript in your browser for better experience. Need to know to enable it? Go here.

Plataformas

Adote ?

Experimente ?

  • À medida que o foco em melhorar a experiência e a efetividade das pessoas desenvolvedoras aumenta nas organizações, vemos Backstage ganhar popularidade, junto com a adoção de portais de desenvolvimento. Essas organizações procuram oferecer suporte e otimizar seus ambientes de desenvolvimento de software. Conforme o número de ferramentas e tecnologias aumenta, alguma forma de padronização se torna cada vez mais importante para a consistência, de modo que as pessoas desenvolvedoras possam se concentrar na inovação e no desenvolvimento de produtos, em vez de se prenderem a reinventar a roda. Backstage é uma plataforma de portal de desenvolvimento de código aberto criada pelo Spotify. É baseada em modelos de software, unificando ferramentas de infraestrutura e documentação técnica consistente e centralizada. A arquitetura de plug-in permite extensibilidade e adaptabilidade no ecossistema de infraestrutura de uma organização. Vamos seguir observando de perto o novo catálogo de serviços do Backstage, atualmente em alfa, que mantém o controle de propriedade e metadados para software como um todo no ecossistema de uma organização.

  • ClickHouse é um banco de dados de processamento analítico online colunar (OLAP) de código aberto para análise em tempo real. Começou como um projeto experimental em 2009 e desde então amadureceu para um banco de dados analítico de alto desempenho linearmente escalável. Seu mecanismo de processamento de consulta eficiente, junto com a compactação de dados, torna-o adequado para executar consultas interativas sem pré-agregação. Usamos ClickHouse e seu desempenho tem nos impressionado bastante.

  • Kafka é um padrão comum para arquiteturas orientadas a eventos, mas adaptá-lo a ambientes legados introduz uma incompatibilidade de impedância. Em alguns casos, tivemos sucesso em minimizar a complexidade do legado usando Confluent Kafka REST Proxy. O proxy permite que as pessoas desenvolvedoras acessem Kafka por meio de uma interface HTTP, o que é útil em ambientes que dificultam o uso do protocolo nativo Kafka. Por exemplo, fomos capazes de consumir eventos emitidos com SAP simplesmente fazendo a equipe SAP invocar um comando HTTP POST por meio de uma chamada de função remota SAP pré-configurada, evitando a necessidade de executar o spin up de uma abstração Java em SAP (e de uma equipe para gerenciá-la). O proxy tem muitos recursos, embora, como acontece com qualquer ferramenta de adaptação, recomendamos cautela e uma visão clara das compensações envolvidas. Acreditamos que o proxy seja valioso quando permite que produtores legados enviem eventos, mas é preciso ter mais cuidado ao criar consumidores de eventos por meio do proxy conforme a abstração fica mais complexa. O proxy não muda o fato de que os consumidores Kafka têm estado, o que significa que as instâncias do consumidor criadas por meio da API REST estão vinculadas a um proxy específico, e a necessidade de fazer uma chamada HTTP para consumir mensagens de um tópico muda a semântica padrão de eventos Kafka.

  • Apesar de nossa recomendação de cautela na última vez em que o mencionamos, temos visto um entusiasmo contínuo com o GitHub Actions. O que dissemos antes ainda é válido: o GitHub Actions ainda não substitui completamente CI/CD para fluxos de trabalho complexos. O orquestrador não pode, por exemplo, disparar novamente uma única tarefa de um fluxo de trabalho, chamar outras ações dentro de uma ação composta ou oferecer suporte a uma biblioteca compartilhada. Além disso, embora o ecossistema no GitHub Marketplace ofereça vantagens óbvias, dar a ações do GitHub de terceiros acesso ao seu pipeline de compilação gera o risco do compartilhamento de segredos de maneiras inseguras (recomendamos seguir as recomendações do GitHub sobre fortalecimento de segurança. Apesar dessas preocupações, a conveniência de criar seu fluxo de trabalho de compilação diretamente no GitHub ao lado do seu código-fonte é uma opção atraente para alguns times, e act ajuda a executar ações do GitHub localmente. Como sempre, recomendamos uma avaliação clara das vantagens e desvantagens envolvidas, mas alguns de nossos times estão satisfeitos com a simplicidade do GitHub Actions.

  • K3s é uma distribuição leve do Kubernetes desenvolvida para IoT e computação de borda. Com K3s, você obtém os benefícios de um Kubernetes em conformidade com todas as regulamentações necessárias, mas com a sobrecarga operacional reduzida. Suas melhorias incluem back-ends de armazenamento leves (sqlite3 como padrão em vez de etcd), um único pacote binário com dependências mínimas de sistema operacional e consumo de memória reduzido, tornando K3s adequado para ambientes com recursos limitados. Usamos K3s em máquinas de ponto de venda e estamos muito contentes com nossa decisão.

  • Mambu é uma plataforma SaaS de serviços bancários em nuvem que permite que clientes criem e alterem de forma simples e flexível seus produtos bancários e empréstimos. Ao contrário de outras plataformas de core banking prontas para uso, que só permitem adaptação com integração embutida no código, Mambu foi projetada para ofertas financeiras em constante mudança. A plataforma vem com um fluxo de trabalho opinativo, ao mesmo tempo fornecendo uma abordagem baseada em API para personalizar a lógica de negócios, processos e integrações. Atualmente, temos vários projetos usando o Mambu. Com sua escalabilidade baseada em nuvem e recursos altamente personalizáveis, está se tornando um padrão sensato de sistema de domínio para construir produtos financeiros.

  • Construído usando o framework Kafka Connect, MirrorMaker 2.0 (também conhecido como MM2) resolve muitas deficiências de ferramentas em abordagens anteriores de replicação do Kafka. O MM2 pode georreplicar dados de tópicos e metadados entre clusters com sucesso, incluindo offsets, grupos de consumidores e linhas de comando de autorização (ACLs). MM2 preserva o particionamento e detecta novos tópicos e partições. Gostamos de sua capacidade de preparar uma migração de cluster ao longo do tempo, uma abordagem que pode ser útil na migração de um cluster local para um cluster em nuvem. Depois de sincronizar os tópicos e grupos de consumidores, primeiro migramos clientes para o novo local do cluster, depois migramos produtores para o novo local e finalmente desligamos o MM2 e descomissionamos o cluster antigo. Também vimos o MM2 sendo usado em cenários de recuperação de desastres e alta disponibilidade.

  • OPA Gatekeeper para Kubernetes é um webhook de admissão personalizável para Kubernetes que impõe políticas executadas pelo Open Policy Agent (OPA). Estamos usando esta extensão da plataforma Kubernetes para adicionar uma camada de segurança aos clusters, fornecendo mecanismos de governança automatizados que garantem que as aplicações sejam compatíveis com as políticas definidas. Nossos times gostam especialmente de sua capacidade de personalização: usar CustomResourceDefinitions (CRD) nos permite definir ConstraintTemplates e Constraints que tornam a definição de regras e objetos (por exemplo, implantações, tarefas, tarefas cron) e namespaces sob avaliação uma tarefa fácil.

  • Temos visto um número cada vez maior de times usando Pulumi em várias organizações. Pulumi preenche uma lacuna no mundo da programação de infraestrutura, onde o Terraform mantém uma posição firme. Embora o Terraform seja um standby testado e aprovado, 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. Pulumi tem seu foco fortemente voltado para arquiteturas nativas de nuvem — incluindo contêineres, funções sem servidor e serviços de dados — e fornece bom suporte para Kubernetes. Recentemente, o AWS CDK se mostrou um forte concorrente, mas Pulumi continua a ser a única ferramenta neutra de nuvem nesta área.

  • O Kubernetes oferece suporte nativo a um objeto de chave-valor conhecido como segredo. No entanto, por padrão, os segredos do Kubernetes não são realmente secretos, sendo tratados separadamente de outros dados de chave-valor para que as precauções ou o controle de acesso possam ser aplicados separadamente. Há suporte para criptografar segredos antes de armazená-los no etcd, mas os segredos começam como campos de texto simples em arquivos de configuração. Sealed Secrets é uma combinação de operador e utilitário de linha de comando que usa chaves assimétricas para criptografar segredos de forma que só possam ser descriptografados pelo controlador no cluster. Esse processo garante que os segredos não sejam comprometidos enquanto permanecem nos arquivos de configuração que definem uma implantação do Kubernetes. Depois de criptografados, esses arquivos podem ser compartilhados com segurança ou armazenados junto com outros artefatos de implantação.

  • Desde que avaliamos pela primeira vez o JAMstack, temos visto cada vez mais aplicações web desse mesmo estilo. No entanto, quando a infraestrutura para construir sites dinâmicos tradicionais e serviços de back-end é muito pesada para o JAMstack, nossos times optam pelo Vercel. Vercel é uma plataforma em nuvem para hospedagem estática de sites. E o mais importante: fornece um fluxo de trabalho perfeito para desenvolver, visualizar e enviar sites JAMstack. A configuração da implantação é bastante simples. Com a integração com o GitHub, cada commit de código ou pull request pode acionar uma nova implantação de site que tem uma URL para visualização, o que acelera muito o feedback do desenvolvimento. Vercel também usa o CDN para escalar e acelerar os locais de produção. Vale a pena mencionar que a equipe por trás do Vercel também é responsável por outro framework popular, o Next.js.

  • Weights & Biases é uma plataforma de aprendizado de máquina (ML) para construir modelos com mais rapidez, por meio de rastreamento de experimentos, controle de versão de conjunto de dados, visualização de desempenho e gerenciamento de modelo. Você pode integrá-la com seu código de ML existente e acessar rapidamente métricas em tempo real, logs de terminal e estatísticas do sistema transmitidas ao dashboard para análise posterior. Nossos times têm usado Weights & Biases, e nos agrada sua abordagem colaborativa para a construção de modelos.

Avalie ?

  • Azure Cognitive Search oferece pesquisa como um serviço para aplicações que exigem pesquisa de texto em conteúdo heterogêneo. Também fornece APIs baseadas em push ou pull para fazer upload e indexar imagens, texto não estruturado ou conteúdo de documento estruturado, com limitações nos tipos de fonte de dados baseados em pull com suporte. O serviço fornece ainda APIs em REST e .NET SDK para executar consultas de pesquisa, usando uma linguagem de consulta simples ou consultas mais poderosas Apache Lucene, com consultas de escopo de campo, pesquisa difusa, pesquisa de infixo e sufixo curinga, pesquisa de expressão regular, entre outros recursos. Usamos com sucesso a Azure Cognitive Search em conjunto com outros serviços Azure, incluindo a pesquisa de conteúdo carregado do Cosmos DB.

  • Até hoje, considerando todas as ferramentas de desenvolvimento e infraestrutura à nossa disposição, muitas vezes chegamos a um ponto em que precisamos de um script para colar várias coisas ou automatizar uma tarefa recorrente. Os atuais favoritos para escrever esses scripts são bash e Python, mas estamos felizes em informar que há uma opção nova e interessante: Clojure. Isso é possível com Babashka, um tempo de execução Clojure completo implementado com GraalVM. Babashka vem com bibliotecas que cobrem a maioria dos casos de uso nos quais você usaria uma ferramenta de script, e o carregamento de outras bibliotecas também é possível. O uso do GraalVM traz os tempos de inicialização dentro do alcance das ferramentas nativas e também torna o Babashka uma das poucas opções para um ambiente de script multithread, para aqueles raros casos em que é necessário.

  • ExternalDNS sincroniza entradas e serviços Kubernetes com provedores DNS externos, preenchendo uma lacuna anteriormente ocupada por kops dns-controller, Zalando's Mate ou route53-kubernetes — os dois últimos foram substituídos por ExternalDNS. A ferramenta torna os recursos internos do Kubernetes detectáveis por meio de servidores DNS públicos, removendo uma etapa às vezes manual para atualizar os registros DNS quando um host de entrada ou endereço de IP do serviço muda. A ferramenta oferece suporte a uma grande lista de provedores de serviços DNS prontos para uso, com mais sendo adicionados por meio do suporte da comunidade. Como diz a velha piada, é sempre DNS.

  • Konga é uma IU de código aberto para administrar Kong API Gateway, anteriormente incluído no Radar no anel Experimente. Nossos times gostaram da configuração rápida e do rico conjunto de recursos, que permite experimentar e testar configurações com facilidade. E o fato de ser um software de código aberto alivia as preocupações em relação a custos de licenciamento.

  • Milvus 2.0 é um banco de dados vetorial de código aberto e nativo de nuvem, criado para busca e gerenciamento de vetores de embedding gerados por modelos de aprendizado de máquina e redes neurais. A plataforma suporta vários índices vetoriais para pesquisa de vizinhos mais próximos aproximados (ANN) em vetores de embedding de áudio, vídeo, imagem ou quaisquer dados não estruturados. Milvus 2.0 é um banco de dados relativamente novo e recomendamos que você o avalie para suas necessidades de busca por similaridade.

  • É raro incluirmos software comercial de prateleira no Radar, principalmente se tratando de uma plataforma de core banking. No entanto, Thought Machine Vault (nenhuma conexão com a Thoughtworks) é um exemplo de um produto desta classe projetado para suportar boas práticas de engenharia de software, como desenvolvimento orientado a testes, entrega contínua e infraestrutura como código. As pessoas desenvolvedoras definem produtos bancários no Vault escrevendo contratos inteligentes em código Python. Isso é muito diferente da abordagem padrão sem código, em que a personalização é feita por meio de interfaces gráficas ou arquivos de configuração proprietários, ou ambos. Como os produtos são definidos em código Python regular, as pessoas desenvolvedoras têm acesso a uma variedade de ferramentas, como estruturas de teste e controle de versão, para garantir que seu trabalho seja seguro e preciso. Gostaríamos que mais plataformas de serviços financeiros fossem projetadas com a eficácia de pessoas desenvolvedoras em mente.

  • XTDB é um banco de dados de documentação de código aberto, com consultas de grafo bitemporais. Suporta nativamente dois eixos de tempo para cada registro: tempo válido, quando um fato ocorre, e tempo de transação, quando um fato é processado e registrado pelo banco de dados. O suporte para bitemporalidade é um benéfico em vários cenários, incluindo casos de uso analíticos executando consultas com reconhecimento de tempo; auditoria de mudanças históricas em fatos; suporte a arquiteturas de dados distribuídas que precisam garantir consultas point-in-time globalmente consistentes como data mesh (malha de dados); e preservação da imutabilidade dos dados. O XTDB recebe informações em forma de documentos, expressas no formato Extensible Data Notation (EDN), um subconjunto da linguagem Clojure. O XTDB suporta grafos e também consultas SQL, e é extensível por meio de uma camada de API REST e Kafka Connect, entre outros módulos. Estamos otimistas em ver um crescimento na adoção de XTDB e a adição de recursos como suporte para transações e SQL.

Evite ?

 
novo
Modificado
Sem alteração

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 faltar um tópico específico porque o Radar reflete nossa experiência, não se baseando em uma análise abrangente do mercado.

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 faltar um tópico específico porque o Radar reflete nossa experiência, não se baseando em uma análise abrangente do mercado.

Radar

Baixar o Technology Radar Volume 25

English | Español | Português | 中文

Radar

Mantenha-se por dentro das tendências de tecnologia

 

Seja assinante

Visite nosso arquivo para acessar os volumes anteriores