Contextualizando: de SOA a Microserviços

A cada dia no universo da tecnologia são criadas novas teorias e tendências para conseguir construir e manter um novo sistema e até mesmo um novo negócio. Você tem visto aqui no Blog da Sensedia muito sobre transformação digital como Open Inovation, e como exemplo eu te indico no post de Open Banking e até mesmo o que é realmente a transformação digital.Porém um assunto muito interessante e importante, do ponto de vista de inovação e transformação, é como o modelo arquitetural voltado a serviços (SOA) conseguiu abrir caminhos até uns dos modelos mais falados na atualidade, Microserviços.Vou abordar neste post a maioria dos assuntos que nos leva de SOA a Microserviços, passando é claro que por APIs e REST.

SOA de Verdade

Para falar em SOA, é impossível não citar Thomas Erl, pois com o livro “SOA: Princípios do Design de Serviços”, ele concretizou as 8 “regras” para definir um serviço, e são elas:

Serviços são REUTILIZÁVEIS

Esta talvez seja a característica que mais comumente está associada a SOA. Quanto mais genérico o Serviço maior a probabilidade de reutilização. Isto permite que a área de TI forneça respostas rápidas a novos requerimentos das áreas de negócio da empresa, desde que estes Serviços sejam definidos em conjunto: TI e área de negócios. Fica claro que um Serviço não é propriedade de uma equipe de desenvolvimento. O Serviço passa a ser um ativo da empresa.

Serviços compartilham um CONTRATO FORMAL

Todo serviço possui um “contrato” entre o requisitante e o provedor deste serviço. O “contrato”, informa o que o Serviço faz e como se comunica (o que deve receber e o que deve entregar).Desnecessário dizer que a empresa deve definir seus padrões de descrição e que isto requer muita disciplina.

Serviços possuem BAIXO ACOPLAMENTO

O acoplamento se refere a uma medida de dependência. Um baixo acoplamento significa que implementações específicas de um Serviço podem ser substituídas, modificadas e evoluídas sem que os consumidores deste Serviço sintam qualquer descontinuidade. Fica claro que Serviços não devem expressar a lógica (regras) de negócio.

Serviços ABSTRAEM A LÓGICA

Serviços são como “caixas pretas”, o que significa que a lógica não precisa nem deve ser exposta, simplificando o contrato formal. Guardando os detalhes também permite que possamos modificar a lógica evoluindo-a ao longo do tempo sem comprometer as “obrigações” do Serviço publicadas em seu contrato formal.

Serviços são CAPAZES DE SE COMPOR

Separar um grande problema em vários pequenos não é uma novidade. Este mesmo princípio pode ser utilizado na construção dos Serviços. Assim, um Serviço pode “chamar” outro(s) para executar a sua tarefa. A composição também é uma forma de reutilização.

Serviços são AUTÔNOMOS

Autonomia significa a capacidade de se auto-governar. Um Serviço autônomo é aquele que independe de um elemento externo para executar sua lógica.

Serviços evitam ALOCAÇÃO DE RECURSOS por longos períodos

Os serviços evitam informação de Estado.Devido ao fato de que um Serviço será reutilizado, deve-se tomar o cuidado de não se criar muitas instâncias deste Serviço onerando a infra-estrutura. Isto significa que para um Serviço ter disponibilidade, ele deve evitar reter informações específicas a uma determinada atividade.

Serviços devem possuir a CAPACIDADE DE SEREM DESCOBERTOS

Ou seja, estamos falando de Visibilidade.Um contrato formal bem descrito e padronizado evita que novos requerimentos resultem em Serviços redundantes. Além disto a arquitetura deve prover mecanismos que facilitem o descobrimento dos Serviços através de Diretórios e Registros.

E o que NÃO é SOA?

Para reforçar a definição de SOA, cabe deixar explícito o que não faz parte desse conceito.SOA não é:

• uma tecnologia. SOA é mais baseada em logística e conceitos e menos em ferramentas;
• um produto, portanto não é possível comprar SOA;
• WebServices, XML e BPM. Eles estõ são relacionados no mundo SOA, mas são distintos no mundo de TI. Portanto: SOA != WebServices != XML != BPM

Entendendo SOA no Dia-a-Dia

Eu gostaria de fazer uma pequena analogia para a melhor compreensão de SOA, com o nosso dia-a-dia.Então, imagine que você é um aplicativo, e precisa usar serviços para conseguir cumprir suas tarefas diárias. Fique tranquilo, vou exemplificar.Todos os dias, você acorda pela manhã e vai até a padaria tomar o seu café da manhã, neste momento está utilizando um serviço. O serviço de café da manhã da padaria.Mais tarde neste mesmo dia, é necessário lavar suas roupas, então você utiliza mais um serviço disponível, o da lavanderia e assim por diante.Por outro lado, observe o exemplo de serviço que não segue padrões de forma correta: imagine que na padaria é possível comer e lavar roupa, ou seja, o serviço não é específico e nem atua em apenas um escopo.Bom, em modos gerais e extremamente simplistas, isso é SOA. São serviços independentes que compõe um sistema, porém podem ser consumidos por outros serviços de forma simples, rápida e muito bem gerenciada, fazendo com que todas as transformações necessárias para que os serviços se comuniquem sem complicações.

