Nas duas partes finais desta série, examinamos o impacto de tendências recentes, como computação em nuvem e sem servidor, juntamente com a proliferação de estruturas de aplicativos cliente e o ecossistema de desenvolvedores associado. Exploramos como essas tendências alteram a maneira como construímos aplicativos, especialmente para startups em estágio inicial, onde o tempo de colocação no mercado é crítico, e fornecemos informações valiosas sobre como incorporar essas abordagens modernas ao criar seu próximo grande sucesso.

Tendências Recentes

Vamos começar explicando brevemente essas tendências de computação que mencionamos.

A primeira tendência é a computação em nuvem. A computação em nuvem, em sua forma mais básica, está executando aplicativos em recursos de computação gerenciados por provedores de nuvem. Ao usar a computação em nuvem, não precisamos comprar ou gerenciar hardware por nós mesmos.

A segunda tendência é a computação sem servidor. A computação sem servidor baseia-se na conveniência da computação em nuvem com ainda mais automação. Ele permite que os desenvolvedores criem e executem aplicativos sem precisar provisionar servidores em nuvem. O provedor sem servidor lida com a infraestrutura e dimensiona automaticamente os recursos de computação para cima ou para baixo, conforme necessário. Isso fornece uma ótima experiência de desenvolvedor, já que os desenvolvedores podem se concentrar no próprio código do aplicativo, sem ter que se preocupar com o dimensionamento.

A terceira tendência surfa nas ondas das duas primeiras. É a proliferação das estruturas de aplicativos cliente e das plataformas de hospedagem front-end que tornam a implantação desses aplicativos front-end fácil.

Frameworks front-end modernos e plataformas de hospedagem

Vamos investigar um pouco mais a terceira tendência.

Nos últimos anos, tem havido uma mudança significativa na forma como as aplicações web são construídas. Muitos dos aplicativos populares de hoje são o que é chamado de Aplicativo de Página Única (SPA).

Um SPA fornece uma experiência de usuário mais perfeita, atualizando dinamicamente a página atual em vez de carregar uma nova cada vez que o usuário interage com o aplicativo. Em um SPA, o HTML inicial e seus recursos são carregados uma vez e as interações subsequentes com o aplicativo são tratadas usando JavaScript para manipular o conteúdo da página existente.

A maneira tradicional de criar aplicativos da web, como a que discutimos anteriormente para nossa empresa de comércio eletrônico Llama, envolvia a veiculação de novas páginas HTML do servidor toda vez que o usuário clicava em um link ou enviava um formulário. Esse modelo convencional é conhecido como MPA (Multi-Page Application). Cada solicitação de página normalmente envolve uma atualização de página inteira, que pode ser lenta e, às vezes, perturbadora para a experiência do usuário.

Por outro lado, um SPA carrega o quadro HTML inicial do aplicativo e, em seguida, faz solicitações ao servidor para obter dados, conforme necessário. Essa abordagem permite um uso mais eficiente dos recursos do servidor. O servidor não está constantemente enviando páginas HTML completas e pode se concentrar em servir dados por meio de uma API bem definida.

Outro benefício da abordagem centrada em API de um SPA é que a mesma API é frequentemente compartilhada com aplicativos móveis, tornando o back-end mais fácil de manter.

Os SPAs geralmente são criados usando estruturas JavaScript como o React. Essas ferramentas fornecem um conjunto de abstrações e ferramentas para a criação de aplicativos complexos que são otimizados para desempenho e capacidade de manutenção. Por outro lado, a criação de um MPA requer uma abordagem mais centrada no servidor, o que pode ser mais desafiador de dimensionar e manter à medida que o aplicativo cresce em complexidade.

O aumento da popularidade dessas estruturas de cliente trouxe uma ampla gama de plataformas de hospedagem front-end de nível de produção para o mercado. Alguns exemplos populares incluem Netify e Vercel. Os principais provedores de nuvem têm ofertas semelhantes.

Essas plataformas de hospedagem lidam com a complexidade de criar e implantar aplicativos front-end modernos em escala. Os desenvolvedores verificam seu código em um repo e as plataformas de hospedagem assumem o controle a partir daí. Eles criam automaticamente o pacote de aplicativos Web e seus recursos associados e os distribuem para a CDN.

Como essas plataformas de hospedagem são construídas sobre a base de computação em nuvem e sem servidor, usando práticas recomendadas, como servir dados na borda perto do usuário, elas oferecem escala praticamente infinita e não há infraestrutura para gerenciar.

