Em novembro, a OTUS lança um novo programa educacional "Arquiteto de Software" . Nesse sentido, continuamos uma série de publicações para futuros alunos do curso e leitores do nosso blog.
Leia a primeira parte
Arquitetura de microsserviço
Os microsserviços são um tipo de arquitetura de software orientada a serviços que se concentra na criação de vários componentes independentes que compõem o aplicativo. Ao contrário dos aplicativos monolíticos criados como um todo, os aplicativos de microsserviço consistem em vários componentes independentes que são colados por meio da API.
A estrutura de microsserviços e arquitetura monolítica em comparaçãoA abordagem de microsserviço se concentra principalmente nas prioridades e oportunidades de negócios, enquanto a abordagem monolítica é organizada em torno de níveis de tecnologia, interfaces de usuário e bancos de dados. A abordagem de microsserviço se tornou uma tendência nos últimos anos, à medida que mais e mais empresas se tornam mais flexíveis e mudam para o DevOps.
Os microsserviços são importantes simplesmente porque agregam valor exclusivo ao cliente, simplificando os sistemas. Ao dividir seu sistema ou aplicativo em várias partes menores, você está implementando uma maneira de reduzir a duplicação, aumentar a consistência e reduzir a comunicação entre as partes, o que torna as partes comuns do sistema mais compreensíveis, escaláveis e fáceis de alterar.
Lucas Kraus, autor de microsserviços
Existem muitos exemplos de empresas que evoluíram de uma abordagem monolítica para microsserviços. Entre os mais conhecidos estão Netflix, Amazon, Twitter, eBay e PayPal. Para determinar se os microsserviços são adequados ao seu projeto, vamos identificar os prós e os contras dessa abordagem.
Profissionais de microsserviços
Fácil de desenvolver, testar e implantar
A maior vantagem dos microsserviços em relação a outras arquiteturas é que pequenos serviços individuais podem ser criados, testados e implantados independentemente. Como a unidade de implantação é pequena, torna o desenvolvimento e a liberação mais fáceis e rápidos. Além disso, o lançamento de uma unidade não se limita ao lançamento de outra, que ainda não está completa. E a última vantagem aqui é que os riscos de implantação são reduzidos à medida que os desenvolvedores lançam partes do software, não o aplicativo inteiro.
Maior flexibilidade
Com a ajuda dos microsserviços, várias equipes podem trabalhar em seus serviços de forma independente e rápida. Cada parte individual do aplicativo pode ser construída de forma independente devido ao isolamento dos componentes do microsserviço. Por exemplo, você pode ter uma equipe de 100 pessoas trabalhando em todo o aplicativo (como em uma abordagem monolítica), ou você pode ter 10 equipes de 10 pessoas desenvolvendo vários serviços.
Vamos imaginar visualmente.
Maior flexibilidade permite que os desenvolvedores atualizem os componentes do sistema sem desligar o aplicativo. Além disso, a flexibilidade fornece um processo de implantação mais seguro e maior tempo de atividade. Novos recursos podem ser adicionados conforme necessário, sem aguardar o lançamento de todo o aplicativo.
A capacidade de escalar horizontalmente
A escala vertical (usando o mesmo software, mas em máquinas mais poderosas) pode ser limitada pela largura de banda de cada serviço. Mas a escala horizontal (criação de mais serviços em um pool) não é limitada e pode funcionar com microsserviços dinamicamente. Além disso, a escala horizontal pode ser totalmente automatizada.
Contras de microsserviços
Dificuldade
A maior desvantagem dos microsserviços é sua complexidade. A separação do aplicativo em microsserviços independentes implica mais artefatos de controle. Esse tipo de arquitetura requer planejamento cuidadoso, enorme esforço, recursos e habilidades da equipe. Os motivos da alta complexidade são os seguintes:
- Maior demanda por automação, pois cada serviço deve ser verificado e controlado
- As ferramentas disponíveis não funcionam com dependências de serviço
- A consistência dos dados e o gerenciamento de transações estão ficando mais difíceis, pois todo serviço tem um banco de dados
Preocupações de segurança
Em um aplicativo de microsserviço, toda funcionalidade que interage da API externamente aumenta a probabilidade de ataques. Esses ataques só podem ocorrer se as medidas de segurança adequadas não forem tomadas ao criar o aplicativo.
Linguagens de programação diferentes
A capacidade de escolher diferentes linguagens de programação é uma faca de dois gumes. O uso de idiomas diferentes complica a implantação. Além disso, é mais difícil alternar os programadores entre os estágios de desenvolvimento, quando cada serviço é escrito em um idioma diferente.
No final
Os microsserviços são bons, mas não para todos os tipos de aplicativos. Este modelo é ótimo para o desenvolvimento de aplicativos e sistemas complexos. Você pode pensar em escolher uma arquitetura de microsserviço quando tiver várias equipes experientes e quando o aplicativo for complexo o suficiente para decompô-lo em serviços. Quando um aplicativo é grande e precisa ser flexível e escalável, uma arquitetura de microsserviço é benéfica.
Agora podemos comparar essas três arquiteturas de software para identificar visualmente as diferenças entre elas.
As aplicações monolíticas consistem em blocos interdependentes e indivisíveis e possuem uma velocidade de desenvolvimento muito baixa. A SOA divide-se em serviços menores e moderadamente relacionados e é lenta no desenvolvimento. Os microsserviços são serviços independentes muito pequenos e pouco acoplados, caracterizados pelo rápido desenvolvimento e integração contínua.
Arquitetura sem servidor
A arquitetura sem servidor é uma abordagem de computação em nuvem para criar e executar aplicativos e serviços sem a necessidade de gerenciamento de infraestrutura. Em aplicativos sem servidor, a execução do código é orientada pela plataforma, permitindo que os desenvolvedores implantem o código sem se preocupar com a manutenção e manutenção do servidor. De fato, ausência de servidor não significa "nenhum servidor". O aplicativo ainda é executado nos servidores, mas um serviço em nuvem de terceiros, como a AWS, é totalmente responsável por esses servidores. A arquitetura sem servidor elimina a necessidade de recursos adicionais, dimensionamento de aplicativos, manutenção de servidores e sistemas de armazenamento e banco de dados.
A arquitetura sem servidor inclui dois conceitos:
- O FaaS (Função como Serviço) é um modelo de computação em nuvem que permite que os desenvolvedores carreguem partes da funcionalidade na nuvem e permite que essas partes sejam executadas independentemente
- O BaaS (back-end como serviço) é um modelo de computação em nuvem que permite que os desenvolvedores terceirizem aspectos de back-end (gerenciamento de banco de dados, armazenamento em nuvem, hospedagem, autenticação de usuário etc.), além de escrever e dar suporte apenas a parte interface externa.
Veja como uma estrutura sem servidor se pareceUsando uma arquitetura sem servidor, os desenvolvedores podem se concentrar no próprio produto sem se preocupar com o gerenciamento ou os tempos de execução do servidor. Isso permite que os desenvolvedores se concentrem no desenvolvimento de produtos com alta confiabilidade e escalabilidade.
Existem muitos fornecedores de soluções em nuvem no mercado. Aqui estão alguns dos principais provedores de computação sem servidor:
Principais fornecedores de computação sem servidorPara descobrir se esse tipo de arquitetura é necessário para o seu projeto, vamos determinar as vantagens e desvantagens da implementação de um modelo sem um servidor.
Prós da arquitetura sem servidor
Fácil de implantar
Em aplicativos sem servidor, os desenvolvedores não precisam se preocupar com infraestrutura. Isso permite que eles se concentrem no próprio código. A arquitetura sem servidor permite implantar rapidamente um aplicativo, pois a implantação leva apenas algumas horas ou dias (em comparação com dias ou semanas com a abordagem tradicional).
Redução de custos
A mudança para a arquitetura sem servidor reduz custos. Como você não precisa processar bancos de dados, alguma lógica e servidores, você pode não apenas criar um código melhor, mas também reduzir custos. Ao usar um modelo sem servidor, você paga apenas pelos ciclos da CPU e memória que realmente usa.
Escalabilidade aprimorada
Muitos empresários desejam que seus aplicativos sejam poderosos e escaláveis, como Google ou Facebook. A computação sem servidor torna o dimensionamento automático e suave. Seu aplicativo será dimensionado automaticamente quando a carga ou a base de usuários aumentar, sem afetar o desempenho. Os aplicativos sem servidor podem lidar com um grande número de solicitações, enquanto os aplicativos tradicionais serão sobrecarregados com seu aumento repentino.
Desvantagens da arquitetura sem servidor
Vinculação de fornecedor
A ligação do fornecedor descreve uma situação em que você fornece ao fornecedor controle total sobre suas operações. Como resultado, as alterações na lógica de negócios são limitadas e a migração de um provedor para outro pode ser difícil.
Não para tarefas de longo prazo.
O modelo sem servidor não é adequado para operações longas. Aplicativos sem servidor são bons para processos curtos em tempo real, mas se a tarefa demorar mais de cinco minutos, o aplicativo sem servidor exigirá recursos adicionais do FaaS.
No final
A arquitetura de software sem servidor é útil para resolver tarefas únicas e processos de suporte. Funciona muito bem para aplicativos ricos em clientes e aplicativos que crescem rapidamente e precisam de escala ilimitada.
Por fim, vejamos a imagem a seguir para descobrir quando escolher cada um desses quatro tipos de arquitetura:
Escolher a arquitetura certa para o seu MVP é um desafio, mas o RubyGarage tem muitos anos de experiência para ajudá-lo com sua escolha. O autor do artigo terá prazer em responder a todas as suas perguntas sobre este tópico.