Menu

Técnicas

Adote?

  • As função de aptidão introduzidas pela arquitetura evolutiva e emprestadas pela computação evolucionária, são funções executáveis que nos informam se nossas aplicações e arquitetura estão objetivamente se afastando de suas características desejadas. São essencialmente testes que podem ser incorporados em nossos pipelines de entrega de software. Uma das principais características de uma aplicação é a atualização de suas dependências para outras bibliotecas, APIs ou componentes de um ambiente. Uma função de aptidão para controle de dependências rastreia esses elementos para sinalizar as dependências desatualizadas que requerem atualização. Com o número crescente de ferramentas para controle de dependências, como Dependabot ou Snyk, podemos facilmente incorporar funções de aptidão para controle de dependências em nosso processo de entrega de software, habilitando a adoção de medidas oportunas para manter as dependências de nossas aplicações atualizadas.

    Histórico
  • Automatizar estimativa, rastreamento e projeção do custo de execução de uma infraestrutura de nuvem é necessário para as empresas de hoje. Os modelos de precificação sagazes dos fornecedores de nuvem, combinados com a proliferação dos parâmetros de precificação e a natureza dinâmica da arquitetura atual podem levar a um custo de execução surpreendentemente caro. Por exemplo, os preços de arquiteturas sem servidor baseadas em chamadas de API, soluções de streaming de eventos baseadas em tráfego ou clusters de processamento de dados baseados em trabalhos em execução, todos têm uma natureza dinâmica que muda com o tempo à medida que a arquitetura evolui. Quando nossos times gerenciam infraestruturas na nuvem, implementar custo de execução como função de aptidão arquitetural é uma das primeiras atividades. Isso significa que nossos times podem observar o custo de executar serviços em relação ao valor entregue. Quando observam divergências em relação ao que era esperado ou aceitável, discutem se é hora de evoluir a arquitetura. A observação e o cálculo do custo de execução são implementados como uma função automatizada.

    Histórico
  • À medida que o panorama da tecnologia se torna mais complexo, questões como segurança demandam mais automação e práticas de engenharia. Ao construir sistemas, precisamos levar em consideração as políticas de segurança, que consistem em regras e procedimentos para proteger nossos sistemas contra ameaças e disrupções. Por exemplo, as políticas de controle de acesso definem e impõem quem pode acessar quais serviços e recursos em quais circunstâncias. Por outro lado, as políticas de segurança de rede podem limitar dinamicamente a taxa de tráfego para um serviço específico.

    Vários de nossos times tiveram boas experiências tratando políticas de segurança como código. Quando dizemos como código, não significa apenas escrever essas políticas de segurança em um arquivo, mas também aplicar práticas como manter o código sob controle de versão, introduzir validação automática no pipeline, implantá-lo automaticamente nos ambientes e observar e monitorar seu desempenho. Com base em nossa experiência e maturidade das ferramentas existentes — incluindo Open Policy Agent e plataformas como Istio, que fornece definição de política flexível e mecanismos de aplicação que suportam a prática de política de segurança como código —, é altamente recomendável usar essa técnica em seu ambiente.

    Histórico
  • Desde que mencionamos pela última vez os modelos de serviço personalizados , vimos uma adoção mais ampla do padrão ajudando a pavimentar o caminho de organizações que estão migrando para microsserviços. Com avanços constantes em ferramentas de observabilidade, orquestração de contêineres e sidecars de malha de serviço, os modelos fornecem padrões razoáveis para iniciar novos serviços, dispensando uma grande quantidade de configurações necessárias para garantir que o serviço funcione bem com a infraestrutura ao seu redor. Tivemos sucesso aplicando princípios de gestão de produto a modelos de serviço personalizados, tratando pessoas desenvolvedoras internas como clientes e facilitando o processo de enviar código para produção e operá-lo com a observabilidade apropriada. Essa prática traz o benefício adicional de atuar como um mecanismo de governança leve para centralizar as decisões técnicas padrão.

    Histórico

