Um bom engenheiro sabe, ao construir uma casa, que deve se preocupar primeiro com as fundações. Afinal, sem elas, “a casa cai”. Entendemos que essa ideia também é aplicável para o desenvolvimento de software.

Há uma demanda crescente pela modernização de sistemas legados para que eles “rodem” na nuvem e que sejam otimizados para a mudança. Os eventos de tecnologia estão recheados de palestras contando a jornada de algumas empresas para transformação de aplicações monolíticas em microsserviços. Não faltam avisos de que o “caminho” é difícil. Entretanto, a pressão pela evolução parece estar superando, com muita frequência, o bom-senso.

Nossa recomendação é que, se vamos realmente iniciar uma jornada em direção a “cloud native applications”, nos preocupemos em construir fundações sólidas que sustentem essa iniciativa. Nessa direção, faz muito sentido a proposta de Bilgin Ibryam e Roland Huß de que há etapas claras que precisam ser cumpridas.

Eles indicam que há uma relação recorrente entre a adoção de contêineres (e nuvem) e o desenvolvimento de aplicações aderentes ao modelo de arquitetura baseado em microsserviços.

The most popular application architecture on the cloud-native platforms such as Kubernetes is the microservices style. This software development technique tackles software complexity through modularization of business capabilities and trading development complexity for operational complexity. – Bilgin Ibryam e Roland Huß

Mesmo que não concordemos com relação a granularidade (tamanho dos serviços), parece inquestionável que dificilmente fará sentido colocar uma aplicação monolítica para rodar, inteira, em um contêiner. 

Entendemos que o aumento da complexidade operacional, implicado pela decomposição em microsserviços, amenizado pela automação, só se justificará pela formação de unidades de trabalho menores concentradas em capabilities bem delimitadas do negócio.

É certo que sistemas decompostos em serviços tendem a ser mais complexos por sua dimensionalidade de solução (número de componentes na arquitetura). Por isso, não podem, de forma alguma, ter a complexidade ainda mais agravada por relações de interdependência. Dessa forma, mais uma vez em concordância com Bilgin Ibryam e Roland Huß, entendemos que [tweet]é fundamental, para microsserviços, adotar uma estratégia eficaz para decomposição da aplicação e uma das melhores abordagens conhecidas para isso é usando conceitos de DDD[/tweet].

Em qualquer caso, porém, de pouco adiantará ter unidades de desenvolvimento concentradas em capabilities do negócio se elas não forem capazes de produzir código de qualidade, que performe bem, distribuídos ou não em contêineres, consumindo apenas o necessário de recursos computacionais (como memória e rede). [tweet]A base de qualquer software bem feito é código bem escrito.[/tweet]

A jornada do “legado” para “cloud native application” fica assim evidente. Primeiro, precisamos ter times que saibam e que produzam código bem feito. Depois, precisamos que esses times consigam decompor as aplicações que desenvolvem e se estruturar a partir dos diversos contextos do negócio. Dessa forma, eles terão condições de combater a complexidade entregando componentes com interdependência mínima, consequentemente, em menos tempo. Para isso, irão utilizar técnicas e tecnologias modernas de automação e gestão do ambiente operacional.

Não há atalhos na jornada para “Cloud Native Applications”, mas a recompensa, em tempos de transformação digital, tem potencial de transformar os resultados do negócio.