Em novembro, a OTUS lança um novo programa educacional “Arquiteto de Software” . Em conexão com isso, preparamos uma série de publicações para futuros alunos do curso e leitores do nosso blog.
Criar um novo produto é sempre arriscado. E escolher a arquitetura certa é um passo importante no caminho para o sucesso. Se você escolher entre uma arquitetura monolítica, orientada a serviços, microsserviço e sem servidor, esta postagem ajudará você a fazer a escolha certa.
Arquitetura monolítica
Monólito é uma palavra antiga que denota um enorme bloco de pedra. Embora o termo seja amplamente usado hoje em dia, a visão permanece a mesma em todas as áreas. Na engenharia de software, um modelo monolítico refere-se a uma única unidade indivisível. O conceito de software monolítico é que os vários componentes do aplicativo são combinados em um programa na mesma plataforma. Normalmente, um aplicativo monolítico consiste em um banco de dados, uma interface de usuário do cliente e um aplicativo de servidor. Todas as partes do software são unificadas e todas as suas funções são gerenciadas em um só lugar. Vejamos a estrutura do software monolítico em detalhes.
A arquitetura monolítica é conveniente para pequenos grupos; muitas startups escolhem essa abordagem ao criar um aplicativo. Os componentes do software monolítico são interconectados e interdependentes, o que ajuda o software a ser auto-suficiente. Essa arquitetura é uma solução tradicional para a criação de aplicativos, mas alguns desenvolvedores a consideram obsoleta. No entanto, acreditamos que a arquitetura monolítica é uma solução ideal em algumas circunstâncias.
Apesar de termos tido uma experiência positiva no uso de microsserviços no Google, nós [na Scaylr] seguimos uma rota monolítica, porque ter um servidor monolítico implica menos trabalho para nós, como dois engenheiros.
Stephen Cherwinski, Chefe de Design, Scaylr
Para descobrir se esta solução é adequada para o seu negócio, vejamos seus prós e contras.
As vantagens da arquitetura monolítica
Desenvolvimento e implantação simplificados
Existem muitas ferramentas que você pode integrar para facilitar o desenvolvimento. Além disso, todas as ações são executadas com um diretório, o que simplifica a implantação. Graças ao kernel monolítico, os desenvolvedores não precisam implantar alterações ou atualizações separadamente, pois podem fazê-lo imediatamente e economizar muito tempo.
Menos problemas transversais
A maioria dos aplicativos depende de muitas tarefas entre componentes, como trilhas de auditoria, registro em log, limitação de velocidade etc. Os aplicativos monolíticos são muito mais fáceis de levar em conta esses problemas devido à sua base de código comum. É mais fácil conectar componentes a essas tarefas quando tudo funciona em um aplicativo.
Melhor performance
Quando montados adequadamente, aplicativos monolíticos geralmente são mais produtivos que aplicativos baseados em microsserviços. Por exemplo, um aplicativo com uma arquitetura de microsserviço pode precisar fazer 40 chamadas de API para 40 microsserviços diferentes para carregar cada tela, o que obviamente leva a um desempenho ruim. Os aplicativos monolíticos, por sua vez, fornecem comunicação mais rápida entre os componentes do software devido ao código e memória comuns.
Contras da arquitetura monolítica
A base de código se torna complicada ao longo do tempo
Com o tempo, a maioria dos produtos continua a ser desenvolvida e expandida, e sua estrutura fica embaçada. A base de código começa a parecer realmente volumosa e fica difícil de entender e mudar, especialmente para novos desenvolvedores. Também está se tornando cada vez mais difícil encontrar efeitos colaterais e vícios. À medida que a base de código aumenta, a qualidade se deteriora e o IDE fica sobrecarregado.
Difícil de introduzir novas tecnologias
Se você precisar adicionar alguma nova tecnologia ao seu aplicativo, os desenvolvedores podem encontrar obstáculos à implementação. Adicionar nova tecnologia significa reescrever todo o aplicativo, que é caro e consome tempo.
Flexibilidade limitada
Em aplicativos monolíticos, cada atualização secundária requer uma reimplantação completa. Portanto, todos os desenvolvedores devem esperar até que isso seja feito. Quando várias equipes trabalham no mesmo projeto, a flexibilidade pode ser significativamente reduzida.
No final
O modelo monolítico não está desatualizado e, em alguns casos, ainda funciona muito bem. Algumas empresas gigantes, como a Etsy, permanecem monolíticas, apesar da popularidade atual dos microsserviços. A arquitetura do software monolítico pode ser útil se sua equipe estiver no estágio inicial, você criar um produto não verificado e não tiver experiência com microsserviços. O monólito é ideal para startups que precisam colocar o produto em operação o mais rápido possível. No entanto, alguns dos problemas mencionados acima andam de mãos dadas com a arquitetura monolítica.
SOA
Arquitetura orientada a serviços (doravante denominada arquitetura orientada a serviços) é um estilo de arquitetura de software que envolve um aplicativo modular que consiste em agentes de software discretos e pouco acoplados que executam funções específicas. SOA divide componentes em duas funções principais: provedor de serviços e consumidor. Ambas as funções podem ser desempenhadas por agentes de software. O conceito de SOA é o seguinte: um aplicativo pode ser projetado e construído de forma que seus módulos sejam facilmente integrados e possam ser reutilizados facilmente.
Profissionais de SOA
Reutilização de serviços
Devido à natureza autônoma e pouco acoplada dos componentes funcionais em aplicativos orientados a serviços, esses componentes podem ser reutilizados em vários aplicativos sem afetar outros serviços.
Leveza acompanhada
Como cada serviço de software é uma unidade independente, é fácil atualizar e manter sem afetar outros serviços. Por exemplo, aplicativos corporativos grandes são mais fáceis de gerenciar quando divididos em serviços.
Maior confiabilidade
Os serviços são mais fáceis de depurar e testar do que grandes pedaços de código, como nos monólitos. Isso, por sua vez, torna os produtos baseados em SOA mais confiáveis.
Desenvolvimento paralelo
Como a arquitetura orientada a serviços é em camadas, ela suporta a simultaneidade no processo de desenvolvimento. Serviços independentes podem ser desenvolvidos em paralelo e concluídos ao mesmo tempo.
Contras de SOA
Dificuldade em gerenciar
A principal desvantagem da arquitetura orientada a serviços é sua complexidade. Cada serviço deve fornecer a entrega oportuna da mensagem. O número dessas mensagens pode exceder um milhão de cada vez, o que dificulta o gerenciamento de todos os serviços.
Altos custos de investimento
O desenvolvimento de SOA requer um investimento inicial significativo em recursos humanos, tecnologia e desenvolvimento.
Carga adicional
No SOA, todas as entradas são validadas antes que um serviço interaja com outro serviço. Ao usar vários serviços, isso aumenta o tempo de resposta e reduz o desempenho geral.
No final
A SOA é mais adequada para sistemas empresariais complexos, como bancos. O sistema bancário é extremamente difícil de dividir em microsserviços. Mas uma abordagem monolítica também não é adequada para o sistema bancário, pois uma parte pode danificar toda a aplicação. A melhor solução é usar a abordagem SOA e organizar aplicativos complexos em serviços isolados e independentes.
Isso conclui a primeira parte da tradução e falaremos sobre microsserviços e arquitetura sem servidor na
segunda parte do material.