A Governança SOA

Um ponto muito interessante de falar é sobre a Governança dentro de SOA. Especificamente, já temos um artigo aqui no Blog sobre esse assunto, mas é sempre interessante retomá-lo.Certo, então o que seria isso? Governança é um conjunto de pessoas, políticas e até mesmo processos que irão garantir que a sua estratégia SOA seja implementada e tenha sucesso.Algumas vantagens que a Governança traz:

• Possibilita pesquisa e descoberta de serviços promovendo o reuso;
• Evita qualquer tipo de duplicidade e aumenta o entrosamento entre projetos;
• Faz com que a análise de impacto seja realizada de maneira integra;
• Mantem e garante padrões arquiteturais;
• Mede o sucesso da estratégia SOA em sua organização.

Ok, agora como levar de SOA a Microserviços?

Bom, agora que já conhece SOA, vamos trabalhar um pouco de como você consegue realizar a orquestração necessária dos seus monolíticos para esta arquitetura.Com a necessidade de fazer o desacoplamento de um sistema monolítico em serviços especializados, o qual depende apenas do time que está implementando, foi criada uma necessidade de conseguir realizar as transformações e comunicações entre sistemas.Ou seja, queremos responder a pergunta: Qual a melhor forma de desmembrar um sistema monolítico em Microserviços?Essa orquestração dos serviços para que tudo funcione da melhor maneira possível pode ser realizada de algumas maneiras diferentes, como por exemplo em código. Assim, não é necessário uma ferramenta comprada para ter SOA de verdade.Porém a entrada dessas soluções "prontas" no mercado ajudou muito a pulverizar o estilo arquitetural nas empresas.Desta maneira entramos com um novo componente arquitetural que fará esse controle, o ESB.ESB, ou Enterprise Service Bus, é um Middleware que irá centralizar toda a integração em uma arquitetura SOA, realizando a orquestração dos formatos de saída e entrada de todos os serviços que estão "plugados" nele.Desta maneira fica muito mais amigável para um desenvolvedor desenhar e codificar as chamadas de acordo com a necessidade.Além disso, por ser uma camada que faz este controle você consegue realizar logs muito importantes para um possível problema que venha ocorrer e requisitar segurança em todas as chamadas, conseguindo proteger o seu backend.Em particular, nós já realizamos um Webinar ensinando a criar um ESB personalizado, usando um Gateway de APIs! Ou seja, não é necessário comprar uma solução cara e com potencial de travar seus serviços. Repensando o ESB, Arquitetura SPA usando APIs:

O Pivô das Mudanças, a Transformação Digital

Pensando em uma linha do tempo, o termo SOA foi adotado nos anos 2000, e nesse período em que todas as empresas começaram a se organizar para colocar as mudanças em ação, um outro termo e forma de venda começa a engatinhar, a transformação digital.A disrupção digital ainda está acontecendo em todos os mercados e para exemplificar isso é legal saber o real concorrente dos chicletes em filas de mercado: o celular.

Sim, parece difícil acreditar nisso não é mesmo? Mas vou te explicar por quê.A atenção dos seus consumidores é o que existe de mais valioso. As marcas estão realizando esse trabalho com tanta excelência na jornada digital que hoje vale mais a pena (para o consumidor) ficar atento a um aplicativo do que ao que está a sua volta, fisicamente. Afinal, esse ambiente virtual permite diversos tipos de distrações: promoções, produtos, trabalho e entretenimento com redes sociais ou jogos.Com a evolução da Internet como um todo, a criação de e-commerces e a possibilidade de interação entre Cliente e Servidor, criaram-se novos cenários no qual o desenvolvedor da comunidade pode ajudar e pulverizar o seu negócio.Se você acompanha o Blog da Sensedia, deve saber que a partir daqui estou falando do surgimento da ferramenta que acelera e permite a transformação digital, as APIs.Caso ainda não conheça os conceitos de API, indico que leia este post ou até mesmo a série que acompanha ele.Junto com as APIs, o protocolo HTTP e boas práticas RESTFul foram adotados para ganhar agilidade, praticidade e simplicidade nas integrações e exposição dos seus serviços/aplicações.Para entender um pouco melhor as boas práticas HTTP e REST eu indico este Webinar da Sensedia: Design de APIs RESTFul.Por que falar desses conceitos em um artigo que trata do tema "de SOA a Microserviços"? Bom, são exatamente os Microserviços que alavancaram a possibilidade de escalabilidade de forma ágil, e para que a arquitetura acompanhasse essa evolução algo precisava mudar.

