Tendências macro na indústria de tecnologia | Abril de 2019

Views: 569
0 0
Read Time:8 Minute, 18 Second

Sempre que publicamos um Radar de Tecnologia, dou uma olhada em tendências mais amplas do setor de tecnologia que não necessariamente entram no radar como blips ou temas. Criar o radar é uma excelente chance de dissecar o que está acontecendo no mundo do software, eis o mais recente:

Compre agora, pague depois

Nos últimos anos, vimos uma ênfase crescente na ” experiência do desenvolvedor ” de ferramentas e plataformas. Seja um IDE, uma biblioteca de código aberto ou algum tipo de plataforma em nuvem, a facilidade com que os desenvolvedores podem usar e adotar é cada vez mais importante. Isso é uma coisa boa e muitas vezes uma força motriz para a inovação. Tratar os desenvolvedores como clientes do seu produto pode definitivamente ajudar você.

No entanto, estamos começando a ver problemas quando a facilidade de uso de uma ferramenta para uma situação desliza por uma ladeira escorregadia e passa a “desvalorizar” em outro caso de uso. Como exemplo, temos os notebooks Jupyter em produçãoem espera. Consideramos o Jupyter uma excelente ferramenta para analisar dados para chegar a conclusões e tirar idéias, mas se você deseja usar o Jupyter diretamente na produção (em vez de portar seu código para uma linguagem mais orientada à produção, como Python), você pode criar dor para si mesmo.

Da mesma forma, é fácil soltar um arquivo em um bucket do Amazon S3, conectá-lo ao Serviço de Notificação Simples (SNS) e acionar um Llambda para processar seu conteúdo, mas o emaranhado de infraestrutura associado pode causar mais problemas do que vale a pena.

Realmente, esta é a última encarnação da regra dos 80% e a necessidade de entendê-la. Muitas ferramentas fornecerão grande aceleração para 80% dos casos de uso. Eles apenas trabalham. Nos próximos 10%, você provavelmente ainda poderá fazer o que quiser. Mas para esses 10% finais, você pode ter trabalhado em um canto e estar em um estado de “pagar mais tarde”. Você pode realmente trabalhar com a complexidade de obter esses 10% finais? Muitas equipes fariam bem em se afastar do problema de vez em quando e perguntar: devemos lidar com a dor ou devemos considerar uma ferramenta diferente para o nosso caso de uso?

O modelo operacional de microsserviços

Meu antigo colega Aaron Erickson costumava descrever os microsserviços como a primeira arquitetura “nativa da nuvem” verdadeira, e certamente achamos que é uma escolha razoável para os sistemas modernos. As equipes devem ter cuidado com a inveja dos microsserviços e entender que o comércio de microsserviços reduziu a complexidade do desenvolvimento para aumentar a complexidade operacional . Ou seja, embora cada serviço seja mais simples, a coreografia necessária para que todos trabalhem juntos é muito mais difícil do que com uma arquitetura monolítica.

Com a popularidade contínua dos microsserviços, estamos vendo uma maturidade crescente em torno da execução de microsserviços com o gerenciamento de serviço ‘adequado’. As técnicas antigas de operações foram reinventadas com novos nomes, como “orçamentos de erro”. Os SLOs fornecem às equipes métricas claras a serem usadas ao determinar se uma abordagem de “você constrói, executa” está funcionando. Malhas de serviço , como o Istio , suportam diretamente esses conceitos de gerenciamento de serviço. Observabilidade é um termo na boca de todos, e as equipes estão trabalhando duro para garantir que a saúde de seus sistemas seja adequadamente visível para as ferramentas de monitoramento.

Um verdadeiro “modelo operacional de microsserviços” também inclui mudanças no design e nas responsabilidades da equipe e nos impactos organizacionais associados. Esses modelos estão começando a surgir, mas acreditamos que eles devem se basear na identificação de uma série de recursos de negócios e de plataformas, alinhando equipes de longa vida que planejam, constroem e executam produtos para fornecer esses recursos. É muito cauteloso contra a idéia de criar uma equipe monolítica de “plataforma” ou simplesmente esperar que os recursos compartilhados de negócios surjam por acaso e sejam curados por osmose.

Melhoria implacável

Se há algo que diferencia tecnólogos ‘bons’ de ‘ótimos’ (não importa sua área específica de especialização), é que as pessoas que são ótimas em alguma coisa nunca ficam satisfeitas com a solução atual e trabalham para criar uma resposta melhor. Como indústria, aprimoramos incansavelmente nossos projetos antigos. Pode haver uma boa solução para um problema, mas alguém cria uma solução melhor e, em seguida, iteramos.

Exemplos neste espaço são abundantes. O Taiko é uma biblioteca de nós para automatizar o navegador Chrome e visa ter uma API clara e concisa. Não é que nunca tenhamos tentado testar no navegador antes, mas está melhorando a cada etapa. Deno , um mecanismo JavaScript e TypeScript seguro do lado do servidor, é do criador original do Node.js e foicriado em resposta direta às áreas que considerava serem as maiores áreas problemáticas do Node. O Gremlin é uma linguagem transversal de gráfico que melhora em relação aos seus antecessores. O Immer.js ganhou o prêmio de “avanço do ano” por sua progressão do estado da arte em árvores estatais imutáveis. O Micronaut é uma estrutura para a criação de aplicativos de microsserviço e sem servidor e nos leva a um passo significativo nesse espaço.

