Orleans Princípios de design de arquitetura

Orleans é um projeto de código aberto, e é importante ser claro sobre os objetivos e princípios. Esses objetivos e princípios motivaram as decisões de design por trás Orleans para que novas mudanças se encaixem nessa estrutura ou revisem explícita e intencionalmente esses objetivos e princípios.

O objetivo do Orleans projeto era produzir uma estrutura que permitisse aos desenvolvedores tradicionais construir facilmente aplicativos distribuídos (nuvem) escaláveis. Para detalhar um pouco isso:

• O público-alvo não deve excluir programadores que não fizeram desenvolvimento de sistemas distribuídos. Queremos permitir que todos os desenvolvedores, sejam especialistas em nuvem ou iniciantes em nuvem, se concentrem em sua lógica e recursos de aplicativos, ou seja, o que fornece valor comercial, em vez de em questões genéricas de sistemas distribuídos.

• O objetivo é permitir que os desenvolvedores tradicionais criem aplicativos em nuvem facilmente. Facilmente significa que eles não devem precisar pensar em distribuição mais do que é necessário. Facilmente também significa que Orleans deve apresentar uma fachada o mais familiar possível para o desenvolvedor, em um contexto .NET, isso significa objetos e interfaces C#.

• Esses aplicativos devem ser escaláveis por padrão. Como os usuários-alvo não são necessariamente especialistas em sistemas distribuídos, queremos fornecer a eles uma estrutura que os leve a criar aplicativos escaláveis sem pensar explicitamente nisso. Isso significa que a estrutura tem que tomar muitas decisões para garantir um grau aceitável de escalabilidade, mesmo que isso signifique que a escalabilidade não é ideal para todos os aplicativos.

Complementámos este objetivo com um conjunto de princípios arquitetónicos:

• Estamos focados no caso '80%'. Há certas aplicações para as quais Orleans não é apropriado, tudo bem. Existem aplicações para as quais Orleans é adequado, mas onde se pode obter um desempenho um pouco melhor através de uma série de ajustes manuais que Orleans não permite; isso também é aceitável. O 80%, que Orleans se encaixa bem e tem desempenho suficiente para abranger várias aplicações interessantes, e nós preferimos fazer um ótimo trabalho em 80% do que um péssimo trabalho em 99%.

• A escalabilidade é fundamental. Sacrificaremos o desempenho bruto se isso resultar em um melhor dimensionamento.

• A disponibilidade é fundamental. Uma aplicação na nuvem deve ser como um utilitário: sempre lá quando quiser.

• Detete e corrija problemas, não assuma que você pode 100% evitá-los. Em escala de nuvem, coisas ruins acontecem com frequência, e até mesmo coisas ruins impossíveis acontecem, apenas com menos frequência. Isso nos levou ao que muitas vezes é chamado de "computação orientada para recuperação", em vez de tentar ser tolerante a falhas. A experiência demonstrou que a tolerância a falhas é frágil e muitas vezes ilusória. Mesmo protocolos matematicamente comprovados não protegem contra inversões aleatórias de bits na memória ou controladores de disco que falham ao relatar o sucesso — ambos os exemplos que ocorreram no mundo real.

Os princípios anteriores conduziram-nos a certas práticas:

• Conceito API-first: se não sabemos como vamos expor uma funcionalidade ao desenvolvedor, então não a criamos. Claro, a melhor maneira é que um recurso não tenha nenhuma exposição do desenvolvedor.

• Torne mais fácil fazer a coisa certa: mantenha as coisas o mais simples possível (mas não mais simples), não forneça um martelo se uma chave de fenda for a ferramenta certa. Como disse um dos nossos primeiros a adotar, tentamos ajudar os nossos clientes a "cair no poço do sucesso". Se houver um padrão padrão que funcionará bem para 80% dos aplicativos disponíveis, não se preocupe em habilitar todas as alternativas possíveis. Orleans' adoção da assincronia é um bom exemplo disso.

• Torne mais fácil para os desenvolvedores estender a estrutura sem quebrá-la. Provedores de serialização e persistência personalizados são alguns exemplos disso. Uma extensão de agendamento de tarefas personalizada seria um antiexemplo.

• Siga o princípio da menor surpresa: tanto quanto possível, as coisas devem ser tão familiares, mas tudo deve se comportar da maneira que parece.