Um dos pontos que está muito em evidência, é a utilização de micro serviços, onde tornaríamos nossos serviços o mais granular possível, e posteriormente os utilizaríamos, mas como conceito básico utilizaríamos serviços baseados em RestFull e Mensagens, mas como primordial acredito que seja a mudança na arquitetura de times.

Exitem estes dois Posts do Rafael Romão parte1, parte2, Recomendo muito a leitura, mas cada um possui um ponto de vista que seria melhor aproveitado em sua organização, e com isso acabei discordando de forma sadia do autor em alguns pontos.

Depois de alguns anos desenvolvendo integrações, e nos últimos meses utilizando talend, foi possível notar que o maior dos problema não esta no uso SOA, mas sim nas aplicações monolíticas.

Aplicações Monolíticas

O bom e velho MV(X), onde você pode trocar o X por qualquer topologia.

Onde ao lado esquerdo temos nossa aplicação monolítica, se utilizarmos o conceito do Java ou .NET, todas as vezes que tivermos que corrigir alguma funcionalidade em nossa API, terminaria tendo que gerar um Deploy total da aplicação com todos seus controles.

Isso não e algo de outro mundo se parar para analisar em integrações, pois sempre existem melhorias e correções entre sistemas, tente imaginar quanto tempo demoramos para gerar um deploy de aplicações, e se der algum problema a aplicação pode parar como um todo.

Conceito de MicroSevice

No conceito de MicroService, teria-se pequenos serviços, rodando de modo independente cada um com seu respectivo deploy, e extremamente especialista na implementações de suas API, a serem expostas a aplicações clientes, temos um video muito interessante como realizar este processo em Nodejs e ActiveMQ.

Sendo assim se for encontrado um problema no serviço, somente este trecho estaria comprometido, e assim que terminado sua correção e o deploy do mesmo, não teria que ser feito nada nos outros serviços, para que a aplicação como um todo volte a funcionar.

Mudanças em Times

Em aplicações monolíticas em sua maioria, a cada nova funcionalidade são envolvidas os seguintes times na equipe, Time de Designers, o Time de Desenvolvimentos e os Especialistas em banco de Dados, mesmo com equipes que utilizam ORM apenas, podemos utilizar a mesma ideia.

Onde no final temos uma entrega com todas as funcionalidades, mas este tipo de organização propicia a criação de aplicações monolíticas.

Uma excelente ideia é segmentar a equipe de desenvolvimento, onde cada equipe teria apenas uma parte do serviço a ser desenvolvido.

Alem disso os times são responsáveis não só pelo desenvolvimento, mas também por todo o processo de deploy, e deixar seu micro serviço funcionando, caso venha a ocorrerem bugs, os mesmos devem os corrigir, este processo já esta sendo utilizado pela Amazon “you build, you run it”.

Como cada equipe tem o controle sobre o seu Deploy, assim podem utilizar as tecnologias que mais se adere ao seu problema, como por exemplo existe um problema de real-time no lugar de Nodejs, estariam utilizando linguagens como Go e Elixir.

Testes

Como ponto primordial para micro serviços, está a necessidade de desenvolvermos testes automatizados e temporizados.

O que isso que dizer, que há necessidade de sistemas os quais analise e execute os micros serviços durantes alguns períodos, garantindo que se em algum momento apresentar problemas, o time responsável será notificado, assim podendo resolver os problemas quanto antes.

Descentralizando o banco de dados

Este acredito que seja o sonho de toda equipe de desenvolvimento, onde a medida que a maturidade dos times, estarão cada vez mais independentes podemos culminar na utilização de Polyglot Persistence.

Onde cada micro serviço teria seu tipo de banco, pois para alguns casos e melhor utilizarmos bancos como Mysql, Oracle e para outros mongoDB, Riak.

Sendo assim teríamos a melhor solução para cada caso, e deixando de seguir o raciocínio de que, para quem possui martelo topo parafuso é prego.

Ainda estou estudando sobre este assunto, pois existe o conceito de transactionless, pretendo chegar neste nível de maturidade ainda.

Conclusão

Acredito que o conceito organizacional que o microService está sugerindo seja, tão importante quanto seu desenvolvimento em si.

Algumas alterações como necessidade de cloud e AWS, e sistemas para analisar servições são primordiais os quais devem ser difundidos dentro da organização.

Alem da mudança do comportamento das equipes.

links

Post/Imagens : James Lewis

Post : http://www.javaworld.com/article/2683277/architecture-scalability/what-microservices-architecture-really-means.html

Projeto Interessante: https://github.com/WASdev/sample.netflixoss.wlp

Infra estrutura: https://www.youtube.com/watch?v=GaHzdqFithc

    william melo gueiros

    Written by

    www.linkedin.com/in/williamgueiros

    Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
    Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
    Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade