Visão geral

Microserviços são o primeiro estilo arquitetural pós-DevOps, que tem, entre seus benefícios, estrutura modular evidente, deploy independente e diversidade tecnológica.

Domain-Driven Design (DDD) é um framework de design de software que possui ferramentas muito úteis para a modelagem de serviços. Microserviços, por sua vez, força uma separação clara entre os componentes de um sistema (neste caso, dos serviços) que é benéfica para a aplicação do DDD.

Essa interação, para uns um princípio de Microserviços, é um círculo virtuoso entre o estilo arquitetural e a aplicação de DDD.

Por que me importar?

Microserviços é um estilo arquitetural que emergiu de um conjunto de tecnologias, práticas e experimentações como virtualização, automação de infraestrutura, Entrega Contínua (Continuous Delivery) e times de produto. Ou como Neal Ford (2015) coloca, de forma sucinta: “Microserviços são o primeiro estilo arquitetural pós-DevOps, é o primeiro a abraçar completamente as práticas de engenharia da Entrega Contínua”.

Uma das definições para o estilo arquitetural diz que “Microserviços são serviços autônomos e pequenos que trabalham em conjunto” (Newman, 2014). Os benefícios por trás dessa simples definição incluem: estrutura modular evidente, deploy independente, diversidade tecnológica, ciclo de entrega de software mais rápido e maior resiliência.

No entanto, com a popularidade, veio a adoção irrestrita sem levar em consideração os pré-requisitos (como a adoção de práticas DevOps) e princípios do estilo. Um dos princípios é de que um serviço deve ser modelado em torno de uma capacidade de negócio. Este princípio também é chamado de Contexto Delimitado (Bounded Context), que é um dos pilares do DDD.

A não adoção das práticas DevOps e a inobservância desse princípio resulta em uma proliferação incipiente de serviços muito granulares e com orientação muito técnica, exarcebando os custos do estilo (computação distribuída e complexidade). Ao invés de um monólito que é uma Grande Bola de Lama, acabamos com muitas Micro Bolas de Lama.

Duração

25 minutos

Eventos

Esse conteúdo foi apresentado (ou será apresentado) no(s) seguinte(s) evento(s):

Sobre o mapa que ilustra a capa da apresentação

O mapa em questão é da cidade italiana de Ímola, em 1502. Este mapa foi feito por Leonardo Da Vinci para César Bórgia, então capitão do exército papal (César era filho do Papa Alexandre VI e serviu de inspiração para o famoso O Príncipe, de Nicolau Maquiavel).

O mais impressionante do mapa, no entanto, é a sua precisão. O mapa resistiu ao teste do tempo. Também é o primeiro mapa conhecido com esse tipo de iconografia, onde os prédios e outros elementos do plano da cidade aparecem perfeitamente na perpendicular de um posto de vista aéreo.

Esse mapa lembra muito a relação de Microserviços e DDD. Há uma barreira física visível (as muralhas) entre a cidade e o mundo exterior. Essa barreira evita que estrangeiros vejam o que há na cidade. A interação só é possível através dos portões (interfaces explícitas e públicas) e não é possível acessar os recursos da cidade de outra forma. As muralhas, dessa forma, preservam o design da cidade.

Citações, referências e agradecimentos

Citações

