Serviço não é API
É realmente difícil achar alguém no mundo do desenvolvimento de software apto a conversar sobre Serviços (ou Microserviços), ou eu estou procurando no lugar errado?
Sempre que ouso levantar alguma dúvida sobre modelos de serviço, sua construção, etc rapidamente recebo duas (melhor, três) respostas:
- Você tem que criar uma API Restful;
- Você tem de definir os endpoints pelos quais seus clientes terão acesso ao serviço.
- Você tem de usar JWT para autenticar seus Serviços (vulgo APIs).
Essas pessoas não estão de todo erradas, mas vamos com calma. Eu queria conversar sobre Serviços, sim Serviços mesmo. Não a ponto de comparar com o serviço de limpeza de uma cidade, ou a entrega de mercadorias. E ao mesmo tempo sim, quero falar no mesmo nível deles a ponto de chegar nas suas diversas formas de automação, gerenciamento, etc, usando ou não alguma tecnologia, de preferência usando, mas uma conversa menos fora da Caixa, ou em uma Caixa menos formatada (ou também fora da Caixa, por que não?).
Me deixa muito assustado e confuso constatar que não consigo falar sobre Serviços com Analistas de Tecnologia, de Desenvolvimento, etc. Isso porque as respostas tecnológicas estão cada vez mais distantes do cliente (aquele que contrata o desenvolvimento) e do consumidor (aquele que vai utilizar o produto ou serviço). E essa confusão me faz questionar onde está a fronteira entre gestão e tecnologia, e como uma equipe de tecnologia pode criar produtos sem uma sensibilidade mínima de gestão.
Então, meus amigos, quando eu criar um debate sobre Serviços, vamos começar esquecendo a Caixa da embalagem, e vamos debater sobre Serviços. Seja esse serviço uma limpeza residencial, conserto de equipamento, ou qualquer coisa. Vamos divagar sobre as plataformas possíveis, e todas as suas arquiteturas. Vamos, principalmente pensar em como entregar ao consumidor esse Serviço, e pensar em quão indispensável esse Serviço pode se tornar para o Consumidor. Antes de limitar o cliente, pense em todas as características de um Serviço.
De uma forma bem descompromissada penso nestas características como principais:
- Serviço tem objetivos;
- Serviços envolve pessoas e/ou máquinas; Principalmente pessoas;
- Serviço envolve cliente, consumidor e fornecedores;
- Serviço envolve alguma forma de tecnologia, não restrinja-a.
Agora que você já tem alguma noção do que significa prestar algum serviço a alguém (A pergunta “O Que?” foi respondida), vamos pensar no “Quem?”.
Quem vai prestar o Serviço? Como expliquei acima, a grande maioria dos desenvolvedores (generalizei) assumem que quem vai prestar o serviço é um website. Mas, a partir de hoje vamos pensar fora da Caixa. Não é porque sou um desenvolvedor web (também) que eu tenho que presumir que tenho de vender ao meu cliente ou chefe um website todas as vezes que ele vier conversar sobre um produto. Antes disso, um serviço é executado, quase sempre, por pessoas. Seja um Gari, um Motoboy, um Vendedor, um Mecânico, ou qualquer outro profissional, quando eu penso em Serviços eu penso em pessoas. Tenho de pensar em como elas interagem dentro do processo de solicitação e entrega de um Serviço. Mas Serviços podem ser transacionado entre máquinas também (como a relação entre o Caixa Eletrônico e o Banco). Ou ainda, um serviço pode envolver robôs. Sim, o Quem? pode ser um robô solicitando um investimento na bolsa de valores. Então, fica claro que nem sempre (pra não dizer raramente) quando alguém quiser falar de Serviços o diálogo deve transcorrer no entorno de determinada tecnologia.
Serviço envolve muito o “Como” ele vai ser prestado? Aí sim, começa a entrar o assunto tecnologia. Atente-se, eu disse começa. A tecnologia tem evoluído muito, não dá para pensar que sempre o melhor serviço para o seu cliente é um App Mobile ou um Website. A depender das características do seu cliente, uma interface robótica pode ser o melhor Serviço que o cliente pode receber. A depender do mercado dele, pode ser mais viável entregar Inteligência Artificial do que 2 Aplicativos Mobile (consumidor + fornecedores), 2 Websites (consumidor + fornecedores), uma arquitetura Restful, e trocentos outros requisitos preestabelecidos que custariam algumas dezenas de milhares de dinheiro (em qualquer moeda) que em tempos de recessão qualquer Cliente está pouco disposto a correr o risco de investir. Para qualquer desenvolvedor, pensar com o cliente sobre o Como o Serviço dele deve ser prestado ao Consumidor vai distinguir os desenvolvedores dentro do oceano.
O “Como?” está muito associado ao “Por que?”. Afinal, por que que seu cliente precisa de um investimento tão alto, em coisas que ele atualmente não pode dar conta de 10% do que vai ser entregue, se é que vai? (Projeto falham mais que acertam).
Vamos pensar no Serviço de Motoboys entregando Alimentos na residência de Consumidores de Restaurantes Delivery? Bom, dificilmente você ainda não pediu uma pizza por telefone ou aplicativo. Você liga ou abre o app mobile (ou um chat Messenger), pede a pizza, de alguma forma o restaurante produz a pizza, passa o endereço do consumidor para o Motoboy, e o Motoboy tem o grande desafio de entregar essa pizza em no máximo 45 minutos ao consumidor, senão a pizza chegará bem fria, e o consumidor ficará insatisfeito. Podemos imaginar vários modelos de negócio em que esse serviço funcione bem, utilizando simplesmente a voz, um telefone/SMS, um aplicativo mobile, um chatbot, um website, etc. Ou seja, na vida real a arquitetura de um website moderno contempla a mínima possibilidades dentre todos os modelos de negócio possíveis, pois são amplas as possibilidades de escolha das plataformas onde o Serviço rodará. Então, não é uma regra sensata adotar como padrão que todo serviço deve ser API Restful.
Vamos falar um pouco mais sobre Serviços e APIs, Restful ou não. Primeiramente os não Restful. Antes dos Restful existia, e ainda existe o Remote Procedure Call (RPC) que vem sofrendo algumas evoluções. Embora pouco discutido no mundo Web, ainda existe o padrão SOAP, no qual a interface de comunicação entre as partes envolvidas entre os serviços era baseada em Mensagens (XML). E ainda existem vários outros modelos, que não estão na moda, e podem não ser tão simples, mas ainda são muito úteis.
Voltando ao gancho da API. Interface de Aplicação é realmente importante, mas o mais importante em um Serviço é definir as Interfaces. Sim, Interface de Interação Homem-Homem, Homem-Maquina, Máquina-Maquina, e avaliar quais tipos de Interface dentro desses grupos melhor se encaixa na forma mais adequada de Definir o Serviço para o Cliente. Se o Cliente optar por um Serviço Robótico dentro do modelo Chatbot, pode ser que utilizaremos uma API Restful sobre um protocolo HTTP, mas de repente o protocolo nem seja o HTTP, pode ser um IRC, RTCP (Real Time, acho que errei — RTP/RTCP), ou qualquer outro, que por exemplo poderia rodar em IoT. Tá, exagerei apenas para mostrar o quanto pensar dentro da mesma caixa é tão anti-inovação.
Agora, voltando um pouco para o modelo Website. Até bem pouco tempo éramos felizes com os aplicativos monolíticos em 3 camadas (vulgo MVC). De repente o Rest se tornou um padrão, surgiram algumas APIs (pelo Amor de Deus, API é documento) ensinando e gerenciando como consumir serviços, e todo mundo começou a dizer que Serviço é API. Vamos com calma, API, antes de mais nada é apenas uma Interface, e Interfaces ensinam como consumir recursos. E essa Interface surgiu para suprir a necessidade de escalar aplicações em MVC. Ou seja, as camadas se separaram em aplicações menores e independentes. O Model se separou do MVC e surgiu a Interface de Banco de Dados, permitindo que a aplicação consumisse quantos bancos de dados fossem possíveis e dos tipos que fossem necessários. Os Controllers também se separaram do MVC. Não fazia sentido replicar várias aplicações MVC quando replicar o Controller atendia a necessidade, permitindo mais acessos simultâneos, em diversas regiões do planeta. E aí a View também se separou do MVC, não só escalando mas permitindo o acesso a aplicação em todas as plataformas (web, desktop, mobile, IoT, etc). Ou seja, antes de pensarmos em API temos de pensar em Interface.
E, por aí vai. Vou dar uma parada pq minha Interface no momento é mobile e a memória já está na swap.
Concluindo, meu caro desenvolvedor, depois de pensar nesse assunto, você já está apto a conversar sobre Serviços? Gostaria de bater um papo com você.
