LaaS: Lock-in as a Service

Compartilhe este artigo:

Uma história conhecida

Em meados de 1999, a Sun Microsystems então proprietária do Java SE, lança a primeira versão (1.2) do Java EE, o que consistia em um conjunto de especificações para a construção de aplicações “enterprise” e também para que fabricantes de softwares construissem runtimes compatíveis com essas especificações.

Já no segundo semestre de 2001 a IBM inicia e lidera uma avalanche de releases de servidores de Aplicação J2EE. Podemos incluir nessa lista Webpshere, Iplanet, WebLogic, BES e muitos outros; Estes produtos entregavam toda a infraestrutura de suporte e abstrações para solucionar problemas como persistência, Integrações, controle de transações, messageria, autenticação, autorização, concorrência, escalabilidade, alta disponibilidade e muitos outros.

O que não se notou ao longo dos anos é que esses mesmos produtos 100% aderentes às especificações escritas pela Sun também traziam consigo certas facilidades, as quais já naquela época tratavam-se de features, protocolos ou integrações com produtos proprietários que direcionavam nossas aplicações para um Lock-in(2) muito difícil de ser revertido na maioria das vezes. Além disso, é fato que muitos desses produtos eram uma ponte para a compra de plataformas de hardware que custavam uma fortuna.

Mea Maxima Culpa

Profissionais de T.I. um dia acreditaram que o especialista no negócio da empresa tinha papel apenas coadjuvante no processo de desenvolvimento do software. Não nos detivemos a dizer a esses valorosos profissionais como fazer seu trabalho, ensinando diariamente “o padre nosso ao vigário”. Desta forma o negócio das empresas foram conduzidos a adaptar-se ao software e não o contrário como deveria ser. Incorremos nesse erro por décadas e quando descobrimos, já era tarde demais para voltar atrás.

Os mercados foram mudando, a concorrência aumentando, o time-to-market cada vez mais acirrado e com isso profissionais de T.I. acordaram frente à maior “sinuca de bico” de suas carreiras – Como acompanhar a enorme velocidade de mudança dos mercados e produtos da empresa com a agilidade necessária, mantendo qualidade e se possível diminuindo custos?

Muitos sistemas que estão hoje em produção são verdadeiros monstrengos, lentos, caros e pesados de se manter, enquanto estamos falando de mudanças que precisam ser entregues semanalmente, sabemos que o rollout de um monolito (1) pode levar mais de dois dias para ser finalizado.

O advento da computação em nuvem nos fez sonhar com soluções para esses problemas e aplicações mais leves, fáceis de manter, pequenas, rápidas, baratas e por fim, ágeis. Com isso, mover nosso portfólio de aplicações para nuvens públicas e privadas passou a ser a nova paixão do mercado de tecnologia.

Mais do mesmo

Nos dias atuais, sempre ouvimos falar que um ou outro time desenvolveu uma prova de conceito na AWS – Amazon Web Service – e que as áreas de negócio vão agora patrocinar essa iniciativa para que o processo vá em frente.

A parte mais comum nessas histórias é exatamente a que fala do tempo recorde em que as coisas foram feitas. Frente a resultados impressionantes, desenvolvedores e arquitetos passam rapidamente a influenciar o resto das áreas a mergulhar de cabeça no mundo das nuvens.

Outro fato importante é que muitas vezes essas iniciativas brotam de dentro de reuniões executivas. É neste momento que o sonho de mover tudo para a nuvem pode tornar-se um pesadelo se não o fizermos com estratégia e parcimônia.

Recebemos quase que diariamente ofertas para que mudemos nosso portfólio e infraestruturas físicas para dentro de provedores do tipo SaaS, PaaS ou IaaS “onde todos os nossos problemas serão resolvidos”. E se aliadas a essas ofertas estamos ansiosos por apresentar resultados aos nossos patrocinadores, nos colocamos cegos em relação aos potenciais riscos da tomada de decisão sem um planejamento adequado.

O que queremos?

Porque desejamos mover nossos portfólios de aplicações para a nuvem? Os principais motivos dos executivos para essa iniciativa são: O que queremos?

Atender às demandas das áreas de negócio com maior agilidade;
A diminuição dos custos operacionais;
Aumento de produtividade;
Escalabilidade horizontal;
Menor downtime geral.

Esses são os primeiros benefícios que nos surgem quando pensamos em transformar nosso parque tecnológico, mas o que quase nunca nos passa pela cabeça é a palavra LIBERDADE.

Ao contratarmos serviços e produtos é importante permanecermos livres para escolher e mudar nossos fornecedores e ferramentas conforme nossas necessidades de negócio principalmente quando desejamos adotar estratégias de Multicloud.

Conclusões Importantes

O ritmo frenético de entregas imposto pelos mercados e seu time-to-market obriga a cada dia mais e mais empresas a modernizarem seus portfólios de aplicações;
As antigas arquiteturas de infraestrutura e de software não mais atendem as necessidades dos mercados;
A modernização de nosso parque computacional deve levar em conta o conceito de LIBERDADE;
Nossas estratégias para arquiteturas em nuvem devem priorizar o modelo de multicloud;
Mover aplicações para dentro de provedores de Cloud, sem realizar adequações para usufruir da nova infraestrutura, não resolve o problema;
Quando desenhamos ou modernizamos nossas aplicações para a nuvem, devemos estar atentos para evitar lockins e futuras dores com respeito à troca de fornecedores;
No que tange o uso de clouds públicas e privadas, a nova onda de lockins não mais parte em meio aos times de infraestrutura, mas sim como decisões de arquitetos e desenvolvedores;
Devemos sempre que possível procurar evitar o uso de serviços proprietários sem similares open sources oferecidos pelos grandes provedores de nuvems;
Existem 3 principais estratégias na hora de mover nossos monolitos para a nuvem: Rehost, Refactory e Replatform e entre elas, Replatform é a que nos traz o melhor custo benefício na maioria dos caso;
Uma das melhores estratégias para modernizar aplicações J2EE será convertê-las para applicações SpringBoot “bootificadas” com o mínimo de alteração em código fonte possível.