Em um mundo conectado, com cada vez mais soluções SaaS e PaaS. Há uma boa tendência e convergência em iniciativas que visam criar marketplaces de soluções. Compondo serviços dos mais variados estendendo as capacidades de nuvens públicas e privadas.
Ao mesmo tempo, nunca estivemos tão conectados e nunca conectamos tantos serviços a tantos provedores de serviços. Assim novas estratégias para a interoperabilidade nascem, não somente como meios de comunicação, mas protocolos que estabelecem formas de se contratar, alocar e desalocar recursos dinamicamente. Esse tipo de abordagem é facilmente visto em grandes provedores de cloud como Azure, Google, Amazon, que possuem seus próprios padrões. Iniciativas como a OSBAPI nascem para oferecer estratégias para o mercado comum, abrindo possibilidade para não somente players menores, mas inclusive provedores menores oferecerem aplicações das mais diversas. Em um mundo cada vez mais conectado, você talvez consiga disponibilizar seu módulo de CRM/ERM diretamente em um CPANEL like em algum pequeno player ao redor do globo.
Vamos começar com uma história:
Olhando sob a perspectiva de infraestrutura de aplicação. Imagina que você deseja oferecer RabbitMQ, Redis, um banco de dados, ou um serviço proprietário como um módulo de folha de pagamento de um ERP em um catálogo de terceiros. Imagine-se implementando uma API que devolva quais são os níveis de serviço/planos oferecidos como small, medium e large ou bronze, silver e gold.
Imagine que o cliente possa contratar/ativar um dos níveis de serviço. Então recebemos uma requisição em uma API e chamamos uma Azure Function que orquestra a criação dos recursos, alocando infraestrutura e provisionando cada elemento necessário para que o tenant rode isolado dos demais.
Uma vez com a infraestrutura no ar, você conecta seu edge service ao recurso, de forma a de fato começar a servir o novo recurso provisionado.
Após o uso, ao cliente desativar esse recurso, imagine que você receba um comando para realizar o dispose dessa infraestrutura. Entregando para o cliente somente a fatura pelo período consumido, e por sua vez, você, não mantendo alocação de recursos desnecessários enquanto não há ninguém pagando por isso.
É isso
Essa é a proposta do Open Service Broken API Specification. Extremamente poderoso em um modelo interconectado de aplicações e serviços. Oferece capacidades para quem trabalha com SaaS mas também quem tem skills para oferecer soluções do dia-a-dia de desenvolvimento como PaaS. Seja um RabbitMQ, Apache Kafka, Redis, Memcached, e qualquer outro serviço que possa vir à cabeça, inclusive bancos de dados, como MySQL, Oracle, PostgreSQL, SQL Server.
Da mesma forma como esse modelo pode servir a um uma rede de Módulos de ERP’s que trabalham sob especificações e protocolos abertos. Cada módulo de um vendor diferente.
0 comentários