Olá, como vai você?

Bom, embora eu tenha citado Microservices nos posts Oragon Architecture – Application Hosting e Roadmap da Reestruturação do Oragon Architecture, acho que é hora de entrar um pouco no detalhe do que vem a ser este “novo velho mundo”.

Bom, às vésperas de lançar o projeto Oragon Aaron, onde encontramos o Oragon Architecture Application Server destinado a endereçar diversos aspectos de uma arquitetura baseada em microservices, li um artigo interessante de um pessoal que sigo há pouco tempo. O highscalability.com é um excelente site para quem quer estar antenado nas tendências de escalabilidade e cloud. Em 8/Abril saiu um artigo chamado “Microservices – Not A Free Lunch!” cujo pelo título já temos um overview do que vem pela frente de quem pretende usar esse desenho de arquitetura.

Antes de falarmos propriamente de Microservices, precisamos definir, e nisso o Fowler fez muito bem.

Introdução

“Microservices” – mais um novo termo nas ruas lotadas da arquitetura de software. Embora a nossa inclinação natural é passar por essas coisas com um olhar de desprezo, essa terminologia descreve um estilo de sistemas de software que está se tornando cada vez mais e mais atraente. Temos visto muitos projetos usando este estilo nos últimos anos, e os resultados até agora têm sido positivos, tanto assim que, para muitos de nossos colegas isso está se tornando o estilo padrão para a construção de aplicações corporativas. Infelizmente, no entanto, não há muita informação que descreve o que o estilo Microservice é e como fazê-lo.

Overview

O termo “Microservice Architecture” surgiu nos últimos anos para descrever uma maneira particular de conceber aplicações de software como suítes de serviços independentemente implementáveis. Embora não exista uma definição precisa desse estilo arquitetônico, há certas características comuns ao redor organização em torno capacidade de negócios, implantação automatizada, inteligência nos pontos de extremidade e controle descentralizado de idiomas e dados.

Em suma, o estilo arquitetônico Microservice [1] é uma abordagem para o desenvolvimento de uma única aplicação como um conjunto de pequenos serviços, cada um rodando em seu próprio processo e comunicar-se com os mecanismos leves, muitas vezes, uma API de recursos HTTP. Estes serviços são construídos em torno de capacidades de negócios e independentemente implementável por máquinas implantação totalmente automatizado. Há um mínimo gerenciamento centralizado destes serviços, que podem ser escritas em diferentes linguagens de programação e utilizar diferentes tecnologias de armazenamento de dados

Consiste na quebra de grandes serviços, em serviços menores, autônomos, completamente isolados e descentralizados. Vale lembrar que o padrão nasce de um senso comum, da comunidade, e não da publicação do Fowler. Fowler tem papel importante, encontrando e documentando esse padrão, e formato de post.

Há uma infinidade de padrões úteis, e relevantes que devemos conhecer, pois são úteis a qualquer design de serviços. Outros, são extremamente específicos, dependentes de ferramentas complexas, e muitas vezes não se justificam, dada a dimensão dos seus serviços ou parque de serviços.

Em 2011, pude conduzir uma arquitetura, que hoje poderia ser facilmente chamada de um monolito escalável para os Sistemas Internos da BRQ. Muitas tarefas que no passado faziam parte do fluxo de negócio das aplicações, passaram a ser implementadas em serviços síncronos e assíncronos. Ao olharmos com maior riqueza de detalhes para a implementação, vemos serviços windows, hospedados em servidores windows, respondendo aos mais variados tipos de tarefas, desde consumo de filas para envio de email, até provisionamento de contas de usuários. Naquela época, minha intenção não era adotar um padrão qualquer, mas prover uma total abstração entre desenvolvimento e estratégia de deploy. Nesse aspecto, muito do que desenvolvíamos inline, tornaria, mais tarde, serviço, apenas com mudanças específicas nas configurações do Spring.Net.

Esse modelo de independência é visível desde 2006, quando tive meus primeiros contatos com o Spring.Net. Naquela época, WCF ainda não existia, estávamos sobre o framework 2.0 mas o Spring.Net já disponibilizava uma série de implementações que abstraiam completamente a estratégia de deploy de serviços. WebServices SOAP (ou ASMX se preferir), Enterprise Services (ou COM+), .Net Remoting (esse não tem outro nome, talvez conheça como Marshalling).

Como podem notar, padrões não tem um pai definido, tem apenas um documentador. Os padrões nascem do senso comum de que podemos melhorar caminhando em determinada direção. Muitas vezes encontramos os mesmos padrões, no senso etimológico de ‘padrão’, e anos mais tarde, vemos que aquele design, poderia facilmente se enquadrar em um estilo, agora conhecido e catalogado. Como qualquer padrão de projeto,  é resultado de inúmeras iniciativas na mesma direção, naturalmente, cada uma com sua peculiaridade, mas ainda mantendo algo forte, em comum.

No artigo da High Scalability, Benjamin Wootton fala das dificuldades e necessidades inerentes à utilização de microservices. E é muito interessante ver que compartilhamos ideias e conceitos a respeito de como proceder com as soluções.

Fico muito feliz de saber que mesmo isolado aqui na terra de Arariboia, um tanto atolado com projetos, família, saúde e afins, possa compartilhar das mesmas ideias de uns loucos do outro lado do mundo. Gera algum tipo de conforto, já que do lado de cá, as vezes vejo as pessoas com cara de interrogação, perguntando muitas vezes “pra que”, “por que”, com um ar que me faz sentir-me mais maluco do que eu já sou! Ou pelo menos mais do que eu acho que sou!

Em adição, temos aqui uma apresentação da ThoughtWorks no SlideShare que é bem interessante.

Então é isso, espero que leia os dois artigos e a apresentação.

Para a galera do iMusica, que trabalha comigo no backoffice, esses artigos são bem interessantes e ajudam a explicar, melhor que eu, muito do que nós fazemos e vamos fazer.

Obrigado pela leitura, obrigado pela visita e até a próxima!!