Technology Radar

Na Thoughtworks, somos há muito tempo fãs do software de código aberto, em parte popularizado pelo famoso ensaio "A Catedral e o Bazar" de Eric Raymond. O software de código aberto melhora a mobilidade da pessoa desenvolvedora e colabora com correções de erros e inovações. No entanto, as tentativas de comercialização demonstram a enorme complexidade econômica do ecossistema atual. Veja, por exemplo, a AWS fazendo um fork do Elasticsearch para o OpenSearch em setembro de 2021, em resposta à mudança de licença da Elastic que passou a exigir contribuição das provedoras de serviços em nuvem que lucram com seu trabalho. Isso mostra como pode ser difícil para o software comercial de código aberto se manter competitivo (a mesma preocupação se aplica ao software livre de código fechado; observamos, por exemplo, algumas empresas explorando alternativas ao Docker Desktop devido ao esforço contínuo do Docker para encontrar o modelo comercial certo.) Às vezes, a dinâmica do poder funciona de maneira inversa: pelo fato de ter sido financiado pelo Facebook como um software aberto, a equipe responsável pelo Presto conseguiu manter a propriedade intelectual e renomeá-lo como Trino depois de deixarem a empresa, beneficiando-se efetivamente do investimento do Facebook. A situação se torna ainda mais complexa pela quantidade de infraestrutura crítica que não é patrocinada pelas empresas, que geralmente só se dão conta do quanto dependem de mão de obra não remunerada quando um erro crítico de segurança é descoberto (como aconteceu recentemente com o Log4J). Em alguns casos, o financiamento de indivíduos e times que desenvolvem como hobby fornece impulso suficiente para fazer a diferença. Em outros, isso simplesmente cria um sentimento adicional de responsabilidade para além do trabalho diário e contribui para o esgotamento. Continuamos a defender fortemente o software de código aberto, mas reconhecemos que esse mercado vem se tornando cada vez mais bizarro, e não há soluções simples para encontrar um equilíbrio ideal.

Instâncias públicas de problemas graves — como o vazamento de dados da Equifax, o ataque da SolarWinds, a vulnerabilidade remota de dia zero do Log4J e assim por diante — foram causadas pela má governança da cadeia de fornecimento de software. Os times agora se dão conta de que entre as práticas responsáveis de engenharia ​​estão a validação e a governança das dependências do projeto, que geraram várias entradas nesta edição do Radar. Entre os blips, estão listas de verificação e padrões, como Supply-chain Levels for Software Artifacts (SLSA), um consórcio apoiado pelo Google para fornecer orientações sobre ameaças padrão à cadeia de fornecimento e CycloneDX, outro conjunto de padrões impulsionado pela comunidade OWASP. Também apresentamos ferramentas concretas como Syft, que gera uma lista de materiais de software (SBOM) a partir de imagens de contêiner. Hackers estão se aproveitando cada vez mais da natureza assimétrica por trás da lógica de ataque e defesa na área de segurança – para atacar só precisam encontrar uma vulnerabilidade, enquanto para defender é necessário proteger toda a superfície de ataque –, aplicando técnicas cada vez mais sofisticadas. A segurança aprimorada da cadeia de fornecimento é uma parte crítica de nossa resposta à medida que trabalhamos para manter os sistemas seguros.

Categorias de frameworks em rápido crescimento parecem ser um padrão comum no Radar: um framework básico se torna popular, sendo seguido por uma série de ferramentas que criam um ecossistema para lidar com evoluções e deficiências comuns, finalizando com a consolidação em torno de algumas ferramentas populares. No entanto, o gerenciamento de estado do React parece resistente a essa tendência comum. Desde que o Redux foi lançado, observamos um fluxo constante de ferramentas e frameworks que gerenciam estado de maneiras ligeiramente diferentes, cada uma com um conjunto diferente de compensações. Não sabemos por quê, então podemos apenas especular: essa é a rotatividade natural que o ecossistema JavaScript parece promover? É uma deficiência subjacente no React, um problema divertido e aparentemente tratável que incentiva as pessoas desenvolvedoras a experimentar? Ou é a incompatibilidade de impedância permanente entre um formato de leitura de documentos (navegadores web) e a interatividade necessária (e o estado) para hospedar o desenvolvimento de aplicações em cima de documentos? Não sabemos o motivo, mas aguardamos com curiosidade a próxima rodada de tentativas de solução para esse problema aparentemente perpétuo.

O desejo de obter mais valor dos ativos de dados corporativos impulsiona grande parte do investimento em tecnologia digital que vemos hoje. Em sua essência, esse esforço geralmente se concentra em melhores maneiras de encontrar e acessar todos os dados relevantes. Por quase tanto tempo quanto as empresas coletam dados digitais, existem esforços para racionalizá-los e catalogá-los em um único diretório corporativo hierárquico. Mas, seguidamente, essa noção intuitivamente atraente esbarra na dura realidade da complexidade, redundância e ambiguidade inerentes às grandes organizações. Recentemente, notamos um interesse renovado em catálogos de dados corporativos e uma onda de submissões de blips para o Radar sugerindo novas ferramentas inteligentes, como Collibra e DataHub. Essas ferramentas podem fornecer acesso consistente e detectável à linhagem e metadados em silos, mas seus conjuntos de recursos em expansão também se estendem a governança, gerenciamento de qualidade, publicação e muito mais.

Em contraste com essa tendência, também parece haver um movimento crescente de afastamento do gerenciamento de dados centralizado e hierarquizado, em direção à governança e descoberta federadas com base em uma arquitetura de malha de dados. Essa abordagem lida com a complexidade inerente dos dados corporativos, definindo expectativas e padrões de forma centralizada, mas segregando a custódia de dados ao longo das linhas de domínio do negócio. Os times de produtos de dados orientados a domínio controlam e compartilham seus próprios metadados, incluindo capacidade de descoberta, qualidade e outras informações. Nesse cenário, o catálogo é apenas uma forma de apresentar informações para pesquisa e navegação. Os catálogos de dados resultantes são mais simples e fáceis de manter, reduzindo a necessidade de plataformas de governança e catalogação ricas em recursos.