Bússola apontando para "qualidade"

Vale a pena pagar mais por software de alta qualidade

Este post é uma tradução de "Is High Quality Software Worth the Cost?", disponível em https://martinfowler.com/articles/is-quality-worth-cost.html. Um debate comum no desenvolvimento de software é se vale a pena gastar tempo na melhoria da qualidade do software ou se é melhor se concentrar no lançamento de funcionalidades. Geralmente, a pressão para entregar funcionalidades domina a discussão, … Continue lendo Vale a pena pagar mais por software de alta qualidade

Infraestrutura na Nuvem – não dê nome aos bois

Era uma vez um programador de DAOs. Dionatan tinha conseguido essa honrada posição no Projeto Quéops depois de um ano como "programador júnior", cuja principal atividade era programar "getters, setters e toStrings". O antigo programador de DAOs saiu da empresa e, amigo de Dionatan, recomendou-o por ser confiável o suficiente para mexer com os acessos ao banco. Dionatan recebia uma "Java Interface", provavelmente do cara do cubículo ao lado, que também fez o DAO Factory (e inúmeras outras "factories") seguindo as recomendações do Todo-Poderoso arquiteto. Dionatan não sabia o nome do homem-factory e do Todo-Poderoso, porque trocavam as pessoas com frequência. Com a "Java Interface", bastava criar uma implementação e preencher os métodos. Várias vezes, era só copiar boa parte do que o amigo já tinha deixado pronto e mudar alguns nomes.

Quebrando um software monolito: Microsserviços vs. Sistemas Autocontidos

Texto de Olga Annenko, disponível em: http://www.elastic.io/breaking-down-monolith-microservices-and-self-contained-systems/ As publicações e discussões recentes de TI estão cheias de termos como "transformação digital", "TI bimodal", "desenvolvimento contínuo" e "agilidade". Não há necessidade de discutir que arquiteturas monolíticas e aplicações monolíticas devem se tornar coisas do passado, cedo ou tarde - de preferência, cedo, é claro. E de fato os departamentos de TI são encorajadas a se afastar dos monolitos por causa de inúmeras razões perceptíveis e compreensíveis: manutenção complicada, muitas dependências, dificuldades de teste e implantação (o monolito só pode ser implantado como um todo.) Os monolitos são como o Triângulo das Bermudas para qualquer iniciativa ágil de TI.

Esculpindo o monolito JavaEE em microsserviços: prefira verticais, não camadas

O texto original é de Christian Posta, e está disponível em: http://blog.christianposta.com/microservices/carving-the-java-ee-monolith-into-microservices-perfer-verticals-not-layers/ O monolito que explorarei nesses artigos será do tutorial Ticket Monster, que tem sido um exemplo canônico há muito tempo sobre como construir uma aplicação impressionante com JavaEE e as tecnologias RedHat. Usaremos o Ticket Monster porque é uma aplicação bem escrita situada entre o "não-trivial" e o "complexo demais para um exemplo". É perfeito para propósitos ilustrativos e podemos apontar algumas coisas dele concretamente e discutir prós e contras de algumas abordagens com código de verdade.

Não comece com um monolito

...quando o seu objetivo é uma arquitetura de microsserviços. Nos últimos meses, ouvi repetidamente que a única forma de ter uma arquitetura bem sucedida de microsserviços é começando primeiro com um monolito. Como lembra Simon Brown: se você não consegue construir um monolito bem estruturado, o que o faz acreditar que será capaz de construir um conjunto bem estruturado de microsserviços? A mais recente, e como sempre convincente, interpretação desse argumento vem de Martin Fowler. Tomei algum tempo para pensar sobre isso. E fiz isso especialmente porque normalmente concordo com ele, e outras pessoas cujas visões eu compartilho também parecem concordar com ele.

Uma Cartilha Rápida sobre Microsserviços

Microsserviços são um tipo de arquitetura de software onde grandes aplicações são feitas de unidades pequenas trabalhando juntos por meio de APIs que não são dependentes em uma linguagem específica. Cada serviço tem um escopo limitado, se concentra em uma tarefa específica e é altamente independente. Esse arranjo permite que os gerentes de TI e desenvolvedores construam sistemas de forma modular. No seu livro "Construindo Microsserviços", Sam Newman disse que microsserviços são componentes pequenos e focados, construídos para fazer uma coisa muito bem.