É assim que o cenário de frontend moderno se parece. O aplicativo front-end é construído com uma estrutura moderna como o React. O aplicativo cliente é atendido por uma plataforma de hospedagem de nível de produção para dimensionamento e busca dinamicamente dados do back-end por meio de uma API bem definida.

Opções modernas de back-end

Como mencionado na seção anterior, a função de um back-end moderno é servir a um conjunto de APIs bem definidas para oferecer suporte à Web de front-end e aplicativos móveis.

Quais são as opções modernas para criar um back-end? A mudança é igualmente dramática.

Vamos ver o que uma startup pequena e com recursos limitados deve usar para criar seu back-end e ver até que ponto esse back-end poderia escalar.

Quando o tempo de colocação no mercado é crítico e os recursos são limitados, uma startup deve descarregar o máximo de trabalho não essencial possível. As opções de computação sem servidor são atraentes, pelas seguintes razões:

• A computação sem servidor gerencia os aspectos operacionais do back-end, como dimensionamento, redundância e failover, liberando a equipe de inicialização do gerenciamento da infraestrutura.

• A computação sem servidor segue um modelo de preços pay-per-use econômico. Não há compromisso inicial.

• A computação sem servidor permite que os desenvolvedores se concentrem em escrever código e testar o back-end sem se preocupar com o gerenciamento de servidores, levando a um menor tempo de comercialização.

Opções de computação sem servidor (serverless)

Existem dois tipos populares de opções de computação sem servidor adequadas para uma inicialização - funções de nuvem, como AWS Lambda e Google Cloud Functions, ou plataformas de contêiner gerenciado, como o Google Cloud Run ou o AWS App Runner.

Vamos explorar cada um deles.

As funções de nuvem são plataformas de computação sem servidor projetadas para lidar com a lógica de aplicativos simples. É adequado para aplicações que exigem execução rápida e simples.

As funções de nuvem são dimensionadas automaticamente com base no volume de solicitações. Eles têm um modelo de programação de solicitação/resposta simples. No entanto, as funções de nuvem são geralmente limitadas a um pequeno número de linguagens de programação populares.

As funções de nuvem devem ser capazes de escalar para milhares de solicitações simultâneas. Se o tempo de execução estiver disponível para seu ambiente de programação específico, as funções de nuvem seriam uma boa escolha.

As plataformas de contêiner gerenciado são semelhantes às funções de nuvem. A principal diferença é que essas plataformas suportam mais ambientes de tempo de execução. Somos livres para escolher a maioria dos ambientes de programação.

O modelo de programação para uma plataforma de contêiner gerenciado é mais convencional e flexível. Em vez do modelo simples de solicitação/resposta das funções de nuvem, uma plataforma de contêiner gerenciado pode executar qualquer programa dentro de um contêiner. Para uma carga de trabalho de servidor de API, cada contêiner é executado como um servidor sem monitoração de estado típico de longa duração. A plataforma de contêiner gerenciado distribui a carga entre os contêineres e lida com o dimensionamento e o failover automaticamente.

As plataformas de contêiner gerenciado são uma escolha melhor se o aplicativo exigir ambientes de tempo de execução mais complexos ou um modelo de programação mais flexível.

API Gateway

Para descarregar ainda mais funcionalidades básicas para os provedores de nuvem, é uma boa ideia considerar colocar um API Gateway na frente das opções de computação sem servidor mencionadas acima.

Um API Gateway pode ser configurado para lidar com autenticação e autorização. Ele fornece monitoramento pronto para uso e recursos como limitação de taxa e cache, o que pode ajudar a otimizar o desempenho e reduzir custos.

Opções de banco de dados sem servidor (database serverless)

O mercado de banco de dados também está vendo uma mudança igualmente dramática nos últimos anos. Há um número estonteante de opções de banco de dados disponíveis no mercado. O desafio para uma startup é escolher a certa para começar entre as muitas opções viáveis. Escolher um banco de dados é uma tarefa difícil.

Aqui está a nossa orientação. Nosso primeiro conselho é usar um banco de dados relacional. Acreditamos que uma startup deve ir com um banco de dados relacional por várias razões.

Primeiro, os bancos de dados relacionais são uma tecnologia bem estabelecida. Ele oferece grande flexibilidade de esquema que permite que uma startup experimente rapidamente. Há menos atrito para mudar de curso com um banco de dados relacional em comparação com o NoSQL. Com o NoSQL, o esquema de dados é mais rígido. Todos os padrões de acesso a dados devem ser determinados com antecedência para o NoSQL. Isso limita muito a capacidade de uma startup de pivotar.

