Quando eu idealizei o Docker Definitivo eu me propus a resolver, em escala, um problema que eu havia encontrado diversas vezes, em diversos times, em diversas restruturações:

Só conhecer aplicação web e banco de dados.

Como já dizia o ditado, para quem só sabe usar martelo, todo problema é um prego!

O dilema das bolhas

Quando o desenvolvedor chega ao mercado, em geral vindo da faculdade, ele leva algum tempo até entender a dinâmica das aplicações de linha de negócio (LOB – Line of Business). Ele leva algum tempo para entender como compomos design patterns, como projetamos segurança, como lidamos com ataques, como nos preocupamos com System Design e arquitetura.

Imerso nesse dia-a-dia, vendo por anos aplicações baseadas em aplicação web ou desktop e banco de dados, é natural acostumar-se com esse desenho.

Um belo dia sua aplicação simplesmente não consegue mais crescer. Você chegou ao máximo daquele modelo, com a base de código que tem.

Ainda em dezembro de 2020 eu li “Evitar a divisão dos trabalhos (Backend / Frontend)” como uma vantagem. Eu nem quero fazer deduções com base nessa frase.

Mas o ponto é que como comunidade de desenvolvedores, apenas uma fração de nós é capaz de tomar boas decisões.

De um lado, alguns dizem: Microsserviços first! Monolitos são ruins.

Enquanto San Newman diz:

– “The monolith is not the enemy”

– “microservices should not be the default choice”

Tradução:

“O monólito não é o inimigo”

“microsserviços não devem ser a escolha padrão”

Sam Newman – QCon London 2020

https://www.infoq.com/news/2020/05/monolith-decomposition-newman/

Tem algo muito errado aqui!

O Docker Definitivo nasceu como um curso de Docker com ambição de se tornar um curso de arquitetura de soluções. E enfim, estamos alcançando esse objetivo.