Master

Técnicas

Adote?

  • O padrão expansão e contração de API , também chamado de mudança paralela, é familiar para muitas pessoas, especialmente quando usado com bancos de dados ou código. No entanto, vemos baixa adoção quando se trata de APIs. Especificamente, temos visto esquemas de controle de versão complexos e mudanças significativas em cenários nos quais uma simples expansão, seguida por uma contração, seriam suficientes. Um exemplo seria adicionar primeiro a uma API enquanto um elemento existente é descontinuado e, em seguida, remover os elementos depreciados depois que a base de clientes for movida para o esquema mais recente. Essa abordagem requer alguma coordenação e visibilidade de clientes da API, talvez por meio de uma técnica como teste de contrato orientado a clientes.

    Histórico
  • Vemos a entrega contínua para aprendizado de máquina (CD4ML) como um bom ponto de partida para qualquer solução de aprendizado de máquina que esteja sendo implantada em produção. Muitas organizações estão se tornando mais dependentes de soluções de aprendizado de máquina tanto para ofertas para clientes quanto para operações internas. Portanto, faz sentido que os negócios apliquem as lições e boas práticas capturadas pela entrega contínua (CD) para soluções de aprendizado de máquina (ML).

    Histórico
  • À medida que o desenvolvimento de aplicações se torna cada vez mais dinâmico e complexo, é um desafio entregar produtos acessíveis e utilizáveis com estilo consistente. Isso vale particularmente para organizações maiores, com vários times trabalhando em produtos diferentes. Os sistemas de design definem uma coleção de padrões de design, bibliotecas de componentes e boas práticas de design e engenharia que garantem produtos digitais consistentes. Construídos com base nos guias de estilo corporativos do passado, os sistemas de design oferecem bibliotecas e documentos compartilhados que são fáceis de encontrar e usar. Geralmente, a orientação é escrita como código e mantida sob controle de versão para que o guia seja menos ambíguo e mais fácil de manter do que documentos simples. Os sistemas de design tornaram-se uma abordagem padrão para se trabalhar entre múltiplos times e disciplinas no desenvolvimento de produtos, porque permitem que os times se concentrem. Eles podem abordar desafios estratégicos em torno do próprio produto sem reinventar a roda toda vez que um novo componente visual for necessário.

    Histórico
  • Conforme observado em um dos temas desta edição, a indústria vem ganhando cada vez mais experiência com times de produto de engenharia de plataforma , que criam e oferecem suporte a plataformas internas. Essas plataformas são usadas pelos times de uma organização e aceleram o desenvolvimento de aplicações, reduzem a complexidade operacional e melhoram o tempo de chegada ao mercado. Com o aumento da adoção, também ficam mais evidentes os padrões bons e ruins dessa abordagem. Ao criar uma plataforma, é fundamental definir clientes e produtos que serão beneficiados, em vez de construí-la no vácuo. Advertimos contra times de plataforma em camadas que simplesmente preservam silos de tecnologia existentes sob o rótulo de "times de plataforma", e também contra modelos operacionais de plataforma orientados a tickets. Ainda defendemos fortemente o uso de conceitos da abordagem de topologias de time quando pensamos sobre a melhor forma de organizar times de plataforma. Consideramos os times de produto de engenharia de plataforma uma abordagem padrão e um facilitador significativo para a TI de alta performance.

    Histórico
  • Aconselhamos fortemente as organizações a certificarem-se – quando realmente for necessário usar contas de serviços em nuvem – de rotacionar as credenciais. Rotação é um dos três Rs da segurança. É muito comum que as organizações se esqueçam dessas contas até que um incidente ocorra. Como resultado, contas com permissões desnecessariamente amplas permanecem em uso por longos períodos, paralelamente a uma ausência de planejamento para substituí-las ou rotacioná-las. A aplicação regular de uma abordagem de rotação de contas de serviços em nuvem também oferece uma chance de exercer o princípio do menor privilégio.

    Histórico

