É virtualmente impossível considerar, hoje, o conceito de uma aplicação que não esteja conectada à internet de alguma forma. Essa realidade implica na necessidade de garantir uma estrutura de suporte confiável — o seu backend —, para fornecer dados e certas funcionalidades à interface de usuário. Uma infraestrutura mal planejada pode criar obstáculos diversos, como limitações de usabilidade, escalabilidade, altos custos e, em última análise, pode ser grande parte do sucesso ou fracasso do projeto inteiro.

É cada vez mais raro que empresas escolham ter sua própria infraestrutura de servidores antes de atingir patamares verdadeiramente impressionantes em termos de números de usuários e transações. Isso porque a oferta de serviços de infraestrutura em nuvem se tornou muito confiável e competitiva. Um recente relatório da consultoria McKinsey aponta que mesmo as maiores empresas do mundo, com operações volumosas e complexas que dificultam migrações de estrutura, já estão gravitando em direção a um modelo cloud first.

Vamos investigar o cenário atual e o que precisa ser considerado na hora de escolher o(s) melhor(es) modelo(s) para seu projeto.

O que são, e quais as diferenças entre os XaaS?

Primeiro, tratemos da sopa de letrinhas. Passou a ser comum se referir a qualquer serviço em nuvem como XaaS (Anything as a Service), sendo o ‘X’ uma variável mesmo. Isso porque o que começou com IaaS e PaaS (Infrastructure as a Service e Platform as a Service), já se desenvolveu em inúmeras variantes: SaaS, BaaS, DBaaS, IDaaS, MaaS… Por questões de objetividade e sanidade, vamos discutir brevemente a relação entre as soluções que de fato se comparam diretamente com servidores ou aplicações próprias:

  • IaaS – Infrastructure as a Service

Infraestrutura física como serviço, ou seja, servidores disponíveis para instalar suas máquinas virtuais, instalar software, configurar e manejar como necessário.

  • PaaS – Platform as a Service

Máquinas virtuais já instaladas e configuradas, o cliente só se preocupa com o desenvolvimento da sua aplicação.

  • DaaS (DBaaS) – Database as a Service

Simples, um banco de dados na nuvem. O cliente só se preocupa com os dados.

  • BaaS (MBaaS) – Backend as a Service

Coleção de serviços e funções de infraestrutura disponibilizados como APIs, sem necessidade de instalar, configurar ou manejar.

Notem que deixei SaaS (Software as a Service) de fora, apesar de ser um dos termos mais comuns de se ver por aí. A questão é que não se trata da mesma categoria, embora haja um pouco de confusão em torno disso. O modelo de SaaS é a distribuição de uma aplicação de uso final como serviço sob demanda, substituindo instalações locais. Bons exemplos são o G Suite (antes Google Apps), Salesforce, SAP HANA, Dropbox, entre outros.

Um pouco mais sobre BaaS

Outra observação é que o BaaS se destaca como um modelo mais abrangente; a ideia é oferecer soluções modulares para as funções mais comuns que precisam estar disponíveis na infraestrutura. Autenticação de usuários, armazenamento, serviço de notificações (push notifications), integração com serviços externos, escalabilidade automática e analytics estão entre os básicos. Mas cada provedor de BaaS pode oferecer estes e muitos outros serviços.

O modelo surgiu como solução para o desenvolvimento de aplicações móveis, principalmente. Por isso também é comum encontrar o termo MBaaS (Mobile Backend as a Service). No entanto, a ideia evoluiu, e as empresas que seguiram apostando em serviços exclusivos para aplicativos iOS e Android acabaram perdendo espaço ou morrendo.

Este modelo mostrou potencial e motivou a criação de startups para desenvolver e fornecer o serviços de BaaS, graças à grande demanda de pequenos desenvolvedores que não tinham tempo, conhecimento ou recursos para cuidar de seu backend.

Algumas dessas startups foram adquiridas, destacando-se Parse pelo Facebook, StackMob pelo PayPal, Firebase pelo Google. Existem vários outros provedores, mas já ocorreram algumas baixas, incluindo o encerramento das atividades de StackMob em 2014, e da Parse, em 2016. Embora o Facebook tenha garantido mais 12 meses de serviço e algumas ferramentas para facilitar a migração, a notícia foi muito estressante para os mais de 600 mil desenvolvedores que utilizavam a plataforma.

baas

BaaS é pra mim?

Então, como saber se meu projeto pode se beneficiar desse modelo? Bem, uma discussão de prós e contras é sempre bem-vinda nessa hora.

Começando pelas vantagens. O primeiro e maior benefício é certamente a diminuição drástica do investimento de tempo e dinheiro na infraestrutura da aplicação. Os SDKs e APIs fornecidos tendem a ser bem documentados e de uso simples. As soluções de autenticação, notificações push multi-plataforma e analytics, por si só já representam uma enorme vantagem do serviço em relação a desenvolver a própria implementação ou integrar serviços de diferentes empresas.

Além disso, a maioria dos BaaS disponíveis no mercado trabalham com o modelo freemium, ou seja, permitem o uso limitado por cota de usuários ou acessos. A cota gratuita costuma ser suficiente para prototipar e até para pequenas empresas trabalharem sem custo por alguns meses. Escalabilidade garantida também é uma mão na roda.

Nem tudo são flores, então temos algumas desvantagens. Há pouco, falamos das aquisições e encerramento das operações de StackMob e Parse. Isso é extremamente prejudicial, porque BaaS tem como efeito colateral níveis consideráveis de Vendor Lock-in. Isso significa que, por conta das especificidades do código relacionados ao uso dos serviços, uma mudança como essa se traduz em desenvolver do zero uma parte do seu projeto.

Os modelos IaaS e PaaS apresentam um nível muito reduzido desse risco. Qualquer mudança tende a se resumir em copiar uma máquina virtual, ou container, ou apenas o código inteiro da aplicação e levar para outro serviço, onde pouca ou nenhuma reconfiguração permite colocar tudo de pé novamente.

Também é importante lembrar que dificilmente pode-se eliminar totalmente qualquer necessidade de implementar funcionalidades de backend. A complexidade da arquitetura do projeto pode significar que os serviços disponíveis pelo BaaS representam uma parcela muito pequena do projeto para oferecerem real benefício. Portanto, de acordo com o volume de funcionalidades implementadas in-house, a necessidade de integração entre o BaaS e os componentes hospedados em PaaS, IaaS ou localmente, pode anular parte da vantagem de não desenvolver certas funções internamente.

IaaS, PaaS, SaaS, BaaS…

… não importa: qualquer modelo pode ser útil, seja em fases diferentes da vida do produto ou em componentes diferentes da mesma solução. Mas para ter sucesso na sua operação, é essencial que a integração dos serviços seja feita de forma eficiente e resiliente. Ou seja, teste seu código!

Se precisar de ajuda para garantir que a integração que você fez foi bem sucedida, a 1DT sabe o caminho! Me encontre em bruno.abreu@sofist.com.br ou ligue em (19) 3291-5321 e vamos falar do seu projeto.