LaaS: Lock-in as a Service

Escrito por:

Publicado em:

dezembro 9, 2020

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. 

    Outros artigos

    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.

    Outros artigos

    Acompanhe as útimas novidades.

    LINGUAGENS DE PROGRAMAÇÃO: JAVA

    LINGUAGENS DE PROGRAMAÇÃO: JAVA

    A linguagem de programação Java foi desenvolvida nos anos 90 pela Sun e hoje é uma das linguagens de programação mais utilizada no mundo, conforme Revista Exame¹. Possui uma das maiores comunidades do mundo, além de ser a principal linguagem de desenvolvimento de um...

    ler mais

    COMO NASCE UMA SOLUÇÃO E PRODUTO DIGITAL NA PRÁTICA?

    Você sabe como nasce e são construídos os produtos digitais? Desde a conceitualização do problema de negócio, até os rituais de ideação, discussão de solução tecnológica, arquitetura, monetização, você sabe como esses detalhes são definidos e nasce uma solução digital...

    ler mais
    Arquitetura de Microsserviços

    Arquitetura de Microsserviços

    A arquitetura de microsserviços permite que as aplicações sejam desmembradas em componentes mínimos e independentes. Este tipo de arquitetura valoriza a granularidade, a leveza e a capacidade de compartilhar processos semelhantes entre várias aplicações. A vantagem...

    ler mais
    Entrar em contato