Contexto
A engenharia de software tem padrões de design de software (por exemplo, GoF ), que descrevem soluções para problemas comuns de codificação - geralmente no nível do código; da mesma forma, existem padrões de arquitetura (por exemplo, Fowler ) que lidam com a arquitetura do sistema em geral (embora estes lidem com considerações fora do código puro, eles geralmente parecem se concentrar mais em questões de engenharia de software do que em questões de infraestrutura).
Também notei que provedores de plataforma como a Microsoft estão lançando " padrões de design de nuvem ".
A infraestrutura como código (IoC) é uma complicação adicional em que considerações de nível de software/codificação começam a se tornar relevantes.
Pergunta(s) específica(s)
No reino da Infraestrutura, padrões orientados à infraestrutura são mesmo uma coisa? Se sim, há alguma coleção relativamente definitiva deles que seja amplamente compreendida pela comunidade de infraestrutura? Ou você apenas 'pega emprestado' padrões de arquitetura de sistema?
Aliás, supondo que a resposta acima seja, em termos gerais, "sim", os padrões de infraestrutura de nuvem são vistos como parte ou extensão desses padrões, ou são vistos como um conjunto separado?
Para sua informação
Sou um arquiteto de soluções que vem de um background de desenvolvimento de software, não de infraestrutura. Quando digo "infraestrutura", estou me referindo a coisas como redes, servidores físicos e virtuais e sua arquitetura de implantação, planejamento de capacidade e volume, segurança de servidor e rede, e assim por diante - basicamente qualquer coisa em que um arquiteto de "software" possa confiar, mas não arquitetar explicitamente a si mesmo.
Atualização - Definições
Só para esclarecer para quem estiver lendo isso mais tarde:
" Padrões " é um termo amplo , que não é específico de uma disciplina...
Em engenharia de software, um padrão de design de software é uma solução específica (muito parecida com uma receita) para um problema comum de nível de código. Esses tipos de padrão geralmente são agnósticos em tecnologia, mas podem ser específicos para um paradigma de linguagem de programação (por exemplo, Orientado a Objetos vs. uma alternativa).
Padrões de Arquitetura (de Sistema/Aplicativo) abrangem problemas comuns de arquitetura e design em nível de sistema, incluindo: estrutura de componentes internos, funções e responsabilidades em nível de componente, aspectos transversais como autenticação e autorização, tratamento de erros e observabilidade, persistência de dados.
Muito longo para um comentário simples:
Minha intuição diz que "design baseado em padrões" é um jargão originário da engenharia de software (especificamente do livro Design Patterns ) e não algo comumente usado fora dessa área.
Como você já mencionou, cada vez mais infraestrutura se torna "definida por software", esse jargão está sendo repetido cada vez mais frequentemente por engenheiros de software que documentam suas ferramentas e funcionalidades em seu próprio jargão, e é por isso que agora vemos títulos como "Padrões de design de nuvem", na minha humilde opinião.
No campo do design de redes (com muito jargão emprestado do campo matemático da Teoria dos Grafos), você pode encontrar "padrões de design" clássicos, chamados topologias de rede , que podem soar familiares, como a topologia de rede hub-and-spoke ou estrela , a topologia de rede em anel , redes em malha e outras que são amplamente implantadas e instantaneamente reconhecíveis.
Fora isso, nada vem imediatamente à mente, a não ser "a forma segue a função" .
Um único aplicativo monolítico não permitirá quase tantos graus de liberdade com relação a uma infraestrutura adequada em comparação a um aplicativo ou serviço que precisa desafiar e/ou operar em escala global com os números de usuários simultâneos de, por exemplo, Netflix, Google, Facebook e outros. Aprender sobre como esses negócios globais resolvem seus desafios semelhantes mostra muito poucos denominadores comuns e, em vez disso, que cada um encontrou suas próprias soluções, que muitas vezes construíram do zero.
Muito mais amplo do que a infraestrutura de TI e talvez não seja imediatamente o que você está perguntando são os conjuntos de melhores práticas, estruturas e jargões associados encontrados, por exemplo, em ITIL , ASL ou TOGAF e outros.
Como reflexão final ao procurar padrões de design, considere a armadilha dos cultos de carga:
https://en.wikipedia.org/wiki/Cargo_cult_programming
Para um determinado produto de software pronto para uso, o fornecedor pode fornecer implementações de referência. Se você estiver planejando uma implementação de diretório ativo, a MS tem orientação para lidar com complicações como escritórios remotos com segurança física ruim ou links de dados lentos. Alguns fornecedores terão diretrizes de dimensionamento e desempenho, como dividir uma arquitetura de 2 ou 3 camadas e como dimensionar cada camada (se necessário).
Infelizmente, a resposta curta é sim e não.
Para uma resposta mais longa, começando com a parte Sim:
Há muitos aspectos da construção de infraestrutura que são formulaicos (como em qualquer trabalho, na verdade). Por exemplo, é extremamente comum e esperado segregar segmentos de rede (por exemplo, PCs de funcionários e servidores locais) e filtrar o tráfego entre eles, porque é uma boa prática de segurança e também torna a administração da rede um pouco mais fácil. Este é um exemplo simples, mas existem muitos desses "padrões", se é isso que você quer dizer. Na maioria dos casos, esse tipo de padrão é simplesmente visto como "as melhores práticas", especialmente em questões de segurança.
Outro tipo de padrão é um pouco abordado por outras respostas, mas não exatamente: Os fornecedores de hardware têm implementações de referência de seu hardware em configurações que são supostamente otimizadas para melhor desempenho, principalmente para fins de demonstração.
Como cliente, você pode simplesmente solicitar esta configuração de referência e instalá-la. Não é exatamente mainstream porque um bom arquiteto será capaz de ver onde o fornecedor de hardware cria margem adicional ao incluir componentes de ponta onde eles são desnecessários, então geralmente é muito mais eficiente em termos de dinheiro (mas não de tempo) projetar a infraestrutura internamente (novamente, projetando de acordo com as melhores práticas).
De forma semelhante, uma vez dei suporte a um cliente que tinha fábricas no mundo todo. Eles tinham projetado (ou contratado um design, não sei os detalhes) um núcleo de infraestrutura "padrão" para cada fábrica, com exatamente as mesmas especificações de hardware, pilha de virtualização e software de infraestrutura comum. Isso tornou o treinamento consideravelmente mais fácil do que em infraestruturas personalizadas, porque a parte que fomos contratados para dar suporte era sempre a mesma.
Por outro lado, além de seguir as melhores práticas, que frequentemente lidam com detalhes relativamente pequenos ou são vagas o suficiente para não se qualificarem como um padrão, o fato é que infraestrutura não é simplesmente sobre "ter servidores". É evidente que uma grande parte do trabalho de infraestrutura tem a ver com coisas que são específicas para aquela infraestrutura.
Além disso, a infraestrutura tem, por natureza, muita dívida tecnológica (o hardware é caro e ocupa espaço físico), então é muito fácil acabar em um lugar onde as melhores práticas do passado não fazem mais sentido no presente, mas, ei, os servidores funcionam, então não vamos substituí-los ainda.