Experimente?

  • Cerca de uma década atrás, apresentamos a entrega contínua (CD), nossa maneira padrão de fornecer soluções de software. As soluções de hoje incluem cada vez mais modelos de aprendizado de máquina e não os consideramos exceção para adoção de práticas de entrega contínua. Chamamos isso de entrega contínua para aprendizado de máquina (CD4ML). Embora os princípios de CD permaneçam os mesmos, as práticas e ferramentas para implementar o processo de treinamento, teste, implantação e monitoramento de modelos de ponta a ponta demandam algumas modificações. Por exemplo: o controle de versão não deve incluir apenas o código, mas também os dados, os modelos e seus parâmetros; a pirâmide de testes se estende para incluir a validação de vieses, imparcialidade e dados e recursos do modelo; o processo de implantação deve considerar como promover e avaliar o desempenho de novos modelos em relação aos modelos de referência atuais. Embora o setor esteja entusiasmado com a nova palavra da moda, MLOps, sentimos que CD4ML é nossa abordagem holística para implementação de um processo de ponta a ponta para liberar de forma confiável e melhorar continuamente os modelos de aprendizado de máquina, da ideia à produção.

    Histórico
  • A malha de dados marca uma mudança bem-vinda de paradigma arquitetural e organizacional na forma como gerenciamos grandes dados analíticos. O paradigma é baseado em quatro princípios: (1) descentralização orientada a domínio da propriedade e da arquitetura de dados; (2) dados orientados a domínio e servidos como produto; (3) infraestrutura de dados de autoatendimento como uma plataforma para habilitar times autônomos de dados orientados a domínio; (4) governança federada para habilitar ecossistemas e interoperabilidade. Embora os princípios sejam intuitivos e tentem abordar muitos dos desafios conhecidos do gerenciamento centralizado de dados analíticos anterior, eles transcendem as tecnologias de dados analíticos disponíveis. Depois de construir a malha de dados para uma variedade de clientes em cima de ferramentas existentes, aprendemos duas coisas: (a) faltam ferramentas de código aberto ou comerciais para a aceleração da implementação da malha de dados (por exemplo, uma ferramenta para implementação de um modelo de acesso universal para dados poliglotas baseados em tempo, o que atualmente criamos de forma personalizada para clientes) e (b) apesar da indisponibilidade de ferramentas, é possível usar tecnologias existentes como blocos de construção básicos.

    Naturalmente, a adaptação da tecnologia é um componente importante da implementação de uma estratégia de dados com base na malha de dados em sua organização. O sucesso, no entanto, exige uma reestruturação organizacional para separar o time de plataforma de dados, a criação da função de product owner de dados para cada domínio e a introdução das estruturas de incentivo necessárias para que os domínios tenham propriedade e compartilhem seus dados analíticos como produtos.

    Histórico
  • Muitos pipelines de dados são definidos em um script grande, mais ou menos imperativo, escrito em Python ou Scala. O script contém a lógica das etapas individuais, bem como o código que as une. Quando confrontadas com uma situação semelhante nos testes Selenium, as pessoas desenvolvedoras descobriram o padrão Page Object e, posteriormente, muitos frameworks de desenvolvimento orientados a comportamento (BDD) implementaram uma divisão entre as definições de etapas e sua composição. Agora, alguns times estão tentando trazer o mesmo pensamento para a engenharia de dados. Uma definição de pipeline de dados declarativa separada, talvez escrita em YAML, contém apenas a declaração e a sequência de etapas. Ela indica conjuntos de dados de entrada e saída, mas faz referência a scripts se e quando uma lógica mais complexa for necessária. A La Mode é uma ferramenta relativamente nova que usa uma abordagem DSL para definir pipelines, mas airflow-declarative, uma ferramenta que transforma grafos acíclicos direcionados definidos em YAML em agendas de tarefas Airflow, parece ter mais força neste espaço.

    Histórico
  • Temos visto cada vez mais ferramentas que permitem criar arquitetura de software e outros diagramas como código. Há benefícios em usar essas ferramentas em relação às alternativas mais pesadas, incluindo controle de versão simples e capacidade de gerar DSLs de várias fontes. Entre as ferramentas de que gostamos neste espaço estão Diagrams, Structurizr DSL, AsciiDoctor Diagram e estáveis como WebSequenceDiagrams, PlantUML e o respeitável Graphviz. Também é bastante simples gerar seu próprio SVG atualmente, portanto, também não descarte a possibilidade de criar rapidamente sua própria ferramenta. Um de nossos autores escreveu um pequeno script Ruby para criar SVGs rapidamente, por exemplo.

    Histórico
  • Ao criar imagens do Docker para nossas aplicações, geralmente temos duas preocupações: a segurança e o tamanho da imagem. Tradicionalmente, usamos ferramentas de escaneamento de segurança de contêiner para detectar e corrigir vulnerabilidades e exposições comuns, e pequenas distribuições como Alpine Linux para tratar do tamanho da imagem e do desempenho da distribuição. Agora, temos mais experiência com imagens do Docker sem distribuição e podemos recomendar essa abordagem como mais uma precaução de segurança importante para aplicações em contêineres. Imagens do Docker sem distribuição reduzem o rastro e as dependências ao eliminar uma distribuição completa do sistema operacional. Essa técnica reduz o ruído da verificação de segurança e a superfície de ataque da aplicação. São menos vulnerabilidades a serem corrigidas e, como bônus, essas imagens menores são mais eficientes. O Google publicou um conjunto de imagens de contêiner sem distribuição para diferentes linguagens. Você pode criar imagens de aplicações sem distribuição usando a ferramenta de construção do Google Bazel ou simplesmente usar Dockerfiles de vários estágios (multistage). Observe que os contêineres sem distribuição, por padrão, não têm um shell para depuração. No entanto, você pode encontrar facilmente versões de depuração de contêineres sem distribuição online, incluindo um shell BusyBox. O uso de imagens do Docker sem distribuição é uma técnica pioneira do Google e, em nossa experiência, ainda é muito restrita a imagens geradas pela empresa. Esperamos que a técnica avance para além deste ecossistema.

    Histórico
  • À medida que mais empresas substituem seus sistemas legados, achamos que vale a pena destacar uma alternativa para a captura de dados alternados (CDC) como um mecanismo para obter dados desses sistemas. Martin Fowler descreveu a interceptação de eventos em 2004. Em termos modernos, ela envolve a bifurcação de solicitações na entrada em um sistema para que seja possível gradualmente construir um substituto. Frequentemente, isso é feito copiando eventos ou mensagens, mas a bifurcação de solicitações HTTP é igualmente válida. Os exemplos incluem bifurcação de eventos de sistemas de ponto de venda antes de serem gravados em um mainframe e bifurcação de transações de pagamento antes de serem gravadas em um sistema bancário central. Ambos levam à substituição gradual de partes dos sistemas legados. Sentimos que, como técnica, a obtenção de mudanças de estado da fonte, ao invés de tentar recriá-las pós-processamento usando CDC, tem sido esquecida, por isso estamos dando destaque a ela nesta edição do Radar.

    Histórico
  • Substituir código legado em escala é sempre uma tarefa difícil, que geralmente se beneficia da execução paralela com reconciliação. Na prática, a técnica se baseia na execução do mesmo fluxo de produção por meio do código antigo e do novo, retornando a resposta do código legado, mas comparando os resultados para ganhar confiança no novo código. Apesar de ser uma técnica antiga, vimos implementações mais robustas nos últimos anos, tendo como base práticas de entrega contínua, como implantações canário e feature toggles, e estendendo-as com a adição de uma camada extra de experimentação e análise de dados para comparar os resultados em tempo real. Usamos a abordagem até mesmo para comparar resultados interfuncionais, como tempo de resposta. Embora tenhamos usado a técnica várias vezes com ferramentas feitas sob medida, certamente devemos um reconhecimento à ferramenta Scientist, do GitHub, usada para modernizar uma parte crítica da aplicação e que agora foi disponibilizada para várias linguagens.

    Histórico
  • Conforme a pandemia se estende, parece que os times altamente distribuídos serão o "novo normal", pelo menos por enquanto. Nos últimos seis meses, aprendemos muito sobre trabalho remoto eficaz. Como pontos positivos, boas ferramentas visuais para gerenciamento de trabalho e colaboração tornaram mais fácil do que nunca colaborar remotamente com colegas. Os times de desenvolvimento, por exemplo, podem contar com o Visual Studio Live Share e o GitHub Codespaces para facilitar o trabalho coletivo e aumentar a produtividade. A maior desvantagem do trabalho remoto pode ser o esgotamento: muitas pessoas têm as agendas tomadas por videochamadas em sequência durante todo o dia, e essa dinâmica começa a ter consequências. Embora as ferramentas visuais online facilitem a colaboração, também é possível construir diagramas grandes e complexos que acabam sendo muito difíceis de usar, e os aspectos de segurança da proliferação de ferramentas também precisam ser gerenciados com cuidado. Nosso conselho é lembrar de dar um passo para trás, conversar com seus times, avaliar o que está funcionando e o que não está e alterar processos e ferramentas conforme necessário.

    Histórico
  • Enquanto a estrutura de computação e dados continua a mudar nas empresas — de aplicações monolíticas para microsserviços, de lagos de dados centralizados para malhas de dados, de hospedagem local a policloud, com uma crescente proliferação de dispositivos conectados — a abordagem para proteger ativos empresariais em sua maior parte permanece inalterada, com grande dependência e confiança no perímetro da rede: as organizações continuam fazendo investimentos pesados para proteger seus ativos, fortalecendo os muros virtuais de suas empresas, usando configurações de firewall e links privados, e substituindo processos de segurança estáticos e complexos que não atendem mais à realidade de hoje. Essa tendência contínua nos obrigou a destacar a arquitetura de confiança zero (ZTA) novamente.

    A ZTA é uma mudança de paradigma na arquitetura e na estratégia de segurança. Parte-se do pressuposto de que um perímetro de rede não representa mais um limite seguro, e nenhuma confiança implícita deve ser concedida a usuários ou serviços com base exclusivamente em sua localização física ou de rede. O número de recursos, ferramentas e plataformas disponíveis para implementar aspectos da ZTA continua crescendo, e inclui: aplicação de políticas como código, com base no menor privilégio e princípios mais granulares possíveis, além de monitoramento contínuo e mitigação automatizada de ameaças; uso da malha de serviços para impor o controle de segurança aplicação a serviço e serviço a serviço; implementação de atestado binário para verificação da origem dos binários; e inclusão de enclaves seguros, além da criptografia tradicional, para reforçar os três pilares da segurança de dados: em trânsito, em repouso e na memória. Para obter uma introdução ao tópico, consulte a publicação NIST ZTA e o artigo do Google sobre BeyondProd.

    Histórico

