Master
ThoughtWorks
Menu
Fechar
  • O que fazemos
    • Visão geral
    • Experiência de Cliente, Produto e Design
    • Estratégia, Engenharia e Análise de Dados
    • Operação e Transformação Digital
    • Modernização Empresarial, Plataformas e Nuvem
  • Com quem trabalhamos
    • Visão geral
    • Setor automotivo
    • Saúde
    • Setor público
    • Cleantech, energia e utilidade pública
    • Mídia
    • Varejo e e-commerce
    • Serviços financeiros e seguros
    • Organizações sem fins lucrativos
    • Viagem e transporte
  • Insights
    • Visão geral
    • Destaques

      • Tecnologia

        Uma análise abrangente de tecnologias e práticas de engenharia nas empresas

      • Negócios

        Mantenha-se em dia com as mais recentes tendências da indústria

      • Cultura

        Um espaço para conteúdo sobre desenvolvimento profissional e nossa visão sobre justiça social e inclusão

    • Ferramentas e Publicações Digitais

      • Technology Radar

        Um guia com opiniões firmes sobre as fronteiras da tecnologia

      • Perspectives

        Uma publicação para líderes digitais

      • Modelo de Fluência Digital

        Um modelo para priorizar as competências digitais necessárias para se navegar a incerteza

      • Decoder

        Um guia de A a Z sobre tecnologia para lideranças executivas

    • Todos os Insights

      • Artigos

        Visões de especialistas para ajudar seu negócio a crescer

      • Blogs

        Pontos de vista pessoais de ThoughtWorkers de todo o mundo

      • Livros

        Explore nossa vasta biblioteca

      • Podcasts

        Discussões instigantes sobre as últimas novidades em negócios e tecnologia

  • Carreiras
    • Visão geral
    • Processo de aplicação

      O que esperar de uma entrevista conosco

    • Pessoas em início ou mudança de carreira

      Comece sua jornada na tecnologia aqui

    • Vagas abertas

      Encontre oportunidades na sua região

    • Conecte-se

      Assine nossa newsletter mensal

  • Sobre
    • Visão geral
    • Nosso propósito
    • Prêmios e reconhecimentos
    • Diversidade, equidade e inclusão
    • Nossas lideranças
    • Parcerias
    • Notícias
    • Conferências e eventos
  • Contato
Brazil | Português
  • United States United States
    English
  • China China
    中文 | English
  • India India
    English
  • Canada Canada
    English
  • Singapore Singapore
    English
  • United Kingdom United Kingdom
    English
  • Australia Australia
    English
  • Germany Germany
    English | Deutsch
  • Brazil Brazil
    English | Português
  • Spain Spain
    English | Español
  • Global Global
    English
Blogs
Selecione um tema
Ver todos os tópicosFechar
Tecnologia 
Gestão de Projetos Agil Nuvem Entrega Contínua Ciência e Engenharia de Dados Defendendo a Internet Livre Arquitetura Evolutiva Design de Experiência IoT Linguagens, Ferramentas & Frameworks Modernização de sistemas legados Machine Learning & Artificial Intelligence Microsserviços Plataformas Segurança Testes de Software Estratégia de Tecnologia 
O negócio 
Serviços Financeiros Saúde Global Inovação Varejo Transformação 
Carreiras 
Dicas de Carreira Diversidade e Inclusão Transformação social 
Blogs

Topics

Escolha um tópico
  • Tecnologia
    Tecnologia
  • Tecnologia Visão Geral
  • Gestão de Projetos Agil
  • Nuvem
  • Entrega Contínua
  • Ciência e Engenharia de Dados
  • Defendendo a Internet Livre
  • Arquitetura Evolutiva
  • Design de Experiência
  • IoT
  • Linguagens, Ferramentas & Frameworks
  • Modernização de sistemas legados
  • Machine Learning & Artificial Intelligence
  • Microsserviços
  • Plataformas
  • Segurança
  • Testes de Software
  • Estratégia de Tecnologia
  • O negócio
    O negócio
  • O negócio Visão Geral
  • Serviços Financeiros
  • Saúde Global
  • Inovação
  • Varejo
  • Transformação
  • Carreiras
    Carreiras
  • Carreiras Visão Geral
  • Dicas de Carreira
  • Diversidade e Inclusão
  • Transformação social
MicrosserviçosTecnologia

Adotar microsserviços?

Rebecca Parsons Rebecca Parsons

Published: May 15, 2018

Microsserviços desempenham um papel importante em muitas organizações hoje em dia. O movimento ganhou força com o artigo seminal de James Lewis e Martin Fowler, seguido pelo livro de Sam Newman e várias palestras e artigos de ThoughtWorkers, da Netflix, Google e várias outras. Os microsserviços chegaram rapidamente ao anel Experimente no Technology Radar da ThoughtWorks, mas nunca chegaram ao anel Adote. Hoje, quero explorar a razão pela qual a os microsserviços não está no Adote.

Adote estabelece um padrão deliberadamente alto

Primeiro, vamos relembrar as definições dos anéis Experimente e Adote no Radar. Experimente significa que a tecnologia está pronta para as empresas testarem em seus próprios sistemas. Colocamos a tecnologia em produção com sucesso em algum lugar, estamos confiantes de que ela é estável e sabemos como e onde fazê-la funcionar. Algo no anel Adote significa que acreditamos que, quando aplicável, essa tecnologia deve ser o padrão. No caso de bancos de dados, o fato de o banco de dados gráfico Neo4J estar no Adote não significa que todos os dados devam estar em bancos de dados gráficos. Significa que, se você quiser usar um banco de dados gráfico, o Neo4J seria a escolha padrão no momento em que o movemos para o Adote.

