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
As vantagens da arquitetura de microserviços
A arquitetura de micro serviços divide o software em pequenos serviços independentes, permitindo maior eficiência, escalabilidade flexível e experimentação de novas tecnologias. Isso resulta em soluções de software mais eficientes e escaláveis, o que é uma vantagem competitiva para qualquer empresa.
Processo de transformação para arquitetura de software ágil
A arquitetura de software ágil é uma abordagem que se concentra em entregar valor ao cliente de...
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.
5 Passos para implementar o Outsourcing de TI
Neste blog post, apresentaremos 5 passos para implementar o outsourcing de TI e como a VMBears pode auxiliar os clientes nesse processo de implantação e acompanhamento, proporcionando melhores resultados para as empresas.
As vantagens da arquitetura de microserviços
A arquitetura de micro serviços divide o software em pequenos serviços independentes, permitindo maior eficiência, escalabilidade flexível e experimentação de novas tecnologias. Isso resulta em soluções de software mais eficientes e escaláveis, o que é uma vantagem competitiva para qualquer empresa.
Processo de transformação para arquitetura de software ágil
A arquitetura de software ágil é uma abordagem que se concentra em entregar valor ao cliente de maneira rápida e flexível. Ao implementar essa abordagem, as equipes de desenvolvimento podem criar software de alta qualidade de maneira mais eficiente e eficaz. Mas como...