Em segundo lugar, os bancos de dados relacionais modernos podem ser executados em alta escala. Para a maioria das cargas de trabalho de API, não é incomum que um banco de dados relacional manipule centenas de milhares de usuários ativos.

Em terceiro lugar, quando uma inicialização é tão bem-sucedida que está atingindo o limite de um banco de dados relacional, há um manual bem conhecido para dimensionar a camada de banco de dados, como adicionar camada de cache ou introduzir réplicas de leitura. Consulte a parte 2 desta série para obter mais informações.

Há várias maneiras de operar um banco de dados relacional de produção. Aconselhamos a escolha de uma solução de banco de dados relacional sem servidor. Com um banco de dados sem servidor, o provedor de nuvem assume a maioria das operações do dia-a-dia. Um banco de dados sem servidor desacopla o armazenamento de dados da unidade de computação que executa consultas. As unidades de armazenamento e computação podem aumentar e diminuir a escala independentemente com base na quantidade de tráfego, e o cliente só é cobrado pelos recursos de armazenamento e computação que são realmente usados.

Um cuidado é que os bancos de dados sem servidor são relativamente novos. Alguns provedores têm ofertas mais maduras do que outros. Se o seu provedor específico não tiver uma oferta forte, uma solução de banco de dados gerenciado é uma boa alternativa. Com um banco de dados gerenciado, o provedor de nuvem gerencia o hardware do servidor de banco de dados. Eles lidam com a manutenção contínua do hardware subjacente e do próprio software de banco de dados. O cliente é responsável por algumas tarefas operacionais, como gerenciar dimensionamento, backups e ajuste de banco de dados para sua carga de trabalho específica.

Tal como acontece com muitas coisas na engenharia de software, a escolha do primeiro banco de dados é sobre compensações. Existem certas situações em que um banco de dados NoSQL é uma escolha melhor, mas para a maioria das startups onde o ajuste do produto / mercado é incerto, e manter a máxima flexibilidade é inestimável, um banco de dados relacional é provavelmente uma escolha melhor.

Pilha de inicialização moderna

Ao aproveitar uma plataforma de hospedagem front-end de produção, um back-end de API sem servidor e um banco de dados relacional sem servidor, os desenvolvedores hoje em dia começam com uma pilha que os levará longe sem investir muito esforço antecipadamente.

Com essa pilha, eles não estão gerenciando nenhuma infraestrutura ou servidores. Essas ofertas têm alta disponibilidade e redundância de várias zonas incorporadas. Os provedores possuem a responsabilidade de ampliar os serviços à medida que o tráfego cresce.

Esta pilha moderna é poderosa. Ele poderia lidar com muitas dezenas de milhares de usuários, com alguns atingindo centenas de milhares. Está muito longe do que conseguimos alcançar com um único servidor.

Na parte 4, exploraremos maneiras de escalar essa pilha moderna à medida que o tráfego cresce.

Esse post é o segundo de uma série de 4 posts sobre arquitetura de software

Primeira parte aqui

Leosalesapp 5.0 - Adicionando Cache

Após implementar o padrão de microserviço seu app provavelmente deve ser capaz de suportar milhares de acessos dependendo da complexidade do app ele pode ser capaz de atingir até 1 milhão de usuários.

Porém para alguns aplicativos que precisam de muita leitura de dados é preciso otimizar a leitura da base de dados para ser capaz de aguentar picos de tráfego, um evento Black Friday poderia facilmente sobrecarregar o banco de dados, resultando em um apagão da base de dados.

Por isso é importante adicionar uma camada de cache para otimizar as operações de leitura, o mais popular hoje para essa finalidade é o Redis.

O Redis é um banco de dados de memória e adicionaremos os dados mais acessados aliviando o banco de dados relacional ao reduzir o número de operações de leitura executadas no banco de dados convencional, o acesso na memória pode chegar até 1000X mais rápido do que o acesso ao disco.

Para nosso aplicativo de exemplo, implementaremos o cache usando a estratégia de cache de leitura, primeiro os dados serão verificados no Redis se encontrados retornaram imediatamente, caso não sejam encontrados faremos uma consulta no banco de dados e gravados no cache para consulta futura.

Também podemos começar a falar sobre CDN onde ficará todo conteúdo estático do aplicativo (imagens, vídeos, css, js, html e etc).