Dadas essas definições, por que não colocamos microsserviços ou arquiteturas de microsserviços em Adote? Afinal, os microsserviços são comumente debatidos em conferências e pautam artigos. Mais e mais organizações estão mudando para esse estilo. Times da ThoughtWorks as utilizaram com sucesso em muitos projetos. Existem várias razões, algumas derivando da definição de Adote, mas outras mais específicas relacionadas a microsserviços. Vamos começar com o problema específico do radar.


Mover algo para Adotar é uma afirmação muito forte. Não queremos que haja muita sutileza envolvida em considerar a recomendação. Adotar significa que estamos confiantes de que esta é a escolha correta para um conjunto de circunstâncias facilmente definido. Ao considerar microsserviços, embora haja algumas vantagens claras, também há custos. Os trade-offs de custo-benefício variam de acordo com a organização; é a maturidade, o domínio e outros fatores que podem afetar os recursos de desenvolvimento disponíveis. Nós não poderíamos ignorar a recomendação Adotar para esse grau. Mesmo que pudéssemos, isso não é realmente consistente com a forma como pensamos sobre nossas recomendações de adoção. Não deve haver ambiguidade em uma recomendação para adotar.


Outro aspecto, mais importante, do anel Adote é que deve ser algo que possa ser amplamente adotado universalmente em toda a ampla gama de maturidade de nossos clientes e empresas em geral. Algo que funciona bem para start-ups, mas não para organizações maiores, por exemplo, não deve entrar em Adote. Um exemplo proeminente disso foi quando os sistemas de controle de versão distribuída passaram a ser amplamente utilizados em empresas de tecnologia. Nós não os colocamos em Adote porque, na época, muitas empresas ainda estavam lutando para adotar o controle básico de fontes. Nós sentimos o salto do nada para o controle de versão distribuído era grande demais para fazer a forte recomendação para Adotar. Nós acabamos colocando o Github em Adote, mas isso foi alguns anos depois.

Nem todas as organizações estão preparadas para microsserviços

Este último ponto é o principal motivador da nossa decisão de não transferir microsserviços para o anel Adote. Como Martin Fowler aponta aqui em um de seus posts sobre microsserviços, há um nível mínimo de maturidade necessário em coisas como entrega contínua e práticas de automação de infraestrutura antes que microsserviços sejam considerados. Este nível de maturidade ainda é um alongamento para muitas organizações. Os microsserviços sobrecarregam as operações, pois há mais coisas para monitorar e alertar, além de mais coisas para implantar. Automatização abrangente e práticas de entrega contínua são essenciais neste contexto.

Da mesma forma, uma arquitetura de microsserviços tem modos de erro que simplesmente não são possíveis em um aplicativo monolítico. Os sistemas de microsserviços são inerentemente distribuídos, e os processos de negócios são mais frequentemente concluídos por meio da interação de vários microsserviços. Em um monolito, esses processos de negócios são executados com maior frequência dentro do mesmo limite de processo, permitindo transações tradicionais e garantindo a execução de tudo ou nada. Embora tenhamos soluções para todos esses problemas, a abordagem de microsserviço introduz esses problemas e exige que eles sejam resolvidos. Assim, há uma compensação (comum) entre a maior flexibilidade da abordagem de microsserviços e a simplicidade da abordagem monolítica, particularmente se for um monólito bem estruturado. Aplicativos que não se beneficiarão da flexibilidade são candidatos ruins para uma arquitetura de microsserviços.

Uma decisão de design crucial para uma arquitetura de microsserviços é a colocação dos limites entre os serviços. Embora contextos limitados certamente forneçam uma forte orientação para onde os limites apropriados estão, as escolhas ainda existem e a escolha errada complica o sistema. Pode não estar claro para um novo domínio onde os limites adequados estão, portanto, há alguma justificativa para não começar com uma arquitetura de microsserviços até que o domínio e os contextos apropriados sejam mais claros.

Os microsserviços ainda são incrivelmente importantes para as empresas!

Você provavelmente já está se perguntando por que ou se ainda recomendamos uma arquitetura de microsserviços. A flexibilidade, a escalabilidade independente, as características evolutivas, o forte encapsulamento ainda são benefícios muito reais para uma abordagem de microsserviços. Esses benefícios são bem articulados em outros lugares. Ainda estamos firmemente comprometidos com o uso de arquiteturas de microsserviço, ampliando nossa compreensão dessas arquiteturas e continuando a explorar ferramentas e abordagens que abordam os problemas aqui descritos. De fato, Zhamak Dehghani, da ThoughtWorks, publicou recentemente este artigo sobre a decomposição de um monolito em microsserviços. No entanto, os custos e desvantagens da abordagem e o nível de maturidade organizacional necessários para executar a abordagem são a razão pela qual os microsserviços provavelmente nunca passarão para o Adote.
Posts relacionados
Arquitetura Evolutiva

Microservices as an Evolutionary Architecture

Neal Ford
Rebecca Parsons
Saiba mais
Estratégia de Tecnologia

Birth of the Technology Radar

Darren Smith
Saiba mais
Estratégia de Tecnologia

​The CxO Guide to Microservices

Jim Highsmith
Neal Ford
Saiba mais
Master
Política de privacidade | Declaração contra a escravidão moderna | Acessibilidade
Connect with us
×

WeChat

QR code to ThoughtWorks China WeChat subscription account
© 2021 ThoughtWorks, Inc.