Nas duas primeiras partes desta série, exploramos a abordagem tradicional para criar e dimensionar um aplicativo. Começou com um único servidor que executava tudo e, gradualmente, evoluiu para uma arquitetura de microsserviço que poderia suportar milhões de usuários ativos diariamente.

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.