Uma CDN (Content Delivery Network) serve o conteúdo estático de uma rede de servidores localizados mais perto do usuário final, reduzindo a latência e melhorando a velocidade de carregamento das páginas da Web. Isso resulta em uma melhor experiência do usuário, especialmente para usuários localizados longe do servidor de aplicativos.

Leosalesapp 6.0 - Escalando objetos com AWS S3

Alguns aplicativos necessitam de melhor gerenciamento e escalabilidade de objetos como: imagens, vídeos e outros arquivos.

Utilizando o AWS S3 para expandir o servidor de arquivos ganhamos em durabilidade e armazenamento ilimitado e com uma API fácil de armazenar e recuperar arquivos e também pode atuar diretamente como servidor de origem para a CDN.

Leosalesapp 7.0 - Microserviços

Com o tempo, se o negócio continua crescendo e a empresa continua contratando desenvolvedores, a cama de serviço evolui naturalmente para ser mais granular.

A arquitetura de microsserviços estrutura um aplicativo como uma coleção de serviços pequenos e independentes, com cada serviço executando seus próprios processos e se comunicando entre si por meio de protocolos leves como o gRPC.

Em nosso exemplo, dividimos os serviços em uma camada da Web onde os serviços lidam com solicitações de usuários do cliente.

Os serviços Web encaminham as solicitações para os serviços apropriados na camada de negócios. Aqui temos o serviço ao usuário, o serviço de pedidos e o serviço de inventário como exemplos.

Vale a pena notar que, na arquitetura de microsserviços, os bancos de dados tendem a se tornar específicos do serviço e são gerenciados pelas equipes específicas que possuem esses serviços. Em nosso exemplo, pode haver um cluster de banco de dados de usuário, um cluster de banco de dados de pedidos e um cluster de banco de dados de inventário. Cada um também pode ser fragmentado se as cargas de solicitação exigirem isso.

Em uma arquitetura de microsserviço, também é comum encaminhar solicitações não críticas de latência para filas de mensagens. Isso desacopla a parte crítica de latência do aplicativo daquelas que poderiam ser processadas de forma assíncrona.

Agora temos uma arquitetura de microsserviços completa. No geral, a arquitetura de microsserviços fornece uma maneira de dividir um aplicativo complexo em componentes menores e mais gerenciáveis, levando a uma maior eficiência do desenvolvimento. Isso resolve principalmente um problema organizacional, em vez de um problema técnico.

Termina assim a discussão da segunda parte, até a próxima

Introdução

Em uma série de 4 partes, vamos discutir a evolução de um website/app passando pelos principais tópicos, esse post é uma sugestão para estudo lembrando que não existe uma solução única para o mesmo problema fique livre para dar sua opinião ou propor modificações 🙂

obs: não vamos falar sobre todas as vantagens e desvantagens nessa série.

Atualização

Decidi exemplificar a teoria utilizando a criação de um sistema do zero vamos desenhar a arquitetura baseado no que estamos falando aqui esse app vai se chamar Leosalesapp.

Arquitetura monolítica vs Microserviço

Vamos começar exemplificando como os sistemas eram criados sem arquitetura distribuída os chamados monolitos e sua evolução para microserviço.

Problemas da arquitetura monolítica

Na figura da arquitetura monolítica possivelmente temos uma API RESTfull para clientes de aplicativos móveis ou web, as imagens e arquivos devem estar no disco local e o banco de dados que também é executado no mesmo servidor.

A arquitetura monolítica provavelmente pode atender a centenas e até milhares de usuários, porém a única maneira de suportar a crescente carga de usuário é aumentar os recursos do servidor como CPU, Memória e etc, e até mesmo o upgrade se tornará recorrente à medida que o servidor chega ao seu limite de capacidade.

Como todo aplicativo executando em um único servidor fica dependendo do uptime exclusivo desse servidor, logo se o servidor cair a aplicação ficará dependente do restart que pode demorar muito tempo tornando a aplicação inacessível em longos períodos.

Por que evoluir para microserviço?

Primeiramente não devemos assumir que a arquitetura de microserviço resolve todos os problemas magicamente. Eles são capazes de resolver desafios no crescimento dos softwares das empresas.

Um dos grandes problemas que os microsserviços resolvem são os isolamentos das responsabilidades, contextos e infraestrutura tornando em pequenos sistemas isso facilita quando precisamos escalar um "pedaço" do sistema que é o mais usado e mais importante, logo uma funcionalidade não comprometerá todo o sistema como visto na arquitetura monolítica.

