Linguagens de programação são um tipo de plataforma de computação, porque ditam tudo o que se pode escrever em um computador, mas não precisam ser encaradas como limitantes, já que é possível escrever qualquer sistema de computação com elas. 

O conceito dos blocos de montar do tipo lego é ótimo para explicar isso, porque com um conjunto de peças de lego não há limites para construir o que a imaginação de uma pessoa possa ditar. O lego em si pode ser visto como limitante pelo fato de a pecinha padrão ser quadrada ou retangular? Talvez. Porém, mesmo com essa limitação de formatos, a partir de peças de lego dá para construir de nave espacial a sorveteria de bairro a castelo de princesa. A limitação não é restritiva no sentido de impedir que alguém crie o que desejar, do jeito que for. 

Quando se cria partindo de blocos maiores pré-fabricados feitos com lego, obviamente há uma restrição maior, mas essa restrição na verdade é positiva, já que, por ter resolvido parte do problema estrutural, há maior agilidade para seguir com o resto, que é o que afinal importa mais. Um construtor que parte de um chassis de barco básico feito de lego pode usá-lo em outros contextos, como montando uma réplica do Titanic, uma marina inteira ou uma batalha naval, e não precisa ficar perdendo tempo de toda vez ter que começar reconstruindo barcos para finalmente chegar aos cenários maiores que deseja erguer.

As plataformas também funcionam assim: são um sistema hierárquico em que se pode compor e chegar a um alto nível verticalizado para resolver problemas mais e mais complexos. Quando se fala em uma solução bem específica, como por exemplo uma voltada para formulações de torra para um fabricante de café, ela exige uma plataforma mais verticalizada; já a solução horizontal funciona para qualquer domínio, como uma plataforma em nuvem, que pode ser usada para desde aplicações alimentícias até sistemas médicos, de cartão de crédito ou de bibliotecas de universidades.  

Plataformas verticais e horizontais e inovação

Pensamento intencional de tecnologia e horizontes de longo prazo para resolver problemas que ainda não foram nem previstos, que estão “além da curva”, não são viáveis sem plataformas verticais e horizontais, que são essenciais para se obter agilidade de produtos em qualquer organização. 

Os blocos mais horizontais são os que preparam a empresa para as inovações sem perder tempo reinventando a roda. Com uma base pronta, não é necessário ter que recriar todo um arcabouço computacional toda vez que surge uma ideia de produto ou serviço, ou que há necessidade de uma atualização. Os módulos construídos em cima de plataformas são aqueles para resolver  problemas atuais ou assuntos específicos, como um novo sistema de Pix de uma companhia de cartões de crédito.

Ainda assim, esses módulos podem ser pensados para funcionar de maneira genérica, como um módulo de Pix que funcione para os vários negócios da empresa, desde integrações para microempresários que alugam prancha de surfe na praia a empresas maiores que precisam de soluções mais sofisticadas para pagar seus fornecedores.

As várias camadas de uma plataforma compõem abstrações, que vão servindo a diferentes usos. Mas elas precisam ser construídas com uma previsão de crescimento. Por exemplo, um time faz uma plataforma prevendo que poderá expandi-la para uma capacidade de até 10x do seu número de clientes. Quando ultrapassa essa escala, ela até funciona, porém não na sua eficiência máxima, e o tempo de resposta de alguns serviços pode não ser mais satisfatório. 

Com o número de clientes aumentando ainda mais, essa plataforma já não rende, vira uma carroça, e então é hora de ou melhorá-la ou de reescrevê-la, dependendo de como foi pensada a arquitetura da camada básica. É um processo mais complicado, porque não se quer afetar as camadas de cima e, ainda assim, é preciso mexer nas de baixo. E, se não fizer nada, a equipe terá que lidar com débitos técnicos que se acumularão cada vez mais.

Camadas de uma plataforma computacional

Fonte: Tecnologia Intencional

Ao contrário das peças de lego, que são de fácil encaixe umas nas outras, as interfaces computacionais são mais complexas, por isso requerem módulos que se comunicam bem entre si. Se a maneira como os encaixes ou interfaces entre os diferentes níveis de uma plataforma for mais perene, as mudanças são mais fáceis; se o design não foi concebido de uma maneira escalável, é necessário ficar repensando as abstrações a toda hora. Outro problema é que as abstrações podem chegar a falhar ou se tornar obsoletas.

E é justamente para evitar esse tipo de surpresa que engenheiros experientes, com sólido conhecimento técnico, são essenciais nas equipes das empresas de tecnologia. São essas pessoas que têm condição de melhor medir as vantagens e desvantagens de construir plataformas escaláveis e genéricas que, ao mesmo tempo, deem conta de necessidades presentes e futuras e tenham um custo aceitável. Não faz sentido, por exemplo, escrever uma plataforma que tenha capacidade para um volume de dados em escala global se a empresa com certeza só vai operar no Brasil. 

Com uma base pronta, não é necessário ter que recriar todo um arcabouço computacional toda vez que surge uma ideia de produto ou serviço, ou que há necessidade de uma atualização.

No livro sobre a Amazon Obsessão pelo cliente (Editora Citadel, 2023), Colin Bryar e Bill Carr contam como o catálogo de produtos da Amazon foi feito como um monólito. Com um sistema só, o do catálogo de produtos, qualquer coisa que precisasse ser modificada exigia mexer em algo que estava acoplado a uma estrutura fixa. À medida que a Amazon foi crescendo, muitos times precisavam alterar aquele sistema o tempo todo, e qualquer modificação arriscava deixá-lo instável, afetando a usabilidade dos clientes. Foi por isso que em determinado momento a empresa chegou à conclusão de que precisava romper o monólito em componentes menores. Foi um projeto de vários anos.

Claro que se uma empresa tivesse uma bola de cristal para acertar todas as abstrações de uma plataforma desde o começo seria muito simples. Como isso não existe, o que dá para fazer é realmente apostar intencionalmente em plataformas básicas, escaláveis e reutilizáveis, com peças intercambiáveis.

Marcus Fontoura
Sobre o autor

Marcus Fontoura

Marcus Fontoura é atualmente technical fellow na Microsoft e CTO do Azure Core. Iniciou a carreira na área de pesquisa da IBM em 2000, depois de concluir o doutorado na PUC-Rio e o pós-doutorado na Universidade de Princeton, nos Estados Unidos. Teve passagens pelo Yahoo! e pelo Google, e promoveu uma transformação digital na fintech brasileira StoneCo, onde atuou como CTO. É autor do livro Tecnologia Intencional e publisher da plataforma com o mesmo nome.