Desenvolvimento, arquitetura e boas praticas

Eu sempre fui f de desenvolvimento de boas arquiteturas, talvez por j ter sofrido muito na vida na sustentao de sistemas ruins.

Alguns decises ruins poderiam ter sido evitadas se tivessem simplesmente "parado para planejar".

Normalmente esse profissional quando questionado comea com o checklist do GoHorse:

[ ] O prazo era apertado
[ ] O sistema muito legado
[ ] No estava claro a atividade
[ ] Foi meu colega que fez
[ ] Mas assim tambm funciona

Nesse momento eu gosto de lembrar de um principio do manifesto gil que e esquecido em alguns casos.

"Contnua ateno excelncia tcnica e bom design aumenta a agilidade."

Isso tem mudado com o surgimento do padro Build & Run.

As equipes de desenvolvimento tm autoridade total sobre os servios que criam, no apenas criando, mas tambm implantando e apoiando-os

Quando as equipes de desenvolvimento so responsveis por construir um sistemas e suport-lo em produo e tambm tentarem construir a plataforma de construo para execut-lo, a organizao pode acabar com vrias plataformas irreconciliveis.Isso desnecessrio, caro de operar (se at possvel) e leva tempo longe das equipes que deveriam se concentrar na entrega de recursos, no na plataforma em que so executados.

• A transferncia entre as equipes de desenvolvimento e operaes mata a velocidade e a agilidade da produo.
• Adicionar uma pessoa de operaes em cada equipe de desenvolvedor como voc acaba com 10 plataformas irreconciliveis.
• A lei de Conway diz que a arquitetura de software se parecer com a estrutura da organizao, portanto, se quisermos que a plataforma seja independente, as equipes de desenvolvimento de um aplicativo precisam ser separadas da equipe que executa a plataforma de produo.
• H um limite para as capacidades que uma equipe pode ter.Devs so devs;eles podem estender seu conhecimento a um certo nvel, mas eles no so Ops.
• Manter operaes e desenvolvimento como disciplinas / equipes separadas no sustentvel no nativo da nuvem.
• Muita liberdade traz caos, mas muita padronizao estrangula a inovao.

Portanto

Crie equipes em que cada uma tenha sua prpria capacidade de construir um sistema distribudo com microsservios gerenciados por agendamento dinmico. As equipes de construo-execuo sero responsveis por construir aplicativos distribudos, implant-los e, em seguida, dar suporte aos aplicativos depois de executados.Todas as equipes Build-Run usam o mesmo conjunto padronizado de servios de plataforma e implantam em uma nica plataforma unificada que executa todos os aplicativos para toda a empresa.Esta plataforma da responsabilidade da Equipa da Plataforma, que a implementa e apoia.

• As equipes Build-Run no so equipes de DevOps no sentido tradicional de que os desenvolvedores e as pessoas de operaes sentam-se juntos.
• No Agile, a equipe de desenvolvimento tambm inclui recursos de teste de software, mas os produtos so entregues a uma equipe de operaes separada para serem entregues produo.
• Na nuvem nativa, uma verdadeira equipe multifuncional deve ser capaz de construir sistemas distribudos.
• A equipe da plataforma um tipo especfico de equipe Build-Run, pois cria, implanta, provisiona e oferece suporte plataforma e infraestrutura nativas da nuvem, mas funciona separadamente das equipes de desenvolvimento de aplicativos.

Consequentemente

H uma forte separao de responsabilidades definidas: As equipes Build-Run lidam com os aplicativos.A Equipe da Plataforma responsvel por construir e manter a plataforma operacional. A Equipe da Plataforma no precisa fazer parte da empresa - nuvens pblicas como Google / AWS / Azure, etc., com suas plataformas automatizadas, podem formar uma Equipe da Plataforma interna desnecessrio.Se uma equipe de plataforma for designada, eles so geralmente globais, oferecendo suporte a todos os servios / aplicativos;As equipes Build-Run so separadas e contam com a plataforma padronizada fornecida pela Equipe da Plataforma.

• As equipes tm um nvel limitado de autonomia e capacidade de se concentrar em suas verdadeiras tarefas.
• Os desenvolvedores ainda tm liberdade para escolher os componentes a serem executados na plataforma padronizada, desde que sejam compatveis.

Acredito que "as melhores arquiteturas, requisitos e designs emergem de equipes auto-organizveis". O que tenho visto e a negligencia desse principio em muitos sistemas e times.

O papel do gestor (depois de gerir pessoas) e provocar para que tenhamos uma vida sadavel em todo ciclo de desenvolvimento de software, sinceramente no vejo como teriamos um ciclo saudavel sem pensarmos em melhores arquiteturas para o problema que queremos resolver.

Vou postar com mais frequncia sobre temas correlacionados a arquitetura, orientao a eventos e como a orientao a eventos nos ajuda a construo de plataformas mais reativas, resilientes e tolerantes a falhas.