As citações nem sempre são literais, mas tento manter o sentido delas o mais próximo possível do texto original. Incluo o texto original quando a citação for adaptada e/ou traduzida.

  • Slide 6.

    Microserviços são o primeiro estilo arquitetural pós-revolução DevOps, é o primeiro a abraçar completamente as práticas de engenharia da Entrega Contínua

    Microservices are the first post DevOps revolution architectural style, the first to fully embrace the engineering practices of Continuous Delivery

    Ford; Parsons, 2016.
  • Slide 8.

    Microserviços são serviços pequenos e autônomos que trabalham em conjunto

    Microservices are small, autonomous services that work together.

    Newman, 2015. p. 2
  • Slide 9.

    É uma forma de desenvolver uma aplicação como uma suíte de pequenos serviços, cada qual rodando em seu próprio processo (...). Esses serviços são construídos ao redor de capacidades de negócio e são implantados independentemente com processos automatizados. (...) Podem ser escritos em diferentes linguagens e usar recnologias diferentes de armazenamento de dados

    In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

    Fowler; Lewis, 2014.
  • Slide 16.

    Uma arquitetura evolutiva possibilita Mudança em uma arquitetura como um Primeiro Princípio. É atraente porque Mudança tem sido historicamente cara e difícil de antecipar

    An evolutionary architecture designs for incremental change in an architecture as a first principle. Evolutionary architectures are appealing because change has historically been difficult to anticipate and expensive to retrofit

    Ford; Parsons, 2016.
  • Slide 17.

    É uma arquitetura evolutiva por causa do seu forte princípio de Contexto Delimitado, tornando a divisão lógica do Domain-Driven Design uma separação física

    Microservices meet this definition because of its strong bounded context principle, making the logical division described in Evan's Domain Driven Design a physical separation

    Ford; Parsons, 2016.
  • Slide 18.

    Questionamentos se design é necessário ou acessível perdem o ponto: design é inevitável. A alternativa para bom design é design ruim, e não a ausência de design

    Questions about whether design is necessary or affordable are quite beside the point: design is inevitable. The alternative to good design is bad design, not no design at all.

    Douglas Martin. Vernon, 2016. p. 5
  • Slide 20.

    O DDD é uma forma de desenvolver software que tem, como objetivo, implementar o melhor design de software baseado em modelos que refletem as competências da organização

    DDD is a set of tools that assist you in designing and implementing software that delivers high value, both strategically and tactically. Your organization can't be the best at everything, so it had better choose carefully at what it must excel. The DDD strategic development tools help you and your team make the competitively best software design choices and integration decisions for your business. Your organization will benefit most from software models that explicitly reflect its core competencies. The DDD tactical development tools can help you and your team design useful software that accurately models the business's unique operations

    Vernon, 2016. p. 1
  • Slide 22. Imagem, Da Vinci pintando a Monalisa por partes como se tivesse uma visão clara do resultado final. Patton, 2014. p. 139
  • Slide 23. Imagem, Da Vinci pintando a Monalisa de forma iterativa, onde cada iteração aproxima o quadro do resultado final. Patton, 2014. p. 140
  • Slide 24.

    Design estratégico é como fazer o rascunho antes de entrar nos detalhes da implementação. Destaca o que é estrategicamente importante para o seu negócio, como dividir o trabalho por importância e como fazer integrações da melhor maneira

    Strategic design is used like broad brushstrokes prior to getting into the details of implementation. It highlights what is strategically important to your business, how to divide up the work by importance, and how to best integrate as needed.

    Vernon, 2016. p. 7
  • Slide 25.

    DDD é primariamente sobre modelar uma Linguagem Ubíqua em um Contexto Delimitado

    In short, DDD is primarily about modeling a Ubiquitous Language in an explicitly Bounded Context.

    Vernon, 2016. p. 11
  • Slide 42.

    Microserviços criam uma barreira concreta ao redor da lógica que um time está criando em um serviço particular. Limites lógicos não sobrevivem no mundo real, é muito fácil em um monólito, na pressa usar alguma coisa que se precisa

    At this point, Microservices does gives us a really nice explicit and concrete boundary around the logic that one team is creating within its particular service. (...) The logical partitioning, it isn't robust, it there is something in the system, you know, the people can see, then it just doesn't hold up. It doesn't tolerate the chaos of a real development project where people get in a hurry. It's too prone to attempt to unify everything, you know, if you have a monolithic implementation, then monolithic modelling feels very natural. (...) The boundaries aren't very clear, so somebody in a hurry just reaches and grab something that needs from over there, and uses as is. That's not so easy in Microservices

    Evans, 2016 (b). Minuto 32:00

Referências

Tecniquês

Softwares usados

  • LibreOffice Impress
  • GIMP
  • Inkscape

Créditos dos arquivos audiovisuais