Já pensou nisso? Já considerou o impacto das novas tecnologias, tendências e panorama socioeconômico em suas aplicações? Este é um estudo que fazemos para recomendar novas formas de desenvolver e implementar seu software em um "novo normal".
#software #arquiteturadesoftware #dev #investimentos
O cenário atual e o futuro próximo
A pandemia não foi a responsável pelas mudanças no panorama socieconômico, embora tenha sido um catalizador. Já havia algumas tendências em andamento e as mudanças estavam acontecendo:- Centralizado por remoto;
- Local por nuvem;
- Estruturado por distribuído;
A agilidade necessária para se manterem competitivas diante da rápida evolução tecnológica, forçou as empresas a reverem conceitos, plataformas e tecnologias, simplificando operações, processos e infraestrutura.
Cada vez mais a ideia de economia de escala se valorizou. Diante da possibilidade de continuar investindo em construir catedrais, tanto de software como de hardware, aumentando mais ainda as "bolas de ferro" nas pernas da empresa, os gestores mais modernos começaram a repensar suas plataformas, investindo em agilidade e flexibilidade, em detrimento da estruturação e propriedade.
É claro que isso iria acontecer com as plataformas de desenvolvimento de software corporativo, como já falávamos há anos ("É hora de balançar a árvore") . A questão é que a pandemia acelerou todo esse processo ao forçar uma digitalização acelerada de serviços e negócios, por conta do isolamento social.
E isso veio para ficar! Embora algumas cidades e países tenham começado a reabrir suas lojas e atrações, o aumento de contaminações e o surgimento de novas "ondas" de Covid19 farão com que nada mais seja como antes, e que os esforços de digitalização e home office continuem assim.
E isso não deve mudar nos próximos 2 ou 3 anos.
A nova TI
Não se trata apenas de home office, mas de downsizing e rightsizing de tudo! Os provedores de Cloud Services devem ter sido os que mais lucraram com essa digitalização acelerada, pois as empresas precisavam de meios rápidos, seguros e baratos para expandir suas operações e se adaptarem ao novo panorama.
Eu diria que a pandemia acelerou em 5 anos esse processo inevitável.
Embora possa parecer marketing de Cloud Services, migrar para nuvem é uma excelente maneira de diminuir a "imobilização" da empresa, ou seja seu investimento em ativos imobilizados, como equipamentos, Centros de Dados etc.
Para uma empresa privada desenvolver um novo serviço, precisará de apoio da área de TI, mais especificamente:
- Sistemas aplicativos: Com prazo entre 6 meses e 1 ano;
- Recursos computacionais: Rede, servidores e storage, com prazo entre 30 e 90 dias;
- Treinamento: Capacitar os colaboradores, com prazo entre 1 e 3 meses;
E muitos destes gastos significarão imobilização de capital. Imaginemos a aquisição de servidores, discos e outros recursos. E temos outros custos, como: Contratação de pessoal de operação, aumento de link de transmissão de dados, de carga elétrica, reformas prediais etc.
Com os Cloud Services, é possível montar toda uma infraestrutura de TI em minutos, colocando-a no ar nesse mesmo tempo. Em vez de esperar 90 dias ou mais (compra, contratação, instalação etc) você colocar no ar em poucos minutos, e tem formas flexíveis de pagar, como "on demand" ou "reservadas".
Essas despesas passam de CAPEX (Capital Expenditures) para OPEX (Operational Expenditures), ou sejam passam a ser despesas e não investimentos.
Manter instalações próprias, chamadas de on premises, se tornará algo impensável nessa nova TI.
Novo ciclo de vida de aplicações
Mais do que nunca, as aplicações estarão ligadas ao ciclo socioeconômico das empresas, tornando-se mais voláteis e flexíveis. Há pouco tempo atrás, a cultura geral era de construir aplicações corporativas robustas, compostas por camadas de software muito bem integradas e estruturadas. Era algo feito para durar, para sobreviver ao crescimento esperado da demanda.
Me lembro bem de um sistema corporativo em que trabalhei há uns 4 anos, que era exatamente assim. Totalmente baseado na plataforma Java Enterprise Edition. Se tudo se mantivesse no mesmo ritmo o software duraria pelo menos uns 10 anos.
E o que aconteceu? Para começar, a Oracle, dona dos direitos da linguagem Java e desenvolvedora da plataforma Java Enterprise Edition, entregou a responsabilidade da mesma para a Eclipse Foundation, que passou a desenvolver a plataforma Jakarta EE.
E ai vem a decisão: O que fazer agora? Um sistema aplicativo gigantesco, com centenas de classes e pacotes, e milhares de linhas de código, altamente acopladas com a plataforma utilizada, pode ser facilmente migrado para uma nova plataforma? Quais são os riscos? E os custos? Todos os serviços necessários estarão disponíveis? Quanto tempo ainda resta, ou melhor, por quanto tempo é possível adiar essa migração?
Eu acho que é o fim das grandes plataformas corporativas de desenvolvimento.
Em menos de 4 anos, o ciclo de vida daquele grande aplicativo foi abruptamente encurtado. Um investimento para 10 anos, durou menos que a metade do tempo.
Software descartável
Eu sempre questionei o rumo que a programação orientada a objetos e os rígidos modelos e arquiteturas Java estavam tomando. Há alguns anos, eu li um artigo que me impressionou muito:
O autor fala das promessas da OOP e da sua adequação à realidade. Fala sobre os grandes problemas que criamos só para nos mantermos fiéis a uma filosofia de mais de 30 anos (sim, OOP tem mais de 30 anos!) Apesar de ter sido "inventada" nos anos 60, a OOP se popularizou nos anos 90, tornando-se o ÚNICO paradigma aceitável para desenvolvimento de software.
Assim como o sistema que eu citei, existe um vasto repositório de hierarquias de classes, embutido nas aplicações corporativas do mundo. A esmagadora maioria dos sistemas aplicativos foram e ainda são construídos com base na OOP, embora, nos últimos anos, tenham privilegiado Composição sobre Herança, o que achata um pouco as hierarquias, ainda se trata de OOP.
OOP gera alta Complexidade Acidental. Não acredita? É só comparar um código OOP com um semelhante, escrito em Progamação Funcional, por exemplo. Você não precisa criar um "framework" antes de escrever seu código. E a Programação Funcional garante um código enxuto e flexível, justamente o que precisamos neste momento.
O que eu quero dizer com "descartável"? É o seguinte: Você deveria fatorar seu sistema aplicativo até o ponto em que os componentes individuais sejam descartáveis, ou seja, possam ser substituídos em pouco tempo e com pouco esforço. Por que é assim que vai ser: Acabou de colocar o código no ar? É hora de escrever outro para substituí-lo.
Ok, pode ser que você ainda tenha algum apego ao passado e pense em todo o investimento feito naquelas belíssimas estruturas que criou ao longo do tempo, mas é necessário evitar a Síndrome do Comprometimento: Já que gastamos tanto para fazer assim, continuaremos da mesma forma.
O que eu quero dizer com "descartável"? É o seguinte: Você deveria fatorar seu sistema aplicativo até o ponto em que os componentes individuais sejam descartáveis, ou seja, possam ser substituídos em pouco tempo e com pouco esforço. Por que é assim que vai ser: Acabou de colocar o código no ar? É hora de escrever outro para substituí-lo.
Ok, pode ser que você ainda tenha algum apego ao passado e pense em todo o investimento feito naquelas belíssimas estruturas que criou ao longo do tempo, mas é necessário evitar a Síndrome do Comprometimento: Já que gastamos tanto para fazer assim, continuaremos da mesma forma.
E não estou só falando da OOP em si, mas de todos os pendurucalhos que orbitam em seu redor, como: ORM (Mapeamento Objeto-Relacional), por exemplo.
Mas, em vez de só falar mal, vou apontar um caminho para você desenvolver software de forma mais eficiente e adequada ao novo "normal".
1) Rapidez: A empresa tem que ser capaz de se reinventar em pouco tempo, em poucos dias;
2) Flexibilidade: Os processos da empresa deve ser capazes de operar com parceiros e condições em mutação;
3) Custo: A empresa deve evitar comprometer capital para realizar mudanças, já que serão mais constantes.
Não dá para esperar entre 3 e 6 meses para ter um novo servidor ou uma nova versão de um software. Mudar sua infraestrutura não deve implicar em imobilização de capital.
A infraestrutura de novas aplicações deve ser o mais leve possível e, de preferência, com custos sob demanda, ou seja, você paga pelo quanto usa. De acordo com essa premissa, hospedagens do tipo Serverless, como Function as a Service (FaaS) podem fazer toda a diferença. Há vários provedores de Cloud Service que oferecem hospedagem deste tipo, permitindo que você coloque sua função de negócio no ar rapidamente e sem qualquer decisão quanto à capacidade antecipada.
O software tem que ser desenvolvido para ter o menor Acoplamento possível, e cada função de negócio tem que ter a maior Coesão possível, que é consequência de seguirmos o Princípio da Responsabilidade Única, por exemplo.
Se cada módulo ou função de negócio tiver uma e somente uma responsabilidade, podemos também segregar a persistência de dados, indo para o domínio dos Microsserviços.
Cada função de negócio que você criar tem que ser totalmente independente da forma como será exposta. Alguns chamam isso de "Camada de protocolo". Se você vai expor com REST ou não, isso não importa. Crie uma casca REST (Wrapper) que invoque sua função, evitando qualquer código de negócio dentro dela. Tudo o que é de negócio fica dentro da função de negócio, e tudo o que é de infraestrutura e hospedagem, fica na casca.
Se for hospedar em como FaaS em um Cloud Provider, coloque todos os comandos de interface necessários na casca, evitando contaminar a função de negócio.
Obviamente, sua função de negócio deverá ser absolutamente Stateless sempre!
Estado de transação e fluxo de processamento devem ser externalizados, não fazendo parte do código das suas funções de negócio. Todos os Cloud Providers oferecem soluções para Orquestração ou Coreografia de workflows, que permitem canalizar e tratar eventos baseados em dados. Assim, você troca codificação por configuração, e torna seu sistema flexível o suficiente para se adaptar a vários provedores diferentes.
Escreva as funções de forma totalmente independente (incluindo a persistência) e poderá arrumá-las da maneira que necessitar, sem dependências que atrapalham a sua flexibilidade e aumentam o seu custo.
E por falar em persistência, esqueça aquelas bobagens de "Transação distribuída" e ORM. Na verdade, sua persistência nem precisa ser banco de dados Relacional. Use a persistência mais apropriada para cada função. O controle de transações pode ser feito com transações compensatórias, é só preparar cada função para isto e registrar as transações em um serviço separado.
Seu código poderá ser escrito em qualquer linguagem de programação, testado isoladamente ou em conjunto e de maneira automática. Até mesmo a instalação de novas versões (deploy) poderá ser feito com mecanismos de Entrega Contínua, automaticamente. Desfazer uma alteração também será fácil e possível.
Mas, em vez de só falar mal, vou apontar um caminho para você desenvolver software de forma mais eficiente e adequada ao novo "normal".
Premissas para a novo desenvolvimento de software
Todas as empresas estão se digitalizando! Tudo está indo para a Internet e até mobile, e não podemos assumir nada, pois tudo pode mudar em pouco tempo. Como sobreviver em um cenário destes?1) Rapidez: A empresa tem que ser capaz de se reinventar em pouco tempo, em poucos dias;
2) Flexibilidade: Os processos da empresa deve ser capazes de operar com parceiros e condições em mutação;
3) Custo: A empresa deve evitar comprometer capital para realizar mudanças, já que serão mais constantes.
Não dá para esperar entre 3 e 6 meses para ter um novo servidor ou uma nova versão de um software. Mudar sua infraestrutura não deve implicar em imobilização de capital.
A infraestrutura de novas aplicações deve ser o mais leve possível e, de preferência, com custos sob demanda, ou seja, você paga pelo quanto usa. De acordo com essa premissa, hospedagens do tipo Serverless, como Function as a Service (FaaS) podem fazer toda a diferença. Há vários provedores de Cloud Service que oferecem hospedagem deste tipo, permitindo que você coloque sua função de negócio no ar rapidamente e sem qualquer decisão quanto à capacidade antecipada.
O software tem que ser desenvolvido para ter o menor Acoplamento possível, e cada função de negócio tem que ter a maior Coesão possível, que é consequência de seguirmos o Princípio da Responsabilidade Única, por exemplo.
Se cada módulo ou função de negócio tiver uma e somente uma responsabilidade, podemos também segregar a persistência de dados, indo para o domínio dos Microsserviços.
Cada função de negócio que você criar tem que ser totalmente independente da forma como será exposta. Alguns chamam isso de "Camada de protocolo". Se você vai expor com REST ou não, isso não importa. Crie uma casca REST (Wrapper) que invoque sua função, evitando qualquer código de negócio dentro dela. Tudo o que é de negócio fica dentro da função de negócio, e tudo o que é de infraestrutura e hospedagem, fica na casca.
Se for hospedar em como FaaS em um Cloud Provider, coloque todos os comandos de interface necessários na casca, evitando contaminar a função de negócio.
Obviamente, sua função de negócio deverá ser absolutamente Stateless sempre!
Estado de transação e fluxo de processamento devem ser externalizados, não fazendo parte do código das suas funções de negócio. Todos os Cloud Providers oferecem soluções para Orquestração ou Coreografia de workflows, que permitem canalizar e tratar eventos baseados em dados. Assim, você troca codificação por configuração, e torna seu sistema flexível o suficiente para se adaptar a vários provedores diferentes.
Escreva as funções de forma totalmente independente (incluindo a persistência) e poderá arrumá-las da maneira que necessitar, sem dependências que atrapalham a sua flexibilidade e aumentam o seu custo.
E por falar em persistência, esqueça aquelas bobagens de "Transação distribuída" e ORM. Na verdade, sua persistência nem precisa ser banco de dados Relacional. Use a persistência mais apropriada para cada função. O controle de transações pode ser feito com transações compensatórias, é só preparar cada função para isto e registrar as transações em um serviço separado.
Seu código poderá ser escrito em qualquer linguagem de programação, testado isoladamente ou em conjunto e de maneira automática. Até mesmo a instalação de novas versões (deploy) poderá ser feito com mecanismos de Entrega Contínua, automaticamente. Desfazer uma alteração também será fácil e possível.
Nenhum comentário:
Postar um comentário