Entenda a origem e os conceitos que estão por detrás do avanço da chamada "Economia das APIs" neste tutorial detalhado

Como a computação em nuvem muda todo o cenário de desenvolvimento de software

Introdução

No mundo atual, a interconexão de quase todos os computadores e muitos outros dispositivos (incluídos os smartphones e muitos outros dispositivos apelidados de 'inteligentes') é um fato corriqueiro.

Nesse cenário opera o chamado 'mundo digital', que inclui os fenômenos das redes sociais, do comércio eletrônico e vários outros.

Esse 'novo mundo' em construção apresenta um conjunto de ameaças e oportunidades para as empresas: a estratégia de cada uma delas determinará o efeito que sofrerão.

Já há várias décadas um ex-presidente do Citibank afirmou que "a informação a respeito do dinheiro ficou quase tão importante quanto o dinheiro propriamente dito". Nos bancos de hoje em dia, sequer existe dinheiro mais: seu saldo bancário é apenas uma informação.

A frase anterior pode ser generalizada substituindo a palavra 'dinheiro' pelo produto ou serviço de qualquer empresa: a informação a respeito do que cada empresa produz é atualmente tão ou mais importante para a perenidade da empresa do que aquilo que ela entrega a seus clientes.

Devemos somar a este fato um fenômeno adicional, chamado de 'software comendo o mundo' pelo criador do Netscape, onde iniciativas empresariais de base tecnológica de fato já transformaram a lógica empresarial de outros segmentos de atividade econômica. O exemplo mais recente a ocupar o noticiário é o impacto do Uber sobre os taxistas no mundo todo.

Porém, esse fenômeno vem se desenvolvendo há bastante tempo: grandes portais globais de aluguel de carros, reservas de salas, reservas de hotéis e passagens aéreas vem redefinindo a comercialização de serviços turísticos (com a gradual extinção do agente de viagens). Analogamente, o sistema de anúncios do Google vem redefinindo o setor de publicidade; o AirBNB vem redefinindo o setor de locação de imóveis; a Amazon age para redefinir o setor de varejo; etc.

Neste sentido, veja o FastSalas->(www.fastsalas.com )

As consequências deste fenômeno se aplicam, portanto, igualmente aos tradicionais produtores de serviços de Tecnologia da Informação, e aos seus consumidores (as empresas chamadas pelos primeiros de 'clientes'): se a informação é tão ou mais importante do que a oferta das empresas, então a disponibilização dessa informação para fora dos limites dos sistemas tradicionais das empresas (que operam em ambientes fechados e controlados) pode criar novas oportunidades de negócios, novos modelos e canais de vendas para qualquer empresa.

É por isso que grandes empresas de consultoria, focadas nas grandes corporações, já publicaram previsões como esta: segundo o Gartner, por exemplo, 75% das mil maiores empresas do planeta devem oferecer acesso a seus sistemas internos, até o ano 2017, por meio de APIs públicas, acessíveis à uma comunidade de desenvolvedores de software externos a essas empresas.

Esse acesso, batizado de 'Economia das APIs', pode ser definido como a troca de recursos de TI entre as empresas, que disponibilizam seus recursos internos a um ecosistema de desenvolvedores externos por meio da Internet, com base em protocolos que chamamos de APIs, para produzir novos recursos, serviços e produtos de TI.

Esse movimento tem potencial para transformar todas as empresas, de qualquer setor da economia, em fornecedores de TI, na avaliação de alguns especialistas.

Porém, esse tipo de iniciativa possui uma série de desafios (p.ex. de gestão e tecnológicos, como a segurança) e exige novas arquiteturas e soluções, descritas a seguir.

Arquiteturas de Software

Vamos nos concentrar agora nas consequências dessa necessidade para a arquitetura dos softwares envolvidos.

O modelo mais simples de arquitetura de software é chamado de 'cliente-servidor'. Entretanto, é necessário tomar cuidado para não associar este nome exclusivamente com as aplicações criadas na era do downsizing dos mainframes, que operavam exclusivamente em ambiente local.

Usamos o nome 'cliente-servidor' para designar qualquer arquitetura onde há apenas dois componentes de software: um deles está instalado em um ambiente acessível ao usuário final, enquanto o outro está instalado em um servidor. Ambos componentes se comunicam para atingir os objetivos propostos, seja através de uma rede local, redes privadas de longo alcance ou da Internet.

Assim, quando um usuário utiliza um browser para 'navegar' na Web, o servidor Web e o browser constituem um exemplo de uso desta arquitetura. Esta mesma arquitetura é utilizada por muitos softwares comercializados como serviço (no modelo conhecido como 'Software as a Service', ou SaaS).

Da mesma forma, um app desenvolvido para plataformas móveis pode ser parte de uma arquitetura 'cliente-servidor', se ele se comunica com um único servidor para entregar os serviços a que se propõe aos usuários.

O ponto central a reconhecer é que no mundo da economia das APIs esta arquitetura é inadequada, exceto para as soluções mais simples: se o servidor que a aplicação deve acessar é um servidor de missão crítica (p.ex. o servidor do sistema de ERP da empresa, o servidor que gerencia contas de usuários - financeiras ou de outro tipo - ou um servidor de gestão de logística de um serviço de comércio eletrônico), então apenas a preocupação com a segurança e escalabilidade do servidor apresentam problemas.

Em primeiro lugar, ao conectar um servidor já existente por meio de APIs ao mundo da computação em nuvem, o número potencial de usuários que terão acesso ao servidor será muito maior do que o maior número de usuários imaginados pela maioria dos projetistas do software destes servidores quando os sistemas foram desenvolvidos originalmente. Este problema pode criar efeitos perversos sobre o funcionamento do servidor, análogos aos ataques de 'Denial of Service', conhecidos como 'DOS' na Web.