Essas etapas individuais hoje levam às inovações de amanhã, que, como dissemos antes, são fundamentalmente imprevisíveis (um princípio central da Arquitetura Evolucionária é construir sistemas sabendo que não podemos prever com eficácia essas mudanças).
 Daqui a dois anos, simplesmente não sabemos como as implacáveis ​​melhorias em uma única etapa se combinarão para produzir algo revolucionário.

Empurrando a configuração muito longe

Nossas discussões sobre radar incluíram um tempo significativo sobre o problema de “codificação na configuração” e a inclinação escorregadia que parece acontecer onde uma linguagem de configuração simples eventualmente cresce e cresce, e você termina com “XML completo de Turing” que é muito difícil de testar e raciocinar sobre. Isso parece acontecer em muitas situações, de arquivos de compilação a arquivos de configuração do Terraform modelados. As equipes geralmente decidem que é mais fácil executar código testado em uma linguagem de programação do que usar uma ferramenta que transformamos em configuração programável.

Kief Morris, autor de Infraestrutura como código, acha que o problema subjacente é que não conseguimos manter limites claros entre o que é configuração e o que é lógica. Na sua opinião, não devemos testar arquivos de configuração e não devemos definir um estado de destino com lógica programável. Se você estiver fazendo um desses, é um cheiro que você entendeu errado os limites.

Morris sugere que linguagens declarativas precisam facilitar sua extensão adicionando lógica a componentes separados e testáveis. Ele diz: “Se eu quiser adicionar uma coisa nova , posso declarar, estenda a linguagem declarativa para adicionar uma definição e implemente a lógica ‘como’ que essa definição aciona em uma linguagem adequada, com testes”.


Complexidade da orquestração em ascensão

Uma tendência geral no cenário tecnológico é a crescente complexidade geral, e vemos isso com um aumento na orquestração necessária entre os componentes. O Luigi é uma nova ferramenta no espaço de dados que ajuda a criar pipelines complexos de tarefas em lote. O Apache Airflow permite criar, agendar e monitorar programaticamente fluxos de trabalho. Agora, temos todos os tipos de novidades em nossos sistemas – funções como serviço, fluxos de trabalho, processos Python e assim por diante.

Neal Ford, citando deliberadamente Dijkstra em nossa recente reunião do Radar, diz: “Nós dissociamos tanto as coisas que quase acabamos com um espaguete de coisas, e agora precisamos reuni-las para tornar algo útil”.

É importante lembrar que a orquestração em si não é ruim. É como acoplamento. Você precisa de uma certa quantia para realmente fazer um sistema funcionar e fornecer valor. Se a orquestração é ruim ou não, depende de quão difundida é dentro de um aplicativo e de quão difundida é.

Difusão de Comportamento nos Negócios

As organizações que enfrentam problemas que levam a configuração muito longe e a complexidade da orquestração são sintomas de uma tendência maior: a lógica de negócios não está mais confinada a pequenos pedaços de código, na verdade, é difundida em todo o sistema. A lógica de negócios é encontrada na maneira como configuramos os pods do Kubernetes e na maneira como orquestramos nossas funções lambda. Scott Shaw coloca assim: “Existe uma noção antiquada de que você tem uma ‘carga de trabalho’ e pode movê-la para lugares diferentes. Há responsabilidades para gravar a carga de trabalho, hospedar a carga de trabalho, e o plano de controle e o aplicativo são bem separados. E isso não é mais verdade. ”

Para ser um pouco mais preciso, os negóciosa lógica é sem dúvida apenas o material que faz cálculos. Mas há decisões relevantes para os negócios a serem tomadas. O que devemos fazer se precisarmos escalar dessa maneira? Como devemos degradar sob carga? Essas são perguntas para o proprietário de um produto e são lógicas de negócios, mas não no sentido tradicional. Decidimos a frase “comportamento comercial” para abranger esses tipos de características.

Nosso conselho é que as equipes primeiro percebam que essa difusão ocorreu. Na arquitetura da velha escola, tudo o que significaria estaria na camada de domínio comercial. Mas isso acabou agora, a lógica equivalente difundiu uma combinação de infraestrutura, configuração, microsserviços e integrações. Funções sem servidor orientadas a eventos, arquivos em um bucket S3 acionando um lambda – é muito difícil acompanhar o fluxo da lógica em um sistema. As equipes devem se esforçar para usar padrões que tornem o comportamento geral mais fácil de entender, possivelmente até reduzindo o número de tecnologias usadas em qualquer sistema.

FONTE: https://origin.thoughtworks.com/insights/blog/macro-trends-tech-industry-april-2019

POSTS RELACIONADOS