Experimente?

  • À medida que a nuvem se torna cada vez mais uma commodity e a capacidade de criar sandboxes na nuvem se torna mais simples e disponível em escala, nossos times tendem a preferir ambientes de desenvolvimento somente na nuvem (em vez de locais) para reduzir a complexidade da manutenção. Temos observado que o conjunto de ferramentas para executar simulação local de serviços nativos da nuvem limita a confiança no build de desenvolvimento e nos ciclos de teste. Portanto, temos procurado nos concentrar na padronização de sandboxes de nuvem em vez de executar componentes nativos de nuvem em máquinas de pessoas desenvolvedoras. Isso impulsionará boas práticas de infraestrutura como código como uma função motriz e bons processos de integração para provisionar ambientes de sandbox para pessoas desenvolvedoras. Existem riscos associados a essa transição, pois pressupõe-se que as pessoas desenvolvedoras terão uma dependência absoluta da disponibilidade do ambiente de nuvem, o que pode desacelerar o ciclo de feedback de desenvolvimento. Recomendamos enfaticamente que você adote práticas de governança enxutas ao tratar da padronização desses ambientes de sandbox, especialmente no que se refere à segurança, IAM e implantações regionais.

    Histórico
  • Contextual bandits é um tipo de aprendizado por reforço, adequado para problemas que envolvem o dilema entre explorar investigando e explorar tirando proveito. Nomeado em referência às "bandits" – como são informalmente chamadas as máquinas caça-níqueis, em inglês –, o algoritmo investiga diferentes opções para aprender mais sobre os resultados esperados e equilibra tirando proveito das opções que funcionarem bem. Usamos com sucesso essa técnica em cenários com poucos dados disponíveis para treinar e implantar outros modelos de aprendizado de máquina. O fato de podermos adicionar contexto à relação explorar investigando e explorar tirando proveito torna a técnica adequada para uma ampla variedade de casos de uso, incluindo testes A/B, recomendações e otimizações de layout.

    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. Mas com o aumento das ameaças à segurança, eliminar todos os vetores de ataque possíveis se tornou mais importante do que nunca. É por isso que as imagens Docker sem distribuição estão se tornando a escolha padrão para contêineres de implantação. 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. Ficaríamos mais confortáveis se houvesse mais de uma provedora para escolhermos. Além disso, tenha cuidado ao aplicar Trivy ou scanners de vulnerabilidade semelhantes, uma vez que contêineres sem distribuição são suportados apenas em versões mais recentes.

    Histórico
  • O grupo por trás do Ethical OS — Omidyar Network, que se define como um empreendimento de transformação social, criado pelo fundador do eBay Pierre Omidyar — lançou uma nova iteração chamada Ethical Explorer. O novo pacote Ethical Explorer baseia-se nas lições aprendidas com o uso do Ethical OS e adiciona outras questões para os times de produto considerarem. O kit, que pode ser baixado gratuitamente e impresso em cartões para iniciar discussões, contém sugestões de perguntas abertas para várias "zonas de risco" técnicas, incluindo vigilância ("alguém pode usar nosso produto ou serviço para rastrear ou identificar outras pessoas usuárias?"), desinformação, exclusão, viés algorítmico, vício, controle de dados, agentes malfeitores e poder desproporcional. O guia de campo incluído tem atividades e workshops, ideias para iniciar conversas e dicas para obter adesão organizacional. Embora tenhamos um longo caminho a percorrer como indústria para melhor representar as externalidades éticas de nossa sociedade digital, tivemos algumas conversas produtivas usando o Ethical Explorer e a ampliação da consciência sobre a importância das decisões de produto ao abordar questões sociais nos encoraja.

    Histórico
  • Frequentemente, recebemos pedidos para atualizar, modernizar ou remediar sistemas legados que não foram originalmente criados por nós. Às vezes, questões técnicas como melhorar o desempenho ou a confiabilidade exigem nossa atenção. Uma abordagem comum para resolver essas questões é criar "histórias técnicas" usando o mesmo formato de uma história de usuário, mas com um resultado técnico em vez de comercial. Entretanto, as tarefas técnicas costumam ser difíceis de estimar, demoram mais do que o previsto ou acabam não tendo o resultado desejado. Um método alternativo, mais bem-sucedido, é aplicar a renovação de legado baseada em hipóteses. Em vez de caminhar em direção a um backlog padrão, o time assume a propriedade de um resultado técnico mensurável e estabelece coletivamente um conjunto de hipóteses sobre o problema. Em seguida, o time conduz experimentos iterativos, com tempo pré-definido, para verificar ou refutar cada hipótese seguindo a ordem de prioridade. O fluxo de trabalho resultante é otimizado para reduzir a incerteza em vez de seguir um plano em direção a um resultado previsível.

    Histórico
  • À medida que as organizações avançam em direção à arquitetura evolutiva, é importante capturar decisões sobre design, arquitetura, técnicas e formas de trabalho dos times. O processo de coleta e agrupamento de feedbacks que levará a essas decisões começa com os Request for Comments (RFCs). RFCs são uma técnica para coletar ideias de contexto, design e arquitetura e colaborar com os times para, em última instância, chegar a decisões considerando contexto e consequências. Recomendamos que as organizações adotem uma abordagem simples para RFCs , usando um modelo simplificado e padronizado para vários times, bem como controle de versão para capturar RFCs.

    É importante reuni-los em uma auditoria dessas decisões para beneficiar futuros membros dos times e para capturar a evolução técnica e comercial de uma organização. Organizações maduras têm usado RFCs em times autônomos para estimular uma melhor comunicação e uma colaboração mais eficiente, especialmente quando se trata de decisões relevantes para times multidisciplinares.

    Histórico
  • Todas as principais provedoras de nuvem oferecem uma gama impressionante de soluções de aprendizado de máquina (ML). Essas ferramentas poderosas podem fornecer muito valor, mas têm um custo. Existe o custo puramente de execução cobrado pelas provedoras de nuvem para esses serviços. Além disso, existe uma espécie de imposto operacional. Essas ferramentas complexas precisam ser compreendidas e operadas e, a cada nova ferramenta adicionada à arquitetura, essa carga tributária aumenta. Em nossa experiência, os times costumam escolher ferramentas complexas porque subestimam o poder de ferramentas mais simples, como a regressão linear. Muitos problemas de ML não exigem uma GPU ou redes neurais. Por esse motivo, defendemos o ML mais simples possível , usando ferramentas e modelos simples e algumas centenas de linhas de Python na plataforma de computação que você tem em mãos. Busque ferramentas complexas apenas quando puder demonstrar a necessidade delas.

    Histórico
  • O padrão da figueira estranguladora costuma ser a estratégia padrão para a modernização de legados, com o novo código envolvendo o antigo e absorvendo lentamente a capacidade de lidar com todas as funcionalidades necessárias. Esse tipo de abordagem "de fora para dentro" funciona bem para vários sistemas legados, mas agora que temos experiência suficiente com aplicações de página única (SPA), de forma que elas próprias se tornem sistemas legados, temos visto a abordagem oposta, "de dentro para fora", usada para substituí-las. Em vez de envolver o sistema legado, incorporamos desde o início a nova SPA ao documento HTML que contém a antiga, e deixamos que ela expanda lentamente em funcionalidade. Os frameworks de SPA nem precisam ser os mesmos, desde que os usuários possam tolerar o impacto no desempenho provocado pelo tamanho aumentado da página (por exemplo, incorporando um novo aplicativo React dentro de um antigo AngularJS. A injeção de SPA permite remover iterativamente a antiga SPA até que a nova assuma completamente. Considerando que uma figueira estranguladora pode ser vista como um tipo de parasita que usa a superfície externa estável da árvore hospedeira para se sustentar até que se enraíze e a própria hospedeira morra, esta abordagem seria como injetar um agente externo no hospedeiro, contando com a funcionalidade da SPA original até que esta possa assumir completamente.

    Histórico
  • A arquitetura de um sistema imita a estrutura organizacional e sua comunicação. Não é exatamente novidade que devemos ser intencionais em relação a como os times interagem — veja, por exemplo, a Manobra Inversa de Conway. A interação do time é uma das variáveis que determinam a rapidez e a facilidade com as quais os times podem entregar valor a clientes. Ficamos felizes em encontrar uma maneira de medir essas interações. Usamos a avaliação dos autores do livro Topologias de Time, que oferece uma compreensão de como pode ser fácil ou difícil para os times construir, testar e manter seus serviços. Medindo a carga cognitiva do time , fomos capazes de aconselhar melhor nossas clientes sobre como mudar a estrutura de seus times e evoluir suas interações.

    Histórico
  • Muitas de nossas pessoas desenvolvedoras que programam iOS no Xcode costumam ter dores de cabeça porque o arquivo Xcodeproj muda a cada mudança no projeto. O formato de arquivo Xcodeproj não é legível por seres humanos, portanto, tentar lidar com conflitos de merge é bastante complicado e pode levar à perda de produtividade e arrisca atrapalhar todo o projeto — se algo der errado com o arquivo, o Xcode não funcionará corretamente e as pessoas desenvolvedoras muito provavelmente ficarão bloqueadas. Em vez de tentar fazer merge e corrigir manualmente ou versionar o arquivo, recomendamos que você use uma abordagem de Xcodeproj gerenciado por ferramenta : defina a configuração do projeto Xcode em YAML (XcodeGen, Struct), Ruby (Xcake) ou Swift (Tuist). Essas ferramentas geram o arquivo Xcodeproj com base em um arquivo de configuração e na estrutura do projeto. Como resultado, os conflitos de merge no arquivo Xcodeproj ficarão no passado e, ainda que eventualmente aconteçam no arquivo de configuração, será muito mais fácil lidar.

    Histórico
  • Com TypeScript se tornando uma linguagem comum para desenvolvimento de front-end e Node.js se tornando a tecnologia preferida para BFF, estamos observando um aumento no uso de tipos compartilhados de UI/BFF. Nesta técnica, um único conjunto de definições de tipo é usado para definir tanto os objetos de dados retornados por consultas de front-end quanto os dados servidos para satisfazer essas consultas pelo servidor de back-end. Normalmente, abordaríamos essa prática com cautela por causa do acoplamento forte desnecessário que ela cria entre os limites do processo. No entanto, muitos times estão considerando que os benefícios dessa abordagem superam os riscos de um acoplamento forte. Uma vez que o padrão BFF funciona melhor quando o mesmo time é dono do código da UI e do BFF, geralmente armazenando ambos os componentes no mesmo repositório, o par UI/BFF pode ser visto como um único sistema coeso. Quando o BFF oferece consultas fortemente tipadas, os resultados podem ser ajustados às necessidades específicas do front-end, em vez de reutilizar uma única entidade de uso geral que deve atender às necessidades de vários consumidores e conter mais campos do que necessário. Isso reduz o risco de expor acidentalmente dados que o usuário não deveria ver, evita a interpretação incorreta do objeto de dados retornado e torna a consulta mais expressiva. Essa prática é particularmente útil quando implementada com io-ts para aplicar a segurança de tipo em tempo de execução.

    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 novamente 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
  • 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
  • Um radiador de desvio de implantação torna o desvio de versão visível para um software implantado em vários ambientes. As organizações que usam implantações automatizadas podem exigir aprovações manuais para ambientes que se aproximam de produção, o que significa que o código nesses ambientes pode estar atrasado em várias versões em relação à versão em desenvolvimento. Essa técnica torna esse atraso visível por meio de um painel simples que mostra o quão desatualizado está cada componente implantado em cada ambiente. Isso ajuda a destacar o custo de oportunidade de um software concluído que ainda não esteja em produção, ao mesmo tempo chamando atenção para os riscos relacionados, como correções de segurança ainda não implantadas.

    Histórico
  • A criptografia homomórfica refere-se a uma classe de métodos de criptografia que permitem que cálculos (como pesquisa e aritmética) sejam realizados diretamente em dados criptografados. O resultado de tais cálculos permanece na forma criptografada, que posteriormente pode ser descriptografada e revelada. Embora o problema da criptografia homomórfica tenha sido proposto pela primeira vez em 1978, uma solução não havia sido construída até 2009. Com avanços no poder da computação e a disponibilidade de bibliotecas de código aberto fáceis de usar — incluindo SEAL, Lattigo, HElib e criptografia parcialmente homomórfica em Python — a criptografia homomórfica está se tornando viável em aplicações do mundo real. Os cenários mais animadores incluem casos de uso de preservação de privacidade, em que a computação pode ser terceirizada para uma parte não confiável, por exemplo, executando computação em dados criptografados na nuvem ou permitindo que uma terceira parte agregue resultados de aprendizado de máquina federado intermediário criptografado homomorficamente. Além disso, a maioria dos esquemas de criptografia homomórfica são considerados seguros contra computadores quânticos, e esforços estão em andamento para padronizar a criptografia homomórfica. Apesar de suas limitações atuais, especificamente, desempenho e viabilidade dos tipos de cálculos, a criptografia homomórfica merece atenção.

    Histórico
  • Hotwire (HTML over the wire) é uma técnica para construir aplicações web. As páginas são construídas a partir de componentes, mas ao contrário das aplicações de página única (SPAs) modernas, o HTML dos componentes é gerado no lado do servidor e, em seguida, enviado pela rede ("over the wire") para o navegador. A aplicação possui apenas uma pequena quantidade de código JavaScript no navegador para juntar os fragmentos HTML. Nossos times, e sem dúvida outros times também, experimentaram essa técnica depois que as solicitações assíncronas web ganharam suporte para vários navegadores por volta de 2005, mas por várias razões, ela nunca ganhou muita força.

    Hoje, a abordagem Hotwire usa um navegador web moderno e recursos HTTP para atingir a velocidade, a capacidade de resposta e a natureza dinâmica de SPAs. Ela adota um design de aplicação web mais simples, localizando a lógica no servidor e mantendo o código do lado do cliente simples. A equipe da Basecamp lançou alguns frameworks Hotwire que alimentam sua própria aplicação, incluindo Turbo e Stimulus. O Turbo inclui um conjunto de técnicas e frameworks para acelerar a capacidade de resposta da aplicação, evitando o recarregamento da página inteira, visualização da página do cache e decomposição da página em fragmentos com aprimoramentos progressivos mediante solicitação. O Stimulus foi projetado para aprimorar o HTML estático no navegador, conectando objetos JavaScript aos elementos da página no HTML.

    Histórico
  • Ao compor uma aplicação a partir de vários micro frontends, alguma parte do sistema precisa decidir quais micro frontends carregar e de onde carregá-los. Até o momento, nós criávamos soluções customizadas ou usávamos um framework mais abrangente, como o single-spa. Agora, existe um novo padrão, import maps, que ajuda em ambos os casos. Nossas primeiras experiências mostram que import maps para micro frontends permite uma separação organizada de responsabilidades. O código JavaScript indica o que importar e uma pequena tag de script na resposta HTML inicial especifica de onde carregar os frontends. Esse HTML é obviamente gerado no lado do servidor, o que torna possível usar alguma configuração dinâmica durante sua renderização. De muitas maneiras, essa técnica nos lembra dos caminhos de vinculadores/carregadores para bibliotecas Unix dinâmicas. No momento, import maps são compatíveis apenas com o Chrome, mas com o polyfill SystemJS, eles podem ser usados de forma mais ampla.

    Histórico
  • O Open Application Model (OAM) é uma tentativa de trazer alguma padronização para o espaço de modelagem de plataformas de infraestrutura como produtos. Usando abstrações de componentes, configurações de aplicações, escopos e características, as pessoas desenvolvedoras podem descrever suas aplicações de uma forma agnóstica de plataforma, enquanto quem implementa a plataforma pode defini-la em termos de carga de trabalho, característica e escopo. Desde a última vez que falamos sobre o OAM, acompanhamos de perto uma de suas primeiras implementações, a KubeVela. A KubeVela está perto de lançar a versão 1.0, e temos curiosidade em saber se implementações como essa podem justificar a promessa por trás da ideia do OAM.

    Histórico
  • Web analytics com foco em privacidade é uma técnica para coletar web analytics sem comprometer a privacidade da pessoa usuária final, mantendo-a verdadeiramente anônima. Uma consequência espantosa da conformidade com o Regulamento Geral de Proteção de Dados (GDPR) é a decisão tomada por muitas organizações de degradar a experiência de uso com processos complexos de consentimento de cookies, especialmente quando a pessoa usuária não consente imediatamente as configurações padrão de “todos os cookies”. Web analytics com foco em privacidade tem o benefício duplo de observar o espírito e o texto do GDPR, ao mesmo tempo que evita a necessidade de introduzir formulários intrusivos de consentimento de cookies. Uma implementação dessa abordagem pode ser vista no Plausible.

    Histórico
  • A programação em grupo é uma daquelas técnicas que nossos times consideram mais fácil de ser executada remotamente. A programação em grupo remota permite que os times rapidamente se agrupem em torno de um problema ou de parte do código sem as restrições físicas de poder acomodar apenas um determinado número de pessoas ao redor de uma estação de pareamento. Os times podem colaborar rapidamente em um problema ou código sem ter que se conectar a um grande display, reservar uma sala de reunião física ou usar um quadro branco.

    Histórico
  • A computação multipartidária segura (MPC) resolve o problema da computação colaborativa protegendo a privacidade entre as partes que não confiam umas nas outras. Seu objetivo é calcular com segurança um problema acordado sem uma terceira parte confiável, com cada participante obrigatoriamente participando do resultado do cálculo, sem que ele possa ser obtido por outras entidades. Uma ilustração simples para a MPC é o problema dos milionários, no qual duas pessoas milionárias querem entender qual delas é a mais rica, mas nenhuma das duas quer compartilhar seu patrimônio líquido real com a outra nem confiar em uma terceira parte. As abordagens de implementação da MPC variam: os cenários podem incluir compartilhamento de segredos, transferência inconsciente, circuitos truncados ou criptografia homomórfica. Algumas soluções comerciais de MPC que surgiram recentemente (por exemplo, Antchain Morse) afirmam ajudar a resolver os problemas de compartilhamento de segredos e aprendizado de máquina seguro em cenários como investigação multipartidária de crédito conjunto e intercâmbio de dados de registros médicos. Embora essas plataformas sejam atraentes do ponto de vista de marketing, ainda precisamos entender se elas são realmente úteis.

    Histórico

Evite?

  • Sugerimos certo cuidado ao abordar GitOps , especialmente em relação às estratégias de branching. GitOps pode ser visto como uma forma de implementar infraestrutura como código que envolve a sincronização contínua e aplicação de código de infraestrutura do Git em vários ambientes. Quando usado com uma infraestrutura de "branch por ambiente", as alterações são promovidas de um ambiente para o outro por meio de merges do código. Embora tratar o código como a única fonte de verdade seja nitidamente uma abordagem correta, estamos vendo branches por ambiente levarem a desvios de ambientes e, eventualmente, configurações específicas do ambiente conforme os merges de código se tornam problemáticos ou até mesmo param completamente. Isso é muito semelhante ao que vimos no passado com branches de longa duração com GitFlow.

    Histórico
  • A explosão de interesse em torno das plataformas de software gerou muito valor para as organizações, mas o caminho para a construção de um modelo de entrega baseado em plataforma está repleto de potenciais becos sem saída. É comum em meio ao entusiasmo com novos paradigmas ver técnicas mais antigas ressurgindo repaginadas para incorporar o novo vernáculo, contribuindo para perdermos de vista as razões pelas quais superamos essas técnicas em primeiro lugar. Para ver um exemplo dessa repaginação, veja nosso blip sobre os tradicionais ESBs disfarçados de gateways de API na edição anterior do Radar. Outro exemplo que estamos vendo é a reformulação da abordagem de divisão de times por camada de tecnologia, mas chamando-os de times de plataformas. No contexto de construção de uma aplicação, costumava ser comum ter um time de front-end separado do time de lógica de negócio, por sua vez separado do time de dados. Vemos analogias a esse modelo quando as organizações segregam os recursos da plataforma entre times dedicados a um negócio ou camada de dados. Graças à Lei de Conway, sabemos que a organização de times de recursos de plataforma em torno de recursos de negócios é um modelo mais eficaz, dando aos times a propriedade de ponta a ponta do recurso, incluindo a propriedade dos dados. Isso ajuda a evitar as dores de cabeça com gerenciamento de dependências de times de plataforma em camadas , com o time de front-end aguardando o time de lógica de negócio aguardando o time de dados para conseguir concluir qualquer coisa.

    Histórico
  • As políticas de senha são um padrão comum para muitas organizações hoje. No entanto, ainda vemos organizações exigindo que as senhas incluam uma variedade de símbolos, números, letras maiúsculas e minúsculas, bem como a inclusão de caracteres especiais. Esses são requisitos ingênuos de complexidade de senha , que levam a uma falsa sensação de segurança, pois as pessoas usuárias optam por senhas mais inseguras porque a alternativa é difícil de lembrar e digitar. De acordo com as recomendações do NIST (National Institute of Standards and Technology), o principal fator na força da senha é o tamanho da senha e, portanto, as pessoas usuárias devem escolher senhas compostas por frases longas com um requisito máximo de 64 caracteres (incluindo espaços). Essas senhas são mais seguras e fáceis de memorizar.

    Histórico
  • Algumas organizações parecem acreditar que a revisão por pares significa pull request. Elas consideram que a única maneira de se obter uma revisão por pares do código é por meio de um pull request. Vimos essa abordagem criar gargalos significativos para o time, além de degradar significativamente a qualidade do feedback, à medida que pessoas revisoras sobrecarregadas passam a simplesmente rejeitar as solicitações. Embora seja possível argumentar que esta é uma maneira de demonstrar a "conformidade regulamentar" (regulatory compliance) da revisão do código, uma de nossas clientes foi informada de que esse argumento era inválido, pois não havia evidências de que o código foi realmente lido por alguém antes da aceitação. Pull requests são apenas uma maneira de gerenciar o fluxo de trabalho de revisão de código. Encorajamos as pessoas a considerarem outras abordagens, especialmente quando houver necessidade de ensinar e transmitir feedback com cuidado.

    Histórico
  • Nosso posicionamento sobre "ser ágil antes de fazer ágil" e nossas opiniões sobre o tema não devem ser uma surpresa. Mas já que o SAFe™ (Scaled Agile Framework®), segundo relatório da Gartner de maio de 2019, é o framework ágil corporativo mais considerado e usado e, como vemos cada vez mais empresas passando por mudanças organizacionais, achamos que era hora de ampliar a conscientização sobre esse assunto novamente. Nós nos deparamos com organizações tendo dificuldades com os processos super padronizados e em fases super controladas do SAFe. Esses processos criam atritos na estrutura organizacional e em seu modelo operacional. O framework também pode promover silos na organização, impedindo que as plataformas se tornem de fato habilitadoras de recursos de negócios. O controle top-down gera desperdício no fluxo de valor e desestimula a criatividade dos talentos de engenharia, limitando a autonomia e a experimentação nos times. Em vez de medir esforço e se concentrar em cerimônias padronizadas, recomendamos uma abordagem e uma governança mais enxutas e orientadas a valor para ajudar a eliminar atritos organizacionais – como a abordagem EDGE –, além de uma avaliação de carga cognitiva do time, para identificar os tipos de time e determinar como podem interagir melhor entre eles.

    Scaled Agile Framework® e SAFe™ são marcas registradas da Scaled Agile, Inc.

    Histórico
  • O ideal, especialmente quando os times praticam DevOps, é que o pipeline de implantação e o código sendo implantado pertençam ao mesmo time. Infelizmente, ainda vemos separação da propriedade do código e do pipeline em algumas organizações, com a configuração do pipeline de implantação ficando sob responsabilidade do time de infraestrutura. Essa prática resulta em atrasos nas mudanças, barreiras para melhorias, além de falta de propriedade e envolvimento do time de desenvolvimento nas implantações. Uma das causas disso pode nitidamente ser a separação do time. Outra pode ser o desejo de manter processos e funções de “gatekeeper”. Embora possa haver razões legítimas para usar essa abordagem (por exemplo, controle regulatório), de forma geral, a consideramos trabalhosa e inútil.

    Histórico
  • Um dos objetivos principais de uma plataforma deve ser reduzir os processos baseados em tickets a um mínimo absoluto, pois eles criam filas no fluxo de valor. Infelizmente, vemos que as organizações ainda não insistem o suficiente nesse importante objetivo, resultando em um modelo operacional de plataforma orientado a tickets. Isso é particularmente frustrante quando os processos baseados em tickets são colocados à frente de plataformas que são construídas tendo como base recursos de autoatendimento e orientados a API de fornecedoras de nuvem pública. Chegar ao autoatendimento com pouquíssimos tickets desde o início é difícil e desnecessário, mas precisa ser o destino.

    O excesso de dependência na burocracia, bem como a falta de confiança, estão entre as causas dessa relutância em abandonar os processos baseados em tickets. Implementar mais verificações e alertas automatizados em sua plataforma é uma maneira de ajudar a romper a dependência nos processos de aprovação com tickets. Por exemplo, dando aos times visibilidade sobre seus custos de execução e colocando barreiras automatizadas para evitar explosões acidentais de custos. Implemente uma política de segurança como código e use scanners de configuração ou analisadores como Recommender para ajudar os times a fazerem a coisa certa.

    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