Em segundo lugar, toda arquitetura cliente-servidor que execute com algum nível de segurança envolve a inclusão de senhas no componente do lado do cliente para validar os acessos ao servidor (por exemplo, a senha da base de dados no servidor que será utilizada pela solução). Ao incluir estas senhas no componente cliente abre-se o risco de que ela seja usada indevidamente por 'hackers' que se dediquem a localizar elas dentro do componente, e passem a usá-la para finalidades 'não planejadas'.

Finalmente, se almejamos que nossas novas soluções no ambiente de nuvem de fato exijam pagamentos por parte dos usuários que sejam proporcionais ao uso efetivo dos sistemas, no modelo chamado 'on demand' (no lugar de valores mensais fixos, ou calculados sem levar em conta o uso efetivo dos servidores), o acesso direto aos servidores de missão crítica diretamente pelas soluções ainda imporia a cada uma delas os processos de cobrança (ou 'billing').

Segurança de acesso, proteção contra ataques DOS e serviços de cobrança, entretanto, são alguns exemplos de necessidades comuns a qualquer solução a ser implementada neste novo ambiente.

Concluímos, portanto, que para que estas novas soluções possam ser desenvolvidas com custos viáveis e operar de forma satisfatória, é indispensável usarmos arquiteturas de software que envolvam ao menos três camadas: além do componente cliente, na mão do usuário, e do servidor, é necessário dispor de ao menos uma camada intermediária.

Na próxima parte desta série de artigos apresentaremos exemplos concretos de soluções deste tipo.

Exemplos de soluções baseadas em APIs

Vamos agora ilustrar esses conceitos com exemplos concretos de soluções que já existem ou vem sendo projetadas para a nuvem.

A primeira categoria de exemplos resulta de transformar informação já existente nos servidores de missão crítica das empresas em uma nova fonte de receita (ou de melhoria do serviço aos clientes) para as empresas.

Exemplos incluídos nesta categoria incluem a disponibilização de dados de presença de atendentes ou vendedores aos clientes (que dependem dos sistemas de controle de acesso das empresas), a disponibilização de informação de estoques dos estabelecimentos comerciais aos consumidores até a comercialização de dados derivados da análise das bases de dados dos sistemas de missão crítica (instituições financeiras ou seguradoras podem mapear potenciais de consumo por região ou áreas 'negras' para sinistros de um determinado tipo e comercializar estas informações a terceiros).

Uma segunda categoria de soluções diz respeito à integração dos servidores de missão crítica com novos dispositivos e sistemas de comunicação. Algumas grandes empresas investiram em desenvolver aplicativos móveis para plataformas específicas, criando funcionalidade 'back-end' específica em seus servidores para atender as características dessa plataforma (p.ex. o iOS da Apple). Quando houver a decisão de criar aplicações móveis para novas plataformas móveis (p.ex. Android ou Windows Phone, ou alguma que ainda será lançada), esses investimentos terão que ser feitos novamente. Seria mais racional, do ponto de vista de custos, dispor de uma camada intermediária de acesso para essas plataformas móveis, que não precisasse ser refeita a cada mudança na tecnologia móvel.

Analogamente, o uso de canais de comunicação como Skype, WhatsApp ou Facebook de forma integrada com os sistemas corporativos gera o desafio de dispor de uma camada que evite, a cada novo tipo de plataforma de comunicação, reescrever a totalidade do código desses componentes.

Uma terceira categoria de exemplos é baseada na transformação de serviços baseados em servidores, dedicados a uma única aplicação, numa plataforma disponível para qualquer desenvolvedor.

Neste grupo se inclui, por exemplo, o Google Maps: na sua primeira versão era um serviço para uso exclusivo no browser, para consultar os mapas. A partir da disponibilização dos serviços do servidor do Google Maps como APIs, a funcionalidade de mapas passou a estar disponível para uso por qualquer aplicação.

Esta estratégia de 'plataformização' de serviços baseados em servidores também soluciona o dilema vivido por grandes empresas com amplas redes de parceiros comerciais independentes (como é o caso das montadoras de automóveis e suas redes de concessionárias). Para prestar um serviço uniforme e de qualidade ao cliente final, em vez de depender de um único fornecedor, elas obtêm vantagens publicando APIs correspondentes aos processos que devem ser uniformes, para que os fornecedores de sistemas para suas redes compitam entre eles para a criação de soluções cada vez melhores.

Uma quarta categoria de exemplos consiste em disponibilizar informação de grandes bases de dados de forma individual a consumidores interessados. Bancos pagam atualmente por acesso 'no atacado' a servidores pertencentes a empresas ditas de 'proteção ao crédito'. Analogamente, escritórios de advocacia assinam sistemas que detalham ocorrências jurídicas registradas nos sistemas dos tribunais.

Essas mesmas informações são de interesse de usuários individuais: qualquer cidadão envolvido numa transação financeira importante para sua vida pessoal (pense na compra ou aluguel de um imóvel ou veículo) gostaria de ter essas informações, mas apenas a respeito dos indivíduos ou empresas com as quais pretende transacionar.

Qualquer grande base de dados pode passar por este processo de transformação de consultas em grandes volumes para o modelo de consultas individuais. O software SuperBINA (www.superbina.com.br) é um exemplo de consultas individuais a uma base de dados originalmente construída para desenvolvimento de pesquisas de mercado.

Fonte: http://www.mbi.com.br/mbi/biblioteca/tutoriais/economia-apis-arquitetura-software-exemplo/