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.
0 comentários