{"id":289,"date":"2016-01-07T15:04:59","date_gmt":"2016-01-07T17:04:59","guid":{"rendered":"https:\/\/blog.umbler.com\/?p=289"},"modified":"2018-12-06T11:24:58","modified_gmt":"2018-12-06T13:24:58","slug":"utilizando-microservices-na-umbler","status":"publish","type":"post","link":"https:\/\/blog.umbler.com\/br\/utilizando-microservices-na-umbler\/","title":{"rendered":"Utilizando MicroServices na Umbler"},"content":{"rendered":"

Ultimamente, muito tem se falado sobre microservices: um padr\u00e3o de arquitetura de software que se prop\u00f5e a dividir suas aplica\u00e7\u00f5es em um conjunto de servi\u00e7os independentes.
\n\u00c0 medida que voc\u00ea vai evoluindo um projeto, \u00e9 natural colocar todas as funcionalidades em um \u00fanico sistema. Estes sistemas unificados, que comp\u00f5em todos os requisitos de um projeto, s\u00e3o chamados de sistemas monol\u00edticos.<\/p>\n

Sistemas monol\u00edticos t\u00eam suas vantagens, j\u00e1 que todo o c\u00f3digo est\u00e1 em uma s\u00f3 base de dados e a atualiza\u00e7\u00e3o do software acontece com um \u00fanico deploy. Por\u00e9m, essas for\u00e7as tamb\u00e9m s\u00e3o fraquezas, j\u00e1 que sistemas monol\u00edticos tendem a ficar cada vez mais complexos.<\/p>\n

Bons desenvolvedores tendem a criar sistemas monol\u00edticos divididos em m\u00f3dulos, criando um belo Megazord.
\n\"Sistema
\nOutros n\u00e3o t\u00eam a mesma sorte e acabam criando no m\u00e1ximo um Frankenstein.
\n\"It\"
\nOs sistemas monol\u00edticos podem at\u00e9 funcionar bem, pelo menos no in\u00edcio do projeto, com execu\u00e7\u00e3o de testes automatizados e cria\u00e7\u00e3o de m\u00faltiplas inst\u00e2ncias simult\u00e2neas em produ\u00e7\u00e3o. Por\u00e9m, \u00a0a tend\u00eancia \u00e9 causar frustra\u00e7\u00f5es, \u00e0 medida que a complexidade aumenta \u00a0\u2013 os testes passam a levar horas e os deploys s\u00e3o postergados o m\u00e1ximo poss\u00edvel.<\/p>\n

Para contornar esses problemas, tem se apostado muito na cria\u00e7\u00e3o de microservices. Ao contr\u00e1rio das aplica\u00e7\u00f5es monol\u00edticas, a ideia aqui \u00e9 dividirmos nossos sistemas em diversos microservi\u00e7os, cada um com uma pequena responsabilidade. Nada muito novo, j\u00e1 que a Filosofia Unix<\/a> incentivava esse estilo de arquitetura desde os anos 1980, com a m\u00e1xima:<\/p>\n

“escreva programas que fa\u00e7am apenas uma coisa, mas que fa\u00e7am bem feito”.<\/p><\/blockquote>\n

O termo se popularizou nos \u00faltimos anos, pois a cria\u00e7\u00e3o de “micro-web-services” tornou-se extremamente f\u00e1cil. Frameworks para a cria\u00e7\u00e3o de APIs REST est\u00e3o dispon\u00edveis nas principais linguagens do mercado, fazendo do protocolo HTTP a escolha padr\u00e3o para a comunica\u00e7\u00e3o entre microservices, APIs disponibilizadas por grandes empresas do mercado, como Google, Twitter e Facebook, tamb\u00e9m contribu\u00edram para isso.<\/p>\n

E se cri\u00e1ssemos nossas pr\u00f3prias micro-api e microservices para determinadas funcionalidades de nossos pr\u00f3prios sistemas?<\/p><\/blockquote>\n

Os benef\u00edcios seriam grandes, j\u00e1 que atualiza\u00e7\u00f5es em sistema pequenos costumam ser mais tranquilas de serem realizadas, facilitando a implanta\u00e7\u00e3o, deploy, inicializa\u00e7\u00e3o, e escalabilidade de cada servi\u00e7o.<\/p>\n

Al\u00e9m disso, voc\u00ea poderia ter times pequenos focados em cada um dos servi\u00e7os, e novos times poderiam rapidamente se tornar produtivos, adaptando-se a um novo servi\u00e7o ou dando manuten\u00e7\u00e3o a um j\u00e1 existente.<\/p>\n

Como come\u00e7ar<\/h2>\n

Os microservices devem ser criados de acordo com funcionalidades do neg\u00f3cio que possam ser independentes, possuindo um deploy pr\u00f3prio.
\n\"Sistema
\nA granularidade vai de acordo com a necessidade. Tente notar partes do sistema que ficariam mais perform\u00e1ticas com uma linguagem ou um banco de dados diferente do utilizado atualmente.<\/p>\n

Algumas regrinhas que todo o microservice deve ter para garantir seu sucesso.<\/h3>\n