Cada vez mais, o desenvolvimento de software atualmente tem se formado em torno de APIs. A razão para isso é muito simples: em vez de incorporar o produto de um fornecedor em uma aplicação, os desenvolvedores podem chamar uma API para consumir os serviços desse fornecedor. Eureka! Os desenvolvedores não precisam saber o que está respondendo às chamadas no backend; eles só precisam saber o que a API do fornecedor espera do código produzido e vice-versa.
Essa é uma inversão do modelo tradicional “open core” por trás de muitas estratégias de código aberto comercial para produtos de camada de nível enterprise. No open core, o core do produto é open source e, na edição enterprise, os fornecedores oferecem suporte a aprimoramentos em nível proprietário. Usando a abordagem API, o core do produto geralmente não é visível na nuvem, e a única maneira de acessá-lo é através da API.
Devido às APIs, temos vivenciado a diferenciação, o aprimoramento e o valor das edições enterprise, que têm migrado do centro para a periferia através de ferramentas, widgets e componentes. Estes podem ser de código fechado e/ou de código aberto, mas devemos ver mais fontes abertas na periferia, porque muitos fornecedores podem ganhar dinheiro apenas dando suporte ao core enquanto cobram por chamadas ou transações de API. Os dois melhores exemplos disso são o Twilio e o Stripe.
Uma maneira simples de entender esse cenário é compará-lo com um projeto de reforma de uma casa. Se quiser adicionar um banheiro novo a uma construção existente, terá que contratar um encanador e um empreiteiro. O encanador traz os tubos e os instala; o empreiteiro então constrói o banheiro em torno dos serviços providos pela instalação realizada pelo encanador.
A maioria das pessoas geralmente não se importam e por vezes nem sequer sabem de onde vêm esses tubos ou como eles se conectam ao sistema geral de encanamento. Nós simplesmente sabemos qual é nosso valor de entrada (input value) e qual é o nosso output value (água limpa). Sabemos que ambos precisam trabalhar e funcionar bem. Geralmente temos um acordo de nível de serviço aceito (SLA), que é uma expectativa de desempenho em torno de como esse encanamento deve funcionar. Ao acionarmos a descarga no banheiro, por exemplo, tudo deve desaparecer pelo encanamento (a API). E quando abrimos a torneira, a água potável precisa fluir com uma certa pressão (outro SLA para o desempenho da API).
O ponto aqui é que a única informação que precisamos é como a API (o encanamento) está sendo executada. Essa expectativa de desempenho é o SLA. Se projetamos um banheiro, passamos um tempo pensando no estilo da pia que desejamos comprar, no tipo de azulejo que desejamos instalar e no layout geral do novo banheiro. Esta “aparência” é o que agrega valor à casa. Ainda temos que pagar o encanador, mas seria uma loucura reinventar o encanamento em toda a casa a cada vez que pensar em fazer uma reforma no banheiro ou na cozinha. A inovação aqui mudou do centro (core) para a periferia (perimeter).
Isso é exatamente o que está acontecendo com o avanço das APIs no mercado. Os desenvolvedores estão percebendo que fornecer uma API de alto desempenho permite que eles possam se concentrar em serviços de valor agregado.
Vejamos alguns exemplos clássicos de software de nível empresarial em código aberto que usam o modelo open core:
Sugar: O Sugar CRM disponibiliza seu código fonte a clientes e parceiros. A edição enterprise do Sugar adiciona recursos específicos de nível empresarial, como relatórios aprimorados, melhor workflow e add-ons específicos de uma versão enterprise.
JasperSoft: A JasperSoft oferece relatórios abertos de business intelligence. Havia mais de 30.000 desenvolvedores registrados em sua comunidade nos idos de 2007. O Jasper também oferece SDKs e APIs RESTful para interagir com seu produto.
Odoo: O aplicativo para planejamento de recursos em nível empresarial Odoo, além de ser um ERP de código aberto, tornou-se uma alternativa muito popular ao software proprietário. Em torno de seu core aberto, o Odoo e um canal parceiro adicionaram centenas de diferentes módulos pagos que estendem os recursos do core aberto. A estrutura central contém cerca de 30 módulos, e existem milhares de módulos criados pela comunidade. Alguns deles são gratuitos, mas muitos outros são pagos e fechados.
ProcessMaker: O ProcessMaker oferece um software para gerenciamento de processos de negócios (BPM) de código aberto e também para workflow. Os desenvolvedores podem aprimorar a versão open source usando JavaScript e PHP. O ProcessMaker oferece uma série de plugins enterprise, incluindo a integração avançada do Active Directory, além de painéis e ferramentas aprimoradas para desenvolvedores.
Muitas empresas de software que adotaram o modelo open core o fizeram depois que um projeto inicial de código aberto ganhou tração significativa no mercado – por exemplo, milhões de downloads – e com isso elas formaram uma empresa para apoiar o desenvolvimento do código aberto. Gradualmente, essas empresas desenvolveram extensões e assinaturas baseadas em código aberto. À medida que os modelos de nuvem e de software como serviço (SaaS) tornaram-se mais proeminentes no início e no meio dos anos 2000, essas empresas desenvolveram versões na nuvem com base no open source core para diferenciar ainda mais sua oferta da versão de código aberto.
Talvez os dois maiores drivers para a adoção rápida de muitos produtos de código aberto fossem a licença de código aberto e o modelo de distribuição sem intermediários, através de sites de download como o SourceForge.
Esse modelo de código aberto comercial tornou-se generalizado no final dos anos 90 e início dos anos 2000. No entanto, uma mudança tem transformado a indústria: o crescimento das APIs. A API tornou-se cada vez mais importante por várias razões:
O software é mais complicado, deve se conectar a mais tipos de aplicativos e tem que escalonar para lidar com maiores demandas (em ordens de grandeza mesmo). Combine esses 3 fatores, e perceberá rapidamente porque o papel da API é tão importante. Os desenvolvedores não podem mais desenvolver uma base de código monolítico e permitir que outros aplicativos se conectem a ele; no entanto, eles querem e esperam manter o software e garantir que seja devidamente escalável. A API é a maneira mais clara e declarada de dois ou mais serviços interagirem uns com os outros. Ao saber como outro software espera trabalhar com seu software, é possível manter a qualidade e analisá-lo sob essa perspectiva/expectativa, caso o software cresça e evolua (ou não).
Em outro post aqui no blog, já comentamos sobre dicas simples para orientar testes de API bem sucedidos.
Para mais informações, acesse: open core vs open perimeter
Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.