Avalie?

  • Uma das decisões mais complexas que as empresas enfrentam no momento é a adoção de plataformas de baixo código ou sem código, ou seja, plataformas que resolvem problemas muito específicos em domínios muito limitados. Muitas fornecedoras estão ocupando agressivamente este espaço. Os problemas que vemos com essas plataformas normalmente estão relacionados à incapacidade de aplicar boas práticas de engenharia, como controle de versão. Testar também é normalmente muito difícil. No entanto, notamos algumas novas participantes interessantes no mercado — incluindo Amazon Honeycode, que facilita a criação de aplicações simples de gerenciamento de tarefas ou eventos, e Parabola, para fluxos de trabalho em nuvem do tipo IFTTT. Por esse motivo, estamos incluindo as plataformas limitadas de baixo código nesta edição. No entanto, continuamos com dúvidas sobre sua aplicabilidade mais ampla, uma vez que essas ferramentas, assim como algumas espécies de plantas, têm por característica avançar para além de seus limites e se emaranhar com outras. Por isso, ainda recomendamos cautela em sua adoção.

    Histórico
  • Polyfills são extremamente úteis para ajudar a evoluir a web, fornecendo implementações que substituem recursos modernos para navegadores que não os implementam (ainda). Muitas vezes, porém, as aplicações web enviam polyfills para navegadores que não precisam deles, o que gera downloads desnecessários e sobrecarga de análise sintática. A situação está se tornando mais evidente agora, já que apenas alguns mecanismos de renderização permanecem em uso e a maior parte dos polyfills visa apenas um deles: o renderizador Trident no IE11. Além disso, a participação de mercado do IE11 está diminuindo com o encerramento do suporte em menos de um ano. Portanto, sugerimos que você use polyfills adaptados ao navegador , enviando apenas os polyfills necessários para um determinado navegador. Essa técnica pode até mesmo ser implementada como serviço com o Polyfill.io.

    Histórico
  • Em 2016, Christopher Allen, um importante contribuidor no espaço de SSL/TLS, nos inspirou com a introdução de 10 princípios sustentando uma nova forma de identidade digital e um caminho para chegar lá, o caminho para a identidade auto-soberana. A identidade auto-soberana, também conhecida como identidade descentralizada , é uma "identidade portátil vitalícia para qualquer pessoa, organização ou coisa que não dependa de nenhuma autoridade centralizada e jamais possa ser removida", de acordo com o padrão Trust over IP. A adoção e a implementação da identidade descentralizada vêm ganhando impulso e se tornando algo mais possível de alcançar. Vemos sua adoção em aplicações de saúde para clientes, infraestruturas de saúde governamentais e identidades jurídicas corporativas que respeitam a privacidade. Se você deseja adotar rapidamente a identidade descentralizada, pode avaliar sistemas de suporte como Sovrin Network, Hyperledger Aries e Indy, bem como padrões para identificadores descentralizados e credenciais verificáveis. Estamos observando este espaço de perto, enquanto ajudamos nossa base de clientes com seus posicionamentos estratégicos na nova era de confiança digital.

    Histórico
  • As provedoras de nuvem começaram lentamente a oferecer suporte a APIs estilo Kubernetes, por meio de definições de recursos personalizadas (CRDs), para gerenciar seus serviços de nuvem. Na maioria dos casos, esses serviços em nuvem são uma parte central da infraestrutura, e observamos times usarem ferramentas como Terraform ou Pulumi para provisioná-los. Com os novos CRDs (ACK para AWS, Azure Service Operator para Azure e Config Connectors para GCP), você pode usar Kubernetes para provisionar e gerenciar esses serviços em nuvem. Uma vantagem dos serviços de nuvem gerenciados por Kube é que você pode aproveitar o mesmo plano de controle do Kubernetes para forçar o estado declarativo tanto da sua aplicação quanto da sua infraestrutura. A desvantagem é que ele acopla fortemente o cluster do Kubernetes com a infraestrutura. Portanto, estamos avaliando-o cuidadosamente, e você também deve ter cautela.

    Histórico
  • Falamos muito sobre os benefícios da criação de times de produto de engenharia de plataforma em apoio aos outros times de produto, mas colocar isso em prática é difícil. A indústria parece ainda estar procurando a abstração certa no universo da infraestrutura como código. Embora ferramentas como Terraform e Helm sejam passos na direção certa, o foco ainda está no gerenciamento da infraestrutura, em oposição ao desenvolvimento de aplicações. Também há mudanças em relação ao conceito de infraestrutura como software, com novas ferramentas como Pulumi e CDK sendo lançadas. O Open Application Model (OAM) é uma tentativa de trazer alguma padronização para este espaço. Usando abstrações de componentes, configurações de aplicativos, escopos e características, as pessoas desenvolvedoras podem descrever suas aplicações de uma forma agnóstica de plataforma, enquanto as implementadoras da plataforma podem defini-la em termos de carga de trabalho, característica e escopo. Resta saber se o OAM será amplamente adotado, mas recomendamos ficar de olho nesta ideia interessante e necessária.

    Histórico
  • Enclaves seguros , também identificados como ambientes de execução confiáveis (TEE), referem-se a uma técnica que isola um ambiente — processador, memória e armazenamento — com um nível mais alto de segurança, fornecendo somente uma troca limitada de informações com seu contexto de execução circundante não-confiável. Por exemplo, um enclave seguro nos níveis de hardware e sistema operacional pode criar e armazenar chaves privadas e executar operações com elas, como criptografar dados ou verificar assinaturas, sem que as chaves privadas saiam do enclave seguro ou sejam carregadas na memória da aplicação não-confiável. O enclave seguro fornece um conjunto limitado de instruções para executar operações confiáveis, isoladas de um contexto de aplicação não-confiável.

    A técnica é há bastante tempo suportada por muitas fornecedoras de hardware e sistemas operacionais (incluindo a Apple), e as pessoas desenvolvedoras vêm a usando em aplicações de IoT e edge. Porém, apenas recentemente ela ganhou atenção em aplicações corporativas e baseadas em nuvem. As provedoras de nuvem começaram a introduzir recursos de computação confidencial, como enclaves seguros baseados em hardware: a infraestrutura de computação confidencial da Azure promete VMs habilitadas para TEE e acesso por meio da biblioteca de código aberto Open Enclave SDK para realizar operações confiáveis. Da mesma forma, o VMs confidenciais e Compute Engine, do GCP, ainda em beta, possibilita o uso de VMs com criptografia de dados na memória, e o AWS Nitro Enclaves está seguindo os mesmos passos com seu próximo lançamento de visualização. Com a introdução de enclaves seguros baseados em nuvem e computação confidencial, podemos adicionar um terceiro pilar à proteção de dados: em repouso, em trânsito e, agora, na memória.

    Embora ainda estejamos no início da jornada de enclaves seguros para empresas, encorajamos você a considerar essa técnica e se manter em dia com as informações sobre vulnerabilidades conhecidas que podem comprometer os enclaves seguros das fornecedoras de hardware subjacentes.

    Histórico
  • Experimentos controlados usando testes A/B são uma ótima maneira de embasar as decisões sobre o desenvolvimento de produtos. Mas não funcionam bem quando não podemos estabelecer independência entre os dois grupos envolvidos no teste A/B — ou seja, adicionar alguém ao grupo "A" afeta o grupo "B" e vice-versa. Uma técnica para resolver essa categoria de problema é a experimentação de switchback. O conceito central aqui é a alternância entre os modos "A" e "B" do experimento em uma determinada região, em períodos alternados, em vez de ambos executando durante o mesmo período. Em seguida, comparamos a experiência de cliente e outras métricas importantes entre os dois intervalos de tempo. Nós testamos essa técnica com bons resultados em alguns de nossos projetos — é uma boa ferramenta para ter em nossa caixa de ferramentas para experimentos.

    Histórico
  • As credenciais estão por toda parte em nossas vidas, incluindo passaportes, carteiras de habilitação e certificados acadêmicos. No entanto, a maioria das credenciais digitais hoje são registros de dados simples de sistemas de informação, fáceis de modificar e falsificar, e frequentemente expõem informações desnecessárias. Nos últimos anos, vimos o amadurecimento contínuo das credenciais verificáveis resolver esse problema. O padrão W3C define de uma forma criptograficamente segura, que respeita a privacidade e é verificável por máquina. O modelo coloca titulares de credenciais no centro, o que é semelhante à nossa experiência ao usar credenciais físicas: as pessoas usuárias podem colocar suas credenciais verificáveis em suas próprias carteiras digitais e mostrá-las a qualquer momento, sem necessidade de permissão da entidade emissora das credenciais. Essa abordagem descentralizada também permite que as pessoas usuárias gerenciem melhor suas próprias informações, podendo selecionar o que compartilhar e melhorando significativamente a proteção da privacidade dos dados. Por exemplo, usando tecnologia de prova de conhecimento zero, você pode criar uma credencial verificável para provar que é uma pessoa adulta sem revelar sua data de nascimento. A comunidade desenvolveu muitos casos de uso em torno das credenciais verificáveis. Nós implementamos nossa própria certificação para a COVID, tendo como referência a COVID-19 Credentials Initiative (CCI). Embora as credenciais verificáveis não dependam de tecnologia de blockchain ou de identidade descentralizada, essa técnica frequentemente funciona com identidade descentralizada na prática e usa blockchain como registro de dados verificáveis. Muitos frameworks de identidade descentralizada também incorporam credenciais verificáveis.

    Histórico