O Próximo Passo

Em 2012 nasce o termo Microserviços (ou no original, em inglês, Microservices), uma nova tendência arquitetural que é considerado a evolução de SOA.Contudo, até 2014, Microserviços não era tão popular e nem algo tão definido. O grande “marco” na história dessa modelagem arquitetural foi este post escrito por Martin Fowler, no qual todas as características foram definidas, e até mesmo a ideia de que um Microserviço pode ser um produto por si só foi proposta e hoje muitas empresas estão trabalhando desta maneira.Agora, primeiramente é necessário entender o motivo desse novo desenho. Então vamos aos fatos:

1. A orientação à Serviços é fundamental, já que um Microserviço é nada mais nada menos que um Serviço completamente independente;
2. No modelo anterior, o banco de dados do serviço é relacional e transcendente a todos os serviços criados, e no novo modelo cada Microserviço possui o seu próprio banco de dados;
3. A orquestração de chamadas precisava de um ESB, que é caro e pesado, e agora com a implementação do REST, a necessidade de transformações e chamadas é simplificada;
4. A segurança e possibilidade de controle aumenta ainda mais, pois cada Microserviço possui o seu próprio API Gateway, que pode aplicar camadas de segurança para cada chamada e até mesmo possuir um trace muito mais completo na comunicação entre Serviços;
5. A exposição externa fica por conta de uma API Management Solution, que irá possuir todo o controle de desenvolvedores e aplicativos, além de segurança e todas as possibilidades para proteger o seu backend.

Para uma visão mais detalhada de Microseviços, além do post referência já mencionado, eu recomendo este Webinar sobre Microserviços, também feito aqui na Sensedia.Agora você deve estar pensando em como essa maravilha pode ser implementada! Vamos lá.

Como implementar Microserviços

Existem algumas maneiras de conseguir chegar no produto final: seu Backend totalmente fragmentado em Microserviços. Vou dar alguns exemplos de como começar a alterar a sua arquitetura direcionando para esse caminho.O primeiro modelo e mais adequado seria realizar a reconstrução do backend já com a arquitetura adequada. Porém, sei que para uma grande empresa, este tipo de abordagem é inadequado pelo investimento já realizado em todos os seus serviços criados e pela complexidade de realizar uma tarefa dessas.Por esse motivo, acredito que é possível utilizar algumas estratégias que direcionam para um futuro visando Microserviços e já direcionando o backend para o futuro.Então, vou começar a falar do segundo modelo.Para isso, primeiramente é necessário criar um API Front, ou seja, uma pequena camada na frente dos seus serviços já implementados em SOA, para que a exposição passe a ser realizada em REST. Desta maneira, as transformações e orquestrações do ESB não serão mais necessários, já que agora é possível ter apenas uma ferramenta de API Management Suite para realizar este trabalho, ganhando em escalabilidade e facilidade de abrir estas APIs para a comunidade.Já a terceira opção é para as arquiteturas que ainda não conseguiram se desenhar para SOA.Para fazer isso, o primeiro passo é conseguir definir os serviços que compõe o seu monolítico, ou seja, criar um desenho que analise o projeto para o futuro. Neste ponto é super interessante usar o apoio de uma consultoria especializada em SOA e APIs, pois a visão de como decompor o backend ficará muito mais ampla e fácil.Em outras palavras, fazer o desenho de serviços sem uma visão especializada pode ser um desafio e tanto!Após este primeiro desenho, é necessário criar um API Front que atende o novo desenho. Esta camada então será responsável pela disruptura inicial de sua arquitetura, já que o consumo interno será realizado através das APIs expostas desse modo. Após isso, você terá mais tempo para conseguir realizar o refactory do seu backend já orientado a visão de serviços criada.Bom, estas são algumas das estratégias a serem adotadas para conseguir adotar o Agile Architecture, e se adaptar a evolução digital de maneira completa.

Vamos bater um papo?

Tenho certeza que este universo está sendo muito falado na sua empresa.Não seria por menos: Microserviços está na boca de todos e a dúvida de como ele surgiu e como pode ser alcançado é sempre um debate interessante.A Sensedia tem uma poderosa plataforma de API Management e estamos à disposição para discutir e te ajudar a abrir portas ao caminho da arquitetura de Microserviços.Então, por favor fique à vontade para entrar em contato! Vamos adorar conversar sobre esse assunto e sugerir algumas abordagens para sua empresa. Confira nossos clientes e entre em contato: