O cenário global atual é marcado por mudanças constantes e incertezas, seja devido à crescente competição, às rápidas evoluções tecnológicas ou aos impactos da pandemia. As empresas precisam ser cada vez mais ágeis e adaptáveis para se manterem competitivas. Ter uma arquitetura de microserviços por si só não é suficiente. Vamos juntos analisar como aplicações combináveis estão se mostrando uma boa resposta a essa demanda.
O que são Composable Services?
O termo “programação modular” foi cunhado na década de 1960, como parte do movimento de programação estruturada. A programação modular é uma abordagem de desenvolvimento de software que se concentra em dividir um programa em módulos ou unidades independentes, cada um responsável por uma tarefa específica. Esses módulos podem ser reutilizados em outras partes do programa, ou até mesmo em outros projetos.
A programação modular teve origem na necessidade de desenvolver programas mais complexos e de maior escala. Antes de sua introdução, os programas eram escritos como uma única sequência de instruções, o que os tornava difíceis de entender, manter e escalar.
Os primeiros trabalhos na programação modular foram realizados por desenvolvedores de sistemas de computação, como John McCarthy e Niklaus Wirth. Eles foram os primeiros a propor a divisão de programas em módulos independentes e a cunhar o termo “programação modular”. Eles também desenvolveram as primeiras linguagens de programação que suportavam a programação modular, como ALGOL e Pascal.
Na década seguinte, o termo “Separation of Concerns” foi cunhado por Edsger W. Dijkstra em seu artigo intitulado “On the role of scientific thought” em 1974:
“Deixe-me tentar explicar a vocês, o que, a meu ver, é característico de todo pensamento inteligente. O fato é que alguém está disposto a estudar em profundidade um aspecto de um assunto de forma isolada de modo deliberado, o tempo todo sabendo que está se ocupando com apenas com um dos aspectos. Sabemos que um programa deve funcionar corretamente, então hoje podemos estudá-lo desse ponto de vista; também sabemos que deve ser eficiente e podemos estudar sua eficiência em outro dia, por assim dizer. (…) É o que às vezes chamei de “separation of concerns” (separação de preocupações), que, embora não seja perfeitamente possível, ainda é a única técnica que eu conheça disponível para ordenar eficazmente os pensamentos de alguém. É isso que quero dizer com “focar a atenção em um único aspecto”: não significa ignorar os outros aspectos, é apenas fazer jus ao fato de que, do ponto de vista desse aspecto, o outro é irrelevante.” (Tradução livre, grifo do autor)
Em engenharia de software, o princípio de modularidade implica que a arquitetura de software deve ser decomposta em módulos independentes caracterizados por alta coesão e baixo acoplamento. Embora o termo baixo acoplamento tenha sido introduzido ainda em 1974 (Wayne P. Stevens, Glenford J. Myers, and Larry L. Constantine. Structured Design. IBM Systems Journal, 13(2):115–139, 1974) e seja geralmente associado com arquitetura de software, suas origens podem ser traçadas já em 1967 (James D. Thompson. Organizations in Action: Social Science Bases of Administrative Theory. McGraw-Hill, New York, NY, June 1967).
O surgimento do SOA (Service Oriented Architecture)
Em meados dos anos 1990, com o surgimento da internet e a necessidade de integrar diferentes sistemas e plataformas surgiu a Service Oriented Architecture (SOA). SOA é uma arquitetura de software que se concentra em dividir um sistema em pequenos serviços independentes, cada um responsável por uma tarefa específica.
Porém, o SOA foi amplamente discutido pela primeira vez em 2001, quando um artigo intitulado “Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services” foi publicado por Thomas Erl.
SOA não é mais amplamente recomendado hoje em dia devido a sua complexidade e dificuldade de implementação. Além disso, as necessidades de negócios e as tecnologias mudaram, e outras abordagens, como a arquitetura de microsserviços, tornaram-se mais populares devido a sua capacidade de proporcionar escalabilidade e flexibilidade. SOA ainda tem seu lugar em alguns cenários específicos, mas na maioria das vezes, outras abordagens são consideradas melhores.
Composable Services
A Gartner começou a discutir a evolução da SOA ao introduzir o conceito de “Composable Services”. Segundo a Gartner, essas aplicações são construídas através da combinação de Packaged Business Capabilities (PBC), ou capacidades de negócio embaladas, como blocos de construção, para criar soluções personalizadas que podem ser facilmente adaptadas às necessidades específicas do negócio.
A medida que essas necessidades de negócio mudam, as aplicações de composição podem ser facilmente adaptadas e reutilizadas, sem a necessidade de construir um novo sistema do zero. O que também traz os seguintes benefícios como:
Redução de custos de desenvolvimento e implementação de aplicativos,
Aumento de agilidade e velocidade na implementação de soluções de negócios,
Facilidade de manutenção e atualização das aplicações,
Possibilidade de integração com outras tecnologias e sistemas existentes,
Aumento de flexibilidade e escalabilidade das aplicações.
Conclusão
Em resumo, os Composable Services representam uma evolução significativa na forma como desenvolvemos software. É importante notar que essa mudança na forma como desenvolvemos software não é uma novidade, ao longo do tempo, temos visto como a tecnologia tem evoluído e mudado a forma como as empresas e organizações lidam com a implementação de soluções de negócios. Aplicações de composição são apenas mais uma etapa na jornada contínua de inovação e melhoria no desenvolvimento de software.
Quer saber mais?
Há mais de 10 anos eu apoio empresas a tornarem suas aplicações mais resilientes, escaláveis e flexíveis. Se precisar de ajuda para fazer isso acontecer, me procure no LinkedIn!