Evite?

  • Quando abordamos GraphQL pela primeira vez no Radar, advertimos que seu uso indevido poderia levar a antipadrões que, a longo prazo, trazem mais desvantagens do que benefícios. No entanto, vimos um interesse crescente no GraphQL entre nossos times devido à sua capacidade de agregar informações de diferentes recursos. Desta vez, queremos alertar sobre o uso de Apollo Federation e seu forte suporte para um único grafo de dados unificado para sua empresa. Embora à primeira vista a ideia de ter conceitos onipresentes em toda a organização seja tentadora, temos que levar em consideração tentativas anteriores semelhantes na indústria — como MDM e modelos de dados canônicos, entre outras — que expuseram as armadilhas desta abordagem. Os desafios podem ser significativos, especialmente quando o domínio em que nos encontramos é muito complexo para se criar um modelo unificado exclusivo.

    Histórico
  • Há muito tempo alertamos contra barramentos de serviços empresariais centralizados (ESBs) e definimos "endpoints inteligentes, pipes burros" como uma das principais características de uma arquitetura de microsserviços. Infelizmente, estamos observando um padrão de ESBs tradicionais passando por processos de rebranding, criando um cenário de ESBs disfarçados de gateways de API , que naturalmente encorajam gateways de API excessivamente ambiciosos. Não se deixe enganar pelo marketing: independentemente do nome que você dê para isso, colocar a lógica de negócio (incluindo orquestração e transformação) em uma ferramenta centralizada cria um acoplamento arquitetural, diminui a transparência e aumenta o aprisionamento a fornecedoras sem vantagens aparentes. Os gateways de API ainda podem atuar como uma abstração útil para questões transversais, mas acreditamos que a inteligência deve residir nas próprias APIs.

    Histórico
  • Vários anos atrás, surgiu uma nova geração de plataformas de agregação de logs, capazes de armazenar e pesquisar vastas quantidades de dados de log para descobrir tendências e insights de dados operacionais. Splunk foi o mais proeminente, mas de maneira alguma o único exemplo dessas ferramentas. Como essas plataformas fornecem ampla visibilidade operacional e de segurança em todo o conjunto de aplicações, pessoas desenvolvedoras e administradoras se tornaram cada vez mais dependentes delas. Esse entusiasmo se espalhou à medida que stakeholders descobriram que podiam usar a agregação de logs para análise de negócio. No entanto, as necessidades de negócio podem superar rapidamente a flexibilidade e a usabilidade dessas ferramentas. Os logs destinados à observabilidade técnica geralmente são inadequados para inferir uma compreensão profunda de clientes. Preferimos usar ferramentas e métricas projetadas especificamente para análise de clientes ou adotar uma abordagem mais orientada a eventos para a observabilidade, na qual os eventos comerciais e operacionais são coletados e armazenados de forma que possam ser reproduzidos e processados por ferramentas mais específicas.

    Histórico
  • Desde que introduzimos originalmente o termo em 2016, os micro frontends cresceram em popularidade e conquistaram aceitação do público em geral. Mas, como qualquer nova técnica com um nome fácil de lembrar, ocasionalmente ela foi mal utilizada. É particularmente preocupante a tendência de usar essa arquitetura como uma desculpa para misturar uma variedade de tecnologias, ferramentas ou frameworks concorrentes em uma única página, levando à anarquia de micro frontends. Um exemplo particularmente ruim dessa síndrome é o uso de vários frameworks de frontend — por exemplo, React.js e Angular — na mesma aplicação de "página única" (SPA). Embora isso possa ser tecnicamente possível, está longe de ser aconselhável quando não faz parte de uma estratégia de transição deliberada. Outras propriedades que devem ser consistentes entre os times incluem técnicas de estilo (por exemplo, CSS-in-JS ou módulos CSS) e os meios pelos quais os componentes individuais são integrados (por exemplo, iFrames ou componentes web). Além disso, as organizações devem decidir se padronizam abordagens consistentemente ou deixam que seus times decidam sobre o gerenciamento de estado, obtenção de dados, ferramentas de compilação, análises e uma série de outras opções em aplicações micro frontend.

    Histórico
  • Nas últimas décadas, notebooks computacionais, introduzidos pela primeira vez pelo Wolfram Mathematica, evoluíram para apoiar pesquisas científicas, explorações e fluxos de trabalho educacionais. Naturalmente, apoiando fluxos de trabalho de ciência de dados e com opções semelhantes aos notebooks Jupyter e Databricks, eles se tornaram grandes companheiros, fornecendo um ambiente de computação interativo, simples e intuitivo para combinação de código para analisar dados com texto rico, e visualização, para contar uma história a partir dos dados. Os notebooks foram projetados para fornecer um meio definitivo para comunicação e inovação científica moderna. Nos últimos anos, entretanto, vimos uma tendência de usar notebooks como meios para executar em produção código com o tipo de qualidade normalmente necessária para conduzir operações corporativas. Vemos fornecedoras de plataformas de notebook anunciando o uso de seus notebooks exploratórios em produção. Este é um exemplo de uma boa intenção — democratizar a programação para cientistas de dados — implementada de forma inadequada, prejudicando a escalabilidade, a manutenção, a resiliência e todas as outras qualidades que um código de produção de longa duração precisa suportar. Não recomendamos o uso de notebooks em produção e, em vez disso, incentivamos a habilitação de cientistas de dados para criar código pronto para produção com os frameworks de programação certos, simplificando assim o conjunto de ferramentas de entrega contínua e removendo a complexidade por meio de plataformas de ML de ponta a ponta.

    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