Entendemos agora que para ter um sistema escalável devemos seguir com arquitetura baseada em microserviço.

Leosalesapp 1.0 - Monolitíco

O Leosalesapp é um ecommerce para venda de produtos tech.

A primeira versão é uma arquitetura tradicional monolítica bastante usada até os dias de hoje. Tudo no mesmo servidor temos:

• API RESTful para manipular as regras de negócio e fornece-las para o app mobile e Web.

• Servidor de aplicativos também disponibiliza conteúdo estático, como imagens que são armazenados diretamente no seu disco local.

• E por fim o servidor se conecta ao banco de dados que também é executado no mesmo servidor.

  

Como mencionado acima a única maneira de escalar é fazendo um upgrade das máquinas, mais CPU, memória etc.

Leosalesapp 2.0 - Mais servidores

A próxima etapa esperada é colocar o banco de dados e os arquivos em um servidor dedicado a eles.

O banco de dados demanda uma carga de trabalho de servidor diferente ao do servidor de aplicativo, ao separa-lo podemos ajustar ambos de forma independente para suas demandas especificas.

Aproveitamos para desacoplar também o servidor onde contem os arquivos se fizer sentido de acordo com o volume de tráfego.

Leosalesapp 3.0 - Load balancer e mais servidores

Com o crescimento do tráfego em algum momento o único servidor de aplicativos ficará sobrecarregado, mesmo podendo redimensionar os servidores a execução da API em um único servidor é ruim do ponto de vista operacional.

Chegou a hora de dimensionar a API horizontalmente introduzindo vários servidores de aplicativos, para fazer isso colocaremos um load balancer entre os aplicativos cliente e os servidores de aplicativos. O balanceador de carga distribuiu as cargas dos clientes em muitos servidores de aplicativos, existe 2 maneiras de distribuir o tráfego, utilizaremos a Round Robin.

Para usar a distribuição round-robin, os dados da sessão do usuário são armazenados no banco de dados. Em cada solicitação, o servidor de aplicativos busca os dados da sessão do usuário do banco de dados antes de processar a solicitação proporcionando maior resiliência no caso de uma falha do servidor, pois ele pode ser substituido facilmente.

Temos outros beneficios como a utilização de TLS que simplifica a implantação de aplicativos seguros.

O balanceador de carga rastreia a integridade de servidores de aplicativos individuais e leva automaticamente cada um para dentro e para fora de serviço com base em sua integridade, tornando a implantação de software sem interrupções do ponto de vista do usuário.

Com um balanceador de carga em vigor, também podemos nos beneficiar de failover e redundância. Se um servidor de aplicativos falhar, o balanceador de carga direcionará automaticamente o tráfego para os servidores íntegros, fornecendo alta disponibilidade e resiliência.

O dimensionamento do servidor de aplicativos traz complexidade extra ao balanceamento de carga. Como podemos ver no resto do artigo, este é um padrão comum: resolvemos um problema introduzindo outro.

Leosalesapp 4.0 - Banco de dados de replica

Conforme contiuamos a crescer os gargalos começarão a aparecer, o banco de dados é provavelmente o primeiro lugar a ter problemas.

O banco de dados por padrão tem problemas para lidar com uma grande número de consultas de leitura enquanto as gravações ocorrem com frequência.

Uma maneira simples de resolver é criando um banco de dados de replica, com esse método implantamos um cluster de banco de dados com um único banco de dados primário para manipular gravações e uma série de réplicas de leitura para manipular leituras, a desvantagem é o atraso na replicação dos dados no banco de dados de leitura.

Para o pequeno número de operações que não podem tolerar atrasos, essas leituras sempre podem ser direcionadas ao banco de dados primário.

Outro problema potencial com bancos de dados relacionais que pode afetar alguns aplicativos é a falta de suporte a pesquisa difusa.

A pesquisa difusa permite a pesquisa, mesmo que haja erros de digitação no termo de pesquisa, o que é útil para aplicativos como o comércio eletrônico on-line, onde permitir que os usuários pesquisem produtos sem exigir o termo de pesquisa correspondente exato é extremamente importante.

Para esses casos de uso específicos, é útil replicar um subconjunto do conjunto de dados em que esses recursos de pesquisa são necessários para um mecanismo de pesquisa de texto completo como o Elasticsearch.

Próximos passos

Nos posts a seguir vamos falar sobre:

• Quando adicionar cache?

• Quando adicionar full-text search engine?

• Quando adicionar mensageria?

• Quando usar um cluster?

Concluímos assim essa primeira parte 🤖